ISO-IEC 20000 - Una Introducción.pdf

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


La Biblioteca de Gestión de Servicios de TI Libros de introducción, fundamentos y para profesionales • Foundations of IT Service Management based on ITIL® (versión 2, en árabe, chino, alemán, inglés, francés, italiano, japonés, coreano, holandés, portugués de Brasil y ruso; danés y español) • Foundations of IT Service Management based on ITIL® V3 (en inglés, holandés, alemán, italiano y español; ediciones en francés y japonés previstas para 2008) • IT Service Management - An Introduction (versión 3, en inglés) • IT Services Procurement based on ISPL - An Introduction (en holandés) • Project Management based on PRINCE2™ 2005 Edition (en holandés, inglés y alemán) • Release & Control for IT Service Management, based on ITIL® - A Practitioner Guide (en inglés) • ISO/IEC 20000 - An Introduction (en inglés, portugués de Brasil; ediciones en japonés, chino, español y alemán previstas para 2008) Mejores prácticas en Gestión de Servicios de TI • IT Service Management - best practices, parte 1 (en holandés) • IT Service Management - best practices, parte 2 (en holandés) • IT Service Management - best practices, parte 3 (en holandés) • IT Service Management - best practices, parte 4 (en holandés) • IT Service Management - Global Best Practices, Volumen 1 (en inglés) Cuestiones e instrumentos de gestión • Metrics for IT Service Management (en inglés y ruso) • Six Sigma for IT Management (en inglés y coreano) • The RfP for IT Outsourcing - A Management Guide (en holandés) • Service Agreements - A Management Guide (en inglés) • Frameworks for IT Management (en inglés, alemán y japonés) • IT Governance based on CobiT® - A Management Guide (en inglés, alemán y japonés) • Implementing ISO/IEC 20000 Certification - The Roadmap (en inglés) Guías de bolsillo • IT Service Management - A summary based on ITIL® (versión 2, en holandés) • IT Service Management based on ITIL® V3 - A Pocket Guide (en inglés, holandés e italiano; ediciones en alemán, francés, japonés y español previstas para el verano de 2008) • ISO/IEC 20000 - A Pocket Guide (en inglés, alemán, japonés, italiano y español) • IT Services Procurement based on ISPL - A Pocket Guide (en inglés) • IT Service CMM - A Pocket Guide (en inglés) • Six Sigma for IT Management - A Pocket Guide (en inglés) • Frameworks for IT Management - A Pocket Guide (en inglés y holandés) Otros • IT Service Management from Hell!! (cubriendo versión 2, en inglés) • IT Service Management from Hell. Based on Not-ITIL (cubriendo versión 3, en inglés) Para cualquier consulta sobre la Biblioteca de Gestión de Servicios de TI, visite www.vanharen.net.


ISO/IEC 20000 Una introducción


IV

Colofón Título:

ISO/IEC 20000 - Una introducción

Editores:

Jan van Bon (editor en jefe, Inform-IT) Selma Polter (coautora y editora, Inform-IT) Tieneke Verheijen (coautora y editora, Inform-IT) Mike Pieper (editor edición español, Inform-IT)

Coautor:

Leo van Selm

Traducción:

Quint Wellington Redwood (España)

Una publicación de:

Van Haren Publishing, Zaltbommel (Holanda), www.vanharen.net

ISBN:

978 90 8753 293 2

Edición:

Primera edición, primera impresión, marzo 2008

Diseño y maquetación:

CO2 Premedia, Amersfoort (Holanda)

Extractos de BS ISO/IEC 20000-1:2005 y BS ISO/IEC 20000-2:2005 reproducidos con autorización de la Institución Británica de Normalización (BSI). Las Normas Británicas se pueden adquirir en formato PDF en la tienda on-line de BSI (http://www.bsi-global.com/en/Shop/) o en papel a través de los Servicios de Atención al Cliente de BSI (tel.: +44 (0)20 8996 9001, correo electrónico: [email protected]). ISO (Organización Internacional de Normalización) e IEC (Comisión Internacional de Electrotecnia) forman un sistema especializado que fomenta la normalización a nivel mundial. Los organismos nacionales que son miembros de ISO o IEC participan en el desarrollo de Normas Internacionales a través de comités técnicos creados por cada organización y dedicados a actividades técnicas o campos específicos. Los comités técnicos de ISO e IEC colaboran en campos de interés común. En esta tarea participan también otras organizaciones internacionales (gubernamentales y no gubernamentales) asociadas con ISO e IEC. En el campo de las Tecnologías de la Información, ISO e IEC han creado un comité técnico conjunto denominado ISO JTC 1. La redacción de Normas Internacionales se realiza de acuerdo con las reglas estipuladas en la Parte 2 de las Directivas ISO y constituye la labor más importante del comité técnico conjunto. Los anteproyectos de Normas Internacionales redactados por el comité técnico conjunto se transmiten a los organismos nacionales y se someten a votación. La publicación como Norma Internacional requiere la aprobación de al menos el 75% de los organismos nacionales con derecho a voto. El nombre oficial de la norma es ISO/IEC 20000, aunque en la práctica se utiliza simplemente “ISO 20000” por ser más breve y sencillo.

Si desea más información sobre Van Haren Publishing, envíe un corre electrónico a: [email protected]. ©Van Haren Publishing 2008 Todos los derechos reservados. Queda prohibida la reproducción de esta publicación en forma alguna, ya sea impresa, microfilmada o por cualquier otro medio, sin la autorización por escrito de la empresa editora. Aunque esta publicación ha sido preparada con el máximo cuidado, los autores, los editores y la empresa editora no se hacen responsables de ningún daño que se pueda producir como consecuencia de errores y/u omisiones en esta publicación. PRINCE2™, M_o_R® e ITIL® son marcas comerciales registradas y marcas comerciales comunitarias registradas de la Oficina de Comercio del Gobierno, y están registradas en la Oficina de Patentes y Marcas Registradas de los Estados Unidos. CobiT® es una marca registrada de la Asociación de Auditoría y Control de Sistemas de Información (ISACA)/ Instituto de Gobierno de TI (ITGI).


V

Prefacio Por John Stewart, Director de Normas y Política de Adquisiciones en la Oficina de Comercio del Gobierno (OGC) del Reino Unido. A su trabajo y al del difunto Pete Skinner debemos el concepto ITIL. John Stewart dirigió las primeras fases del desarrollo de ITIL y actualmente se ocupa de nuevo del mismo tema desde un cargo directivo en la OGC. “La razón para el desarrollo de ITIL hay que buscarla en el hecho de que las organizaciones dependen cada vez más de las Tecnologías de la Información para alcanzar sus objetivos corporativos y satisfacer sus necesidades de negocio. Esta mayor dependencia hace que cada vez sea más importante contar con servicios de TI de la máxima calidad, es decir, adaptados a los cambios en las necesidades de negocio y los requisitos de los usuarios. Este libro forma parte de una serie de códigos de prácticas pensados para facilitar la gestión de la calidad en los servicios de TI.” Estas líneas proceden del prefacio de las publicaciones de la versión 1 de ITIL, la primera de las cuales fue puesta en marcha por el Gobierno Británico hace 19 años. Circulan por ahí (sobre todo en Internet) multitud de historias sobre cómo y por qué empezó ITIL. Algunas son fascinantes y otras resultan absolutamente esperpénticas, pero ninguna de ellas es cierta. La verdad es que, como desarrolladores de proyectos, propusimos la idea porque nos preocupaba ver que el Gobierno Británico, a pesar de depender cada vez de las Tecnologías de la Información, dejaba su gestión a las distintas organizaciones y carecía de un enfoque común o de una definición clara de “lo que está bien”. Cuando nuestro Comité acordó financiar los primeros trabajos de desarrollo, comenzamos a buscar ejemplos de buenas prácticas y colaboramos con los distintos grupos de interés para conseguir un enfoque coherente. ITIL pertenecía al Gobierno Británico, que de esta forma se podía colocar “por encima del mercado”. Desde este punto de vista, ITIL tenía el potencial de convertirse en un estándar de facto para la Gestión de Servicios de TI. Al abogar por un mercado abierto y competitivo para la provisión de servicios y productos basados en ITIL, nuestro objetivo era extender las ventajas del concepto a organizaciones ajenas al sector público británico y, al mismo tiempo, conseguir que ITIL se beneficiara de las opiniones y aportaciones de una base mayor de grupos de interés. ITIL es una especie de “lengua franca” que favorece la adopción de un enfoque más uniforme para la Gestión de Servicios de TI. Ayuda a los usuarios a no tener que reinventar la forma en que gestionan sus servicios de TI, ya que les ofrece un sistema completo al tiempo que adaptable. Todo ello se basa en el concepto de gestión de la calidad del servicio. Dos datos demuestran hasta qué punto la gestión de la calidad era una de nuestras prioridades iniciales: en primer lugar, el hecho de que publicáramos una Biblioteca de Gestión de la Calidad poco después de los primeros volúmenes de ITIL; y en segundo lugar, la concesión (quizás por vez primera en el Gobierno Británico) del certificado ISO 9001 a nuestro trabajo sobre ITIL y temas afines. Gracias al esfuerzo de muchas organizaciones y personas, ITIL se ha convertido por derecho propio en un éxito internacional. Me gustaría dar las gracias al gran número de organizaciones Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

VI

que han centrado sus actividades en el mercado de ITIL, así como a la multitud de organizaciones de usuarios que han adoptado ITIL como base para la gestión de sus servicios de TI. Sin estas organizaciones, ITIL no habría alcanzado nunca la repercusión que sin duda tiene actualmente. Pese a todo, es evidente que hay muchas partes del mundo donde queda todavía mucho por hacer para fomentar el uso de ITIL. ¡No cese en el empeño si está usted en una de esas regiones! Siempre hemos pensado que la adopción del concepto ITIL en todo el mundo resultaría mucho más fácil si existiera una norma internacional complementaria. Por eso quiero agradecer a los promotores y desarrolladores de ISO 20000 la visión de futuro con que concibieron la norma, y sus esfuerzos por hacerla realidad. Juntas, ISO 20000 e ITIL nos permitirán avanzar hacia un objetivo común: mejorar las Tecnologías de la Información y aumentar la eficacia del soporte a empresas y gobiernos allí donde se utilicen. Confío en que los lectores compartan este objetivo y puedan beneficiarse de él.


VII

Agradecimientos ISO/IEC 20000, la norma internacional sobre Gestión de Servicios de TI, está despertando mucha atención entre los profesionales. Muchas organizaciones y personas están interesadas en las oportunidades que ofrece la norma y organizan encuentros para hablar de ello. El objetivo de este libro es servir como guía de introducción a la norma para todos aquéllos que participen en un proyecto de certificación o que estén preparando alguno de los distintos exámenes sobre ISO/ IEC 20000 que han aparecido recientemente en el mercado y que, en el futuro, tendrán una gran importancia en el campo de la Gestión de Servicios de TI. En primer lugar deseamos expresar nuestro agradecimiento a Selma Polter quien, en su calidad de primera editora, diseñó el índice de este libro y dedicó un gran esfuerzo a preparar presentaciones gráficas sobre los requisitos y recomendaciones de la norma, consiguiendo así que las explicaciones del libro resulten mucho más claras. Ella creó el primer borrador del manuscrito, combinando sus conocimientos de ISO 9000 con los requisitos estipulados en ISO/IEC 20000. Tieneke Verheijen pasó a ocupar el puesto de editor general una vez terminado el primer borrador, añadiendo el capítulo de introducción e instrucciones sobre Mejores Prácticas para los distintos procesos incluidos en la norma. El editor jefe, Jan van Bon, se encargó del proyecto en su totalidad, asegurándose de que el libro respondiera a las necesidades del mercado. También participó en la revisión final de los contenidos del libro, con particular atención a los gráficos. Debemos un agradecimiento especial al Sr. Leo van Selm, quien amablemente se ofreció como coautor y adaptó los contenidos del libro a los requisitos del examen para ISO/IEC 20000. También redactó el capítulo adicional sobre preparación de exámenes y las secciones sobre certificados para personas individuales y organizaciones. La versión final del manuscrito fue revisada por 30 personas, quienes realizaron su tarea con grandes dosis de entusiasmo y dedicación. Queremos dar las gracias especialmente a la Sra. Renate Eberle. Como Presidenta del Comité EXIN/TÜV, que desarrolló uno de los primeros exámenes de ISO/ IEC 20000 en el mercado, la Sra. Eberle facilitó la participación de los siguientes miembros de este Comité en la revisión: • Michael Brenner, de Leibniz Supercomputing Centre (Alemania) • Marcus Giese, de TÜV SÜD Management Service GmbH (Alemania) Como miembro del equipo de desarrollo de EXIN, que se encargó de diseñar el programa de certificación, el Sr. Leo van Selm nos puso en contacto con otros colegas a quienes también deseamos agradecer su apoyo en el trabajo de revisión: • Michael Busch, de it SolutionCrew GmbH (Alemania) • David Clifford, de PRO-ATTIVO (Reino Unido) • Bryan Shoe, de Process Catalyst Solutions (Estados Unidos)


VIII

Igualmente damos las gracias a los demás expertos que participaron en la revisión y que se unieron al equipo por distintas vías: • Gérald Audenis, de ORSYP Consulting (Francia) • Rob van der Burg, de Microsoft (Holanda) • Rosario Fondacaro, de Quint Wellington Redwood (Italia) • Peter van Gijn, de Logica (Holanda) • Ralph Gray, de Lucid IT Pty Ltd. (Nueva Zelanda) • John Groom, de West Groom Consulting (Reino Unido) • Matiss Horodishtiano, de Amdocs (Israel) • Wim Hoving, de BHVB (Holanda) • Alfons Huber, de TÜV SÜD Informatik und Consulting Services GmbH (Alemania) • Luis F. Martínez Sánchez, de Gestió i Govern de les TIC (G2TIC) (España) • Alex Tito, de Morais de Fujitsu do Brasil (Brasil) • Alan Nance, de BMC (Estados Unidos) • Tatiana Orlova, de EC-leasing (Rusia) • Joel A. Pereira, de The Centre For IT Service Management Pte. Ltd. (CISM™) (Singapur) • Selma Polter, de Independent (Holanda) • Silvia Prickel, de United Airlines (Estados Unidos) • Douglas Read, de PRO-ATTIVO (Reino Unido) • Claudio Restaino, de BITIL.COM (Italia) • Mart Rovers, de InterProm USA Corporation (Estados Unidos) • Rui Soares, de GFI Portugal (Portugal) • Jaap van Staalduine, de ING Service Centre Budapest (Holanda) • Ray Tricker, de Herne European Consultancy Ltd. (Reino Unido) • Tony Verlaan, de Getronics PinkRoccade (Holanda) • Flip van de Waerdt, de HP (Holanda) • Paul Wigzel, de Parity Training (Reino Unido) • Stuart Wright, de PRO-ATTIVO (Reino Unido) Entre todos plantearon unas 700 cuestiones que fueron consideradas por los editores y por el coautor Leo van Selm, mejorando el manuscrito y adaptando sus contenidos a la opinión de los expertos. Todos los revisores expresaron su satisfacción con el proceso y certificaron su cierre. Fiel a su objetivo de difundir los conocimientos sobre Mejores Prácticas, itSMF España no ha desaprovechado la oportunidad de traducir ISO/IEC 20000 - An Introduction al español. Como siempre, se ha seguido un amplio proceso de Aseguramiento de la Calidad en el que ha participado un equipo multidisciplinar de considerable tamaño: • Antonio Cruz Andrade, de Quint Wellington Redwood • Francisco Gil - de Renfe • Julio Ballesteros - de Quint Wellington Redwood • Isabel Diaz - de New Horizons Madrid • Manuel Diaz - de Telefónica España • Orlando Pereda - de Informática El Corte Inglés • Juan José Carpintero - de Al Campo • Sergio Ribes - de Tissat


IX

Debemos un agradecimiento especial a Marlon Molina (New Horizons Madrid), que coordinó la revisión y se aseguró de que no se pasara por alto ninguna cuestión. Así mismo, agradecemos especialmente a Quint Wellington Redwood Iberia su colaboración en la traducción y adaptación al castellano de esta edición. Confiamos en que este libro sea una guía clara y amena a ISO/IEC 20000, y que le sirva para preparar de la mejor forma posible los exámenes individuales y la certificación de la organización. Encontrará más información práctica sobre la certificación en la publicación que acompaña a este libro: “Implementing ISO/IEC 20000 Certification, A Roadmap”. El equipo editorial recibirá con agrado todas las propuestas de mejora y las incorporará en futuras ediciones. Puede enviar sus comentarios al editor jefe a la dirección [email protected]. Jan van Bon Editor general de la Biblioteca de Gestión de Servicios de TI


X


XI

Índice Prefacio��V Agradecimientos��VII Índice��XI

1 Introducción�� 1 1.1 Cómo utilizar este libro��2

2 Principios de Gestión de la Calidad del Servicio�� 5 2.1 2.2 2.3 2.4 2.5

Qué es la calidad��5 Qué es el servicio�� 14 Qué es la Gestión de Servicios de TI�� 21 Qué son los procesos�� 24 Qué es la mejora continua��28

3 La posición de ISO 20000 en la Gestión de Servicios de TI�� 33 3.1 Panorama actual de normas y marcos de trabajo��33 3.2 Conceptos de prácticas de certificación��35 3.3 Concepto de ISO 20000��44

4 Especificaciones y Código de buenas prácticas para ISO 20000�� 63 4.1 4.2 4.3 4.4 4.5

Gestión y mejora de procesos de Gestión de Servicios de TI��64 Control de servicios de TI��91 Alineación entre el negocio y las Tecnologías de la Información�� 129 Entrega de servicios de TI�� 164 Soporte de servicios de TI�� 199

5 El examen de Fundamentos de ISO/IEC 20000�� 219 5.1 5.2 5.3 5.4 5.5

Prerrequisitos��220 Formato de examen��220 Reclamaciones��221 Preparación del examen de Fundamentos de ISO/IEC 20000��221 Preguntas de ejemplo��222

Lista de abreviaturas�� 231 Referencias��235 Índice alfabético��239


XII


Capítulo 1

Introducción

La calidad de la Gestión de Servicios de TI (ITSM) es uno de los requisitos más importantes para poder ofrecer servicios que no pasen desapercibidos y sean muy valorados por el negocio. Con la publicación de la norma ISO 20000 para la Gestión de Servicios de TI, los principios ISO sobre gestión de la calidad se han combinado con los procesos ITSM estándares en el sector. Esta combinación se plasma en una norma internacional muy práctica y fácil de aplicar, que garantiza la calidad de la Gestión de Servicios de TI y que tiene por objeto suministrar servicios gestionados de TI de una calidad aceptable para los clientes de un proveedor de servicios de TI. La gestión de la calidad del servicio es cada vez más importante para la Gestión de Servicios de TI en todo el mundo. En los últimos años han surgido numerosas normas que se centran fundamentalmente en la calidad y la provisión de servicios y que están basadas en las demandas de los clientes y el negocio. La norma ISO 20000 especifica una serie de requisitos mínimos que deben cumplir todos los proveedores de servicios, además de definir una línea de referencia independiente a partir de la cual se pueden conseguir nuevas mejoras del servicio. La introducción de la versión 3 de ITIL® hace que la norma sea aún más importante, puesto que ofrece una forma de explorar la amplia guía de mejores prácticas, ya sea en la nueva versión de ITIL® o en otros marcos de trabajo como CobiT®. ISO 20000 es independiente de todos los marcos de trabajo; es “neutral” a ellos. No existe ningún control definido o implícito entre la norma y los marcos de trabajo (como MOF, ITIL® y Modelos de Referencia como el ITSM de HP o el IPW de Quint) o sus correspondientes sistemas de cualificación. No obstante, existen muchos marcos de trabajo tanto públicos como privados (mejores prácticas internas) que pueden ayudar a garantizar el reconocimiento de las capacidades. De hecho, la adopción de dichos marcos de trabajo puede significar la consecución de la certificación ISO 20000. Los proveedores internos y externos de servicios tienen el reto de demostrar que sus procesos de Gestión del Servicio aseguran la calidad que sus clientes exigen. De hecho, los proveedores Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

2

ISO/IEC 20000 – Una introducción

externos de servicios ya están siendo instados a obtener la certificación ISO 20000 como parte de algunas convocatorias de licitación. Aunque cualquiera podría asegurar que una organización satisface los requisitos de ISO 20000, el programa de certificación que gestiona itSMF UK aporta credibilidad al proceso. Este programa supedita la concesión de la certificación ISO 20000 al resultado de auditorías realizadas por Entidades de Certificación Registradas (RCBs), basadas en ISO 20000 Parte 1 (“Especificaciones”). Esto garantiza que un proveedor de servicios diseña, implanta y gestiona un sistema de Gestión de Servicios de TI según los requisitos de la norma. La experiencia en todo el mundo con ISO 20000 y sus precursoras (BS 15000, AS 8018 y SANS 15000) indica que los programas de certificación para proveedores de servicios de TI generan también una demanda de formación y certificación, por ejemplo, para auditores, propietarios de procesos, responsables de la Gestión del Servicio y consultores. También se genera un mayor interés entre los profesionales de la Gestión de Servicios de TI, tanto por parte de los clientes como de los proveedores de servicios. En un futuro próximo es probable que sea imprescindible conocer ISO 20000 (en sus aspectos básicos, al menos) para poder aspirar a muchos puestos de Gestión de Servicios de TI.

1.1 Cómo utilizar este libro Esta publicación, que se puede emplear como referencia para los exámenes de Fundamentos de ISO 20000, trata el concepto de calidad y la norma de calidad ISO 9000, además de explicar el lugar que ocupa ISO 20000 en la Gestión de Servicios de TI. También presenta el texto de la norma, utilizando para ello gráficos y una guía de mejores prácticas. Este libro se puede usar también para preparar la certificación ISO 20000 de una empresa. Explica los requisitos de ISO 20000 y describe cómo satisfacerlos empleando Mejores Prácticas. Los lectores que participen directamente en un proceso de certificación también pueden utilizar esta publicación como guía para mejorar la calidad de los servicios que ofrecen. El Capítulo 2 presenta los principios de gestión de la calidad del servicio, discutiendo la gestión de la calidad total y los conceptos de calidad, servicios y Gestión de Servicios de TI, procesos y mejora continua. El Capítulo 3 sitúa la norma ISO 20000 en el campo de la Gestión de Servicios de TI, además de explicar el concepto de prácticas de certificación. A continuación se presentan las distintas partes de la norma ISO 20000, incluyendo tanto los requisitos como las mejores prácticas. Siempre que es posible, se utilizan gráficos para distinguir las partes exigidas por las especificaciones de la norma (“obligaciones”) y las partes que se consideran mejores prácticas según el código de práctica (“recomendaciones”).


Introducción

3

El Capítulo 5 se centra en el examen de Fundamentos de ISO 20000, en sus requisitos y en cómo prepararlo. Actualmente, itSMF UK, ISEB y EXIN/TÜV SÜD están preparando exámenes para evaluar la competencia individual en las prácticas de ISO 20000, incluyendo procesos de consultoría y auditoría basados en la norma. En el momento de redactar este texto sólo se disponía de información sobre el programa de certificación de EXIN/TÜV SÜD, por lo que la mayor parte de la información ofrecida en este libro está basada en ese material, incluyendo las preguntas de ejemplo. No obstante, el libro incluye toda la información que necesita cualquier estudiante que se aproxime por primera vez a ISO 20000, y se puede usar para preparar cualquier examen de ISO 20000 de nivel fundamental.


4



Capítulo 2

Principios de Gestión de la Calidad del Servicio

Las empresas dependen cada vez más de servicios con un elevado nivel tecnológico. Hoy más que nunca, el éxito del negocio y de las Tecnologías de la Información se basa en su capacidad de satisfacer las expectativas de una base de clientes cada vez más exigente. Escándalos de gobierno corporativo ampliamente conocidos, junto con nuevas presiones reguladoras como la Ley Sarbanes-Oxley en los Estados Unidos, han llevado a las empresas a insistir en la necesidad de que el sector de las Tecnologías de la Información adopte una metodología coherente, enfocada al cliente y orientada a la calidad en la provisión de servicios de TI. Lo primero que se necesita para poder gestionar la calidad es ponerse de acuerdo en la definición del concepto. A eso se dedica la próxima sección.

2.1 Qué es la calidad Aunque cada uno puede tener su propia idea de “calidad”, la norma ISO 9000 (en la que está basada ISO 20000) la define de esta forma: Se puede hablar de calidad cuando el cliente recibe todas las características que exige de un producto (o servicio). La gestión de la calidad incluye, por tanto, todo lo que hace la organización para garantizar que sus productos o servicios satisfacen los requisitos de calidad de los clientes y cumplen todas las normas aplicables a esos productos o servicios. Para el departamento de servicios de TI, la Gestión de la Calidad consiste en comprender la perspectiva del negocio sobre calidad y servicio y en asegurar que el servicio está diseñado y gestionado para cumplir estas especificaciones.


6


2.1.1 Gestión de la Calidad Total (TQM) La Gestión de la Calidad Total (TQM) anima continuamente a todos los miembros de la organización a satisfacer las demandas del cliente interno o externo con el fin de conseguir una ventaja competitiva. Se trata de un término genérico que se utiliza para describir un enorme conjunto de filosofías, conceptos, métodos y herramientas. Existen diversos métodos que permiten gestionar la calidad de un servicio de TI. Todos ellos tienen su origen en las primeras décadas del siglo XX. Desde entonces las empresas han tratado siempre de controlar la calidad de sus productos, impulsadas fundamentalmente por la revolución tecnológica. Este proceso recibió el nombre de Gestión de la Calidad Total (TQM) en la década de 1980.

El ciclo Planificar-Hacer-Verificar-Actuar William Edwards Deming partió de un sencillo diagrama de un ciclo de mejora de la calidad y le añadió el ciclo Planificar-Hacer-Verificar-Actuar (denominado ciclo PDCA e ilustrado en la Figura 2.1)1: • Planificar - Qué es lo que hay que hacer, cuándo, quién debe hacerlo, cómo y con qué medios. • Hacer - Ejecución de las actividades planificadas. • Verificar - Comprobación de que las actividades dan el resultado deseado. • Actuar - Ajuste de los planes en función de los resultados de la fase de verificación. Sentido de giro

CALIDAD

Mejora de la calidad

P

D

A

C

Gestión de la calidad 1 PLANIFICAR 2 HACER 3 VERIFICAR 4 ACTUAR

ISO

/IE

C2

Aseguramiento de la calidad

00

00

TIEMPO

Figura 2.1 El ciclo PDCA. La cuesta se sube siguiendo sucesivamente las fases P, D, C y A.

1 Deming se inspiró en uno de sus profesores, Walter Shewhart, quien ya había propuesto un “ciclo de aprendizaje y mejora”.



7

Este círculo forma parte del sistema de mejora continua tanto en ISO 9000 como en ISO 20000. Fue Joseph Juran quien introdujo el “concepto de mejora continua”. Este importante “padre fundador” de TQM estableció el enfoque a cliente como otro concepto fundamental de la Gestión de la Calidad Total. Un diálogo continuo con el cliente es imprescindible para garantizar que tanto el cliente como el suministrador saben lo que se espera de un servicio. El tercer concepto introducido por Juran fue el del valor de cada asociado. Los empleados influyen en el cambio y pueden convertirse en el activo más importante para mejorar la calidad. Es necesario comunicar a todos los empleados una política clara y coherente sobre cómo y hasta qué punto su trabajo ayuda a alcanzar los objetivos de la organización, de manera que se sientan autorizados y responsables para llevar a cabo las tareas que se les haya asignado. Esto mejorará la satisfacción de los empleados y fomentará la productividad y la innovación. La formación y los exámenes de ISO 20000 pueden aclarar los roles de los empleados dentro de una organización.

2.1.2 La importancia de la calidad en la Gestión de Servicios de TI La gran importancia que adquirieron las Tecnologías de la Información en muchos sectores durante la década de 1980 hizo que aumentara la demanda de software y de modelos, métodos y herramientas para TI. Para un número de productos cada vez mayor (los del sector de la electrónica de consumo o las comunicaciones, por ejemplo), el tiempo total de desarrollo pasó a depender fundamentalmente del tiempo que se tardaba en desarrollar el software. Esto hizo que resultara especialmente importante mejorar la eficacia y la eficiencia de los procesos de desarrollo de software. Al mismo tiempo aumentó también la importancia de la Gestión de Servicios de TI, lo que llevó a la aparición de la Biblioteca de la Infraestructura de Tecnología de Información (ITIL®). De este modo se empezó a prestar atención a la calidad de los servicios de TI. La gestión de la calidad de los servicios de TI tiene que garantizar que la información es fiable y segura. No es posible mejorar los procesos de una organización si no se cuenta con información completa y precisa que pueda servir de base en la toma de decisiones. El primer elemento cuya calidad hay que garantizar es por tanto la información de gestión, ya que sirve y afecta a todos los demás productos y procesos. TQM combina distintos sistemas de gestión de la calidad, por lo que no existe ninguna certificación “oficial” para TQM. Junto con distintos premios a la calidad (como el Premio Nacional de Calidad Malcolm Baldrige o los premios de la Fundación Europea para la Gestión de la Calidad), la certificación ISO 9001:2000 indica que una organización se rige según los principios de TQM. Las empresas con certificación ISO 20000 tienen que haber superado una auditoría basada en las mejores prácticas internacionales para ITSM.

2.1.3 Principios (componentes) de la gestión de la calidad La buena gestión de una organización exige que sea dirigida y controlada de un modo sistemático y transparente. Alcanzar el éxito es posible si se emplea un sistema de gestión que mejore continuamente el rendimiento y tenga en cuenta las necesidades de todas las partes interesadas. La gestión de una organización incluye, entre otras disciplinas, la gestión de la calidad.


8


La norma ISO 20000 para Gestión de Servicios de TI debe mucho a ISO 9000, la norma internacional para gestión de la calidad. Entre otras cosas, incluye los ocho principios de la gestión de la calidad de ISO 9000 (Figura 2.2): • Enfoque a cliente • Liderazgo • Implicación de las personas • Planteamiento de procesos • Mejora continua • Planteamiento basado en hechos para la toma de decisiones • Relaciones de mutuo beneficio con los suministradores • Planteamiento de sistema para la gestión Planteamiento de sistema para la gestión Relaciones con los suministradores

Planteamiento basado en hechos

Enfoque a cliente

LOS OCHO PRINCIPIOS DE LA GESTIÓN DE LA CALIDAD

Liderazgo

Implicación de las personas

Mejora continua Planteamiento de procesos

Figura 2.2 Los ocho principios de la Gestión de la Calidad en ISO 9000

Estos principios, que se pueden considerar como los componentes de la calidad, son de gran utilidad para que la alta dirección guíe la mejora del rendimiento de su organización. En las secciones que siguen se discute con más detalle cada uno de los componentes.

Enfoque a cliente Todas las organizaciones dependen de sus clientes. Eso las obliga a comprender las necesidades presentes y futuras de los clientes, satisfacer sus requisitos y hacer todo lo posible por superar sus expectativas. Las principales ventajas del enfoque a cliente son: • Aumento de los ingresos y de la cuota de mercado gracias a una respuesta más rápida y flexible a las oportunidades que ofrece el mercado. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


9

• Uso más eficaz de los recursos de la organización para aumentar el grado de satisfacción de los clientes. En general, la aplicación del principio de enfoque a cliente permite: • Desarrollar una estrategia corporativa basada en las necesidades futuras de los clientes. • Analizar y comprender las necesidades y expectativas de los clientes, vinculando a ellas los objetivos de la organización. • Comunicar las necesidades y expectativas de los clientes a toda la organización. • Medir el grado de satisfacción de los clientes y actuar en consecuencia. • Gestionar las relaciones con los clientes de una forma sistemática. • Conseguir un equilibrio entre la satisfacción de los clientes y la de otras partes interesadas (como propietarios, empleados, suministradores, financieros, comunidades locales y el conjunto de la sociedad). A veces hay que distinguir entre el cliente y el usuario de un servicio. La persona que paga por el servicio es el cliente, pero no siempre coincide con la persona que lo utiliza y que es, por definición, el usuario. En última instancia, los requisitos del cliente son siempre lo más importante, aunque es probable que el cliente tenga en cuenta las experiencias de los usuarios a la hora de evaluar los servicios recibidos.

Liderazgo Los líderes son los encargados de establecer la unidad de acción y los objetivos comunes de la organización. Para ello deben crear y mantener un ambiente en el que todo el mundo se sienta plenamente implicado en la consecución de los objetivos de la organización. Las principales ventajas del liderazgo son: • Las personas asumen los objetivos de la organización y se sienten motivadas por ellos. • Las actividades se evalúan, alinean e implantan de un modo unificado. • Se minimiza la falta de comunicación entre los distintos niveles de la organización. En general, la aplicación del principio de liderazgo permite: • Tener en cuenta las necesidades de todas las partes interesadas (clientes, propietarios, empleados, suministradores, financieros, comunidades locales y el conjunto de la sociedad). • Tener una idea clara del futuro de la organización. • Definir metas y objetivos específicos que estimulen el progreso. • Crear y sostener valores comunes, ecuanimidad y modelos de comportamiento en todos los niveles de la organización. • Fomentar la confianza y disipar temores. • Proporcionar a las personas los recursos, la formación y la libertad que necesitan para actuar de forma responsable. • Inspirar y animar a las personas y reconocer sus aportaciones.

Implicación de las personas Las personas son el alma de una organización a todos sus niveles. Su implicación permite aprovechar al máximo el potencial de todos en beneficio de la organización.


10


Las principales ventajas de la implicación de las personas son: • Una organización formada por personas motivadas, comprometidas y que se sienten implicadas. • Fomento de la innovación y la creatividad para alcanzar los objetivos de la organización. • Las personas son responsables de su propio trabajo. • Las personas se sienten con ganas de participar y contribuir a la mejora continua. En general, la aplicación del principio de implicación de las personas permite: • Hacer que las personas comprendan la importancia de su contribución a la organización y el rol que desempeñan dentro de ella. • Hacer que las personas sean conscientes de los factores que limitan su rendimiento. • Hacer que las personas sientan los problemas como suyos y acepten la responsabilidad de resolverlos. • Hacer que las personas evalúen su rendimiento en función de sus metas y objetivos personales. • Hacer que las personas busquen activamente oportunidades de mejorar su grado de competencia, conocimiento y experiencia. • Fomentar la libre circulación de conocimientos y experiencias entre personas. • Fomentar la discusión franca de todo tipo de asuntos y problemas. • Reducir los conflictos dentro de la empresa. • Mejorar la forma en que los clientes perciben la organización.

Planteamiento de procesos Gestionar actividades y los recursos correspondientes como un proceso permite alcanzar el resultado deseado de una forma más eficiente, como se explica también en la Sección 2.4. Un proceso es un conjunto estructurado de actividades diseñado para cumplir un objetivo concreto (más información en la Sección 2.4). Un proceso tiene entradas y salidas. Las organizaciones que persiguen la eficacia en su funcionamiento tienen que identificar y gestionar numerosos procesos que están relacionados entre sí, ya que es frecuente que la salida de un proceso pase directamente a ser la entrada del siguiente proceso. La identificación y gestión sistemáticas de los procesos empleados en una organización, y especialmente de las interacciones entre esos procesos, se denomina “planteamiento de procesos”. Las principales ventajas del planteamiento de procesos son: • Costes más bajos y ciclos más cortos, gracias a un uso más eficaz de los recursos. • Resultados mejorados, coherentes y predecibles. • Oportunidades de mejora enfocadas y con prioridades asignadas. La Figura 2.3 presenta un sistema de gestión de la calidad basado en procesos tal como se describe en ISO 9000. Aunque no muestra los procesos en detalle, deja claro que las partes interesadas desempeñan un rol importante, ya que proporcionan entradas a la organización. Para monitorizar los niveles de satisfacción de las partes interesadas es necesario contar con información sobre su percepción y determinar hasta qué punto se han satisfecho sus necesidades y expectativas.



11

Mejora continua

PROCESOS DE PROVISIÓN DE SERVICIO Gestión de la Capacidad Gestión de la Disponibilidad y la Continuidad del Servicio

Gestión del Nivel de Servicio

Informes del Servicio

Gestión de la Seguridad de la Información Presupuestos y Contabilidad de los Servicios de TI

PROCESOS DE CONTROL Gestión de la Configuración Gestión de Cambios

PROCESO DE ENTREGA Gestión de la Entrega

PROCESOS DE RESOLUCIÓN Gestión de Incidencias Gestión de Problemas

PROCESOS DE RELACIÓN

Hacer

Gestión de Relaciones con el Negocio Gestión de Proveedores

Planificar

Realización del producto Medición análisis mejora Requisito del cliente

Gestión de recursos Satisfacción del cliente

Responsabilidad de la dirección

ENTRADA

Sistema d

Verificar

Actuar

PROCESO

SALIDA

d e Gestión de la Calida

Figura 2.3 Modelo de un sistema de gestión de la calidad basado en procesos (Tricker, 2006)

En general, la aplicación de una metodología de procesos permite: • Concentrarse en los resultados previstos de las actividades integradas en el proceso. • Definir de forma sistemática las actividades necesarias para obtener el resultado deseado. • Definir con claridad las responsabilidades de la dirección para las actividades clave. • Analizar y medir la capacidad de las actividades clave. • Identificar las interfaces de las actividades clave en y entre las distintas funciones de la organización. • Concentrarse en los factores (como recursos, métodos y materiales) que pueden mejorar las actividades clave de la organización. • Evaluar los riesgos, consecuencias e impactos de las actividades para clientes, suministradores y otras partes interesadas.

Mejora continua Un sistema de gestión de la calidad se debe ir mejorando de manera continua para aumentar el rendimiento de la organización y la satisfacción de los clientes. Este punto debe ser un objetivo permanente de la organización. Las principales ventajas de la mejora continua son: • Más rendimiento gracias a una mejor capacidad organizativa. • Más calidad del servicio prestado. • Alineación de las actividades de mejora a todos los niveles con los objetivos estratégicos de la organización. • Flexibilidad para reaccionar con rapidez ante las oportunidades. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

12


En general, la aplicación del principio de mejora continua permite: • Emplear un planteamiento coherente de mejora continua del rendimiento en toda la organización. • Formar a las personas en los métodos y herramientas de mejora continua. • Convertir la mejora continua de productos, procesos y sistemas en un objetivo para cada uno de los miembros de la organización. • Analizar y evaluar la situación existente para identificar áreas de mejora. • Definir los objetivos de la mejora. • Buscar posibles soluciones para alcanzar los objetivos. • Evaluar estas soluciones y seleccionar la mejor. • Implantar la solución seleccionada. • Adoptar medidas para efectuar un seguimiento de la mejora continua. • Medir, verificar, analizar y evaluar los resultados de la implantación para determinar que se han alcanzado los objetivos. • Formalizar cambios. • Reconocer las mejoras conseguidas. • Reducir los conflictos con los clientes y generar más negocio a medio plazo mediante una mejora proactiva de las relaciones y de los productos suministrados. Los resultados se someten a las revisiones necesarias para identificar nuevas oportunidades de mejora. De esta forma, la mejora se convierte en una actividad continua. Los comentarios de los clientes y otras partes interesadas, las auditorías y la revisión del sistema de gestión de la calidad también pueden ayudar a detectar oportunidades de mejora.

Planteamiento basado en hechos para la toma de decisiones Las decisiones eficaces se basan siempre en el análisis de datos e información. Principales ventajas: • Decisiones basadas en información precisa y completa. • Mayor capacidad para demostrar la eficacia de decisiones anteriores recurriendo a datos reales. • Mayor capacidad para revisar, cuestionar y alterar opiniones y decisiones. Para aplicar el principio de planteamiento basado en hechos para la toma de decisiones es preciso: • Garantizar que los datos y la información son lo suficientemente precisos y fiables. • Hacer que los datos sean accesibles a quien los necesite. • Analizar los datos y la información empleando métodos válidos. En general, la aplicación de este principio permite adoptar decisiones y acciones basadas en un análisis de hechos que apoya a la experiencia y la sabiduría.

Relaciones de mutuo beneficio con los suministradores Una organización y sus suministradores son mutuamente dependientes, por lo que una relación que sea beneficiosa para las dos partes aumentará la capacidad de ambas para generar valor.



13

Principales ventajas: • Mayor capacidad de generar valor por ambas partes. • Flexibilidad y velocidad a la hora de responder conjuntamente a cambios en las necesidades y expectativas de los clientes o el mercado. • Optimización de costes y recursos. En general, la aplicación del principio de relaciones de mutuo beneficio con los suministradores permite: • Establecer relaciones que equilibren las ganancias a corto plazo con las estimaciones a largo plazo. • Compartir experiencias y recursos con los asociados. • Identificar y seleccionar a los suministradores clave. • Mantener una comunicación franca y abierta. • Compartir información y planes futuros. • Iniciar actividades conjuntas de desarrollo y mejora. • Inspirar, fomentar y reconocer las mejoras y logros de los suministradores.

Planteamiento de sistema para la gestión El objetivo de un enfoque sistemático es identificar, comprender y gestionar las relaciones entre procesos, gestionándolos como un sistema. De esta forma, la organización puede alcanzar sus objetivos de una forma más eficaz y eficiente. Las principales ventajas del planteamiento de sistema son: • Integración y alineación de los procesos que permiten alcanzar con más facilidad los resultados deseados. • Capacidad para concentrar esfuerzos en los procesos clave. • Confianza de las partes interesadas en la coherencia, eficacia y eficiencia de la organización. En general, la aplicación de un planteamiento de sistema para la gestión permite: • Estructurar un sistema para alcanzar los objetivos de la organización de la forma más eficaz y eficiente. • Comprender las dependencias mutuas entre los procesos del sistema. • Adoptar enfoques estructurados que armonizan e integran procesos. • Comprender mejor los roles y responsabilidades necesarios para alcanzar objetivos comunes, reduciendo así las barreras entre funciones. • Comprender la capacidad organizativa y definir las limitaciones de recursos antes de emprender una acción. • Marcar objetivos específicos y definir cómo debe funcionar cada actividad dentro de un sistema. • Mejorar continuamente el sistema por medio de medidas y evaluaciones. Encontrará más información en la Sección 2.1.4.

2.1.4 Sistemas de gestión de la calidad Un sistema de gestión de la calidad es la forma en que una organización trabaja y gestiona su negocio. Define la manera en que una organización gestiona la calidad de sus productos o Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

14


servicios. ISO 9000:2005 describe las características fundamentales de los sistemas de gestión de la calidad y define términos relacionados. Como se indicó anteriormente, la satisfacción de los requisitos del cliente debe ser el objetivo último de cualquier organización dedicada a la calidad. El uso de un sistema de gestión de la calidad estimula a las organizaciones a analizar los requisitos del cliente, a definir los procesos que puedan contribuir a desarrollar un producto aceptable para el cliente y a mantener dichos procesos bajo control. También proporciona un marco de trabajo para mejora continua, aumentando la satisfacción de los clientes y otras partes interesadas. Todo ello hace que tanto la organización como sus clientes tengan confianza en que los productos cumplirán siempre los requisitos establecidos. Un planteamiento para desarrollar e implantar un sistema de gestión de la calidad consta de varios pasos: • Determinar las necesidades y expectativas de los clientes y otras partes interesadas. • Definir la política y los objetivos de calidad de la organización. • Determinar los procesos y responsabilidades que se necesitan para alcanzar los objetivos de calidad. • Determinar y proporcionar los recursos necesarios para alcanzar los objetivos de calidad. • Definir métodos para medir la eficacia y la eficiencia de cada proceso. • Medir la eficacia y la eficiencia de cada proceso. • Determinar formas de prevenir incumplimientos y eliminar sus causas. • Definir y aplicar un proceso para la mejora continua del sistema de gestión de la calidad. Este método se puede utilizar también para mantener y mejorar un sistema de gestión de la calidad ya existente. La política y los objetivos de calidad marcan el camino a seguir por la organización, ya que determinan los resultados deseados y ayudan a la organización a aprovechar sus recursos para alcanzar dichos resultados. La política de calidad define el marco de trabajo en el que se marcan y revisan los objetivos de calidad. Por su parte, los objetivos de calidad tienen que ser coherentes con la política de calidad y con el compromiso de mejora continua, además de ser cuantificables. El cumplimiento de objetivos de calidad puede repercutir positivamente en la calidad de los productos, en la eficacia operativa y en el rendimiento financiero, y por tanto también en la satisfacción y la confianza de las partes interesadas.

2.2 Qué es el servicio 2.2.1 ¿Qué es un servicio de TI? Tradicionalmente, las Tecnologías de la Información se consideraban una fuente de productos: hardware, sistemas, software, ordenadores, etc. Esta situación ha cambiado, como demuestra la gran importancia de las TI para el negocio. Aunque las Tecnologías de la Información utilizan productos para la provisión de servicios de TI, actualmente se consideran sobre todo un dominio de servicios. Pero, ¿cuál es la diferencia entre un producto y un servicio? Se puede expresar en términos de las siguientes características: Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


15

• Los servicios son básicamente intangibles - Un servicio no es algo físico que se pueda tocar o pesar. Consta de componentes tangibles (como el hardware que se usa para la prestación del servicio, la red o el disco donde está instalado el software), pero un servicio es mucho más que la simple combinación de productos tangibles. • Los servicios se producen y consumen al mismo tiempo - Un servicio se consume en el mismo momento en que se produce. Además, no es posible almacenar servicios. Por este motivo, el aseguramiento proactivo de la calidad es mucho más importante para la gestión de servicios que cualquier verificación posterior de la calidad del servicio suministrado. • Los servicios son muy variables - La prestación de servicios se realiza a través de máquinas, pero también de personas. Y las personas, a diferencia de las máquinas, pueden ser muy variables. Por ejemplo, un empleado del servicio de atención al cliente que haya pasado una mala noche puede resultar bastante grosero durante la primera hora de su turno, pero su humor (y su servicio) puede mejorar mucho después de una taza de café. Los productos tienden a parecerse más a las máquinas, por lo que sus variaciones se pueden gestionar más fácilmente. • El usuario participa en la producción del servicio - Es frecuente que no sea posible consumir un servicio si el usuario no lleva a cabo algunas acciones concretas. De esta forma, el usuario (y por tanto el cliente) también influye en la calidad del servicio. Por el contrario, un producto suele ser el resultado de una acción unilateral de un proveedor externo. • La satisfacción es un concepto subjetivo - El consumo de servicios depende en parte del consumidor (en este caso, el usuario de TI). Además, los servicios sólo se pueden medir una vez entregados, pero no antes. Los productos se pueden valorar, probar y evaluar antes de comprarlos, mientras que no es posible juzgar un servicio que no se ha recibido. Muchas de las diferencias entre servicios y productos se deben al porcentaje de bienes tangibles que hay en el servicio (Figura 2.4). Las características intangibles suelen resultar más difíciles de medir que los bienes tangibles, ya que son subjetivas. Por lo tanto, cuantos menos bienes tangibles contenga un servicio, más difícil será medirlo de un modo objetivo. Mayoría de bienes

Bienes que requieren muchos servicios

Parte tangible del producto

Mezcla

Servicios que requieren muchos bienes

Mayoría de servicios

Parte intangible del producto

Figura 2.4 Servicios y productos


16


2.2.2 Componentes de un servicio de TI La entidad “servicio” es esencial para la Gestión de Servicios de TI. Según ITIL® V3: Un servicio es un medio de crear valor para los clientes facilitando los resultados que los clientes quieren conseguir sin incurrir en costes y riesgos específicos. Pero, ¿qué es un servicio de TI si se mira en detalle? El servicio de TI es una salida de la organización de TI (ya sea interna o externa), y no un resultado del negocio, donde el valor real se debe crear con el servicio. En términos de esta salida de la organización interna o externa de TI, un servicio de TI se puede describir como una colección de elementos relacionados que, cuando se combinan, forman el servicio y crean un valor potencial para los clientes. Desde el punto de vista de la composición técnica, un servicio de TI es un sistema de información con soporte, que se entrega a un cliente con unos niveles de calidad previamente acordados. Esta composición menciona tres elementos: • Sistema de información • Soporte • Especificaciones de calidad Las secciones que siguen explican cada uno de estos elementos.

Sistema de información (SI) El sistema de información (SI) es un sistema coherente de procesamiento de datos para el control o soporte de información en uno o más procesos de negocio. Está formado por Personas, Procesos y Tecnología, y se puede usar (en colaboración con Proveedores asociados) para gestionar el área de atención final: Información (Figura 2.5). Las personas que forman parte del servicio de TI son el personal encargado de garantizar que el servicio funciona de acuerdo con los requisitos. Realizan todas las actividades necesarias a lo largo del ciclo de vida del servicio para que el servicio cumpla en todo momento las especificaciones. Ningún servicio de TI puede durar mucho tiempo sin personas. Los procesos se documentan en descripciones de procesos. Estos documentos contienen también procedimientos, instrucciones de trabajo y manuales. Una organización que no disponga de instrucciones debidamente documentadas se verá pronto dependiendo únicamente de los conocimientos de su personal. Pero las personas cambian a menudo de trabajo, tienden a olvidar cosas o pueden no estar de acuerdo sobre algún tema concreto. Resulta difícil alcanzar la normalización si no se parte de instrucciones bien documentadas y aceptadas. Los expertos en TI están especialmente familiarizados con el dominio tecnológico. La infraestructura de Tecnologías de la Información se puede descomponer en varios elementos. El conjunto de elementos más habitual sería: aplicaciones ejecutadas en sistemas de un entorno. En términos más técnicos se diría: [aplicaciones] ejecutadas en [infraestructura técnica] empleando [instalaciones].



Personas = personal

17

Personas

Hardware

Información

Servicio de TI

Sistema de información Requisitos de calidad

Disponibilidad Rendimiento Capacidad Seguridad Confidencialidad Escalabilidad Adaptabilidad Portabilidad

Software de sistema

Infraestructura técnica

Redes

Tecnología Tecnologías de la Información

Software de aplicaciones Aplicaciones Bases de datos

Instalaciones Documentación

Proceso

.......

Figura 2.5 Árbol terminológico en el que se muestra el desglose y los niveles de agrupación de los componentes de un servicio de TI (Fuente: Compendio de ITSM)

Dependiendo de la tecnología aplicada, estos dominios de alto nivel se pueden descomponer todavía más. Por ejemplo, la infraestructura técnica se puede dividir en hardware, software de sistema y redes. Otro posible desglose podría incluir entidades de infraestructura como middleware, firmware, etc. El desglose elegido puede depender de la opinión del gestor y de la tecnología aplicada, siempre y cuando todos los componentes estén gestionados correctamente. El desglose de las aplicaciones puede variar del mismo modo: una arquitectura de dos líneas de soporte se podría descomponer en software de aplicaciones y bases de datos, mientras que en una arquitectura de tres líneas de soporte se podría hablar de una capa de presentación, una capa de procesamiento y una capa de datos. Las instalaciones se pueden descomponer, por ejemplo, en alimentación, temperatura y espacio.

Soporte El segundo término importante en el contexto de un servicio de TI es “soporte”. El sistema de información (SI) necesita soporte para funcionar en todo momento según las especificaciones. Esto significa que se deben introducir cambios cuando sea necesario y que hay que restaurar el sistema si no funciona como estaba previsto. El soporte incluye también el elemento de “mantenimiento”. Las personas que componen el equipo del SI siguen las líneas de los procesos para efectuar estas acciones de soporte, que incluyen restaurar un servicio de TI que haya sido alterado, adaptar un servicio de TI si el cliente exige características diferentes y aumentar o reducir un servicio de TI. Si todo ello se hace correctamente, el sistema de información funcionará según lo previsto para facilitar los procesos de negocio.


18


Calidad El sistema de información debe cumplir las especificaciones acordadas con el cliente, lo que significa que se tienen que definir y aceptar sus atributos de calidad. En la práctica, la calidad de un servicio de TI se suele expresar como las características específicas del servicio que satisfacen las expectativas del cliente. Estas características se pueden referir a aspectos de comportamiento (como el tiempo de respuesta) o bien ser características más físicas (como “un portátil”). El cliente y el proveedor tienen relativa libertad para elegir las especificaciones de calidad de servicio, aunque algunos atributos son más habituales que otros: • La disponibilidad del sistema de información (SI) es el más importante y habitual de los atributos de calidad de un servicio. Especifica el tiempo y el lugar en que el SI debe estar disponible para el usuario. • La capacidad es el segundo atributo esencial de calidad en la mayor parte de los casos. Indica la “cantidad” de una característica (por ejemplo, la capacidad de almacenamiento de un disco, la capacidad de procesamiento de una CPU, la capacidad de restauración de un centro de atención al usuario, la capacidad de aceptar un gran número de cambios, etc.). • El tercer atributo común de calidad es el rendimiento, que se refiere a la velocidad a la que se procesa la información desde el punto de vista del usuario. ISO 20000 considera el rendimiento dentro de la gestión de la capacidad. El concepto de rendimiento de sistemas de información es totalmente diferente del rendimiento de TI, rendimiento de aplicaciones, rendimiento de sistemas, rendimiento de instalaciones, rendimiento de personal o rendimiento de procesos. El rendimiento de un componente no resulta de interés directo para el cliente/usuario, ya que lo que el usuario experimenta es la “salida unificada” de los rendimientos de todos los componentes del sistema de información. • La seguridad es otro atributo crucial para la mayor parte de las organizaciones y se contempla en casi todos los acuerdos sobre servicios de TI. • También la confidencialidad puede ser muy importante como elemento de seguridad, dependiendo de la naturaleza del negocio del cliente. • La escalabilidad puede ser importante para una organización en rápido crecimiento. Un proveedor tiene que ser capaz de garantizar el crecimiento a la velocidad exigida y sin perjudicar el negocio. • La adaptabilidad puede ser importante para organizaciones con un alto grado de innovación. Un proveedor tendrá que elegir sus métodos de desarrollo, la arquitectura de su infraestructura y todo lo que sea necesario para garantizar la adaptabilidad de un sistema de información. • La portabilidad puede ser importante para un cliente que desee contar con la posibilidad de cambiar proveedores, ya sea con frecuencia o en caso de finalización (normal o anticipada) de un contrato. Los atributos de un servicio también pueden depender unos de otros. Por ejemplo, la hora de cierre de una incidencia puede influir directamente en la disponibilidad del sistema de información.

2.2.3 Relación entre servicios de TI y calidad Es habitual que las organizaciones dependan de sus servicios de TI y esperen de ellos no sólo que den apoyo a la organización, sino también que ofrezcan nuevas opciones para hacer frente a cambios en las necesidades. Los proveedores de servicios de TI ya no se pueden concentrar únicamente en la tecnología y su organización interna; ahora también deben tener en cuenta la calidad de sus servicios y prestar gran atención a la relación con sus clientes. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


19

Como se explica en la sección anterior, un producto comprado en una tienda se puede valorar por su calidad antes de comprarlo. La prestación de un servicio, por el contrario, es el resultado de la interacción del proveedor con sus clientes y usuarios, por lo que no es posible valorar el servicio por anticipado. La calidad de un servicio depende de la forma en que interactúan el proveedor del servicio, el cliente y los usuarios. A diferencia de lo que ocurre en el proceso de fabricación, el cliente y el proveedor pueden introducir cambios una vez iniciada la prestación del servicio. Tanto la percepción que el cliente y los usuarios tienen del servicio como la opinión del proveedor dependen en gran medida de las expectativas y experiencias personales de cada uno. Esto significa que el proceso de prestación de un servicio es una combinación de producción y uso en la que participan al mismo tiempo el proveedor y el cliente (usuarios). La percepción del cliente y los usuarios es fundamental para la provisión de servicios. Por lo general, los clientes y usuarios recurren a las siguientes preguntas para valorar la calidad del servicio: • ¿Satisface el servicio las expectativas acordadas? • ¿Recibiré un servicio similar la próxima vez? • ¿Pago un precio razonable por el servicio?

Percepción de la calidad La percepción de la calidad se basa fundamentalmente en las expectativas, que a su vez pueden tener su origen en el diálogo entre proveedor y cliente o en cualquier otro factor. Estas expectativas pueden influir más en la calidad percibida que la calidad técnica real de los servicios ofrecidos por el proveedor. La percepción de un servicio es un aspecto fundamental de la relación clienteproveedor. No obstante, la percepción de la calidad puede verse afectada por varias diferencias o “gaps” (véase la Figura 2.6): • Gap 1 - La diferencia entre lo que los clientes esperan y la forma en que el proveedor entiende esas expectativas; se debe a una falta de entendimiento o a una idea incorrecta de las necesidades o deseos del cliente; la comunicación puede ser muy importante para eliminar esta diferencia. • Gap 2 - La diferencia entre la forma en que el proveedor entiende las expectativas del cliente y los diseños y normas del servicio definidos por el proveedor; se debe a la incapacidad de traducir los requisitos del cliente en especificaciones del servicio. • Gap 3 - La diferencia entre los diseños y normas del servicio y el servicio que se ofrece realmente; se debe a la incapacidad del proveedor de ofrecer lo acordado. • Gap 4 - La diferencia entre los servicios que se ofrecen realmente y lo que se ha dicho al cliente que va a recibir; se debe a una comunicación mala o incluso engañosa. • Gap 5 - La diferencia entre el servicio tal como lo perciben los clientes y el servicio que esperaban recibir; puede tener muchas causas; puede ocurrir que un cliente reciba más de lo que esperaba, pero la mayor parte de los problemas se deben a que el servicio no cumple las expectativas y el cliente está insatisfecho. Un diálogo continuo con el cliente (incluyendo a los empleados) es fundamental para mejorar los servicios y garantizar que tanto el cliente como el suministrador saben qué esperar del servicio. La clave para ello es contar con un lenguaje común basado en conceptos mutuamente aceptados. No siempre es fácil conseguir que se entiendan distintas personas, pero el uso de una terminología Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

20


común para modelos de referencia y mejores prácticas (CobiT®, ITIL®) puede ser de gran ayuda.

Comunicación verbal

Necesidades personales

Experiencia previa

Servicio esperado Gap 5 Servicio percibido

Cliente Proveedor Gap 1

Servicio real

Gap 4

Comunicaciones externas con clientes

Gap 3 Traducción de expectativas en normas de calidad Gap 2 Percepción de las expectativas del cliente por parte del proveedor

Figura 2.6 Percepción de la calidad (Fuente: Modelo SERVQUAL de Parasuraman, Zeithaml y Berry)

En un restaurante, por ejemplo, el camarero empezará explicando el menú y preguntará si el servicio es satisfactorio cada vez que sirva un nuevo plato. El camarero coordina activamente el suministro y la demanda a lo largo de la comida y utiliza esta experiencia con los clientes para mejorar el grado de satisfacción de los clientes futuros. La calidad de un servicio depende de hasta qué punto el servicio satisface los requisitos y expectativas del cliente (incluyendo a los usuarios). Para poder ofrecer calidad, el suministrador tiene que evaluar de forma continua cómo se percibe el servicio y qué es lo que el cliente espera en el futuro. Lo que para un cliente resulta normal puede ser visto como un requisito especial por otro cliente. También es posible que un cliente se acostumbre a algo que consideraba especial hasta el punto de llegar a verlo como un servicio normal. Los resultados de la evaluación continua del servicio pueden servir para determinar si es necesario modificar el servicio, si hay que ofrecer más información al cliente o si se debe cambiar el precio. Un coste razonable puede ser considerado como un requisito secundario o derivado, ya que el coste se decide una vez acordado lo que se espera del servicio. También es posible ver el coste como un atributo de calidad que se debe considerar conjuntamente con otros atributos para alcanzar un equilibrio global que resulte más satisfactorio para el cliente. En este punto, el proveedor del servicio debe ser consciente de los costes en los que incurre y de los precios de mercado para servicios similares. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


21

El cliente no estará satisfecho si el proveedor del servicio supera de vez en cuando las expectativas pero sin llegar a cumplirlas el resto del tiempo. Ofrecer una calidad constante es uno de los aspectos más importantes, pero también uno de los más difíciles, de la provisión de servicios. Cuando se ofrece un servicio, la calidad general será la combinación de la calidad de diversos procesos y componentes que juntos forman el servicio. Estos procesos y componentes crean una cadena cuyos eslabones influyen unos en otros y en la calidad del servicio. Una coordinación eficaz de los procesos y componentes requiere no sólo una calidad adecuada en la ejecución de cada proceso, sino también un nivel de calidad uniforme.

2.3 Qué es la Gestión de Servicios de TI 2.3.1 Concepto de Gestión de Servicios de TI A medida que aumenta la importancia de los servicios de TI para que las organizaciones puedan cumplir los objetivos de negocio, hay que dedicar cada vez más atención a la Gestión de Servicios de TI en lugar de al desarrollo de aplicaciones de TI. Un sistema de información (llamado en ocasiones aplicación de TI) sólo ayuda a alcanzar los objetivos corporativos si está a disposición de los usuarios y si dispone de mantenimiento y gestión operativa en caso de fallo o modificación. Dentro del ciclo de vida de los productos de TI, la fase de operaciones supone la mayor parte del gasto. El presupuesto operativo (compuesto fundamentalmente por costes de personal y costes acumulables asociados con el mantenimiento de sistemas de información) representa la parte más grande de los gastos en TI: una media en torno al 70% del gasto general en TI por empresa [Gartner2], mientras que el otro 30% se emplea en desarrollo de productos (o adquisiciones). Por lo tanto, el éxito de las Tecnologías de la Información exige disponer de estrategias, procesos y sistemas de Gestión de Servicios de TI que sean eficaces y eficientes. Esto es válido para cualquier tipo de organización, ya sea grande o pequeña, pública o privada, con servicios de TI centralizados o descentralizados, y con servicios de TI internos o externalizados. En todos los casos el servicio tiene que ser fiable, uniforme, de alta calidad y de un coste aceptable. La Gestión de Servicios de TI es la gestión de todos los procesos que cooperan para garantizar la calidad de los servicios de TI en producción, de acuerdo con los niveles de servicio acordados con el cliente. La Gestión de Servicios de TI incluye la iniciación, el diseño, la organización, el control, la provisión, el soporte y la mejora de los servicios de TI, adaptándose siempre a las necesidades de la organización del cliente. Existen diversas referencias que ofrecen guías prácticas para la Gestión de Servicios de TI. Entre ellas figuran ISO 20000 y modelos de madurez como CMMI, pero también un gran número de normas, mejores prácticas y marcos de trabajo, como ITIL®, o marcos de gobierno como CobiT®.

2 ¿Cómo se mide el gasto en TI? Informe de Gartner Research, 2003.


22


2.3.2 Ventajas y riesgos de la Gestión de Servicios de TI La principal ventaja de ITSM es que ofrece criterios cuantitativos de calidad para servicios de extremo a extremo con enfoque a cliente. Ésta es la única base para una gestión madura de la infraestructura de TI, representada por componentes de TI y ajenos a TI que se agrupan en servicios durante la fase de operación y otras fases del ciclo de vida del servicio. A continuación se da una lista de algunas ventajas y posibles problemas en el uso de mejores prácticas de Gestión de Servicios de TI. Aunque en ningún caso pretende ser una lista definitiva, contiene algunas de las ventajas que se pueden obtener y algunos de los errores que se pueden cometer cuando se emplean marcos de trabajo basados en procesos para la Gestión de Servicios de TI. Ventajas para el cliente o el usuario: • La provisión de servicios de TI tiene un mayor enfoque a cliente y la relación mejora gracias a los acuerdos sobre calidad del servicio. • Los servicios están mejor descritos, en el lenguaje del cliente y con más detalle. • Se gestiona mejor la disponibilidad, la fiabilidad, el coste y otros aspectos de la calidad de los servicios. • Se acuerdan los puntos de contacto para mejorar la comunicación con la organización de TI. Ventajas para la organización de TI: • La organización de TI desarrolla una estructura más clara, es más eficiente y se concentra más en los objetivos corporativos. • La organización de TI tiene más control sobre la infraestructura y los servicios de los que se ocupa, por lo que los cambios son más fáciles de gestionar. • Una buena estructura de procesos proporciona un marco de trabajo para la externalización eficaz de elementos de los servicios de TI. • La adopción de mejores prácticas fomenta un cambio de cultura hacia la prestación de servicios y favorece la introducción de sistemas de gestión de la calidad basados en la serie ISO 9000 o en ISO 20000. • Los marcos de trabajo pueden proporcionar marcos coherentes de referencia para las comunicaciones internas y con suministradores, así como para la normalización e identificación de procedimientos. Dificultades y aspectos a tener en cuenta: • La introducción se puede prolongar mucho tiempo y, si no se diseña y planifica correctamente, puede exigir un esfuerzo considerable e incluso un cambio de cultura en la organización; un exceso de ambición puede acabar siendo frustrante si no se alcanzan nunca los objetivos. • La calidad del servicio se puede resentir si las estructuras de procesos se convierten en un objetivo en sí mismas; en este caso, los procedimientos innecesarios o excesivamente complejos se consideran obstáculos burocráticos que hay que evitar siempre que sea posible. • Los servicios de TI no mejorarán si no se comprende bien qué es lo que debe hacer cada proceso, cuáles son los indicadores de rendimiento apropiados y cómo se pueden controlar los procesos.



23

• Es posible que la mejora en la provisión de servicios y las reducciones de costes no resulten suficientemente visibles si no se dispone de datos de referencia o si los objetivos definidos son incorrectos. • El éxito de la implantación requiere la participación y el compromiso del personal a todos los niveles de la organización; dejar el desarrollo de las estructuras de procesos a un departamento especializado puede hacer que dicho departamento quede aislado dentro de la organización y adopte una estrategia que no sea aceptada por los demás departamentos. • No se podrá sacar partido a los procesos (y, por tanto, el servicio no mejorará) si no se invierte lo suficiente en formación y herramientas de soporte; es posible que a corto plazo se necesiten recursos y personal adicionales si la organización está ya sobrecargada con actividades rutinarias de Gestión de Servicios de TI en las que no se sigan “mejores prácticas”.

2.3.3 Herramientas empleadas en la Gestión de Servicios de TI Para efectuar las tareas de Gestión de Servicios de TI se puede recurrir a innumerables accesorios automatizados que reciben el nombre de “herramientas”. Estas herramientas permiten automatizar las tareas de gestión, como por ejemplo las de monitorización o las de distribución de software. Otras herramientas, como las de centros de atención al usuario o las de Gestión del Servicio, facilitan la realización de las propias actividades. Estas herramientas permiten gestionar varios procesos y con frecuencia se denominan herramientas de flujo de trabajo, aunque no siempre son motores de flujo de trabajo. El hecho de que las Tecnologías de la Información se centren fundamentalmente en instalaciones automatizadas (para el procesamiento de información) ha llevado a la aparición en el mercado de un gran número de herramientas. Las herramientas también son muy importantes para lograr el objetivo de reducir los costes de forma continua. El uso de herramientas para distribución de software y de herramientas para el control remoto de ordenadores facilita enormemente la gestión de infraestructuras remotas. Esto permite crear centros de operaciones centralizadas muy eficientes, desde donde es posible monitorizar y suministrar los servicios con más calidad y un menor coste. Por otro lado, las herramientas de Gestión del Servicio hacen que sea mucho más fácil recopilar evidencias de cara a obtener la cualificación ISO 20000. El cumplimiento de muchos de los requisitos se puede demostrar con los registros almacenados en el sistema de Gestión del Servicio. A la hora de elegir herramientas de Gestión del Servicio, conviene tener en cuenta los requisitos de ISO 20000. A pesar de todos los sistemas y las herramientas de Gestión del Servicio, “un tonto con herramientas sigue siendo un tonto”. Por ello, el uso de herramientas tiene que estar basado en las mejoras de eficiencia conseguidas con los procesos de Gestión del Servicio. Las herramientas deben tener siempre en cuenta el contexto de personas, procesos y proveedores asociados, para poder dar los resultados esperados. Las organizaciones de TI siempre han tendido a prestar mucha atención a las herramientas y la tecnología, pero para alcanzar el éxito es preciso fijarse por igual en todos los aspectos.


24


2.4 Qué son los procesos 2.4.1 Ventajas y características de un enfoque basado en procesos Ventajas Todas las organizaciones intentan hacer realidad su visión, misión, estrategia, objetivos y políticas, lo que significa que tienen que emprender las actividades apropiadas para ello. Para poder controlar la serie de actividades que se realizan en las operaciones diarias, es importante que dichas actividades y sus vínculos se gestionen desde el principio hasta el final de la cadena de servicio. Un restaurante, por ejemplo, tendrá que adquirir alimentos frescos que pueden cambiar según la estación. Los chefs deben colaborar para ofrecer resultados uniformes, mientras que entre el servicio de mesa tampoco deben existir grandes diferencias. Un restaurante sólo recibirá tres estrellas si consigue ofrecer el mismo nivel de alta calidad durante un período prolongado de tiempo. No siempre ocurre así, ya que puede haber cambios de camareros o chefs que decidan abrir sus propios restaurantes. Ningún método garantiza el éxito permanente. Ofrecer una calidad elevada y constante también implica que hay que coordinar todas las actividades necesarias: cuanto mejor y más eficiente sea el trabajo de la cocina, mayor será la calidad de servicio que se puede ofrecer a los clientes. Entre estas actividades figuran, por ejemplo, comprar legumbres, mantener reservas, pedir materiales para publicidad, recibir a los clientes, limpiar las mesas, pelar patatas o preparar café. Con una lista tan poco estructurada, lo más probable es que se olvide algo y que el personal no sepa muy bien a qué atenerse. Por eso es mucho más recomendable estructurar las actividades. Lo mejor es hacerlo de tal manera que se pueda ver la contribución de cada grupo de actividades a los objetivos de la empresa, además de las relaciones entre ellas. La combinación lógica de actividades da como resultado puntos de transferencia bien definidos en los que es posible monitorizar la calidad de los procesos. En el ejemplo del restaurante, se podría separar la responsabilidad de comprar de la de cocinar, de manera que los chefs no tengan que comprar nada y se puedan concentrar en sus actividades principales. Aunque la mayor parte de los negocios siguen una organización jerárquica con departamentos que son responsables de las actividades de un grupo de empleados, los servicios de TI dependen por lo general de varios departamentos o disciplinas. Por ejemplo, un servicio de TI que dé acceso a los usuarios a un programa de contabilidad en un ordenador central afecta a diversas disciplinas: el centro de informática se encarga del acceso al programa y la base de datos, el departamento de datos y telecomunicaciones garantiza el acceso al centro de informática y el equipo de soporte informático se ocupa de ofrecer a los usuarios una interfaz de acceso a la aplicación. Los procesos que abarcan varios departamentos (equipos) pueden monitorizar la calidad de un servicio a partir de aspectos concretos de la calidad, como disponibilidad, capacidad, coste y estabilidad. Una organización de servicios intentará adaptar estos aspectos de la calidad a las demandas del cliente. La estructura de estos procesos puede garantizar el acceso a información útil sobre la provisión de servicios, de manera que sea posible mejorar la planificación y el control de servicios. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


25

Por otra parte, la descripción de la estructura de procesos proporciona un punto de referencia común y estable que puede ayudar a mantener la calidad de los servicios de TI durante y después de reorganizaciones, incluyendo cambios de suministradores y asociados. Esto hace que los proveedores de servicios estén menos expuestos a los cambios organizativos y sean mucho más flexibles, ya que pueden adaptar su organización a cambios constantes de condiciones pero sin alterar sus procesos esenciales. De esta forma, una tienda podría permanecer abierta durante unas obras de reconstrucción, por ejemplo. En la realidad pueden surgir problemas que hagan que esto sea más complicado en la práctica que en la teoría. La Gestión de Servicios de TI cubre todas las actividades del departamento de TI. Estas actividades se dividen en procesos que, una vez integrados, crean un marco de trabajo eficaz que aumenta la capacidad y madurez de la Gestión de Servicios de TI. Cada uno de estos procesos cubre una o más tareas de la organización de TI, como el desarrollo de servicios, la gestión de infraestructuras o el soporte de servicios. Este planteamiento de procesos hace posible describir las mejores prácticas de Gestión de Servicios de TI de manera independiente de la estructura de la organización. En la Sección 2.1.3 se explican otras ventajas del planteamiento de procesos.

Características Un proceso es un conjunto estructurado de actividades diseñado para cumplir un objetivo concreto. Las actividades no se organizan en procesos siguiendo la asignación existente de tareas o la división en departamentos, sino que se trata de una elección consciente. Una estructura de procesos permite con frecuencia detectar actividades de la organización que carecen de coordinación, que están duplicadas, que se ignoran o que son innecesarias. Lo que hay que hacer es fijarse en el objetivo del proceso y en las relaciones con otros procesos. La Figura 2.7 muestra cómo se pueden combinar actividades de distintos elementos organizativos para formar un proceso (indicado por las líneas quebradas). La Figura 2.8 muestra un ejemplo de proceso.

Gestión de TI

Desarrollo de software

SALIDA Operaciones

Centro de atención al usuario ENTRADA

Organización de proyectos

Mantenimiento de software y gestión de aplicaciones

Automatización de oficina y telecomunicaciones

Gestión de redes

Figura 2.7 Procesos y departamentos (ejemplo)


26


Si la estructura de procesos de una organización está descrita con claridad, tiene que indicar: • Qué es lo hay que hacer. • Cuáles son las entradas y los resultados esperados. • Cómo medir si los procesos ofrecen los resultados esperados. • Cómo afectan los resultados de un proceso a los otros procesos. A lo largo de la última década, la Gestión de Servicios de TI ha sido el planteamiento basado en procesos y enfocado a servicios de lo que anteriormente se conocía como gestión de tecnologías de la información. Este desplazamiento de la infraestructura a los procesos ha llevado a la aparición del término “Gestión de Servicios de TI” para describir una disciplina basada en procesos y enfocada a cliente.

Presentación de solicitud de cambio Registro Aceptación para tratamiento Clasificación Planificación Aceptación para construcción Construcción Pruebas Aceptación para implantación Evaluación Cierre

Figura 2.8 Gestión de cambios: ejemplo de flujo de procesos

Los procesos deben tener siempre un objetivo definido, de manera que los procesos de Gestión de Servicios de TI contribuyan a la calidad de los servicios de TI. La gestión de la calidad y el control de procesos son parte de la organización y sus políticas.

2.4.2 Medida y control de procesos Los procesos están formados por dos tipos de actividades: las actividades que contribuyen a la consecución de metas (actividades operativas que se ocupan de la respuesta) y las actividades asociadas con la gestión de metas (actividades de control). Las actividades de control garantizan que las actividades operativas (el flujo de trabajo) se realizan en el momento previsto y en el orden correcto. En el procesamiento de cambios, por ejemplo, siempre se garantiza que se realiza una prueba antes (y no después) de la puesta en producción de una entrega. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


27

La Figura 2.9 ilustra esta filosofía, que también se conoce como modelo ERSCR (ITOCO). Según este modelo, un proceso es una serie de actividades efectuadas para convertir una entrada en una salida y, finalmente, en un resultado: • Entrada • Respuesta • Salida • Control • Resultado normas y políticas

CONTROL

ENTRADA

RESPUESTA

SALIDA

eficiencia

RESULTADO eficacia

requisitos

consecución de objetivos

Figura 2.9 Diagrama de procesos basado en el modelo ERSCR

La entrada está relacionada con los recursos que se utilizan en el proceso. La salida (comunicada) describe los resultados inmediatos del proceso, mientras que el resultado indica los resultados a largo plazo del proceso (en términos de efectos significativos). Las actividades de control permiten asociar la entrada y la salida de cada uno de los procesos con políticas y normas, con el fin de ofrecer información sobre los resultados que se van a obtener de los procesos. El control regula la entrada y la respuesta en caso de que los parámetros de respuesta o salida no cumplan las normas o políticas mencionadas. De esta forma se generan cadenas de procesos que indican cuáles son las entradas de la organización y cuál es el resultado, así como puntos de monitorización en las cadenas para verificar la calidad de los productos y servicios que ofrece la organización. Las normas para la salida de cada proceso se tienen que definir de manera que toda la cadena de procesos en el modelo cumpla el objetivo corporativo. Si la salida de un proceso satisface los requisitos establecidos, se dice que el proceso es eficaz para transformar su entrada en la salida. Para que sea realmente eficaz, también hay que tener en cuenta el resultado. Si las actividades del proceso se realizan además con el mínimo coste y esfuerzo, se dice que el proceso es eficiente. La gestión de procesos utiliza la planificación y el control para garantizar que los procesos se ejecutan de una forma eficaz y eficiente.


28


2.4.3 Roles necesarios para la gestión de procesos Los roles son conjuntos de responsabilidades, actividades y autoridades de una persona o equipo. Cada proceso debe tener un propietario, que es responsable de los resultados del proceso. El gestor del proceso es responsable de la ejecución y estructura del proceso e informa al propietario del proceso. Los operarios del proceso se encargan de actividades definidas, sobre las que informan al gestor del proceso. La dirección de la organización puede proporcionar control basándose en evaluaciones de la calidad de cada proceso. En la mayor parte de los casos se habrán acordado previamente las normas y los correspondientes indicadores de rendimiento, lo que permite dejar el control diario al gestor del proceso. El propietario del proceso evalúa los resultados basándose en un informe de indicadores de rendimiento y verifica que cumplen la norma establecida. Sin unos indicadores claros, el propietario del proceso tendría dificultades para determinar si el proceso está bajo control y si se están implantando las mejoras planificadas. Una persona o equipo puede desempeñar múltiples roles; por ejemplo, los roles de gestor de la configuración y gestor de cambios pueden corresponder a una misma persona.

2.5 Qué es la mejora continua Como se explicó en la Sección 2.1.3, la mejora continua es uno de los ocho principios de la gestión de la calidad en ISO 9000. Es necesaria para mejorar el rendimiento y aumentar la satisfacción de los clientes y otras partes interesadas, y debe ser un objetivo permanente de la organización. La mejora continua mantiene en movimiento la rueda del ciclo PDCA, como se explica en la Figura 2.1 de la Sección 2.1.1. La siguiente sección explica el funcionamiento de los modelos de madurez y su relación con las evaluaciones de capacidad.

2.5.1 Modelos de madurez Desde el momento en que Richard Nolan introdujo en 1973 su “modelo por etapas” para aplicar las Tecnologías de la Información en las organizaciones, son muchos los que han propuesto modelos de mejora gradual. Estos modelos se convirtieron muy pronto en instrumentos adecuados para desarrollar programas de mejora de la calidad, ayudando así a las organizaciones a ascender en la escala de madurez. Es muy fácil encontrar docenas de variaciones sobre este tema en campos que van desde el desarrollo de software, la adquisición, la ingeniería de sistemas, las pruebas de software, el desarrollo de sitios Web, los Data Warehouses o la ingeniería de seguridad, hasta los centros de atención al usuario y la gestión del conocimiento. Después del modelo por etapas de Nolan en 1973, la aplicación más interesante de este tipo de modelos se debe al Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon en los Estados Unidos, que propuso su Modelo de Madurez de la Capacidad de Software Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


29

(SW-CMM). El modelo CMM se copió y aplicó en la mayor parte de los casos mencionados anteriormente, convirtiéndose en la práctica en el modelo de madurez estándar. Posteriormente aparecieron nuevas ediciones del modelo CMM, como CMMI (Integración de CMM). Otro modelo de madurez bien conocido es el modelo de madurez global para TI. El modelo CMMI describe los siguientes niveles de madurez organizativa: • Nivel de Madurez 1: Inicial - Procesos específicos y caóticos. La organización no dispone de un entorno estable para dar soporte a los procesos. El éxito depende de la competencia y los esfuerzos heroicos de las personas que forman la organización, y no del uso de procesos de eficacia probada. A pesar de este caos, las organizaciones con nivel de madurez 1 producen con frecuencia productos y servicios que funcionan, aunque suelen salirse del presupuesto y casi nunca cumplen el calendario previsto. • Nivel de Madurez 2: Reproducible (gestionado) - Los proyectos de la organización garantizan que los procesos se planifican y ejecutan según la política establecida. Los procesos afectan a los grupos de interés adecuados y son ejecutados por personas cualificadas y con los recursos necesarios para producir salidas controladas. También son sometidos a un programa de monitorización, control y revisión, y se evalúa hasta qué punto responden a las descripciones de procesos. • Nivel de Madurez 3: Definido - Los procesos están bien caracterizados y documentados y se describen en normas, procedimientos, herramientas y métodos. El conjunto de procesos estándar de la organización, que es la base para el nivel de madurez 3, está bien definido y mejora con el tiempo. Estos procesos estándar se utilizan para garantizar la coherencia en toda la organización. Los proyectos establecen sus procesos adaptando el conjunto de procesos estándar de la organización de acuerdo con las directrices correspondientes. • Nivel de Madurez 4: Gestionado cuantitativamente - La organización y sus proyectos definen objetivos cuantitativos de calidad y rendimiento de procesos y los utilizan como criterios para la gestión de procesos. Los objetivos cuantitativos se basan en las necesidades del cliente, los usuarios finales, la organización y los encargados de implantar procesos. La calidad y el rendimiento de procesos se entienden en términos estadísticos y se gestionan durante toda la vida de los procesos. • Nivel de Madurez 5: Optimización - Este nivel se centra en la mejora continua del rendimiento de los procesos mediante mejoras incrementales e innovadoras de procesos y tecnologías. Se han definido objetivos cuantitativos de mejora de los procesos de la organización, se revisan continuamente para que reflejen cambios en los objetivos de negocio y se utilizan como criterios para mejorar el proceso de gestión. Se miden y evalúan los efectos de las mejoras desplegadas, comparándolos con los objetivos cuantitativos de mejora de los procesos. Tanto los procesos definidos como el conjunto de procesos estándar de la organización se someten a actividades de mejora cuantificables. Estos modelos se aplicaron posteriormente en modelos de gestión de la calidad, como el de la Fundación Europea para la Gestión de la Calidad (EFQM). Además de los modelos generales de gestión de la calidad, existen diversas prácticas aceptadas por el sector como Six Sigma o TQM, que complementan a ITIL®.


30


Las normas y marcos existentes de mejores prácticas sirven de guía a las organizaciones que persiguen la “excelencia operativa” en la Gestión de Servicios de TI. El tipo de guía que requiere cada organización varía en función de su fase de desarrollo. Las normas ISO 9000 y 20000 hacen hincapié en la definición, descripción y diseño de procesos y en el desarrollo y mantenimiento de un sistema de calidad que satisfaga sus requisitos, por lo que se pueden considerar como una herramienta que permite a la organización alcanzar y mantener un nivel de madurez previamente definido para el sistema.

2.5.2 Evaluaciones de capacidad y su relación con modelos de madurez Una evaluación compara el rendimiento de un proceso con un estándar de rendimiento, que puede estar estipulado en un acuerdo de nivel de servicio (SLA) o bien ser un estándar de madurez o un promedio calculado con empresas del mismo sector, en cuyo caso se habla de una evaluación comparativa. Una evaluación para ISO 20000 es claramente una evaluación de capacidades, ya que indica si se cumplen o no los requisitos de ISO 20000. En caso de cumplirse los requisitos, la organización tiene capacidad para ofrecer servicios con el nivel de calidad especificado en la norma. Una evaluación de madurez indica el nivel de madurez alcanzado, lo que permite identificar las acciones necesarias para llegar al siguiente nivel de madurez. Las evaluaciones son la mejor forma de dar respuesta a la pregunta “¿cuál es la situación actual?” y determinar cuánto falta para alcanzar la “situación deseada”. El uso de un marco de trabajo aceptado ayuda a realizar evaluaciones comparativas de la madurez. Hay que tener en cuenta que el nivel deseado de madurez o rendimiento de un proceso depende del impacto que ese proceso tenga sobre los procesos de negocio del cliente. Lo primero que hay que determinar es la relación entre procesos de negocio, servicios de TI, sistemas de TI y componentes. A continuación se evalúa la eficacia y la eficiencia de cada componente, lo que facilita la identificación de áreas de mejora. Es muy importante definir claramente el objeto de la evaluación, que debe estar basado en los objetivos y el uso previsto de los informes. Una evaluación se puede realizar a tres niveles: • Sólo proceso - Únicamente se evalúan componentes del proceso incluidos en la descripción del proceso. • Personas, proceso y tecnología - Se evalúan también los conocimientos, los roles y el talento de los gestores y empleados que participan en el proceso, así como la tecnología que da soporte al proceso. • Completo - Se evalúan también la capacidad y el nivel de preparación para aceptar el proceso, así como la posibilidad de formular y seguir una estrategia y unos objetivos para el proceso. Todos estos resultados se pueden comparar con el modelo de madurez seleccionado.



31

Las evaluaciones resultan de utilidad en las siguientes fases: • Planificar - Como punto de partida (línea de referencia) para el rendimiento del proceso. • Hacer - Para medir si las estimaciones son correctas. • Verificar - Para completar el balance e identificar otras posibles mejoras. Las evaluaciones ofrecen las siguientes ventajas: • Pueden medir ciertas partes de un proceso independientemente de las demás y determinar el impacto de cada componente sobre el resto del proceso. • Se pueden repetir. • Se pueden utilizar para realizar evaluaciones comparativas. Por el contrario, las evaluaciones presentan los siguientes inconvenientes: • Únicamente representan un momento concreto y no dan información sobre la dinámica cultural de una organización. • Pueden dejar de ser un medio para convertirse en un fin en sí mismas. • Exigen mucho trabajo. • Los resultados siguen dependiendo de puntos de vista subjetivos y por tanto no son totalmente objetivos, aunque las medidas lo sean. • Es posible que entrevistadores y entrevistados no acaben de comprender lo que significa una pregunta, lo que llevaría a una mala comunicación y resultados poco precisos. A continuación se explicará como se pueden evaluar los sistemas de gestión de la calidad.

Evaluación de procesos en el sistema de gestión de la calidad Cuando se evalúa un sistema de gestión de la calidad hay que hacerse cuatro preguntas básicas sobre cada uno de los procesos evaluados: • ¿Está el proceso identificado y definido correctamente? • ¿Se han definido responsabilidades? • ¿Se han implantado y se mantienen los procedimientos? • ¿Es eficaz el proceso para alcanzar los resultados deseados? El resultado de la evaluación dependerá de las respuestas a estas preguntas. La evaluación de un sistema de gestión de la calidad puede variar en alcance e incluir diferentes actividades, como auditorías, revisiones y autoevaluaciones.

Auditoría del sistema de gestión de la calidad Las auditorías se utilizan para determinar el grado de cumplimiento de los requisitos del sistema de gestión de la calidad. Los resultados de una auditoría permiten evaluar la eficacia del sistema de gestión de la calidad y detectar oportunidades de mejora. Las auditorías internas son las realizadas por, o en nombre, de la propia organización y pueden ser la base para una declaración interna de conformidad. Las auditorías externas son las realizadas por clientes de la organización o por otras personas en representación de los clientes.


32


Las auditorías de terceros son las realizadas por organizaciones externas independientes. Estas organizaciones suelen estar acreditadas y emiten certificaciones o registros de conformidad con requisitos como los de ISO 9001. ISO 19011 contiene instrucciones sobre auditorías.

Revisión del sistema de gestión de la calidad La alta dirección debe realizar evaluaciones sistemáticas de la idoneidad, la adecuación, la eficacia y la eficiencia del sistema de gestión de la calidad respecto a la política y los objetivos de calidad. También puede ser necesario determinar si hay que adaptar la política y los objetivos de calidad a los cambios en las necesidades y expectativas de las partes interesadas. La revisión incluye la decisión sobre la necesidad de acciones. Entre otras fuentes de información, en la revisión del sistema de gestión de la calidad se utilizan los informes de auditorías.

Autoevaluación La autoevaluación de una organización consiste en una revisión completa y sistemática de las actividades y resultados de la organización, utilizando como referencia el sistema de gestión de la calidad o un modelo de excelencia. La autoevaluación permite tener una visión general del rendimiento de la organización y del grado de madurez del sistema de gestión de la calidad. También ayuda a identificar áreas que necesitan mejoras en la organización, así como a determinar prioridades.

Evaluación comparativa de itSMF Todas las características anteriores se pueden combinar en un proyecto de evaluación comparativa como el que está siendo desarrollado actualmente por itSMF Holanda. La parte que se refiere al modelo de procesos es un diseño basado en la norma ISO 20000 y ampliado con gestión de operaciones. Cada cuestionario detallado combina las cuestiones específicas de 20000-1 y 200002 con preguntas del modelo de madurez CMMI. Como resultado se obtienen listas detalladas de actividades de mejora del rendimiento que facilitan la obtención de la certificación. Los resultados deben ser validados por un consultor externo, ya que de lo contrario las organizaciones tienden a asignarse una puntuación un 25% más alta de la real. También se necesita una base de datos de confianza. Conocer la posición de la organización con respecto a la norma y el modelo CMM, junto con los resultados de otras organizaciones en cada campo, permite disponer de una información muy importante y hace que sea más fácil definir objetivos significativos y realistas.


Capítulo 3

La posición de ISO 20000 en la Gestión de Servicios de TI 3.1 Panorama actual de normas y marcos de trabajo La siguiente lista muestra varios marcos de trabajo que son importantes en el campo de la Gestión de Servicios de TI, junto con su propósito y el tipo de organización al que van dirigidos: • CMMI − Propósito: Aumentar la facilidad de uso de los modelos de madurez para ingeniería de software y otras disciplinas mediante la integración de muchos modelos diferentes en un solo marco de trabajo. − Tipo de organización: Organizaciones que buscan mejorar los procesos en toda la empresa. • CobiT® − Propósito: Proporcionar una estructura uniforme para comprender, implantar y evaluar capacidades, rendimiento y riesgos de TI con el objetivo fundamental de cumplir los requisitos de negocio. − Tipo de organización: Organizaciones que deseen estructurar su gobierno. • ISO 9000 − Propósito: Demostrar la capacidad de una organización para satisfacer los requisitos de sus clientes a través de un Sistema de Gestión de la Calidad (QMS) bien documentado, flexible, estructurado y orientado al cliente. − Tipo de organización: Cualquier organización que desee demostrar que tiene capacidad para entregar productos o servicios siguiendo constantemente los mismos procesos. • ISO 15504 − Propósito: Proporcionar una guía que permita realizar valoraciones de capacidad con el fin de mejorar procesos. − Tipo de organización: Organizaciones tecnológicas que deseen valorar su capacidad en cada una de las fases de un proceso y determinar la eficacia de sus procesos en relación con los objetivos de la organización. • ISO 20000 − Propósito: Fomentar la adopción de un planteamiento de procesos integrados que garantice la entrega de servicios bien gestionados que cumplan los requisitos del negocio y los clientes.


34


− Tipo de organización: Todos los proveedores de servicios de TI que deseen adoptar la norma global y quieran demostrar que tienen capacidad para entregar servicios de TI de calidad a clientes internos o externos. • ISO 27001 − Propósito: Reducir la vulnerabilidad de una organización a riesgos de seguridad de la información mediante el uso de un Sistema de Gestión de la Seguridad de la Información (ISMS). − Tipo de organización: Organizaciones que deseen mantener los riesgos bajo control y proteger sus activos. • ITIL® − Propósito: Proporcionar mejores prácticas para la Gestión de Servicios de TI, así como un conjunto de procesos integrados para la provisión y el soporte de servicios de TI de alta calidad. − Tipo de organización: Organizaciones que deseen normalizar sus procesos de Gestión de Servicios de TI según un marco de mejores prácticas universalmente aceptado. • Six Sigma − Propósito: Ofrecer a las empresas las herramientas necesarias para realizar medidas estadísticas y aumentar la capacidad de sus procesos de negocio o de TI, reduciendo el número de defectos para maximizar el rendimiento y minimizar la variación de procesos. − Tipo de organización: Organizaciones que deseen conocer mejor el rendimiento de sus procesos y detectar las mejores oportunidades de mejora. • Normas específicas de empresa Cada organización puede tener sus propias normas específicas. Estas normas se pueden basar en los modelos y marcos de trabajo anteriormente citados, pero están adaptadas especialmente para cada organización. Las normas específicas de empresa pueden ser políticas relativas a distintos aspectos de la Gestión de Servicios de TI (como políticas de seguridad) o bien normas que afecten a la normalización o la arquitectura de TI. Por ejemplo, Microsoft ha desarrollado MOF (Microsoft Operations Framework) a partir de ITIL para dar soporte a diferentes productos Microsoft. Las normas específicas de empresa deben satisfacer los requisitos de alto nivel de ISO 20000-1. Por otra parte, tiene que haber alineación entre la enorme variedad de normas específicas de empresa, marcos de trabajo y normas ISO. Al iniciar el proceso que lleva a la certificación ISO 20000 es importante analizar con todo cuidado las normas internas para compararlas y alinearlas con los requisitos de ISO 20000‑1. La organización a la que se aplica la norma es uno de los grupos de interés, aunque normalmente no es el único. Un grupo de interés se define como: Un grupo de interés es cualquier persona, grupo u organización que pueda afectar, ser afectada o considerarse afectada por cualquier acción iniciada por un sistema de una organización, y que por lo tanto tenga derecho, parte, pretensión o interés en dicho sistema u organización. Esta definición indica que también son grupos de interés los clientes, los suministradores, los miembros de los proveedores de servicios y otras partes.


La posición de ISO 20000 en la Gestión de Servicios de TI

35

3.2 Conceptos de prácticas de certificación Al recopilar la información básica de los procesos de Gestión de Servicios de ITIL® en una norma internacional de carácter formal, BSI y ahora ISO dotan a los proveedores de servicios de los medios necesarios para determinar el cumplimiento de estas mejores prácticas. Hasta la creación de BS 15000, el proceso formal de certificación estaba enfocado a individuos (Fundamentos de ITIL®, Responsable de la Gestión de Servicios ITIL®, Profesional ITIL®), no a organizaciones. La certificación ISO 20000 no es una certificación formal en ITIL®; de hecho, la norma no menciona a ITIL® ni siquiera en la lista de referencias. Pese a ello, los contenidos de la versión 2 de ITIL® se pueden encontrar fácilmente en la norma (véase Sección 3.3.1). Con ISO 20000, un proveedor de servicios puede obtener un certificado internacional en Gestión de Servicios de TI orientado a organizaciones. Es de esperar que esto estimule la aceptación de la Gestión de Servicios de TI como un campo de gran importancia.

3.2.1 Certificación de empresas La norma ISO/IEC 20000-1:2005 ha sido desarrollada como norma de certificación para proveedores de servicios. Un proveedor de servicios que desee hacer público su compromiso con la calidad en la Gestión de Servicios de TI puede solicitar la certificación independiente para su organización de TI.

Roles y responsabilidades Aunque cualquiera podría asegurar que una organización satisface los requisitos de ISO 20000, el programa de certificación que gestiona itSMF UK aporta credibilidad al proceso. Las entidades autorizadas por itSMF UK (Entidades de Certificación Registradas o RCBs) son las que conceden la certificación. En la mayor parte de los países hay entidades locales de certificación (o sucursales de entidades internacionales) que pueden llevar a cabo una auditoría de certificación. Las entidades de certificación tienen que estar registradas ante la entidad nacional de certificación. Muchas de estas entidades nacionales están unidas en el Foro Internacional de Acreditación (IAF). Los certificados emitidos por entidades que hayan sido acreditadas por miembros del Programa de Reconocimiento Internacional (MLA) del IAF se consideran válidos en todo el mundo, ya que el MLA avala su credibilidad. Este proceso de certificación y acreditación ha funcionado con éxito durante muchos años para todos los certificados ISO y es una garantía para los clientes internacionales.

Campo de aplicación El campo de aplicación consiste en el cumplimiento de las condiciones para la certificación. ISO 20000 tiene un campo de aplicación muy amplio, lo que significa que los sistemas de Gestión del Servicio son válidos para una gran variedad de proveedores de servicios. ISO 20000 es aplicable a proveedores de servicios internos y externos, a empresas grandes y pequeñas o a organizaciones comerciales y no comerciales. Un proveedor de servicios que desee obtener la certificación puede ser una organización completa o una parte de una organización, pero no puede ser un grupo de organizaciones; tiene que ser una entidad legal única. Otra condición es que el proveedor de servicios debe mantener el control sobre la gestión de todos los procesos ISO 20000, lo que significa que todos sus servicios y actividades


36


deben estar controlados por su sistema de Gestión del Servicio. Un proveedor de servicios que no tenga control sobre estos procesos no podrá optar a una certificación ISO 20000. Por ejemplo, si una empresa controla sólo algunos procesos, como la gestión de incidencias y la gestión de problemas, no puede recibir la certificación ISO 20000. Tiene que ofrecer un servicio de TI que incluya todos los procesos ISO 20000. Por otro lado, esto no significa que un proveedor de servicios no pueda externalizar las actividades de TI. Si, por ejemplo, un proveedor de servicios externaliza el centro de atención al usuario y las actividades asociadas en los procesos de gestión de incidencias y gestión de problemas, habrá actividades que ya no realice por sí mismo. No obstante, si ha definido cuál debe ser el rendimiento de esas actividades y puede demostrar que mantiene el control de la gestión a través de SLAs, análisis periódicos de informes y la adopción de acciones, es posible que pueda recibir certificación para los servicios de TI que la organización ofrece a sus clientes.

Alcance El alcance del servicio prestado tiene que estar descrito en una declaración de alcance. Un proveedor de servicios puede obtener la certificación para todos los servicios que ofrece o bien para un país o cliente concreto, siempre y cuando lo especifique en una declaración de alcance que valide la certificación para cada situación específica. Por ejemplo, si una gran empresa multinacional sólo ha recibido certificación para los servicios de TI internos en un país concreto, debe indicarlo en la declaración de alcance de ese certificado. La estructura típica de una declaración de alcance es la siguiente: El suministrado por a desde . Como se ve, se debe mencionar el servicio (o servicios). También hay que incluir en la declaración de alcance el nombre de la organización (entidad legal), el nombre del receptor del servicio y la ubicación o área geográfica desde donde se suministra el servicio.

Ventajas de la certificación ISO 20000 proporciona un marco de trabajo y un enfoque sistemático que permite gestionar los procesos de Gestión de Servicios de TI de manera que el servicio de TI resultante satisfaga las expectativas del cliente. La implantación de ISO 20000 ahorra dinero y aumenta la eficacia y eficiencia de los procesos de negocio. La mayor parte de las empresas que han obtenido la certificación ISO 20000 consiguen también procesos más eficientes, clientes más satisfechos y servicios de más calidad. Para los clientes, la certificación de los proveedores según las normas ISO significa la seguridad de que el desarrollo y la provisión de los servicios se realiza siguiendo documentos de referencia globalmente aceptados. Por supuesto, esto quiere decir que clientes y suministradores están capacitados para competir en los mercados de todo el mundo.



37

Obtener la certificación conlleva numerosas ventajas, aunque las empresas deben asegurarse de perseguir la certificación por los motivos correctos: • Para llegar a nuevos clientes, puesto que cada vez son más las empresas que consideran la certificación ISO 20000 como un requisito esencial para establecer una relación comercial con un nuevo proveedor. • Para acceder a mercados globales gracias al amplio reconocimiento de la norma ISO 20000. • Para disponer de mejor documentación para diversos fines. • Para dar a la empresa una ventaja competitiva y demostrar su compromiso con la calidad del servicio.

Proceso de certificación Una vez se han ejecutado los procesos de implantación para el sistema de gestión de la calidad y se ha realizado una valoración interna que indica que dichos procesos satisfacen los requisitos de ISO 20000, el proveedor de servicios está listo para iniciar el proceso de certificación. El proceso de certificación consta de siete pasos: 1. Cuestionario 2. Solicitud de valoración 3. Auditoría previa opcional 4. Auditoría inicial (fase 1) 5. Auditoría de certificación (fase 2) 6. Auditorías de vigilancia 7. Auditorías de renovación Estos pasos se discuten a continuación. El proceso de certificación se inicia cuando la entidad de certificación seleccionada envía un cuestionario de datos sobre los requisitos y la empresa. Este cuestionario proporciona a la entidad de certificación la información que necesita para poder enviar un presupuesto. Una vez tomada la decisión de continuar el proceso de certificación con la entidad seleccionada, se cumplimenta el formulario de solicitud y se envía a la entidad de certificación. Posteriormente se organiza una visita inicial por parte de un auditor jefe. Esta visita sirve para que los representantes de la empresa conozcan al auditor jefe que va a evaluar el sistema de gestión para el que se solicita la certificación ISO 20000. El auditor explica el proceso de valoración y efectúa una revisión del sistema de gestión existente. Se acuerda una fecha para la valoración y un calendario de auditoría. La química interna del equipo es una parte importante de cualquier auditoría, como lo es también tener buenos conocimientos del proceso, la empresa y el auditor jefe. Una auditoría previa es una evaluación de alto nivel que indica el grado de cumplimiento de los requisitos de ISO 20000 por parte de la empresa. Si una organización no se ha sometido nunca a auditorías para obtener una ISO, esta auditoría previa preparará a la dirección y al personal para lo que vendrá después. El auditor señala posibles problemas para que se puedan resolver en este momento y reducir así el riesgo de incumplimiento durante la auditoría real. Este análisis previo se puede implantar inmediatamente en el sistema de gestión para eliminar posibles problemas antes de que se inicie la auditoría oficial. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

38


La auditoría inicial verifica la implantación del sistema de gestión empleando diversos controles, que incluyen la documentación de todas las políticas y procedimientos relacionados. El auditor planifica la auditoría de certificación (fase 2). En esta sesión se discute y acuerda la declaración de alcance. También se realiza una valoración inicial de la documentación del sistema de gestión y de los documentos de procesos. Los fallos o incumplimientos detectados por la auditoría se incorporarán al Plan de Acciones Correctivas (CAP). El cliente deberá documentar cómo piensa llevar a cabo los CAPs y presentar la información a la entidad de certificación para su visto bueno. Durante la auditoría de certificación se efectúa una valoración objetiva de las prácticas y los procedimientos organizativos con respecto al sistema de gestión documentado (revisado en la auditoría inicial). El auditor buscará registros (pruebas) de que el Sistema de gestión funciona según las especificaciones del sistema de gestión documentado. Una vez finalizada la valoración, el auditor presentará los resultados por escrito en un informe. Los incumplimientos y observaciones pasarán al CAP si se considera necesario. Si la auditoría finaliza con éxito y se decide conceder la certificación, se emite un certificado y se autoriza a la organización a utilizar la marca de la entidad de certificación y la marca de la correspondiente certificación ISO 20000. También se acuerda un calendario de auditorías de vigilancia que se realizan periódicamente para comprobar que se siguen cumpliendo los requisitos de la norma ISO 20000 y proponer CAPs si es necesario. Estas auditorías de vigilancia se llevan a cabo a lo largo de un ciclo de 3 años con el fin de verificar el correcto funcionamiento del sistema de gestión. A ellas hay que añadir las auditorías internas y las actividades continuas de monitorización y gestión dentro de la organización. La frecuencia real de estas actividades varía dependiendo de la RCB, pero en general se sigue el siguiente patrón: • Se llevan a cabo auditorías de vigilancia periódicas (normalmente cada 6-12 meses). • En cada auditoría se verifica la ejecución de los CAPs pendientes. • Durante un período de 3 años se verifica el cumplimiento de todos los requisitos obligatorios. • Se realiza una auditoría de una muestra representativa de todos los demás controles (de manera que durante el ciclo de vigilancia se revisen todos los controles incorporados al sistema de gestión). La auditoría de renovación se realiza cada 3 años y es similar a la auditoría original. Normalmente lleva menos tiempo, puesto que el auditor ya conoce los sistemas (salvo que haya habido un cambio de alcance o de otro tipo). Se evalúan todos los controles para comprobar que el sistema de gestión sigue funcionando correctamente y, si es así, se renueva el certificado para otros 3 años. En caso contrario, las mejoras necesarias, los incumplimientos y las observaciones se incorporan al Plan de Mejora del Servicio (SIP) y al CAP para su resolución. A continuación se vuelve a iniciar el proceso de auditorías de vigilancia durante 3 años.

3.2.2 Certificación personal La cualificación internacional de profesionales en ISO 20000 (de acuerdo con el programa de cualificación) es cada vez más importante, tanto para organizaciones como para profesionales individuales. Alcanzar un nivel óptimo de profesionalismo debe ser una de las piedras angulares de los programas de mejora de servicios de TI. La implicación del personal en dichos programas se puede incentivar ofreciendo a los empleados una certificación reconocida internacionalmente. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


39

Para obtener la certificación ISO 20000, las empresas tienen que demostrar que cuentan con un sistema de gestión de la calidad y con procesos ITSM (Gestión de Servicios de TI) bien definidos. Sin embargo, la norma ISO 20000-1: 2005 no se extiende demasiado en los requisitos que debe cumplir el personal que participa en la provisión de los servicios. En la introducción se puede leer: Se da por supuesto que la ejecución de las cláusulas de esta parte de ISO 20000 se confiará a personas competentes y debidamente cualificadas. ¿Qué quiere decir esto? ¿Qué nivel de conocimiento de los procesos ITSM deben tener estas “personas competentes y debidamente cualificadas”? ¿Y cómo es posible medir de manera objetiva el cumplimiento de este requisito? Resulta difícil aplicar la norma y auditar su cumplimiento si no se dispone de una terminología común y de una descripción de roles aceptada por todos. La existencia de programas educativos y de cualificación que incluyan definiciones claras y requisitos para los empleados puede facilitar notablemente la aplicación de la norma. Por otra parte, los clientes tienden a confiar más en organizaciones que pueden presentar certificados para demostrar que su personal está debidamente cualificado. Un proyecto de certificación en ISO 20000 exige un alto grado de compromiso y conocimientos a la práctica totalidad del personal que participa en la provisión de servicios de TI. Los principios de la gestión de la calidad no deben ser conocidos sólo por los consultores, los gestores y los instructores. Los empleados de nivel operativo también deben recibir formación sobre calidad, Gestión de Servicios de TI y procesos de gestión y mejora en general, con el fin de aumentar sus conocimientos y su motivación. El auditor, por su parte, debe tener amplios conocimientos sobre Gestión de Servicios de TI para poder realizar auditorías de empresas según los requisitos de ISO 20000. La tabla 3.1 muestra los roles que participan en la Gestión de Servicios de TI y en la gestión de la calidad. Para cada uno de estos roles se debe definir un plan de formación que especifique los conocimientos y competencias necesarios. Estos roles son sólo genéricos y no deben ser interpretados como descripciones de funciones o perfiles profesionales reales. Algunos de estos roles se pueden combinar en una sola función. Rol de Gestión de Servicios de TI Director de TI

Responsable de la Gestión del Servicio/ Profesional de TI Consultor de servicios de TI

Operador ITSM

Descripción breve Es responsable de (parte de) la organización de TI. Normalmente es también el propietario de uno o más procesos de Gestión de Servicios de TI. Implanta, mejora y mantiene la provisión de servicios de TI y los procesos subyacentes de una organización de TI. Este rol suele incluir también las tareas de gestor de proceso. Asesora a una organización de TI sobre la introducción, mejora y mantenimiento de servicios de TI y los procesos subyacentes. Efectúa una o más de las actividades de un proceso.


40


Rol de Gestión de Servicios de TI Administrador de sistemas

Descripción breve Instala y mantiene uno o más componentes de la infraestructura de TI. Jefe de proyecto Gestiona proyectos de infraestructura o ITSM (mejora de la calidad). Gestor de la calidad Es responsable del sistema de gestión de la calidad de la organización de TI. Consultor de gestión de la calidad Asesora a una organización de TI sobre la introducción, mejora del servicio y mantenimiento de un sistema de gestión de la calidad. Auditor externo Valora el sistema de gestión de la calidad de un proveedor de servicios de TI según los requisitos de ISO 20000 para conceder una certificación externa. Auditor interno Valora el sistema de gestión de la calidad de un proveedor de servicios de TI según los requisitos de ISO 20000 para detectar oportunidades de mejora. Tabla 3.1 Roles de Gestión de Servicios de TI y gestión de la calidad del servicio

Ventajas del programa de cualificación Obtener un certificado independiente es la mejor prueba de que se han satisfecho plenamente los requisitos del curso. Demuestra el compromiso de la persona por convertirse en alguien competente y valioso para su organización y para los clientes a los que da servicio. Conseguir un certificado ayuda a los participantes a: • Reforzar sus conocimientos y mejorar su rendimiento laboral. • Ponerse al día en el campo de ISO 20000. • Aumentar su valor ante el empresario. • Aspirar a empleos que exigen un conocimiento especializado de ISO 20000. • Recibir el reconocimiento del sector y de sus compañeros de trabajo. • Seguir siendo competitivos y abrir nuevas oportunidades de desarrollo profesional. El certificado aporta también ventajas para el negocio de la empresa: • Mejor uso de los recursos humanos. • Calidad demostrada de su personal de TI. • Posibilidad de seleccionar a personas cualificadas para empleos que exijan conocimientos de ISO 20000. • Conocimientos específicos precisos para realizar un trabajo de TI. • Incentivos, bonificaciones y retos para los empleados. El programa de cualificación de ISO 20000 ha hecho que muchas empresas reconozcan la necesidad de dar formación a su personal de Gestión de Servicios de TI. Cualquier organización que decida usar el marco de trabajo ISO 20000 para mejorar sus servicios de TI tiene que ser consciente de que muchos empleados participarán de una manera o de otra. Es probable que se necesiten muy pocos expertos, pero es fundamental que el personal esté familiarizado con la terminología y tenga conocimientos básicos sobre los principios de gestión de la calidad del servicio.



41

Un curso sobre fundamentos de ISO 20000 ofrece a los participantes una visión general de ISO 20000 y de los principales procesos empleados para gestión de la calidad. También abre la puerta a los cambios de actitud, cultura y procedimientos que se necesitan para mejorar el enfoque a cliente y la provisión de servicios de TI. El certificado de Fundamentos de ISO 20000 es una recompensa para los participantes en el curso y una forma de medir los conocimientos y la importancia de ISO 20000 en su organización. El programa de certificación de ISO 20000 también ayuda a evaluar a los proveedores de formación y los materiales para el curso. Para desarrollar e implantar los planes de mejora de la calidad de los servicios de TI en una empresa es necesario contar con profesionales bien cualificados en este campo. La piedra angular de este perfil profesional debe ser una certificación adecuada en Gestión de Servicios de TI, que al fin y al cabo es la base para la gestión de la calidad del servicio.

Proveedores de cursos acreditados La calidad de un curso de ISO 20000 puede depender de diversos factores: • La calidad de los instructores. • La planificación del curso. • La idoneidad del lugar. • La adaptación de los materiales del curso a ISO 20000. • La experiencia de los participantes. • El uso de ejemplos prácticos. • La asignación de tareas. • Las posibilidades de discusión en grupo. Las entidades examinadoras mantienen una estrecha colaboración con las organizaciones de formación acreditadas con el fin de monitorizar la calidad de los cursos e introducir mejoras si es preciso. Para obtener una cualificación reconocida internacionalmente suele ser necesario que el candidato asista a un curso de formación impartido por un proveedor acreditado. Las reglas de acreditación garantizan: • La calidad de todos los proveedores de formación sobre ISO 20000. • Los conocimientos y experiencia de los profesores en materia de Gestión de Servicios de TI, calidad y educación. • La calidad de los materiales de formación. • La adaptación de los contenidos del curso a los requisitos para los exámenes del programa de cualificación en gestión de la calidad del servicio. Los requisitos que deben cumplir los proveedores de cursos acreditados están publicados en los sitios Web de las entidades examinadoras. Con el fin de garantizar la imparcialidad en la acreditación de proveedores de cursos y en la puntuación de los exámenes, la entidad examinadora no ofrece formación sobre gestión de la calidad del servicio y es ajena a los intereses de mercado de los proveedores de cursos.


42


Programa de cualificación Una empresa que desee obtener la certificación ISO 20000 deberá dar formación a todos los empleados que participen en la gestión de la calidad de los servicios de TI acerca de los requisitos concretos de las Partes 1 y 2 de la norma, así como sobre temas más generales relacionados con la gestión de la calidad. Hasta 2007, una persona sólo podía optar a la certificación ISO 20000 a través de itSMF UK, que convoca dos exámenes de ISO 20000: • Auditor de ISO/IEC 20000 • Consultor de ISO/IEC 20000 Desde 2007 se puede acudir también al Registro Internacional de Auditores Certificados (IRCA), una entidad internacional de certificación para auditores de sistemas de gestión. IRCA convoca un examen de Auditor de Sistemas de Gestión de Servicios de Tecnologías de la Información (ITSMS) basado en ISO 20000 e ISO 19011, que tiene varios niveles: • Auditor interno provisional de ITSMS • Auditor interno de ITSMS • Auditor provisional de ITSMS • Auditor de ITSMS • Auditor jefe de ITSMS • Auditor principal de ITSMS También itSMF Francia y AFAQ AFNOR Certification han unido sus fuerzas en el desarrollo de un “programa de certificación de auditores jefe para ISO/IEC 20000-1”: Auditor Jefe de Gestión de Servicios de TI de ICA® (ISO/IEC 20000-1). ICA® tiene acreditación ISO 17024 concedida por COFRAC y ofrece este programa de certificación (que también cumple la norma internacional ISO 17021) para garantizar que los auditores certificados son personas con experiencia en ITSM, ISO/IEC 20000-1 y metodología de auditorías. En 2007, EXIN y TÜV SÜD desarrollaron un programa de formación y cualificación: “Programa de cualificación en ISO/IEC 20000 para personas”. Este programa está diseñado según las normas de acreditación ISO (ISO 17024), por lo que puede ser reconocido por el Foro Internacional de Acreditación (IAF). El programa de formación y cualificación de EXIN/TÜV SÜD ofrece diversas certificaciones dirigidas a los siguientes roles de ITSM: • Fundamentos de ISO/IEC 20000 • Profesional de ISO/IEC 20000 (5 posibles certificados) • Gestor/consultor de servicios de TI según ISO/IEC 20000 • Gestor/consultor sénior de servicios de TI según ISO/IEC 20000 • Auditor interno de ISO/IEC 20000 • Auditor jefe de ISO/IEC 20000 La Figura 3.1 muestra el programa de cualificación. La certificación personal ofrece actualmente un programa de cualificación que reconoce internacionalmente los conocimientos de una persona sobre gestión de la calidad de servicios de TI.



43

Gestión de Servicios de TI según ISO/IEC 20000 Programa básico de cualificación para personal Resumen de certificados ofrecidos RAMA DE GESTIÓN

RAMA DE AUDITORÍA

FILTRO

Auditor interno

Auditor jefe

FILTRO

Gestor/consultor sénior de servicios de TI

Gestor/consultor de servicios de TI

NIVEL PROFESIONAL

Gestión y mejora de procesos ITSM

Control de servicios de TI

Soporte de servicios de TI

Provisión de servicios de TI

Alineación entre el negocio y las Tecnologías de la Información

NIVEL BÁSICO Fundamento

Figura 3.1 Programa de cualificación en ISO 20000 de EXIN/TÜV SÜD para personal

La diferencia principal con las otras opciones está en la estructura. El programa de certificación de EXIN/TÜV SÜD está formado por “bloques”, cada uno de los cuales demuestra la competencia necesaria para un rol determinado. De esta forma, el bloque “Fundamentos de ISO 20000” puede formar parte de distintas “ramas de certificación”. Por ejemplo, un auditor o consultor que comience el proceso de certificación ISO 20000 tendrá que aprobar el examen de Fundamentos de ISO 20000 y los exámenes apropiados del nivel profesional para demostrar que conoce todos los procesos. Esto significa aprobar tres de cinco módulos posibles, incluyendo el módulo obligatorio de Gestión y Mejora. Una vez superado el nivel profesional, el auditor deberá seguir adelante por la rama de auditoría para adquirir conocimientos más especializados, mientras que el consultor tendrá que elegir la rama de consultoría/gestión para especializarse en la implantación de ISO 20000 y las dificultades que conlleva. La tabla 3.2 indica la certificación más adecuada para cada rol de ITSM y gestión de la calidad.


44



 

 

 

 

 

   



 

ICA - Auditor jefe de Gestión de Servicios de TI (ISO/IEC 20000-1)

 

IRCA - Auditor de sistemas ITSM (varios niveles)

   

itSMF - Consultor de ISO/IEC 20000



itSMF - Auditor de ISO/IEC 20000



EXIN/TÜV SÜD - Auditor jefe de ISO/IEC 20000

 

EXIN/TÜV SÜD - Auditor interno de ISO/IEC 20000

EXIN/TÜV SÜD - Gestor/ consultor sénior de servicios de TI según ISO/IEC 20000 EXIN/TÜV SÜD - Profesional de ISO/IEC 20000

Rol de Gestión de Servicios de TI Director de TI Responsable de la Gestión del Servicio/ Profesional de TI Consultor de servicios de TI Operador ITSM Administrador de sistemas Jefe de proyecto Rol de gestión de la calidad del servicio Gestor de la calidad Consultor de gestión de la calidad del servicio Auditor externo Auditor interno

EXIN/TÜV SÜD - Fundamentos de ISO/IEC 20000

Certificación




 

 

Tabla 3.2 Roles de ITSM y gestión de la calidad relacionados con la certificación ISO 20000

En noviembre de 2007, ISEB anunció que había iniciado conversaciones con itSMF UK con el fin de participar en el programa de certificación, añadiendo un examen de nivel básico. Los detalles de este acuerdo se añadirán a esta publicación cuando sean públicos. La sección de Referencias en el Apéndice contiene hipervínculos para acceder a las distintas organizaciones que ofrecen certificación.

3.3 Concepto de ISO 20000 ISO 20000 es una norma internacional cuyo objetivo es garantizar la prestación de servicios gestionados de TI con una calidad aceptable para los clientes de un proveedor de servicios de TI.

3.3.1 Historia y titularidad de ISO 20000 La norma ISO 20000 fue publicada el 15 de diciembre de 2005 por la Organización Internacional de Normalización, que convertía así la Norma Británica 15000 (BS 15000) en una norma internacional.



45

BS 15000 tenía su origen en DISC PD 0005, el Código de Práctica para la Gestión de Servicios de TI, que había sido definido para la Institución Británica de Normalización (BSI) por un grupo de trabajo formado por expertos británicos a finales de la década de 1990. Su objetivo era llenar el vacío que había dejado ITIL, cuyos primeros libros (versión 1) carecían de instrucciones concretas sobre el diseño práctico de procesos para Gestión de Servicios de TI. DISC PD 0005 especificaba claramente requisitos y ofrecía recomendaciones. Aunque el punto de partida era ITIL, su desarrollo dio pie a que se incluyeran también otros procesos. Esto contribuyó a aclarar las relaciones entre los distintos procesos. La Figura 3.2 muestra de una forma distinta los procesos de provisión y soporte de servicios de la versión 2 de ITIL. Se identificaron nuevos grupos, incluyendo los procesos de relación y los informes del servicio, que ya se han incorporado a la versión 3 de ITIL3. Este modelo no varió cuando la norma pasó a BS 15000 e ISO 20000, aunque se modificaron los nombres de los procesos. El modelo no incluye procesos para gestión de infraestructuras TIC ni para gestión de aplicaciones.

PROCESOS DE PROVISIÓN DE SERVICIO Gestión de la Capacidad

Gestión del Nivel de Servicio

Gestión de la Disponibilidad y la Continuidad del Servicio

Informes del Servicio

Gestión de la Seguridad de la Información Presupuestos y Contabilidad de los Servicios de TI

PROCESOS DE CONTROL Gestión de la Configuración Gestión de Cambios

PROCESO DE ENTREGA Gestión de la Entrega

PROCESOS DE RESOLUCIÓN Gestión de Incidencias Gestión de Problemas

PROCESOS DE RELACIÓN Gestión de Relaciones con el Negocio Gestión de Proveedores

Figura 3.2 La Gestión de Servicios de TI según DISC PD 0005 e ISO 20000

itSMF UK publicó BS 15000 en noviembre de 2000. Esta Norma Británica especificaba los requisitos para un sistema de gestión de la calidad, así como los requisitos de calidad de los distintos procesos. En sólo unos años, itSMF UK (que también actuaba como entidad de certificación responsable) recibió un gran número de peticiones de empresas que deseaban una certificación. El interés internacional continuó aumentando hasta que se convirtió en una norma internacional. 3 E stos libros de ITIL no habían sido aún publicados y DISC PD005 se adelantó en algunos aspectos, como en el reconocimiento de la gestión de incidencias y la gestión de entregas como procesos independientes. Los nombres de los procesos gestión de la continuidad y gestión financiera para servicios de TI en las actualizaciones de ITIL en 2000 y 2001 también se basaron en DISC PD005.


46


Las normas internacionales son sometidas a revisión al menos una vez cada 5 años por parte de los comités responsables de la organización ISO. El comité decide si una norma tiene que ser confirmada, revisada o retirada. En el caso de ISO 20000, actualmente (finales de 2007) se están desarrollando al menos dos partes adicionales: ISO 20000-3: Guía sobre el cumplimiento de ISO/IEC 20000-1 (alcance y campo de aplicación), e ISO 20000-4: Modelo de referencia para procesos de Gestión del Servicio.

ISO 9000 e ITIL® en ISO 20000 ITIL® no es el único precursor de ISO 20000. La norma para Gestión de Servicios de TI también debe mucho a ISO 9000, la norma internacional para gestión de la calidad. ISO 9000 describe sólo procesos generales, para la gestión organizativa, la gestión de recursos, la realización del producto o servicio, y para la medición, el análisis y la mejora. Tal como se explicó en la discusión sobre el planteamiento de procesos, en la Sección 2.1.3, los procesos de Gestión de Servicios en ITIL® son los procesos de realización de ISO 9000 para la organización de servicios de TI. La tabla 3.3 resume todos los procesos de ISO 9000, ISO 20000 y las versiones 2 y 3 de ITIL®. Los procesos que aparecen en una misma fila de la tabla son muy similares y se solapan. ISO 9000 presenta una falta evidente de procesos para la realización del producto. Los procesos de Gestión de Servicios de ITIL® y los requisitos de ISO 20000 vienen a paliar esta carencia.



Estrategia del Servicio, Diseño del Servicio, Mejora Continua del Servicio Gestión del nivel de servicio Informes del servicio

Centro de atención al usuario (primer solape)

Gestión de proveedores

Gestión de la Cartera de Servicios Diseño del Servicio, Operación del Servicio

Estrategia del Servicio

Proceso de mejora CSI

Mejora Continua del Servicio

ITIL® versión 3

Gestión de relaciones con el negocio Gestión de proveedores

(+ v1 Enlace con el cliente) (v1 Gestión de las instalaciones + relaciones con terceros)

Procesos de provisión de servicio

Gestión del nivel de servicio Informes del servicio

Provisión de Servicio

Gestión del nivel de servicio Informes del servicio (no un proceso autónomo, sino parte de la gestión del nivel de servicio)

Gestión del Servicio

Procesos de relación

Planificación e implantación de la Gestión del Servicio Planificación de la Gestión de Servicios (Planificar) Implantación de la Gestión de Servicios y provisión del servicio (Hacer) Monitorización, medida y revisión (Verificar) Mejora continua (Actuar) Planificación e implantación de servicios nuevos o modificados

ISO 20000 Requisitos para un sistema de gestión Responsabilidad de la dirección, requisitos de documentación, competencia, concienciación y formación

Perspectiva del negocio

Planificación de la implantación de la Gestión del Servicio

ITIL® versión 2

Procesos de realización Todos los procesos que ofrecen la salida prevista por la organización

Procesos relacionados con el cliente

Planificación de la realización del producto

Procesos para gestión de recursos Provisión de los recursos necesarios para procesos de gestión organizativa, realización y medida

ISO 9000 Procesos para gestión organizativa Planificación estratégica, definición de políticas y objetivos, comunicación, garantía de disponibilidad de los recursos necesarios y revisiones de gestión (fases Planificar y Hacer del ciclo PDCA) Procesos para medida, análisis y mejora Procesos necesarios para medir y recopilar datos para análisis de rendimiento y mejora de la eficacia y la eficiencia. Incluyen la medida, monitorización y auditoría de procesos, así como acciones correctivas y preventivas. Son parte integral de los procesos de gestión, gestión de recursos y realización (fases Verificar y Actuar del ciclo PDCA).

La posición de ISO 20000 en la Gestión de Servicios de TI 47

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net Gestión de cambios

Gestión de cambios

Fuera de ISO 20000: Gestión de infraestructuras TIC Gestión de aplicaciones

Gestión de entregas

Proceso de entrega Gestión de entregas

Gestión de la configuración

Gestión de la configuración

Centro de atención al usuario

Gestión de problemas Procesos de control

Procesos de resolución Gestión de incidencias

Gestión de la seguridad de la información

Gestión de la capacidad

Presupuestos y contabilidad de los servicios de TI Gestión de la disponibilidad y la continuidad del servicio

ISO 20000

Gestión de problemas

Centro de atención al usuario

Gestión de incidencias

Soporte de Servicio

Gestión de la demanda (no un proceso autónomo, sino parte de la gestión de la capacidad) Gestión de la seguridad

Gestión financiera de los servicios de TI Gestión de la continuidad de los servicios de TI Gestión de la disponibilidad Gestión de la capacidad

ITIL® versión 2

Tabla 3.3 Procesos de las versiones 2 y 3 de ITIL®, ISO 20000 e ISO 9000

Operación del Servicio Gestión de incidencias Gestión de peticiones Centro de atención al usuario (segundo solape) Gestión de problemas Transición del Servicio, Operación del Servicio Gestión de la configuración y activos del servicio Gestión de cambios Planificación y soporte de la Transición (primer solape) Validación y pruebas del servicio Evaluación Centro de atención al usuario (tercer solape) Transición del Servicio Gestión de entregas y despliegues Planificación y soporte de la Transición (segundo solape) Fuera de ISO 20000: Gestión de accesos Gestión de eventos Operaciones de TI Gestión del conocimiento Monitorización y control

Gestión de la seguridad de la información

Gestión de la continuidad de los servicios de TI Gestión de la disponibilidad Gestión de la capacidad Gestión de la demanda

ITIL® versión 3 Gestión del Catálogo de Servicios Gestión financiera

ISO 9000

48 ISO/IEC 20000 – Una introducción


49

Pasado, presente y futuro de ITIL® La Biblioteca de la Infraestructura de Tecnología de Información (ITIL®) ofrece un marco de trabajo común para todas las actividades del departamento de TI con el fin de aumentar la madurez de la provisión, el soporte y el control de los servicios de TI. Fue desarrollada en la década de 1980 por la Agencia Central de Informática y Telecomunicaciones (CCTA, actualmente Oficina de Comercio del Gobierno, OGC) del Gobierno Británico. Ante la escalada en los costes de TI, el objetivo fundamental fue utilizar los recursos de TI de forma más eficiente y con un mayor control de costes. La Biblioteca de la Infraestructura de Tecnología de Información nació como una colección de libros, cada uno de los cuales cubría una práctica concreta de la Gestión de Servicios de TI. Tras la publicación inicial, el número de libros aumentó rápidamente hasta los 48 volúmenes con la versión 1 de ITIL®, que posteriormente sería adoptada y utilizada por muchas organizaciones, incluyendo también el sector privado. Los contenidos de la biblioteca fueron revisados a partir de 1999 para incorporar las prácticas más recientes, la informática distribuida e Internet. El resultado de esta actualización fue la versión 2 de ITIL® (2000), cuyo objetivo fue hacer ITIL® más accesible (y asequible) para quienes desearan adoptarlo. La versión 2 de ITIL® estructuró las publicaciones en “conjuntos” lógicos que agrupaban directrices de procesos relacionados en los distintos aspectos de la gestión, las aplicaciones y los servicios de TI. Los libros y disciplinas de la versión 2 de ITIL® fueron los siguientes: • Soporte de Servicio • Provisión de Servicio • Gestión de Infraestructuras TIC • Planificación de la implantación de la Gestión de Servicios • Gestión de Aplicaciones • Perspectiva del negocio • Gestión de la Seguridad • Gestión de Activos Software En diciembre de 2005, la OGC promulgó una “Actualización de ITIL”, comúnmente conocida como ITIL® versión 3 (v3). El proyecto de actualización finalizó con la publicación de cinco nuevos textos principales y un glosario Web, el 30 de mayo de 2007. La “nueva ITIL” presenta la Gestión de Servicios de TI como un ciclo continuo de servicios de diseño, transferencia y operación de servicios. No obstante, antes de diseñar un servicio es necesario definir la estrategia de servicios de TI. Los procesos se deben mejorar de forma continua durante todo el ciclo de vida del servicio. Todo ello da como resultado las cinco fases siguientes, que se muestran también en la Figura 3.3: 1. Estrategia del Servicio - Explica cómo diseñar, desarrollar e implantar la Gestión del Servicio como una capacidad organizativa y como un activo estratégico. 2. Diseño del Servicio - Se ocupa del diseño y desarrollo de servicios y de procesos de Gestión del Servicio.


50


3. Transición del Servicio - Se ocupa de gestionar cambios, los riesgos y el aseguramiento de la calidad, y de implantar diseños de servicios de modo que en las operaciones del servicio se puedan controlar los servicios y la infraestructura. 4. Operación del Servicio - Explica cómo aumentar la eficacia y la eficiencia mientras se ejecutan servicios en el entorno operativo. 5. Mejora Continua del Servicio - Comprueba la calidad de los servicios y la aumenta mediante mejoras en el diseño, la introducción y la operación de servicios.

o

er Op

ac

ici Serv o

ITIL V3

n nsició del Serv ici Tra

ontinua del S ra C erv ejo ici o o i ic v r e S l de Estrategia d el

Dis e

ño

M

ión

del Servicio

Figura 3.3 Modelo de ciclo de vida de la versión 3 de ITIL®

Para simplificar, es posible trazar una correspondencia entre las fases del ciclo de vida del servicio de la versión 3 de ITIL® y las fases del ciclo PDCA. Las fases Estrategia del Servicio y Diseño del Servicio podrían corresponder a la fase Planificar del ciclo de Deming, mientras que las fases Transición del Servicio y Operación del Servicio equivaldrían a la fase Hacer. La Mejora Continua del Servicio (CSI) representa las fases Verificar y Actuar del ciclo PDCA, junto con la monitorización y los informes sobre el rendimiento de los procesos. Por supuesto, cada una de las fases del ciclo de vida se debe mejorar de forma continua. Aunque no hay ninguna relación formal entre ISO 20000 e ITIL® (no existe ningún control definido o implícito entre ambas), la norma está basada en los libros de la versión 2 de ITIL®. Esto significa que los cambios en el contenido, el alcance y la terminología de la versión 3 de ITIL® no aparecen todavía reflejados en ISO 20000. No obstante, una de las muchas consignas que recibieron los autores de la versión 3 de ITIL® fue la de adaptar la nueva versión a ISO 20000. Aunque sigue habiendo algunas diferencias entre la norma e ITIL®, la alineación entre ambas no había sido nunca tan evidente. Por ejemplo, ISO 20000 trata las peticiones de servicio como incidencias del mismo modo que la versión 2 de ITIL®, mientras que la versión 3 establece una separación formal en gestión de incidencias, gestión de peticiones y gestión de eventos. Es de suponer que la próxima actualización Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


51

de ISO 20000 reflejará las mejores prácticas incluidas en la versión 3 de ITIL®. Para ello puede ser necesario algún tiempo, puesto que las normas ISO deben superar un riguroso proceso de control de cambios para garantizar la calidad del producto final. En cualquier caso, no se recomienda esperar hasta que aparezca la siguiente versión de la norma, ya que se pueden obtener importantes ventajas de la versión actual sin necesidad de que pase tanto tiempo. Por otra parte, lo más probable es que un auditor acepte la adopción de la versión 3 como prueba de que se cumplen los requisitos de ISO 20000, ya que la norma admite que el proveedor de servicios puede utilizar cualquiera de los distintos marcos de trabajo existentes para la Gestión del Servicio.

ISO 9000 La Organización Internacional de Normalización (ISO) ha existido desde 1947. Las primeras normas ISO se referían a artículos de ingeniería y tecnología, como pernos, tuercas, tornillos y clavijas. La primera versión de ISO 9000, la norma ISO para sistemas de gestión de la calidad, se publicó en 1987. ISO 9000 es una norma para un sistema de gestión genérico. Especifica requisitos para todas las organizaciones, independientemente del tipo de actividades realizadas, el tamaño del negocio o la complejidad de los procesos de negocio. La organización que implanta un sistema de gestión genérico puede ser un parque de atracciones, un proveedor de servicios de TI, un departamento del gobierno o una pequeña empresa de fontanería, por ejemplo. La última versión de la norma ISO 9000 data del año 2000. La versión anterior era de 1994 y tenía reputación de ser un “tigre de papel”. Los requisitos de ISO 9001:1994 formaban una larga lista de documentos, lo que obligaba a muchas organizaciones a generar muchos papeles para demostrar el cumplimiento. La situación es diferente con ISO 9001:2000, una norma que se centra en el rendimiento, en la mejora continua y en la satisfacción de los clientes. La cantidad de documentación se puede reducir mucho en función de la organización, la complejidad de sus procesos y los niveles de competencia de los empleados. Tal como establecen las directrices de documentación en el sitio Web de ISO (www.ISO.org), ISO 9001 requiere un sistema documentado de gestión de la calidad en lugar de un sistema de documentos (ISO, 2001). La familia de normas ISO 9000 incluye ISO 9000, ISO 9001:2000 e ISO 9004. ISO 9000 contiene los fundamentos y la terminología para sistemas de gestión de la calidad. ISO 9001 especifica los requisitos que debe cumplir un sistema de gestión de la calidad, mientras que ISO 9004 contiene directrices para la mejora del rendimiento.

3.3.2 Propósito y ventajas de ISO 20000 El objetivo de ISO 20000, heredado de BS 15000, consiste en “proporcionar una norma de referencia común para todas las empresas que ofrezcan servicios de TI a clientes internos o externos”. Dada la importancia de la comunicación en la Gestión del Servicio, uno de los objetivos más importantes de la norma es crear una terminología común para los proveedores de servicios, sus suministradores y sus clientes.


52


La norma fomenta la adopción de un planteamiento de procesos integrados para la Gestión de Servicios de TI (véase Sección 3.3.4). Tiene en cuenta todos los elementos que son obligatorios para una buena Gestión del Servicio (es decir, aquellos que son comunes y exigidos por todos los proveedores de servicios para la Gestión del Servicio), pero no se ocupa directamente de requisitos particulares. En las especificaciones ISO 20000-1 se declara: ISO 20000-1:2005 define los requisitos que debe cumplir un proveedor de servicios para ofrecer servicios gestionados con una calidad aceptable para sus clientes. Puede ser utilizada: • Por negocios que vayan a ofertar sus servicios. • Por empresas que exijan un enfoque coherente a todos los proveedores de servicios en una cadena de suministro. • Por proveedores de servicios que deseen evaluar comparativamente su Gestión de Servicios de TI. • Como base para una valoración independiente. • Por una organización que tenga que demostrar que tiene capacidad para ofrecer servicios que satisfagan los requisitos de los clientes. • Por una organización que desee mejorar su servicio mediante la aplicación eficaz de procesos para monitorizar y mejorar la calidad del servicio.

3.3.3 Diferencia entre ISO 20000-1 e ISO 20000-2 La norma ISO 20000 consta de dos partes reunidas bajo el título general de Gestión del Servicio de Tecnologías de la Información: • Parte 1: Especificaciones - Publicada como ISO 20000-1: 2005, es la especificación formal de la norma. • Parte 2: Código de buenas prácticas - Publicada como ISO 20000-2: 2005, describe con detalle las mejores prácticas y ofrece instrucciones y recomendaciones para los procesos de Gestión del Servicio dentro del alcance de la norma formal. En general, la Parte 1 de la norma contiene una lista de controles obligatorios (“obligaciones”) que deben cumplir los proveedores de servicios si desean recibir la certificación, mientras que la Parte 2 incluye una lista de directrices y sugerencias (“recomendaciones”) para proveedores de servicios.

3.3.4 Grupos de procesos ISO 20000 fomenta la adopción de un planteamiento de procesos integrados. Una organización que quiera desarrollar un sistema de gestión de la calidad tiene que identificar su propósito, definir las políticas y objetivos y determinar los procesos y su secuencia. Para planificar un proceso, una organización tiene que definir las actividades que componen ese proceso. ISO 20000-1 requiere diversas actividades. Concretamente define 170 “obligaciones”, mientras que ISO 9001 contiene 135. También hace referencia a procesos e interfaces de procesos, aunque es poco clara sobre las relaciones entre procesos. Uno de los motivos para ello es que dichas



53

relaciones dependen de la aplicación en una organización. Otra razón es que son demasiado complejas para incorporarlas a un modelo. La subsección 1 de ISO 20000-1 contiene una imagen que muestra “varios procesos de Gestión del Servicio estrechamente relacionados” (Figura 3.2). La Figura 3.4 ilustra los otros tres tipos de procesos contemplados en ISO 9000 (para gestión organizativa, para gestión de recursos y para medida, análisis y mejora) en relación con los procesos de ISO 20000. Estos procesos están incluidos en la Subsección 3.1 de ISO 20000, “Responsabilidad de la dirección”, en la Subsección 4, “Planificación e implantación de la Gestión del Servicio”, y en la Subsección 5, “Planificación e implantación de servicios nuevos o modificados”. Los procesos de mejora se encuentran también en la Subsección 4 de ISO 20000-1.

Sistema de Gestión Responsabilidad de la Dirección

Requisitos de Documentación

Competencia, Concienciación y Formación

Planificación e Implantación de la Gestión del Actuar Act Servicio

Planificar Plan Hacer

Planificación e Implantación de Servicios Nuevos o Modificados

Check Verificar

Procesos de Provisión de Servicio • Gestión de la Capacidad • Gestión de la Disponibilidad y la Continuidad del Servicio

• Gestión del Nivel de Servicio • Informes del Servicio

• Gestión de la Seguridad de la Información • Presupuestos y Contabilidad de los Servicios de TI

Procesos de Control • Gestión de la Configuración • Gestión de Cambios

Proceso de Entrega • Gestión de Entregas

Procesos de Relación Procesos de Resolución • Gestión de Incidencias • Gestión de Problemas

• Gestión de Relaciones con el Negocio • Gestión de Proveedores

Figura 3.4 Sistema de gestión de la calidad de Servicios de TI según ISO 20000

Las especificaciones ISO 20000-1 dicen: Las relaciones entre los procesos dependen de su aplicación dentro de una organización y, generalmente son demasiado complejas para incorporarlas a un modelo. Como consecuencia, este diagrama (Figura 3.2) no muestra relaciones entre procesos. La lista de objetivos y controles contenida en ISO 20000-1 no es exhaustiva, y una organización puede considerar que son necesarios objetivos y controles adicionales para Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

54


cumplir con sus necesidades particulares de negocio. La naturaleza de la relación de negocio, entre el proveedor de servicios y el negocio, determinará cómo se implantarán los requisitos de ISO 20000-1, para cumplir el objetivo global. ISO 20000-1 es una norma basada en procesos y, como tal, no está orientada a la evaluación de productos. No obstante, las organizaciones que se dediquen al desarrollo de herramientas, productos y sistemas de Gestión del Servicio pueden utilizar ambas partes, ISO 20000-1 y el Código de buenas prácticas, para hacer que dicho desarrollo siga las mejores prácticas de la Gestión del Servicio. El Código de buenas prácticas ISO 20000-2 dice: ISO 20000-2 es el resultado del consenso del sector sobre normas de calidad para procesos de Gestión de Servicios de TI. El objetivo de estos procesos es garantizar el mejor servicio posible que satisfaga las necesidades de negocio del cliente con los recursos acordados; es decir, un servicio profesional, con eficiencia en costes y con riesgos conocidos y bien gestionados. La gran variedad de términos que se emplean para un mismo proceso, así como entre procesos y grupos funcionales (y puestos de trabajo), puede hacer que la Gestión del Servicio resulte un tema confuso para el nuevo gestor, hasta el punto de que la terminología se convierta en una barrera que impida la definición de procesos eficaces. La fácil comprensión de la terminología es una de las ventajas más importantes y tangibles de ISO 20000. ISO 20000-2 recomienda a los proveedores de servicios que adopten una terminología común y un enfoque más coherente de la Gestión del Servicio. De esta forma dispondrán de una base común para la mejora de servicios, así como de un marco de trabajo para los suministradores de herramientas de Gestión del Servicio. ISO 20000-2 sirve de guía a los auditores y puede ser muy útil a los proveedores de servicios que deseen planificar mejoras en el servicio o que se vayan a someter a una auditoría de ISO 20000-1. Los procesos para gestión de recursos están incluidos en la Subsección 3.3 de ISO 20000 y en los procesos de presupuestos y contabilidad de los servicios de TI, en la Subsección 6.4: “Debe haber políticas y procedimientos claros para: a) elaboración y control de presupuesto y contabilidad de todos los componentes, incluyendo activos de TI, recursos compartidos, gastos generales, servicios suministrados externamente, personal, seguros y licencias.” Así, mientras ISO 9000 considera los procesos de gestión de recursos como uno de tres tipos posibles de procesos de soporte, ISO 20000 sólo los menciona como una subsección de los procesos de provisión de servicio.

3.3.5 Documentación, procesos, procedimientos y registros necesarios Por lo que respecta a documentación, procesos, procedimientos y registros, la Sección 3.2 de ISO 20000-1 establece: Los proveedores de servicios deben facilitar los documentos y registros necesarios para garantizar la eficacia en la planificación, operación y control de la Gestión del Servicio, incluyendo: a) Políticas y planes documentados de Gestión del Servicio b) Acuerdos de nivel de servicio documentados Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


55

c) Procesos y procedimientos documentados requeridos por esta norma d) Registros requeridos por esta norma Se deberán definir procedimientos y responsabilidades para la creación, revisión, aprobación, mantenimiento, eliminación y control de los distintos tipos de documentos y registros. NOTA: La documentación puede estar en cualquier formato o soporte.4 Como ocurre en cualquier norma ISO/IEC, todos los procesos descritos en la Parte 1 son de obligado cumplimiento para la organización que se somete a la auditoría. Todos ellos deben ir acompañados de documentos y registros, incluyendo una descripción del proceso. Sin los documentos y registros de apoyo, no es posible verificar que todos los procesos obligatorios cumplen su descripción y presentan los niveles necesarios de eficacia y eficiencia. Las organizaciones tienen libertad para diseñar procesos y procedimientos adicionales para cumplir los requisitos de ISO 20000-1. Aunque ISO no define el término “procedimiento”, requiere “procedimientos documentados y bien mantenidos para cada proceso o conjunto de procesos” (Sección 4.2, “Implantación de la Gestión del Servicio y provisión de los servicios”). El glosario de la versión 3 de ITIL® define un procedimiento de la siguiente manera: Un procedimiento es un documento que contiene los pasos que especifican cómo llevar a cabo una actividad. Los procedimientos están definidos como parte de procesos. Por lo tanto, la descripción de los procesos debe incluir también la descripción de los procedimientos. Hay también algunos procedimientos adicionales que están relacionados con el alcance de esta norma pero quedan fuera de los procesos mencionados, como por ejemplo un proceso o procedimiento de auditoría. La tabla 3.4 contiene procesos y procedimientos que se mencionan explícitamente, aunque hay que recordar que en ningún caso se trata de una lista exhaustiva. (Sub)Sección de la Parte 1 3.2 Requisitos de la documentación 4.2 Implantación de la Gestión del Servicio y provisión de los servicios (Hacer) 4.3 Monitorización, medición y revisión (Verificar) 4.4 Mejora continua (Actuar) 6.1 Gestión del nivel de servicio 6.4 Presupuestos y contabilidad de los servicios de TI

Proceso o procedimiento exigido Procedimientos de documentación Procedimientos documentados y bien mantenidos para cada proceso o conjunto de procesos Realización de auditorías Mejora de la Gestión del Servicio Soporte de procedimientos de SLA Presupuesto y contabilidad de todos los componentes Distribución de costes indirectos y asignación de costes directos a los servicios Control financiero y de autorizaciones

4 Por ejemplo: discos ópticos o electrónicos, fotografías, copia maestra de software o sitio Web de intranet.


56

(Sub)Sección de la Parte 1 6.5 Gestión de la capacidad

6.6 Gestión de la seguridad de la información 7.2 Gestión de relaciones con el negocio 7.3 Gestión de Proveedores

8.2 Gestión de incidencias

8.3 Gestión de problemas 9.1 Gestión de la configuración

9.2 Gestión de cambios 10.1 Gestión de entregas


Proceso o procedimiento exigido Monitorización de la capacidad del servicio Ajuste del rendimiento del servicio Provisión de la capacidad adecuada Investigación de todas las incidencias de seguridad Adopción de acciones de gestión Proceso de quejas Proceso de satisfacción del cliente Control del suministrador: • Revisión de contratos • Disputas contractuales • Fin de servicio Procesos de suministradores y subcontratistas Gestión del impacto de incidencias Definición de registro, priorización, impacto en el negocio, clasificación, actualización, escalado, resolución y cierre formal de todas las incidencias Identificación, minimización y eliminación del impacto de incidencias y problemas Comprobación de la integridad de sistemas, servicios y componentes de los servicios Registro de deficiencias, inicio de acciones correctivas y preparación de informes Control de la autorización e implantación de cambios de emergencia Actualización y modificación de la información de configuración y los registros de cambios

Tabla 3.4 Procesos o procedimientos exigidos por ISO 20000-1

Los proveedores de servicios deberán proporcionar documentación y registros para dar soporte a procesos de gestión, incluyendo: • Políticas y planes • Acuerdos de nivel de servicio (SLAs) • Procedimientos y procesos • Registros exigidos por ISO 20000 Se deberán definir procedimientos y responsabilidades para la creación, revisión, aprobación, mantenimiento, eliminación y control de documentos y registros. El propietario responsable sénior debe garantizar que se cuenta con la evidencia necesaria para superar una auditoría de políticas, planes y procedimientos de Gestión del Servicio. Tiene que haber un proceso operativo para la creación y gestión de documentos. Igualmente se debe proteger la documentación contra posibles daños. Al igual que para procesos o procedimientos, ISO 20000 menciona pocos documentos que se exijan específicamente. Esto no significa que una organización que disponga sólo de los documentos exigidos explícitamente pueda recibir la certificación de manera automática. Será preciso demostrar que se han definido e implantado todos los procesos exigidos por la norma, además de poder presentar la documentación correspondiente (no necesariamente en papel).



57

La tabla 3.5 muestra los planes, políticas y otros documentos que una organización necesita para la planificación, la operación y el control. (Sub)Sección de la Parte 1 4.1 Planificación de la Gestión del Servicio (Planificar) 4.2 Implantación de la Gestión del Servicio y provisión de los servicios (Hacer) 4.3 Monitorización, medición y revisión (Verificar) 4.4 Mejora continua (Actuar) 6.1 Gestión del nivel de servicio 6.3 Gestión de la disponibilidad y la continuidad del servicio 6.5 Gestión de la capacidad 6.6 Gestión de la seguridad de la información 7.2 Gestión de relaciones con el negocio 7.3 Gestión de Proveedores

9.1 Gestión de la configuración 9.2 Gestión de cambios 10.1 Gestión de entregas

Documentos exigidos Dirección de gestión y responsabilidades documentadas Políticas, planes, procedimientos y definiciones para cada proceso o conjunto de procesos Objetivos de revisiones, valoraciones y auditorías Política de mejora del servicio Acuerdos de nivel de servicio, junto con acuerdos de servicio y contratos de suministradores Planes de disponibilidad y continuidad de los servicios Plan de capacidad Política de seguridad de la información Controles de seguridad Grupos de interés y clientes del servicio Actas de reuniones Proceso de gestión de proveedores Acuerdo de nivel de servicio con suministradores Interfaces de procesos Roles y relaciones entre suministradores principales y subcontratados Política sobre definición de elementos de configuración Alcance de cambios en servicio e infraestructura Política de entregas

Tabla 3.5 Documentos exigidos por ISO 20000-1

Los registros son un tipo específico de evidencia. Los registros son documentos que indican los resultados obtenidos o que proporcionan evidencia sobre las actividades realizadas (la Sección 3.3.8 sobre terminología contiene más información). La tabla 3.6 muestra los registros exigidos explícitamente por ISO 20000-1; una vez más, esto no significa que tener todos los registros indicados en la lista suponga la certificación automática. (Sub)Sección de la Parte 1 4.3 Monitorización, medición y revisión (Verificar) 4.4 Mejora continua (Actuar) 6.1 Gestión del nivel de servicio

6.3 Gestión de la disponibilidad y la continuidad del servicio

Registros exigidos Registros de revisión, valoración y auditoría Acciones correctivas identificadas Mejoras sugeridas del servicio Servicios, objetivos específicos y características de carga de trabajo Registros de acciones identificadas de mejora Registros de disponibilidad Registros de pruebas de planes de continuidad del servicio


58

(Sub)Sección de la Parte 1 6.4 Presupuestos y contabilidad de los servicios de TI 6.6 Gestión de la seguridad de la información 7.2 Gestión de relaciones con el negocio 7.3 Gestión de proveedores 8.2 Gestión de incidencias 8.3 Gestión de problemas 9.1 Gestión de la configuración

9.2 Gestión de cambios

10.1 Gestión de entregas


Registros exigidos Registros financieros de presupuestos y previsiones Registros de incidencias de seguridad Acciones de mejora Registros de quejas del servicio Acciones de mejora Acciones de mejora Registros de incidencias Registros de problemas Acciones de mejora Registros de configuración Relaciones y documentación necesaria para una Gestión del Servicio eficaz Deficiencias Solicitudes de cambio Registros de cambios (análisis) Acciones de mejora Fechas de entrega y entregables, con referencia a las correspondientes solicitudes de cambios, errores conocidos y problemas

Tabla 3.6 Registros exigidos por ISO 20000-1

ISO 20000 no debe convertirse en ningún caso en una mera colección de procesos, procedimientos, documentos y registros, sino que tiene que ser un sistema de gestión integrado y con documentación interrelacionada.

3.3.6 Propósito de las distintas partes de la norma La especificación de la norma define un objetivo para cada una de sus partes. Dichos objetivos son los siguientes: • Sección 3: Requisitos de un sistema de gestión - Proveer un sistema de gestión que incluya las políticas y el marco de trabajo para hacer posible una efectiva gestión e implantación de todos los servicios de TI. • Sección 4.1: Planificación de la Gestión del Servicio (Planificar) - Planificar la implantación y la provisión de la Gestión del Servicio. • Sección 4.2: Implantación de la Gestión del Servicio y provisión de los servicios (Hacer) - Implantar los objetivos y el plan de Gestión del Servicio. • Sección 4.3: Monitorización, medición y revisión (Verificar) - Monitorizar, medir y revisar el cumplimiento de los objetivos y el plan de Gestión del Servicio. • Sección 4.4: Mejora continua (Actuar) - Mejorar la eficacia y la eficiencia de la provisión y de la Gestión del Servicio. • Sección 5: Planificación e implantación de servicios nuevos o modificados - Asegurar que, tanto los servicios nuevos, como las modificaciones a los existentes, se pueden gestionar y proveer con los costes y la calidad acordados. • Sección 6.1: Gestión del nivel de servicio - Definir, acordar, registrar y gestionar los niveles de servicio. • Sección 6.2: Informes del servicio - Generar en plazo los informes acordados, fiables y precisos, que sirvan de apoyo a la toma de decisiones y faciliten una comunicación eficaz. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


59

• Sección 6.3: Gestión de la disponibilidad y la continuidad del servicio - Asegurar que los compromisos adquiridos con los clientes sobre la disponibilidad y la continuidad del servicio se pueden cumplir bajo todas las circunstancias. • Sección 6.4: Presupuestos y contabilidad de los servicios de TI - Elaborar y controlar los presupuestos y contabilizar los costes de la provisión del servicio. • Sección 6.5: Gestión de la capacidad - Asegurar que el proveedor de servicios tiene, en todo momento, la capacidad suficiente para cubrir la demanda acordada, presente y futura, de las necesidades del negocio del cliente. • Sección 6.6: Gestión de la seguridad de la información - Gestionar eficazmente la seguridad de la información para todas las actividades del servicio. • Sección 7.2: Gestión de relaciones con el negocio - Establecer y mantener una buena relación entre el proveedor de servicios y el cliente, basándose en el entendimiento del cliente y de los fundamentos de su negocio. • Sección 7.3: Gestión de proveedores - Gestionar a los suministradores para garantizar la provisión sin interrupciones de servicios de calidad. • Sección 8.2: Gestión de incidencias - Restaurar el servicio acordado con el negocio tan pronto como sea posible o responder a peticiones de servicio. • Sección 8.3: Gestión de problemas - Minimizar los efectos negativos sobre el negocio de interrupciones del servicio, mediante la identificación y el análisis proactivos de la causa de las incidencias y la gestión de los problemas para su cierre. • Sección 9.1: Gestión de la configuración - Definir y controlar los componentes del servicio y de la infraestructura, y mantener información precisa sobre la configuración. • Sección 9.2: Gestión de cambios - Asegurar que todos los cambios son evaluados, aprobados, implantados y revisados de una manera controlada. • Sección 10.1: Gestión de entregas - Suministrar, distribuir y realizar el seguimiento de uno o más cambios en una entrega en el entorno de producción.

3.3.7 Uso de ISO 20000 en el ciclo de vida de un servicio de TI Como se explicó en la Sección 3.3.1, la versión 3 de ITIL® consiste en un núcleo que es la Estrategia del Servicio, en torno al cual se desarrolla un ciclo de vida formado por Diseño del Servicio, Transición del Servicio, Operación del Servicio y Mejora Continua del Servicio (Figura 3.3). Hasta cierto punto, es posible establecer una correspondencia entre los requisitos de ISO 20000 y las fases del ciclo de vida en la versión 3 de ITIL. Dentro de este modelo de ciclo de vida de ITIL, el sistema de gestión definido según la norma ISO 20000 representa la estrategia de la Gestión del Servicio. Los requisitos sobre planificación e implantación de la Gestión del Servicio se refieren al diseño de la gestión de los servicios prestados. El libro sobre Diseño del Servicio de la versión 3 de ITIL® discute el diseño del servicio prestado y explica qué tiene que hacer la organización para garantizar la calidad de los servicios. Los requisitos sobre planificación e implantación de servicios nuevos o modificados tienen por objeto hacer que la transición de nuevos servicios a operación se realice correctamente, de manera que se pueda garantizar la calidad de los servicios nuevos y los ya existentes. Este tema se discute en


60


el libro sobre Transición del Servicio de la versión 3 de ITIL®, que también contiene un gran número de mejores prácticas. El texto de ISO 20000 sobre procesos (capítulos 6-10 de la norma) define los requisitos que deben cumplir todos los procesos de Gestión del Servicio para garantizar un servicio de calidad según ISO 20000. No es posible establecer una relación biunívoca entre estos requisitos y las mejores prácticas de Operación del Servicio en ITIL®, ya que los procesos mencionados en ISO 20000 están repartidos entre los cinco libros esenciales de la versión 3 de ITIL®.

3.3.8 Términos y definiciones relativas a ISO 20000 Las especificaciones ISO 20000-1 dicen: Para los fines de ISO 20000 son de aplicación los siguientes términos y definiciones. 2.1 Disponibilidad (availability): Capacidad de un componente o un servicio para realizar su función requerida en un instante determinado o a lo largo de un período de tiempo determinado. NOTA: La disponibilidad se suele expresar como una relación entre el tiempo en que el servicio está disponible realmente para su uso por el negocio y las horas de servicio acordadas. 2.2 Línea de referencia (baseline): Instantánea del estado de un servicio o un elemento de configuración individual en un momento concreto (véase 2.4). 2.3 Registro de cambio (change record): Registro que contiene los detalles de aquellos elementos de configuración (véase 2.4) a los que afecta un cambio autorizado y sobre cómo los afecta. 2.4 Elemento de configuración (Configuration Item, CI): Un componente de una infraestructura o un elemento que está o estará bajo el control de la gestión de la configuración. NOTA: Los elementos de configuración pueden variar mucho en complejidad, tipo y tamaño, comprendiendo desde un sistema completo (incluyendo todo el hardware, el software y la documentación) hasta un módulo aislado o un componente hardware menor. 2.5 Base de datos de gestión de la configuración (Configuration Management Database, CMDB): Base de datos que contiene todos los detalles relevantes de cada elemento de configuración y los detalles de las relaciones importantes entre ellos. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


2.6 Documento (document): Información y el medio que la contiene. NOTA 1: En esta norma, los registros (véase 2.9) se distinguen de los documentos por el hecho de que los registros sirven para proporcionar la evidencia de actividades, en lugar de la evidencia de intenciones. NOTA 2: Ejemplos de documentos son las declaraciones de políticas, los planes, los procedimientos, los acuerdos de nivel de servicio o los contratos. 2.7 Incidencia (incident): Cualquier suceso que no sea parte del funcionamiento normal de un servicio y que cause, o pueda causar, una interrupción de dicho servicio o una disminución de su calidad. 2.8 Problema (problem): Causa subyacente desconocida de una o más incidencias. 2.9 Registro (record): Documento que indica los resultados obtenidos o que proporciona la evidencia de las actividades realizadas. NOTA 1: En esta norma, los registros se distinguen de los documentos por el hecho de que los registros sirven para proporcionar la evidencia de actividades, en lugar de la evidencia de intenciones. NOTA 2: Ejemplos de registros son los informes de auditorías, las solicitudes de cambio, los informes de incidencias, los registros de formación individual o las facturas enviadas a clientes. 2.10 Entrega (release): Colección de elementos de configuración, nuevos y/o modificados, que se prueban e introducen de forma conjunta en el entorno de producción. 2.11 Solicitud de cambio (request for change): Formulario, en forma impresa o en pantalla, que se utiliza para registrar los detalles de una solicitud de un cambio en cualquier elemento de configuración perteneciente a un servicio o una infraestructura.


61

62


2.12 Centro de atención al usuario (service desk) Grupo de soporte de cara al usuario o al cliente, que realiza una alta proporción del total del trabajo de soporte. 2.13 Acuerdo de nivel de servicio (Service Level Agreement, SLA) Acuerdo escrito entre un proveedor de servicios y un cliente en el que se documentan los servicios y los niveles de servicio acordados. 2.14 Gestión del Servicio (Service Management) Gestión de los servicios para cumplir con los requisitos de negocio. 2.15 Proveedor de servicios (service provider) La organización que quiere cumplir con la Norma ISO/IEC 20000.


Capítulo 4

Especificaciones y Código de buenas prácticas para ISO 20000 Esta parte del libro explica los requisitos de ISO 20000 y ofrece una guía para la evaluación, mantenimiento y mejora del sistema de gestión de la calidad de servicios de TI. Contiene literalmente las especificaciones para la provisión de servicios de TI de calidad según ISO 20000‑1 y el código de buenas prácticas de ISO 20000-2. Al final del título de cada sección se indica entre paréntesis la sección original de ISO. Después de citar los requisitos y mejores prácticas de ISO 20000-1 e ISO 20000-2, una ilustración muestra cómo visualizarlos en un modelo de procesos. Uno de los principios de la gestión de la calidad en ISO 9000 es el planteamiento de procesos, que especifica que es posible alcanzar con más eficiencia un determinado resultado si las actividades y recursos relacionados se gestionan como un proceso. Otro principio de la gestión de la calidad es el planteamiento de sistema para la gestión, según el cual la organización puede alcanzar sus objetivos de una forma más eficaz y eficiente si identifica, comprende y gestiona procesos interrelacionados como un sistema. Las ilustraciones se muestran en notación BPM (Modelo de Procesos de Negocio) para que la norma sea más sencilla de comprender. Estas ilustraciones contienen en muchos casos actividades separadas, sin mostrar la conexión con las otras actividades en un modelo de procesos. Como se dice en la Sección 1.1 de la Parte 1 de ISO 20000, la relación entre los procesos depende de su aplicación dentro de una organización. Lo mismo ocurre con la relación entre las actividades. La norma habla fundamentalmente de actividades, más que de procesos. Algunos de los procesos o los pasos de los procesos se pueden solapar. Estrictamente hablando, cada verbo que aparece en la norma se podría reducir a una sola actividad. Para facilitar la comprensión, se han combinado varias actividades en un paso de proceso. El Código de buenas prácticas (Parte 2 de la norma) ofrece una explicación de los requisitos; en algunos casos esto implica más detalles y, por tanto, más actividades y documentos de los que serían necesarios según la Parte 1 de la norma.


64


En pocos casos, la Parte 1 de la norma exige explícitamente un proceso, un procedimiento o un documento. Los procedimientos de documentación y el proceso de auditoría son ejemplos de esta situación. La Figura 4.1 ilustra la notación empleada. ISO 20000-1

ISO 20000-2

Actividad explícita de ISO 20000-1

Actividad explícita de ISO 20000-2

Actividad implícita de ISO 20000-1

Actividad implícita de ISO 20000-2

Documento explícito de ISO 20000-1

Documento explícito de ISO 20000-2

Documento implícito de ISO 20000-1

Documento implícito de ISO 20000-2

Disparador de ISO 20000-1

Disparador de ISO 20000-2

Guía de ISO 20000-1

Guía de ISO 20000-2

Figura 4.1 Leyendas de las ilustraciones en notación BPM (Modelo de Procesos de Negocio)

Para simplificar las cosas, cada sección incluye también una guía de mejores prácticas cuyo objetivo es aclarar los aspectos prácticos de la aplicación de la norma.

4.1 Gestión y mejora de procesos de Gestión de Servicios de TI 4.1.1 Requisitos para un sistema de gestión (3) Objetivo: Proporcionar un sistema de gestión que incluya políticas y un marco de trabajo para garantizar la eficacia de la gestión e implantación de todos los servicios de TI.


Especificaciones y Código de buenas prácticas para ISO 20000

65

Responsabilidad de la dirección (3.1) Las especificaciones ISO 20000-1 dicen: La alta dirección debe proveer, a través del liderazgo y de acciones, evidencias de su compromiso para desarrollar, implementar y mejorar sus capacidades de Gestión del Servicio dentro del contexto de los requisitos de negocio de la organización y de los requisitos de los clientes. La dirección debe: a) Establecer la política de la Gestión del Servicio, sus objetivos y planes. b) Comunicar la importancia de cumplir con los objetivos de Gestión del Servicio y la necesidad de la mejora continua. c) Asegurar que los requisitos del cliente se determinan y se cumplen con el objetivo de mejorar la satisfacción del cliente. d) Designar un miembro de la dirección como responsable para la coordinación y gestión de todos los servicios. e) Determinar y proveer recursos para planificar, implementar, monitorizar, revisar y mejorar la provisión y la gestión de los servicios, por ejemplo, contratando el personal apropiado o gestionando la rotación personal. f ) Gestionar los riesgos para la organización de la Gestión del Servicio y para los servicios. g) Llevar a cabo revisiones de la Gestión del Servicio, a intervalos planificados, para asegurar la continuidad de su idoneidad, su adecuación y su efectividad. El Código de buenas prácticas ISO 20000-2 dice: El papel de la dirección para asegurar que las mejores prácticas son adoptadas y mantenidas en los procesos es fundamental para cualquier proveedor del servicio que quiera cumplir con los requisitos de la Norma ISO/IEC 20000-1. Para asegurar el compromiso de la dirección se debería identificar un responsable a nivel de alta dirección como responsable de los planes de Gestión del Servicio. Este responsable senior debería responsabilizarse de la entrega a todos los niveles del plan de Gestión del Servicio. El rol de responsable sénior debería estar al frente de los recursos designados para la actividades de mejora del servicio, bien sean actividades continuas o con un enfoque de proyecto. El responsable sénior debería estar apoyado por un grupo encargado de la toma de decisiones que tenga la suficiente autoridad para definir la política y para hacer cumplir sus decisiones. La Figura 4.1.1 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Las actividades de la dirección no forman parte de los procesos en la Figura 3.2, aunque son una parte importante de los procesos de negocio.


66


Definir la política, los objetivos y los planes de Gestión del Servicio

Política, objetivos y planes de Gestión del Servicio

Determinar y proporcionar recursos

Recursos determinados Incluye la gestión de recursos para actividades de mejora del servicio

Requisitos del cliente

Designar a un gestor responsable

Gestor responsable designado

Transmitir la importancia

Registros de comunicaciones

Garantizar la identificación de los requisitos del cliente

Requisitos del cliente

Apoyado por un grupo autorizado de toma de decisiones

Garantizar el cumplimiento de los requisitos del cliente

Medidas de logros de servicios

Medidas de satisfacción del cliente

Intervalo planificado

Efectuar revisiones

Registros de revisiones

Gestionar riesgos

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP

Figura 4.1.1 Responsabilidad de la dirección

El compromiso de la alta dirección es indispensable para una buena implantación de ISO 20000. El liderazgo es uno de los ocho principios de gestión de la calidad en ISO 9000. El compromiso de la dirección es un concepto intangible. El cumplimiento del requisito sobre responsabilidad de la dirección se puede demostrar mediante liderazgo y acciones documentadas para el desarrollo, implantación y mejora del sistema de Gestión del Servicio. Los documentos que pueden demostrar el compromiso de la dirección son: • Registros de la designación de un miembro de la dirección como responsable de la coordinación y gestión de todos los servicios. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


67

• Documentos escritos de la política, los objetivos y los planes de Gestión del Servicio. • Resultados de la implantación de planes. • Registros de comunicaciones. • Documentación de requisitos del cliente y registros de medidas de satisfacción del cliente. • Registros de la determinación de recursos. • Registros de revisiones de la Gestión del Servicio, como actas de reuniones de revisión, planes de acción y seguimientos.

4.1.2 Requisitos de documentación (3.2) Las especificaciones ISO 20000-1 dicen: Los proveedores del servicio deben facilitar documentos y registros necesarios para asegurar una planificación, operación y control de la Gestión del Servicio efectivas. Esto debe incluir: a) Políticas y planes de la Gestión del Servicios documentados. b) Acuerdos de nivel de servicios documentados. c) Procesos y procedimientos documentados requeridos por esta norma. d) Registros requeridos por esta norma. Deben establecerse los procedimientos y las responsabilidades para la creación, revisión, aprobación, mantenimiento, eliminación y control de los diferentes tipos de documentos y registros. NOTA: La documentación puede estar en cualquier forma o tipo de soporte. El Código de buenas prácticas ISO 20000-2 dice: El responsable senior debería asegurar que las evidencias necesarias están disponibles para una auditoria de las políticas, planificaciones y procedimientos de la Gestión del Servicio y de cualquier actividad relacionada con ellos. Gran parte de las evidencias de los planes y operaciones de la Gestión del Servicio se deberían encontrar en forma de documentos, los cuales pueden ser de cualquier tipo y estar en cualquier formato o soporte que sea adecuado para su fin. Los siguientes documentos son considerados normalmente como válidos para servir de evidencias de la planificación de la Gestión del Servicio: a) Políticas y planes b) Documentación del servicio c) Procedimientos d) Procesos e) Registros de control de procesos Debería existir un proceso para la creación y gestión de los documentos para ayudar a asegurar que se satisfacen las características descritas.


68


La documentación se debería proteger de daños, debidos, por ejemplo, a inadecuadas condiciones del entorno donde se encuentran y a desastres en los sistemas informáticos. La Figura 4.1.2 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Como indica ISO 20000-1, es obligatorio que haya procedimientos para la creación, revisión, aprobación, mantenimiento, eliminación y control de documentos y registros. Ésta es una de las pocas “obligaciones” sobre procesos y procedimientos en ISO 20000-1.

Procedimientos de documentación Definir procedimientos y responsabilidades de documentación

Incluye la protección de la documentación contra daños

Responsabilidades de documentación

Políticas y planes de Gestión del Servicio

SLAs

Proporcionar documentos/ evidencia de auditoría

La documentación puede ser de cualquier tipo, formato o soporte

Procesos y procedimientos

Registros (control de procesos)

Glosario de términos


Figura 4.1.2 Requisitos de documentación Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


69

La documentación se utiliza como medio para comunicar información y para compartir conocimientos. También hace que sea más sencillo mejorar el rendimiento de la organización. Sin documentación, una organización no puede tener una idea común de su propio rendimiento. La serie ISO 9000 forma parte de los antecedentes de ISO 20000. Como se indicó anteriormente, la versión de 1994 de ISO 9001 tenía reputación de ser un “tigre de papel”. La versión del año 2000 de la serie ISO 9000 incluye una metodología de procesos, lo mismo que ISO 20000. Esto no excluye ningún tipo de trabajo de oficina o documentación, pero desplaza la atención hacia la gestión de procesos. La documentación es necesaria para demostrar el cumplimiento de la norma. Tal como se dice en la norma, la documentación puede ser de cualquier tipo, formato o soporte.

4.1.3 Competencia, concienciación y formación (3.3) Las especificaciones ISO 20000-1 dicen: Se deben definir y mantener todos los roles y responsabilidades de la Gestión del Servicio, junto con las competencias que sean requeridas para su ejecución efectiva. Las competencias y necesidades de formación del personal deben revisarse y gestionarse para permitir al personal llevar a cabo sus roles de forma efectiva. La alta dirección debe asegurar que sus empleados son conscientes de la relevancia e importancia de sus actividades y de cómo deben contribuir a la consecución de los objetivos de la Gestión del Servicio. El Código de buenas prácticas ISO 20000-2 dice: Generalidades El personal que realiza el trabajo relativo a la Gestión del Servicio debería ser competente para esta función gracias a la educación recibida, a la formación, las habilidades y la experiencia adecuada. El proveedor del servicio debería: a) Determinar las aptitudes necesarias para cada rol en la Gestión del Servicio. b) Asegurar que el personal sea consciente de la relevancia e importancia de sus actividades dentro del más amplio contexto de negocio y de cómo contribuyen a la consecución de los objetivos de calidad. c) Mantener registros apropiados de la educación, formación, habilidades y experiencia. d) Proveer formación o llevar a cabo otras acciones para satisfacer estas necesidades. e) Evaluar la efectividad de las acciones realizadas. Desarrollo profesional El proveedor del servicio debería desarrollar y mejorar las competencias profesionales de su equipo de trabajo. Entre las medidas tomadas para conseguir esto, el proveedor del servicio debería incluir lo siguiente:


70


a) Contratación - con el objetivo de comprobar la validez de los detalles de los candidatos al puesto de trabajo (incluyendo su cualificación profesional) y de identificar la fortalezas, debilidades y habilidades potenciales de los candidatos frente a una descripción/perfil del puesto de trabajo, frente a los objetivos de la Gestión del Servicio y frente al conjunto de objetivos de la calidad del servicio. b) Planificación - con el objetivo de dotar de personal a los servicios nuevos o a aquellos que se hayan ampliado (también contratando servicios), usando tecnología nueva, asignando personal de Gestión del Servicio a los equipos de desarrollo de proyecto, planificando la sucesión y rellenando los vacíos que se generen debido a rotación anticipada del personal. c) Formación y desarrollo - con el objetivo de identificar los requisitos de formación y desarrollo dentro de un plan de formación y desarrollo y proveer su impartición en el momento oportuno y de forma efectiva. Se debería informar al personal en los aspectos relevantes de la Gestión del Servicio (por ejemplo, a través de cursos de formación, auto estudio, tutorías y formación en el trabajo) y se debería desarrollar el trabajo en equipo y las habilidades de liderazgo. Se debería mantener un registro cronológico de la formación para cada persona, junto con las descripciones de la formación proporcionada. Enfoques a considerar Para que los equipos de personal alcancen unos niveles apropiados de competencia, el proveedor del servicio debería decidir cual es la proporción óptima entre las contrataciones a corto plazo y las de forma indefinida. El proveedor del servicio debería decidir también la proporción a alcanzar entre la contratación de nuevo personal con las habilidades requeridas y el reciclaje de personal ya existente. NOTA: El equilibrio óptimo entre las contrataciones a corto plazo y las de forma indefinida es particularmente importante cuando el proveedor del servicio está planificando como proveer un servicio durante y después de cambios a gran escala en el número y habilidades del personal de apoyo. Los factores que se deberían considerar para establecer la combinación más adecuada de estos enfoques incluyen: a) El carácter de las competencias nuevas o modificadas: si son a corto o a largo plazo. b) La tasa de cambio en las habilidades y competencia. c) Los picos y los descensos esperados en la carga de trabajo y la combinación de habilidades requeridas, datos basados en la Gestión del Servicio y en la planificación de las mejoras del servici. d) Disponibilidad de personal competent. e) Tasas de rotación del persona. f ) Planes de formación. Para todo el personal, el proveedor del servicio debería revisar el desempeño a nivel individual al menos anualmente y tomar las acciones oportunas. En una metodología de procesos, una organización define las entradas y salidas de un proceso, pero también las actividades que forman los pasos del proceso. La organización define además los



71

roles y responsabilidades que corresponden a cada paso del proceso. El empleado al que se haya asignado un determinado rol debe encajar en el perfil del puesto de trabajo asociado al rol y las responsabilidades (Figura 4.1.3). Definir y mantener roles y responsabilidades de Gestión del Servicio

Validez de competencias nuevas/modificadas

Índice de cambio en conocimientos y competencias

Carga de trabajo prevista y cualificaciones necesarias

Disponibilidad de personal competente

Hacer que el personal sea consciente de la relevancia e importancia de sus actividades Revisar y gestionar las competencias y necesidades de formación del personal

Roles y responsabilidades de Gestión del Servicio

Registros de competencias y necesidades de formación

Registros de formación, conocimientos y experiencia

Buscar un equilibrio óptimo entre contrataciones permanentes y de corta duración y entre la contratación de nuevos empleados y la formación de personal existente

Proporción cuantificada

Planificar y ofrecer formación o adoptar las medidas adecuadas para satisfacer estas necesidades

Plan de formación y desarrollo

Índices de rotación del personal

Planes de formación

Al menos una vez al año

Revisar el rendimiento de todos los miembros del personal

Emprender las acciones oportunas

Evaluar la eficacia de las acciones emprendidas


Figura 4.1.3 Competencia, concienciación y formación


Junto con las competencias necesarias

72


Una parte importante del modelo de procesos de la organización consiste en garantizar que los pasos del proceso son ejecutados en todo momento por empleados competentes, cualificados y con la concienciación necesaria. La competencia, la concienciación y la formación se basan en tres principios de la gestión de la calidad: • Liderazgo - Capacidad de una persona para influir, motivar y habilitar a otras personas para que contribuyan a la eficacia y éxito de la organización a la que pertenecen. • Implicación de las personas - Se deben identificar los talentos especiales de cada uno y aprovecharlos en beneficio de la organización. • Mejora continua - Continuamente se deben desarrollar y aumentar la competencia y la concienciación de las personas.

Guía Lo más importante a la hora de organizar a los empleados no es sólo conseguir un buen equilibrio entre las competencias necesarias y disponibles, sino también aprovechar las oportunidades de desarrollar competencias, transmitir experiencias y adquirir conocimientos. Los tutores o profesores pueden dar apoyo a los empleados. La formación de grupos también puede favorecer el intercambio de experiencias y el desarrollo de nuevas competencias. Los grupos de interés, incluyendo clientes y empleados, deben ser conscientes de las ventajas que aporta una gestión de TI más madura y de los motivos que llevan a planificar ciertos cambios y medidas. Esta concienciación ayuda a vencer la resistencia a cambios en la forma de trabajar. Es importante que se detecten las lagunas de conocimiento existentes en la organización y que se comuniquen los resultados de este tipo de evaluación. Estas lagunas se pueden cubrir incorporando el conocimiento a los procesos en todo el ciclo de vida de TI, que es a su vez el que marca las prioridades para el desarrollo de conocimientos y el proceso para compartirlos. También impulsa la identificación y el desarrollo de la base de conocimientos necesaria antes de que llegue el momento de usar esos conocimientos. Muchas organizaciones no son conscientes de esta necesidad y no ofrecen la formación precisa a sus empleados, lo que lleva a una interrupción del proceso por falta de personal cualificado. La ausencia de intercambio de conocimientos es algo que hay que vigilar antes, durante y después de la aplicación del conocimiento a una tarea.

4.1.4 Planificación e implementación de la Gestión del Servicio (4) Las especificaciones ISO 20000-1 dicen: NOTA: La metodología conocida como Planificar-Hacer-Verificar-Actuar (PDCA, del inglés Plan-Do-Check-Act) puede aplicarse a todos los procesos. La metodología PDCA puede describirse del modo siguiente: a) Planificar - Establecer los objetivos y los procesos necesarios para proporcionar resultados de acuerdo con las necesidades del cliente y con las políticas de la empresa. b) Hacer - Implementar los procesos. c) Verificar - Monitorizar y medir los procesos y los servicios contrastándolos con las políticas, los objetivos y los requisitos, e informar sobre los resultados. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


73

d) Actuar - Emprender las acciones necesarias para mejorar continuamente el rendimiento y comportamiento del proceso. La Figura 4.1.4 ilustra el proceso y las relaciones de los procesos presentados en los capítulos 4 a 10 de ISO 20000.

Gestión de servicios Requisitos de negocio

Responsabilidad de la dirección PLANIFICAR Planificar la Gestión del Servicio

Requisitos del cliente Solicitud de servicio nuevo/ modificado Otros procesos (negocio, suministrador, cliente)

Centro de atención al usuario Otros equipos (como Operaciones de TI, Seguridad)

ACTUAR Mejora continua

HACER Implantar la Gestión del Servicio

Resultados de negocio

Satisfacción del cliente

Servicio nuevo o modificado Otros procesos (negocio, suministrador, cliente)

VERIFICAR Monitorizar, medir y revisar

Satisfacción de equipos y personas

Figura 4.1.4 La metodología Planificar-Hacer-Verificar-Actuar para los procesos de Gestión del Servicio (círculo de calidad de Deming)

La Figura 4.1.4 muestra el modelo de procesos completo para un proveedor de servicios al máximo nivel. Las entradas para los procesos de Gestión del Servicio son: • Requisitos de negocio • Requisitos del cliente • Solicitud de servicio nuevo/modificado • Otros procesos (negocio, suministrador, cliente) • Registros del centro de atención al usuario • Otros equipos (como Operaciones de TI, Seguridad)


74


Las salidas para los procesos de Gestión del Servicio son: • Resultados de negocio • Satisfacción del cliente • Servicio nuevo o modificado • Otros procesos (negocio, suministrador, cliente) • Satisfacción de equipos y personas La responsabilidad de la dirección va más allá del ciclo Planificar-Hacer-Verificar-Actuar que se muestra en la Figura 4.1.4, ya que todos los procesos de Gestión del Servicio se ejecutan bajo la responsabilidad de la alta dirección. La metodología Planificar-Hacer-Verificar-Actuar es necesaria para todos los procesos.

Guía Una técnica recomendada para la implantación o la mejora de procesos en la introducción de un Plan de Mejora del Servicio (SIP). La Figura 4.1.5 muestra las seis fases iterativas que forman dicho plan.

¿Cómo mantener el impulso?

¿Cuál es la visión?

Visión, misión, metas y objetivos de negocio

¿Cuál es la situación actual?

Valoraciones de referencia

¿Cuál es la situación deseada?

Objetivos medibles

¿Cómo conseguirla?

Mejora de servicios y procesos

¿Se ha conseguido?

Medidas y métricas

Figura 4.1.5 Las seis fases de un Plan de Mejora Continua del Servicio (Fuente: OGC)

Es posible establecer las siguientes correspondencias entre estas fases y el ciclo PDCA: • Planificar - ¿Cuál es la visión? ¿Cuál es la situación actual? ¿Cuál es la situación deseada? (objetivos de negocio de alto nivel, valoraciones, objetivos medibles) • Hacer - ¿Cómo conseguir la situación deseada? (mejora de procesos) • Verificar - ¿Cómo comprobar que se han alcanzado los hitos? (medidas y métricas) • Actuar - ¿Cómo mantener el impulso?



75

4.1.5 Planificación de la Gestión del Servicio (Planificar) (4.1) Objetivo: Planificar la implementación y la provisión de la Gestión del Servicio. Las especificaciones ISO 20000-1 dice: Se debe planificar la Gestión del Servicio. Como mínimo, el plan debe definir lo siguiente: a) El alcance de la Gestión del Servicio del proveedor del servicio; b) Los objetivos y los requisitos que se tienen que alcanzar por la Gestión del Servicio; c) Los procesos que se van a ejecutar; d) El marco de roles y responsabilidades de la dirección, incluyendo al directivo de alto nivel responsable directo, al propietario del proceso y a la dirección de la gestión la dirección de los suministradores; e) Las interfaces entre los procesos de Gestión del Servicio y el modo en que tienen que coordinarse las actividades; f ) El enfoque que hay que dar a la identificación, la evaluación y la gestión de actividades y de los riesgos para la consecución de los objetivos definidos; g) El enfoque para la relación con proyectos que estén creando o modificando los servicios; h) Los recursos, el equipamiento y los presupuestos necesarios para alcanzar los objetivos definidos; i) Las herramientas necesarias para dar soporte a los procesos; y j) Cómo se va a gestionar, auditar y mejorar la calidad del servicio. Deben estar claramente definidas tanto la orientación de la gestión como las responsabilidades documentadas para revisar, autorizar, comunicar, implementar y mantener los planes. Cualquier plan específico de un proceso que se elabore debe ser compatible con este plan de Gestión del Servicio. El Código de buenas prácticas ISO 20000-2 dice: El alcance de la Gestión del Servicio se debería definir como parte del plan de Gestión del Servicio. Por ejemplo, puede definirse según: a) La organización b) La ubicación c) El servicio La dirección debería definir el alcance como parte de sus responsabilidades de gestión (y como parte del plan de Gestión del Servicio). Luego se debería comprobar si el alcance resulta adecuado para la Norma ISO/IEC 20000-1. NOTA: La planificación de cambios operativos se describe en el apartado 9.2, Gestión de Cambios. Se pueden utilizar varios planes de Gestión del Servicio en lugar de un plan o programa de gran magnitud. En este caso, los procesos subyacentes a la Gestión del Servicio deberían ser coherentes entre


76


ellos. También se debería poder demostrar cómo se gestiona cada requisito de planificación vinculándolo a sus correspondientes funciones, responsabilidades y procedimientos. La planificación de la Gestión del Servicio debería formar parte del proceso para convertir las necesidades de los clientes y las intenciones de los directivos en servicios y para proporcionar una guía para dirigir el proceso. Un plan de Gestión del Servicio debería incluir: a) La implementación de la Gestión del Servicio (o de parte de la Gestión del Servicio) b) La entrega de los procesos de la Gestión del Servicio. c) Los cambios de los procesos de la Gestión del Servicio. d) Las mejoras de los procesos de la Gestión del Servicio. e) Los nuevos servicios (hasta el punto que afecten a los procesos incluidos en el alcance acordado de la Gestión del Servicio). El plan de Gestión del Servicio debería estar enfocado a los procesos de Gestión del Servicio y a los cambios en los servicios desencadenados por eventos como los siguientes: a) La mejora del servicio. b) Los cambios en el servicio. c) La normalización de infraestructuras. d) Los cambios de la legislación. e) Las modificaciones en normativas como, por ejemplo, modificaciones de las tasas impositivas locales. f ) La liberalización o la regulación de los sectores industriales. g) Las fusiones y las adquisiciones. Un plan de Gestión del Servicio debería definir: a) El alcance de la Gestión del Servicio del proveedor del servicio. b) Los objetivos y requisitos que se pretenden conseguir con la Gestión del Servicio. c) Los recursos, instalaciones y presupuestos necesarios para conseguir los objetivos definidos. d) La estructura de las funciones y las responsabilidades de gestión, incluyendo al responsable senior, a los gerentes de los procesos y a la gestión de proveedores. e) Las interfaces entre los procesos de la Gestión del Servicio y el modo en que se deberían los coordinar los procesos y/o actividades.; f ) El enfoque que se debería aplicar para la identificación, la evaluación y la gestión de riesgos para la consecución de los objetivos definidos. g) Una planificación de los recursos expresada en términos de las fechas en las que deberían estar disponibles las fuentes de financiación, las habilidades y los recursos. h) El enfoque para la modificación del plan y de los servicios definidos por el plan. i) El modo en que el proveedor del servicio demostrará la continuidad del control de calidad continuo (por ejemplo, auditorías internas). j) Los procesos que se van a ejecutar. k) Las herramientas apropiadas para soportar los procesos. La Figura 4.1.6 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Planificar la Gestión del Servicio

Planes de Gestión del Servicio

77

Incluyen: - Alcance de la Gestión del Servicio del proveedor de servicios - Objetivos y requisitos que debe cumplir la Gestión del Servicio - Procesos que se deben ejecutar - Marco de roles y responsabilidades de gestión - Interfaces de procesos de Gestión del Servicio y coordinación de actividades - Método de gestión de riesgos - Método de conexión con proyectos de Gestión del Servicio - Recursos, instalaciones y presupuestos - Herramientas apropiadas para dar soporte a los procesos - Métodos de gestión, auditoría y mejora de la calidad del servicio

Tienen en cuenta procesos y cambios debidos a eventos como: - Mejora de servicios - Cambios de servicios - Normalización de infraestructuras - Cambios en la legislación - Cambios en normativas - Liberalización o reglamentación de sectores - Fusiones y adquisiciones

Planes para procesos específicos (deben ser compatibles con los planes de Gestión del Servicio)

Definir una dirección clara de gestión y responsabilidades documentadas

Dirección de gestión y responsabilidades documentadas

Incluyen: - Implantación de (parte de) la Gestión del Servicio - Entrega de procesos de Gestión del Servicio - Cambios en procesos de Gestión del Servicio - Mejoras en procesos de Gestión del Servicio - Nuevos servicios Deben facilitar la vinculación de los requisitos de planificación a roles, responsabilidades y procedimientos

Para revisión, autorización, comunicación, implantación y mantenimiento de los planes


Figura 4.1.6 Planificación de la Gestión del Servicio (Planificar)

ISO 20000-1 exige que la organización defina el alcance de su plan de Gestión del Servicio, así como los objetivos y requisitos que debe cumplir dicho plan. La organización tiene que definir sus procesos de Gestión del Servicio con los correspondientes roles y responsabilidades, las interfaces entre procesos y las interfaces con proyectos. También se tiene que definir la forma en que van a coordinar las actividades. Los planes que se desarrollen para procesos específicos tienen que ser compatibles con el plan de Gestión del Servicio. Para ello, la Subsección “Métodos de planificación” de ISO 20000-2 especifica que es posible utilizar múltiples métodos de planificación de Gestión del Servicio en lugar de un único plan o programa, en cuyo caso los procesos subyacentes de la Gestión del Servicio deben mantener una coherencia interna. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

78


La suma de todos los elementos aquí mencionados para la planificación de la Gestión del Servicio forma el modelo para los procesos de realización de la Gestión del Servicio.

Guía Una organización de TI que se embarque en un programa de mejora puede conseguir una situación más favorable si comienza a actuar como un negocio y define una visión (fase 1) con objetivos, presupuestos y métricas. Una visión de Gestión del Servicio de TI es una declaración sobre “¿Cuál es la situación deseada?” acordada por el negocio y la organización de TI. Describe el objetivo y el propósito de un Plan de Mejora del Servicio (SIP). La declaración de visión tiene que dejar claro cómo es el programa en términos de sus objetivos técnicos y de negocio, describir el compromiso y las opiniones de la dirección superior y motivar al personal para que empiece a actuar en consecuencia. Una cierta urgencia (“¿qué ocurre si no se hace nada?”) y el punto de vista personal de la visión (“¿qué saco yo?”) son la base de todas las comunicaciones con los grupos de interés que participan en un SIP o se ven afectados por él. Las estrategias del negocio y la organización de TI deben estar alineadas en la dirección del SIP. Tiene que haber normas y políticas claras que garanticen un enfoque coherente y continuo de la Gestión del Servicio de TI. La gestión de TI y la arquitectura de herramientas también deben dar soporte a los requisitos de negocio. Entre las actividades clave para definir la dirección figuran: • Analizar las necesidades de negocio y lo que puede hacer la organización de TI para garantizar su satisfacción. • Definir una política de gestión de riesgos y hacer que se incluya en los procesos de planificación y toma de decisiones. • Definir una estrategia de TI y hacer que se integre en la estrategia de negocio. • Diseñar políticas en función de los resultados de negocio y garantizar que se obtiene el máximo rendimiento de las inversiones en TI. Los factores críticos de éxito para la alineación de TI con los objetivos de negocio son: • Crear una sensación de urgencia. • Contar con un compromiso sólido de la alta dirección. • Visión y liderazgo para mantener la dirección estratégica, alcanzar objetivos y medir la consecución de objetivos. • Aceptación de la innovación y de nuevas formas de trabajar. • Una idea común del negocio, sus grupos de interés y su entorno. • Comprensión de las necesidades del negocio por parte del personal de TI. • Comprensión del potencial de TI por parte del negocio. • Información y comunicación a disposición de todo el que lo necesite. • Conocimiento de los avances tecnológicos para identificar oportunidades para el negocio. • Búsqueda de éxitos rápidos sin olvidar los beneficios a largo plazo. • Institucionalización de los cambios organizativos.



79

Antes de empezar a aplicar un SIP, la organización de TI tiene que saber cuál es la visión (fase 1) y cuál es la situación actual (fase 2) desde distintos puntos de vista: • Directrices de negocio: La estrategia y dirección del negocio, los problemas a los que se enfrenta y su efecto sobre TI. • Directrices tecnológicas: Los avances tecnológicos y la forma en que se deben aplicar para que contribuyan al negocio. • La forma en que el negocio ve las directrices y el modo en que pretende obtener nuevas ventajas con la tecnología. • ¿Tienen el negocio y la organización de TI la misma opinión sobre el rol de la organización de TI, la madurez y la calidad de la provisión de servicios de TI en relación con estas directrices? • ¿Cuáles son las opiniones y necesidades de los grupos de interés? • ¿Existe una respuesta clara a la pregunta “qué ocurre si no se hace nada?” Tener una idea clara de la estructura existente ayuda a determinar la escala y la complejidad de la visión y el esfuerzo necesario para hacerla realidad. Los modelos de madurez, las evaluaciones comparativas y los informes de análisis de “Gaps” permiten identificar carencias en la capacidad de las personas, el proceso y la tecnología. También revelan el valor potencial de los resultados para el negocio en caso de eliminarse esa carencia. Un análisis de “Gaps” bien documentado facilita la priorización de las carencias y la identificación de áreas de mejora. El negocio y la organización de TI se tienen que poner de acuerdo acerca del rol y las características de la organización de TI. Para ello deben dar respuesta a la pregunta “¿Cuál es la situación deseada?” (fase 3). Las preguntas que hay que hacerse son: • ¿Se trata de un rol atractivo? • ¿Se trata de un rol necesario? • ¿Cuáles serán las consecuencias para el negocio y la organización de TI si no se cubre este rol? Para justificar un SIP hay que comparar los costes y beneficios del proyecto en un caso de negocio. Aunque los costes son relativamente fáciles de medir (personal, herramientas, etc.), resulta más complicado determinar los beneficios como resultado directo de un SIP. Los resultados no siempre se pueden cuantificar económicamente, ya que los proyectos orientados a procesos suelen ofrecer más calidad de provisión de servicios, niveles de servicio más elevados y más flexibilidad de organización. Para que un caso de negocio tenga éxito es necesario que un alto directivo apoye el SIP y se sienta comprometido en su ejecución. Sin este tipo de patrocinio, existe un riesgo elevado de que no se pueda disponer de los fondos y los recursos necesarios y no sea posible alcanzar las mejoras previstas. El patrocinador debe definir la base para la aceptación por parte del negocio. Un SIP puede ser un largo programa de cambios. Los éxitos rápidos contribuyen a mantener un alto grado de compromiso, por lo que tienen que ser evidentes para todos y estar incorporados en el SIP. Estos éxitos rápidos también se deben comunicar con frecuencia para que sean conocidos por todos los grupos de interés.


80


4.1.6 Implementación de la Gestión del Servicio y provisión de los servicios (Hacer) (4.2) Objetivo: Implementar los objetivos y el plan de Gestión del Servicio. Las especificaciones ISO 20000-1 dicen: El proveedor del servicio debe implementar el plan de Gestión del Servicio para proveer y gestionar los servicios, incluyendo: a) La asignación de presupuestos y fondos. b) La asignación de roles y responsabilidades. c) La documentación y el mantenimiento de políticas, planes, procedimientos y definiciones para cada proceso o conjunto de procesos. d) La identificación y la gestión de riesgos para el servicio. e) La gestión de los equipos de trabajo, por ejemplo, la contratación y el desarrollo del personal adecuado y la gestión de continuidad del personal. f ) La gestión del equipamiento y el presupuesto. g) La gestión de los equipos o grupos de personas, incluidos los del centro de atención al usuario y los de operaciones. h) Informar del progreso en comparación con los planes. i) La coordinación de los procesos de Gestión del Servicio. El Código de buenas prácticas ISO 20000-2 dice: La consecución de los procesos de mejores prácticas de Gestión del Servicio capaces de satisfacer los requisitos de la Norma ISO/IEC 20000 no se alcanzará si los servicios originales no cumplen los requisitos descritos para la implementación en la Norma ISO/IEC 20000-1. Una vez implementados tanto el servicio como los procesos de Gestión de Servicios se deberían mantener. Se deberían realizar revisiones de acuerdo con el aparatado 4.3, Monitorización, medición y revisión (Verificar). NOTA: Es posible que la persona que sea adecuada para realizar la planificación y la implementación inicial no sea la apropiada para la operación continua. La Figura 4.1.7 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. En la fase Hacer del ciclo PDCA se implantan el modelo de procesos y los roles y responsabilidades del proceso. En esta fase, la organización empieza a funcionar de acuerdo con el modelo de procesos. La organización “congela” el modelo de procesos mediante la documentación del diseño y la asignación de los recursos y los empleados necesarios para el plan de Gestión del Servicio. Los cambios en el proceso se tienen que documentar e implantar a través de un proceso gestionado. En ese momento, el proceso de cambios hace que el modelo de procesos se “derrita” y se vuelva a “congelar”.



Plan de Gestión del Servicio

81

Implantar el plan de Gestión del Servicio

Asignar fondos y presupuestos

Fondos y presupuestos asignados

Asignar roles y responsabilidades

Roles y responsabilidades asignados

Políticas, planes, procedimientos y definiciones de procesos

Documentar y mantener políticas, planes, procedimientos y definiciones de procesos

Políticas, planes, procedimientos y definiciones de procesos

Revisar políticas, planes, procedimientos y definiciones de procesos

Políticas, planes, procedimientos y definiciones de procesos actualizados


Coordinar procesos de Gestión del Servicio Gestionar equipos, incluyendo los del centro de atención al usuario y operaciones Gestionar instalaciones y presupuestos

Identificar y gestionar riesgos

Planes de Gestión del Servicio

Comunicar el progreso con respecto a los planes

Riesgos identificados y medidas adoptadas

Informes de progreso

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP Gestión de cambios: - Presentar solicitudes de cambio Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes

Figura 4.1.7 Implantación de la Gestión del Servicio y provisión del servicio (Hacer)


82


Guía Al responder a la pregunta “¿Cómo conseguir la situación deseada?” (fase 4) hay que tener en cuenta: • CÓMO se van a hacer realidad los cambios necesarios. • QUÉ elementos se deben incorporar a un SIP. La respuesta a la pregunta “¿Por dónde hay que empezar?” depende de: • El nivel de madurez de la organización de TI en su conjunto (objetivo actual y futuro). • La madurez de cada uno de los procesos de Gestión del Servicio de TI (objetivo actual y futuro). • Las metas estratégicas de la organización. • Las prioridades basadas en las relaciones entre procesos. En general, las organizaciones no pueden alcanzar un nivel de madurez elevado si únicamente han definido procesos individuales de Gestión del Servicio de TI. Los procesos dependientes se deben implantar con un nivel de madurez similar. Se tiene que preparar un resumen de las carencias identificadas para presentarlo a un grupo multidisciplinar de los principales grupos de interés. Es preciso que este grupo comprenda las mejoras necesarias y se comprometa con ellas para eliminar las carencias identificadas antes de que se pueda iniciar la planificación de acciones. Para contar con más apoyo de la dirección es muy importante garantizar la credibilidad de los análisis o evaluaciones comparativas y sus resultados. La implantación o mejora de la Gestión del Servicio de TI siempre implica cambios organizativos y es, básicamente, un programa de cambio organizativo. Muchos programas de este tipo no alcanzan los resultados deseados debido a las dificultades que surgen cuando las personas tienen que cambiar su orientación y la forma en que trabajan. Las personas en general se muestran reacia a los cambios, por lo que es preciso explicar las ventajas a todos los afectados con el fin de conseguir su apoyo y hacer que abandonen sus anteriores métodos de trabajo. Para ello es fundamental un liderazgo fuerte. La cultura empresarial es otro aspecto básico que se debe tener en cuenta, ya que puede facilitar la implantación o, por el contrario, ser una fuente de resistencia. Cuando se inicia un SIP, se suele prestar mucha atención a la nueva estructura organizativa y a la nueva tecnología y muy poca a la cultura de la organización. La cultura organizativa afecta al liderazgo, el cual a su vez influye en las probabilidades de éxito de un cambio organizativo. La cultura es un factor intangible, pero se debe gestionar para: • Determinar la cultura existente. • Definir actitudes de colaboración. • Cambiar los aspectos indeseaqbles de dicha cultura. Los cambios organizativos propuestos afectan a las personas y a su forma de ver las cosas. En momentos de cambio radical es importante canalizar correctamente estas emociones para favorecer los cambios, ya que son un factor muy importante para el éxito. Se deben planificar éxitos rápidos que generen optimismo y animen a los miembros afectados del personal a Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


83

explorar las posibilidades que ofrece la nueva situación. El siguiente paso consiste en consolidar e institucionalizar las mejoras. La comunicación no es una actividad aislada, sino un requisito continuo para garantizar que el entusiasmo inicial se mantiene e incluso aumenta. Todo el mundo debe participar en discusiones sobre los motivos para el cambio organizativo. Fomentar el intercambio directo de opiniones hace que sea más sencillo resolver problemas, lo que a su vez puede acelerar el cambio organizativo y hacer que resulte más eficaz a largo plazo. La organización se tiene que comprometer a tener en cuenta todas las opiniones. No se puede ignorar la resistencia a los cambios, ya que eso sólo serviría para mantenerla oculta. Hacer que la resistencia sea abierta para poder discutirla y analizarla permitirá identificar nuevas áreas de participación o barreras que es necesario eliminar. Los nuevos procesos y prácticas de trabajo se suelen implantar en estructuras organizativas ya existentes. La implantación de la Gestión del Servicio de TI en una organización puede conllevar la introducción de nuevos roles que tal vez superen los límites tradicionales de la organización, lo que puede ser causa de dificultades. Es fundamental contar con una definición clara de todas las responsabilidades. Sin estos roles y responsabilidades, el nuevo proceso será confuso y es posible que las personas vuelvan a sus viejos métodos de trabajo. Una vez definidos los procesos, lo primero que hay que hacer es ponerlos bajo control, tras lo cual se pueden desarrollar hasta un nivel reproducible para que posteriormente maduren a un nivel que sea gestionable. Se deben definir grados de control sobre procesos, usando métricas para gestionar cualquier aspecto del control de procesos. Un plan de mejora basado en procesos exige una idea clara de lo que son los procesos, de cuál es su relación con las estructuras organizativas existentes y de las formas de trabajar. Para que los departamentos funcionen como equipos multidisciplinares y no como ‘guetos tecnológicos’ es preciso introducir cambios fundamentales, como: • Implantación de procesos bien definidos y reproducibles en todos los departamentos. • Inclusión de nuevas áreas de responsabilidad en las descripciones de los puestos de trabajo. • Modificación de valores, comportamientos y culturas para fomentar el enfoque a cliente. • Aumento del nivel de conocimientos entre el personal que utiliza procesos complejos. • Herramientas integradas, que permitan el intercambio de datos y faciliten el flujo de trabajo. • Compromiso de la dirección con servicios de TI enfocados a negocio. • Propietarios de procesos que tengan autoridad y sean responsables de los procesos. Los procesos y procedimientos tienen que ser simples y dar soporte directo a una función del negocio; no deben ser un objetivo en sí mismos, sino contribuir a un objetivo de negocio. La implantación de herramientas de soporte para Gestión del Servicio de TI es fundamental, pero sin olvidar que una herramienta tiene que facilitar un proceso (“la estructura sigue a la estrategia”). Es posible que las herramientas existentes para Gestión de Servicios de TI dejen de ser adecuadas una vez se haya tenido en cuenta el nivel de madurez de los procesos y los objetivos de la organización. En este caso se debe preparar una nueva declaración de requisitos e iniciar el proceso de evaluación y selección de herramientas nuevas o modificadas. Si la organización carece de experiencia en herramientas, lo más aconsejable es empezar con una herramienta sencilla y Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

84


usarla como prototipo para documentar los requisitos, tras lo cual se podrá iniciar una selección más seria de herramientas. Para todas estas iniciativas es imprescindible un buen patrocinio.

4.1.7 Monitorización, medición y revisión (Verificar) (4.3) Objetivo: Monitorizar, medir y revisar que los objetivos y el plan de Gestión del Servicio se están cumpliendo. Las especificaciones ISO 20000-1 dicen: El proveedor del servicio debe aplicar métodos adecuados para la monitorizar y, cuando sea necesario, la medición de los procesos de Gestión del Servicio. Estos métodos deben demostrar la capacidad de los procesos para alcanzar los resultados planificados. La dirección debe realizar revisiones a intervalos planificados para determinar si los requisitos de Gestión del Servicio: a) Son conformes con el plan de Gestión del Servicio y los requisitos de esta norma. b) se implementan y se mantienen de manera eficaz. Se debe planificar un programa de auditorías, teniendo en cuenta el estado y la importancia de los procesos y las áreas que auditar, así como, los resultados de las auditorías anteriores. Se deben definir en un procedimiento los criterios, el alcance, la frecuencia y los métodos de auditoría. La selección de auditores y la realización de las auditorías deben garantizar la objetividad y la imparcialidad del proceso de auditoría. Los auditores no deben auditar su propio trabajo. El objetivo de las revisiones, evaluaciones y auditorías de la Gestión del Servicio se debe registrar junto con las conclusiones de dichas auditorías, sus revisiones y las acciones correctivas que se hayan identificado. Se debe comunicar a las partes correspondientes la existencia de cualquier área significativa con alguna no conformidad u otra discrepancia. El Código de buenas prácticas ISO 20000-2 dice: El proveedor del servicio debería planificar e implementar la monitorización, la medición, el análisis y la revisión de los servicios, los procesos de Gestión del Servicio y los sistemas asociados. Entre los elementos que se deberían monitorizar, medir y revisar están los siguientes: a) Los logros respecto a los objetivos de servicio definido b) La satisfacción del cliente c) La utilización de los recursos d) Las tendencias e) Las no conformidades de mayor consideració La Figura 4.1.8 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Intervalos planificados

Resultados de autorías anteriores

Revisar requisitos de Gestión del Servicio


Planificar un programa de auditoría

Programa de auditoría

¿Cumplen el plan de Gestión del Servicio? ¿Está eficazmente implantado y mantenido?

Para determinar la frecuencia de auditoría hay que tener en cuenta: - El nivel de riesgo en un proceso - La frecuencia de operación - Los antecedentes de problemas

Incluyendo: - Criterios - Alcance - Frecuencia - Métodos

Definir el procedimiento de auditoría

Proceso y selección de auditores para garantizar la objetividad e imparcialidad

Realizar auditorías

Monitorizar y demostrar la capacidad de los procesos de Gestión del Servicio

85

Datos sobre la capacidad de los procesos de Gestión del Servicio para alcanzar resultados

Medidas cuando corresponda Elementos que se deben monitorizar: - Grado de cumplimiento de los objetivos definidos de servicio - Satisfacción del cliente - Utilización de recursos - Tendencias - Principales faltas de conformidad

Objetivos de revisiones, valoraciones y auditorías

Registrar el objetivo, los resultados y las acciones correctivas

Informar a las partes correspondientes de las áreas con posibles problemas

Registros de revisión, valoración y auditoría Registros de acciones correctivas identificadas

Registros de comunicaciones

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP Informes del servicio: - Recibir información

Figura 4.1.8 Monitorización, medición y revisión (Verificar)


86


La monitorización, la medida y la revisión son actividades clave para la mejora continua, uno de los principios de la Gestión de la Calidad en ISO 9000. Es imposible conseguir una mejora continua sin determinar lo que se ha conseguido realmente. Una organización sólo puede verificar si ha alcanzado sus objetivos cuando dispone de registros de su rendimiento. El número mínimo de indicadores clave del rendimiento (KPIs) de la Gestión del Servicio comprende: • Grado de cumplimiento de los objetivos definidos de servicio • Satisfacción del cliente • Utilización de recursos • Tendencias • Principales faltas de conformidad Esta subsección de la Parte 1 de la norma especifica uno de los pocos procedimientos documentados que se exigen explícitamente: un procedimiento de auditoría. La subsección también exige de forma explícita registros del objetivo de revisiones, valoraciones y auditorías de la Gestión del Servicio, de los resultados de dichas auditorías y de las acciones correctivas identificadas.

Guía Para comprobar si se han alcanzado los hitos (fase 5) es necesario definir objetivos claros y medibles. Estos objetivos pueden definir lo que se tiene que conseguir con un proceso (salida), aunque también pueden contener criterios de madurez del propio proceso, como auditorías y revisiones. Una métrica determina si una cierta variable ha llegado a su objetivo, midiendo así los resultados de un proceso o actividad. Las métricas esenciales son el tiempo, el coste, la calidad y la eficacia. Es importante determinar cuál es el método más eficaz para medir el rendimiento en cada caso. Los resultados pueden presentar alguna desviación si no se miden todos los componentes principales, por lo que es necesario seleccionar un conjunto de métricas bien equilibrado para evitar este problema. Las medidas se tienen que realizar con frecuencia para poder introducir ajustes siempre que sea preciso, pero no tan a menudo que se generen cargas de trabajo innecesarias. También es importante incluir resultados y métricas de proyectos en las revisiones de rendimiento de los empleados. Las mejores métricas son aquéllas que resultan creíbles, son objetivas y necesitan pocos recursos de procesamiento o cortos tiempos de parada. Siempre que sea posible hay que utilizar herramientas automatizadas para recopilar, comunicar y controlar las medidas. Las medidas y las métricas se deben revisar periódicamente con el negocio para comprobar que son adecuadas y corregirlas si es necesario. Los factores críticos de éxito (CSFs) son elementos fundamentales para cumplir la misión del negocio. Los indicadores clave del rendimiento (KPIs) se derivan de estos CSFs y determinan la calidad, el rendimiento, el valor y la conformidad de un proceso. Los CSFs se deben tener en cuenta en todos los procesos de Gestión del Servicio de TI. Los KPIs se tienen que definir y medir periódicamente para cada proceso con el fin de verificar que se cumplen los CSFs.



87

Los CSFs y los KPIs se van transmitiendo sucesivamente desde los departamentos hasta niveles individuales, proporcionando una línea de referencia y mecanismos que permiten efectuar un seguimiento del rendimiento. Se recomienda concentrarse en un número mínimo de KPIs (cinco por proceso, por ejemplo). Una vez verificado un KPI, se puede pasar a nuevos KPIs. Cada organización tiene que determinar los correspondientes CSFs y KPIs. También es posible que se necesiten distintas métricas en función del grupo de interés o la disciplina de la Gestión del Servicio. Un método que se emplea habitualmente para el seguimiento de métricas es la realización de auditorías empleando KPIs. También se pueden hacer análisis de tendencias con un “Cuadro de Mando Integral” que facilita la gestión del rendimiento en la organización. Los objetivos de la gestión del rendimiento organizativo tienen que incluir las cuatro perspectivas siguientes: • Perspectiva del cliente - Es importante para la mayor parte de los procesos, y especialmente para SLM con objetivos documentados de SLA. • Perspectiva de procesos internos - Incluye los procesos de ISO 20000. • Perspectiva de aprendizaje y crecimiento - Contratación, formación e inversiones en software. • Perspectiva financiera - La gestión financiera de TI cubre la asignación de costes y gastos a la organización del cliente. Los CSFs y KPIs también se pueden utilizar como objetivos para un SIP. Al terminar cada una de las fases importantes del SIP se puede realizar una Revisión Post-Implantación (PIR) para comprobar que se han cumplido los objetivos. Los resultados se deben comparar con las metas originales para definir nuevos objetivos de mejora.

4.1.8 Mejora continua (Actuar) (4.4) Objetivo: Mejorar la eficacia y la eficiencia de la entrega y de la Gestión del Servicio. Las especificaciones ISO 20000-1 dicen:

Política Debe haber una política publicada sobre mejora del servicio. Se debe corregir cualquier no conformidad con la norma o con los planes de Gestión del Servicio. Se deben definir claramente los roles y las responsabilidades para la actividades de mejora del servicio.

Gestión de las mejoras del servicio Se deben evaluar, registrar, priorizar y autorizar todas las propuestas de mejora del servicio. Se debe utilizar un plan para controlar la actividad. El proveedor del servicio debe disponer de un proceso para identificar, medir y gestionar las actividades de mejora e informar de dichas actividades de manera continua. Este proceso debe incluir: a) Las mejoras de un proceso aislado que el propietario del proceso puede implementar con los recursos de personal habituales, por ejemplo, la realización de las acciones correctivas y preventivas. b) Las mejoras en toda la organización o en más de un proceso. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

88


Actividades El proveedor del servicio debe realizar actividades para: a) Recopilar y analizar los datos para delimitar y medir la capacidad del proveedor del servicio para gestionar y proveer el servicio junto con los procesos de gestión del mismo. b) Identificar, planificar e implementar mejoras. c) Consultar a todas las partes implicadas. d) Establecer objetivos de mejora en cuanto a la calidad, los costes y la utilización de recursos. e) Tener en cuenta las aportaciones importantes, referentes a mejoras, que se realicen desde todos los procesos de Gestión del Servicio. f ) Medir, informar y comunicar las mejoras en el servicio. g) Revisar las políticas, los planes y los procedimientos de Gestión del Servicio, siempre que sea necesario. h) Asegurar que todas las acciones aprobadas se llevan a cabo y que se alcanzan los objetivos deseados. El Código de buenas prácticas ISO 20000-2 dice: Política Los proveedores del servicio deberían reconocer que siempre existe la posibilidad de conseguir que la provisión del servicio sea más eficaz y más eficiente. Debería hacerse pública una política de la calidad y de mejora del servicio. Todas las personas implicadas en la Gestión del Servicio y la mejora del mismo deberían ser conscientes de la política de calidad del servicio y de cuál debería ser su contribución personal a la consecución de los objetivos establecidos en esta política. En particular, todo el personal del proveedor del servicio implicado en la Gestión del Servicio debería tener un conocimiento detallado de las repercusiones de estos factores sobre los procesos de Gestión del Servicio. Debería existir una coordinación eficaz entre la estructura de gestión propia del proveedor del servicio, los clientes y los suministradores del proveedor del servicio a la hora de tratar cuestiones que afecten a la calidad del servicio y a los requisitos del cliente. Planificación de mejoras del servicio Los proveedores del servicio deberían adoptar un enfoque metódico y coordinado para cumplir con los requisitos de la política desde su propia perspectiva y desde la perspectiva del cliente. Antes de implementar un plan de mejora del servicio, se deberían registrar los niveles de servicio y la calidad del mismo como línea de referencia sobre la que se puedan comparar las mejoras reales. Para evaluar la eficacia del cambio se deberían comparar la mejora real con la mejora prevista. NOTA 1: Los requisitos para la mejora del servicio pueden venir de todos los procesos. Los proveedores de servicios deberían animar a su personal y a sus clientes a proponer alternativas para mejorar los servicios. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


89

NOTA 2: Esto se puede conseguir utilizando esquemas de sugerencias, círculos de calidad, grupos de usuarios y reuniones de coordinación. Los objetivos de la mejora del servicio deberían ser medibles, estar vinculados con los objetivos de negocio y estar documentados en un plan. La mejora del servicio se debería gestionar de una manera activa y se debería supervisar el progreso tomando como referencia los objetivos formalmente acordados. La Figura 4.1.9 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Como se indicó anteriormente, la metodología Planificar-Hacer-Verificar-Actuar es aplicable a todos los procesos. La fase final de esta metodología consiste en aprovechar las oportunidades de mejora y tiene que ser objeto de una cuidadosa planificación. La mejora continua es uno de los ocho principios de la gestión de la calidad. El proceso de mejora continua es uno de los pocos procedimientos documentados que se exigen explícitamente en ISO 20000. La subsección sobre mejora continua también exige de forma explícita registros de todas las mejoras sugeridas del servicio.

Guía La parte más difícil de cualquier SIP consiste en mantener las mejoras (fase 6) que se han conseguido. Es necesario documentar las mejoras de procesos para conseguir que los procesos sean reproducibles y para facilitar la definición de algún tipo de norma de calidad. Todos los conocimientos adquiridos durante el SIP se deben recopilar y divulgar mediante la aplicación de técnicas de gestión del conocimiento. Mantener las mejoras puede resultar más complejo debido a la continua aceleración de los cambios en las Tecnologías de la Información. Esta mayor demanda de cambio responde a una mayor necesidad del negocio para innovar y seguir siendo competitivo. Para conservar las mejoras de un proceso es necesario distinguir entre ganancias a corto, medio y largo plazo e incorporar los cambios principales al trabajo diario. Hay que aprovechar al máximo los éxitos rápidos para mantener el impulso y favorecer la adopción de nuevos cambios. Los procesos se tienen que monitorizar y revisar continuamente. Suponiendo que el negocio está realizando inversiones importantes en iniciativas de mejora de la Gestión de Servicios de TI y en los SIPs, se deben utilizar medidas y métricas relacionadas con el negocio y su uso de TI para demostrar que se obtiene un retorno de la inversión. Las métricas también ayudarán a los empleados a comprender en qué punto se encuentran, qué es lo que han conseguido, hacia dónde deben avanzar, cuándo se alcanzan hitos significativos y cuándo se deben superar barreras de importancia. La información de las medidas permitirá al equipo revisar y comprender los resultados e introducir ajustes a medida que progresen. Es necesario reforzar continuamente la alineación entre el negocio y las Tecnologías de la Información a todos los niveles. Las prioridades del negocio ayudan a identificar los efectos de las operaciones sobre el negocio, las partes que se ven afectadas y de qué manera. Como resultado, la productividad Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

90


del negocio en general será de más calidad y las actividades de negocio se efectuarán en el orden correcto de importancia. Establecer y publicar una política sobre mejora del servicio Definir roles y responsabilidades

Política de mejora del servicio

El personal debería conocer la política de calidad del servicio

Roles y responsabilidades definidos

Animar a empleados y clientes a que sugieran mejoras Recopilar y analizar datos sobre la capacidad del proveedor de servicios

De otros procesos de Gestión del Servicio

SIP

Valorar y registrar oportunidades de mejora

SIP

Definir objetivos para mejoras en calidad, costes y utilización de recursos

Implantar mejoras

Los objetivos de mejora del servicio tienen que: - Ser medibles - Estar vinculados a objetivos de negocio - Estar documentados en un plan

Interfaces:

Comprobar que las acciones aprobadas se llevan a cabo y cumplen los objetivos previstos

Todos los procesos: - Recibir oportunidades de mejora para SIP Gestión de cambios: - Presentar solicitudes de cambio

Corregir faltas de conformidad con los planes de Gestión del Servicio

Informes del servicio: - Recibir información Gestión de la seguridad de la información: - Recibir información de gestión sobre tendencias en incidencias de seguridad de la información

Consultar a todas las partes implicadas

Medir y comunicar las mejoras del servicio

Cuando sea necesario

Revisar las políticas, procesos, procedimientos y planes de Gestión del Servicio

Plan de mejora del servicio, incluyendo mejoras sugeridas

SIP autorizado

Comparar la mejora real con la mejora prevista

SIP

Línea de referencia para monitorizar y comparar las mejoras reales

Tener en cuenta entradas relevantes sobre mejoras

Identificar y planificar mejoras

SIP

Registros de la calidad actual del servicio y los niveles de servicio

Informe de mejoras

Política de Gestión del Servicio y plan de mejora del servicio revisados

Gestión de problemas: - Revisar incidencias graves Gestión de relaciones con el negocio: - Informar sobre el progreso

Figura 4.1.9 Mejora continua (Actuar) Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


91

4.2 Control de servicios de TI 4.2.1 Planificación e implementación de nuevos servicios o de servicios modificados (5) Objetivo: Asegurar que, tanto los servicios nuevos, como las modificaciones a los existentes, se pueden gestionar y proveer con los costes y la calidad acordados. Las especificaciones ISO 20000-1 dicen: En las propuestas de nuevos servicios o modificaciones en los existentes, se deben considerar los costes y el impacto a nivel organizativo, técnico y comercial que pudiera derivar de su entrega y gestión. La implementación de nuevos servicios o modificaciones en los existentes, incluyendo la eliminación de un servicio, debe ser planificada y aprobada a través de un proceso formal de gestión de cambios. La planificación e implementación deben incluir los fondos y recursos adecuados para llevar a cabo los cambios necesarios para la provisión y la Gestión del Servicio. Los planes deben incluir: a) Los roles y responsabilidades para implementar, operar y mantener los nuevos servicios o modificaciones en los existentes, incluyendo las actividades a llevar a cabo por clientes y suministradores. b) Los cambios en el marco de trabajo existente de Gestión del Servicio y en los propios servicios. c) La comunicación a las partes afectadas. d) Los nuevos contratos y acuerdos, o modificaciones a los contratos y acuerdos existentes, para estar alineados con las necesidades del negocio. e) Los requisitos de mano de obra y contratación. f ) Los requisitos de perfiles y formación, por ejemplo usuarios, soporte técnico. g) Los procesos, medidas, métodos, herramientas que han de usarse con relación a los nuevos servicios o modificaciones en los existentes, por ejemplo gestión de la capacidad, gestión financiera. h) Los presupuestos y plazos de tiempo. i) Los criterios de aceptación del servicio. j) Los resultados esperados al operar con el nuevo servicio, expresados en términos medibles. Los nuevos servicios, o las modificaciones en los existentes, deben ser aceptados por el proveedor del servicio antes de ser implementados en el entorno de producción real. Tras la implementación, el proveedor del servicio debe informar de los resultados alcanzados por el servicio nuevo, o por el servicio modificado, comparándolos con los resultados previstos. Se debe realizar una revisión posterior a la implementación, que compare los resultados reales con los planificados a través del proceso de gestión de cambios.


92


El Código de buenas prácticas ISO 20000-2 dice: Temas a considerar La planificación de los servicios nuevos o modificados debería incluir la revisión de: a) Los presupuestos b) Los recursos de personal c) Niveles de servicio existente d) Los SLAs y otros objetivos o compromisos del servicio e) Los procesos de Gestión del Servicio, procedimientos y documentación existentes f ) El enfoque de la Gestión del Servicio, incluyendo la implementación de los procesos de Gestión del Servicio que hubieran sido previamente excluidos del enfoque Debe tener en cuenta: - Coste - Impacto organizativo - Impacto técnico - Impacto comercial

Planificar servicios nuevos o modificados

Aprobar el plan a través de gestión de cambios

Aceptar los servicios modificados

Implantar los servicios nuevos o modificados a tr avés de gestión de cambios

Revisión Post-Implantación (PIR)

Propuesta de servicios nuevos o modificados

Incluye: - Roles y responsabilidades - Cambios en los servicios y en el marco de trabajo existente para Gestión del Servicio - Comunicación con las partes afectadas existente para Gestión del Servicio - Contratos nuevos o modificados para alinearlos con los cambios en las necesidades de negocio - Requisitos de mano de obra y contratación - Requisitos de formación y conocimientos - Uso adaptado de procesos, medidas, métodos y herramientas - Presupuestos y escalas de tiempo - Criterios de aceptación del servicio - Resultados previstos expresados en términos medibles - Alcance de la Gestión del Servicio

Registros de gestión de cambios, incluidos: - Contratación/formación de personal - Reubicación - Formación de usuarios - Comunicaciones acerca de los cambios - Cambios en el tipo de tecnología compatible - Cierre formal de servicios

Comunicar los resultados obtenidos en relación con los planificados

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP Gestión de cambios: - Planificar y aprobar la implantación de servicios nuevos o modificados, incluidos la financiación y los recursos adecuados; con aceptación formal - Presentar solicitudes de cambio Informes del servicio: - Recibir información

Figura 4.2.1 Planificación e implantación de servicios nuevos o modificados Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


93

Registros de los cambios Todas las modificaciones al servicio se deberían reflejar en los registros de gestión de cambios: Esto incluye a los planes para: a) La contratación y formación del persona b) La reubicación c) La formación al usuarios d) Las comunicaciones sobre los cambios e) Los cambios en la naturaleza de la tecnología a la que se da soporte f ) El cierre formal de los servicios La Figura 4.2.1 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Cuando el negocio de un proveedor de servicios esté en marcha, siempre existirá la necesidad de introducir servicios nuevos o modificados. Estos nuevos servicios o los cambios en el catálogo de servicios se tienen que tramitar a través del proceso de gestión de cambios. La sección de ISO 20000-1 sobre planificación e implantación de servicios nuevos o modificados estipula los requisitos que tienen que cumplir las propuestas de servicios nuevos o modificados, que constituyen una entrada para el proceso de gestión de cambios. La planificación e implantación de servicios nuevos o modificados tiene que colaborar con el proceso de gestión de cambios. La interfaz entre ambos debe estar documentada.

4.2.2 Procesos de control: gestión de la configuración (9.1) Objetivo: Definir y controlar los componentes del servicio y de la infraestructura, y mantener información precisa sobre la configuración. Las especificaciones ISO 20000-1 dice: Debe existir una visión integrada para la planificación de la gestión de cambios y de la configuración. El proveedor del servicio debe definir la interfaz con los procesos de contabilidad financiera de activos. NOTA: La contabilidad financiera de los activos queda fuera del ámbito de esta sección. Debe existir una política que defina qué se considera como elemento de configuración y qué componentes lo constituyen. Se debe definir la información que se debe registrar para cada elemento, y se deben incluir las relaciones y la documentación necesaria para la Gestión efectiva del Servicio. La gestión de la configuración debe proporcionar los mecanismos para identificar, controlar y hacer el seguimiento de las versiones de los componentes identificables del servicio y de Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

94


la infraestructura. Se debe asegurar que el grado de control es suficiente para cubrir las necesidades del negocio, los riesgos de fallo y la criticidad del servicio. La gestión de la configuración debe proporcionar información al proceso de gestión de cambios sobre el impacto de un cambio solicitado sobre la configuración del servicio y de la infraestructura. Los cambios en los elementos de configuración deben ser fáciles de identificar y auditables cuando sea apropiado, por ejemplo para cambios y movimientos en el software y el hardware. Los procedimientos de control de configuración deben asegurar que se mantiene la integridad de los sistemas, servicios y componentes de servicio. Antes de un paso al entorno real, debe establecerse una línea de referencia de los elementos de configuración correspondientes. Deben estar controladas, en una biblioteca física o electrónica segura, las copias maestras de los elementos de configuración digitales, con referencias a los registros de configuración, por ejemplo software, productos de prueba, documentos de soporte. Todos los elementos de configuración deben ser identificables de manera única y registrados en la base de datos de gestión de la configuración, cuyo acceso para actualizaciones se debe controlar de manera estricta. La base de datos de la gestión de la configuración se debe gestionar y verificar activamente para asegurar su fiabilidad y precisión. El estado de los elementos de configuración, sus versiones, ubicación, cambios y problemas relacionados, así como la documentación asociada deben estar visibles para quienes lo requieran. Los procedimientos de auditoría de la configuración deben incluir el registro de deficiencias, el lanzamiento de acciones correctivas y la comunicación de su resultado. El Código de buenas prácticas ISO 20000-2 dice: La gestión de la configuración se debería planificar e implementar junto con la gestión de cambios y la gestión de entregas para asegurar que el proveedor del servicio pueda gestionar sus activos y configuraciones de TI de forma efectiva. Debería estar disponible una información precisa sobre la configuración para dar soporte a la planificación y al control de los cambios a medida que los sistemas y los servicios nuevos y modificados son liberados y distribuidos. El resultado debería ser un sistema eficiente que integre los procesos de gestión de la información de configuración del proveedor del servicio con los de los clientes y suministradores, cuando proceda. Todos los activos y configuraciones principales se deberían tener en cuenta y tener un gestor responsable que asegure que se mantienen la protección y el control apropiados, por ejemplo: los cambios son autorizados antes de la implementación. Se podría delegar la tarea de implementar los controles, pero la responsabilidad sigue estando en el gestor responsable. Este gestor responsable debería disponer de la información necesaria para delegar Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


95

esta responsabilidad, por ejemplo, la persona que autoriza un cambio podría requerirle información del coste, riesgos, impacto del cambio y recursos para la implementación. La infraestructura y/o los servicios deberían tener un plan(es) actualizado(s) de gestión de la configuración, que puede ser independiente o formar parte de otros documentos de la planificación. Éstos deberían incluir o describir: a) Ámbito, objetivos, políticas, roles y responsabilidades normalizados. b) Los procesos de gestión de la configuración para definir los elementos de configuración de los servicios e infraestructuras, controlar cambios en las configuraciones, resgistrar e informar del estado de los ítems de configuración y verificar la integridad y la exactitud de los elementos de configuración. c) Los requisitos para la contabilidad, el seguimiento y la auditoría, por ejemplo, para propósitos de seguridad, legales, regulatorios y de negocio. d) El control de la configuración (acceso, protección, versionado, construcción, control de entrega). e) El proceso de control de los elementos de contacto que identifiquen, registren y gestionen los elementos y la información de la configuración en los límites comunes a dos o más organizaciones, por ejemplo: interfaces de sistemas, versiones. f ) La planificación y el establecimiento de los recursos para mantener los activos y las configuraciones bajo control y mantener el sistema de gestión de la configuración, por ejemplo, formación. g) La gestión de los suministradores y subcontratistas que estén llevando a cabo labores de gestión de la configuración. NOTA: Se debería implantar un nivel apropiado de automatización para asegurar que los procesos no se convierten en ineficaces en proclives al error o que no pudieran ejecutarse. Identificación de configuración Todos los elementos de configuración deberían estar identificados de manera unívoca y estar definidos por atributos que describan sus características funcionales y físicas. La información debería ser relevante y auditable. En la base de datos de la configuración deberían utilizar y registrar los marcas apropiados u otros métodos de identificación. Los elementos a ser gestionados se deberían identificar usando los criterios de selección establecidos y deberían incluir: a) Todas las distribuciones y entregas de los sistemas de información y del software (incluyendo software de terceras partes) y la documentación relativa de los sistemas, por ejemplo, las especificaciones de requisitos, diseños, informes de prueba, documentación de la entrega. b) Las líneas de referencia de la configuración o las premisas de construcción para cada entorno, módulo hardware normalizado y versión. c) Copia física maestra y bibliotecas electrónicas, por ejemplo: la biblioteca definitiva de software. d) Las herramientas o paquetes usados para la gestión de la configuración. e) Licencias. f ) Componentes de seguridad, por ejemplo: cortafuegos. g) Activos físicos que sean necesarios para la gestión financiera de activos o bien por motivos de negocio, por ejemplo: medios magnéticos seguros, equipamiento. h) Documentación relativa al servicio, por ejemplo: SLAs, procedimientos. i) Instalaciones para el soporte del servicio, por ejemplo: energía eléctrica para la sala de ordenadores. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

96


j) Relaciones y dependencias entre los elementos de la configuración. NOTA: Otros elementos que podrían ser considerados como elementos de configuración son: a) Otra documentación b) Otros activos c) Otras instalaciones, por ejemplo: emplazamientos d) Unidades de negocio e) Personas Se deberían identificar las relaciones y dependencias adecuadas entre los elementos de configuración para proporcionar el nivel de control necesario. Cuando sea necesario establecer alguna trazabilidad, el proceso debería asegurar que se puede seguir el registro de los elementos de la configuración en todo su ciclo de vida, desde los documentos de requisitos hasta los registros de entrega, por ejemplo, utilizando una matriz de trazabilidad. Control de la configuración El proceso debería garantizar que sólo los elementos de la configuración autorizados e identificables son aceptados y registrados desde su recepción hasta su baja. Ningún elemento de la configuración se debería añadir, modificar, reemplazar o eliminar/retirar sin la documentación de control apropiada, por ejemplo: aprobación de la solicitud de cambio, información actualizada de la versión. Para proteger la integridad de los sistemas, servicios e infraestructura, los elementos de la configuración se deberían mantener en un entorno seguro y adecuado que: a) Los proteja de accesos no autorizados, cambios o corrupción, por ejemplo: virus. b) Proporcione algún medio de recuperación ante desastres. c) Permita la recuperación controlada de una copia del maestro controlado, por ejemplo: software. Seguimiento del estado de configuración y elaboración de informes Los registros de la configuración se deberían mantener actualizados y con la precisión adecuada para reflejar los cambios en el estado, localización y versión de los elementos de la configuración. El seguimiento del estado debería proporcionar información sobre los datos actuales e históricos de cada elemento de configuración a lo largo de su ciclo de vida. Esto debería permitir el seguimiento de los cambios en los elementos de la configuración a través de sus diferentes estados, por ejemplo: solicitado, recibido, en pruebas de aceptación, activo, bajo cambio, retirado y eliminado. La información de la configuración se debería mantener actualizada y disponible para: los planes, la toma de decisiones y la realización de cambios a las configuraciones definidas. Cuando sea requerida, la información de la configuración debería estar accesible a: usuarios, clientes, suministradores y socios para darles apoyo en sus planes y en la toma de decisiones. Por ejemplo, un proveedor externo de servicios podría poner accesible su información de la configuración a los clientes y a otras partes, para dar soporte a los procesos de Gestión del Servicio y al resto de las partes implicadas para un servicio completo extremo a extremo. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


97

Los informes de gestión de la configuración deberían estar disponibles para todas las partes correspondientes. Los informes deberían cubrir: la identificación y el estado de los elementos de la configuración, sus versiones y la documentación asociada. Los informes deberían cubrir: a) Las últimas versiones de los elementos de la configuración. b) La localización del elemento de configuración y, para el software, la localización de las versiones maestra. c) Interdependencias. d) Historia de la versión. e) Estado de los elementos de la configuración que conjuntamente constituyan: 1) La configuración del servicio o del sistema. 2) Un cambio, una línea de referencia, un paquete de instalación o una entrega. 3) Una versión o variante. Verificación y auditoría de la configuración Los procesos de verificación y auditoría, en sus aspectos físicos y funcionales, se deberían planificar y se debería realizar una comprobación para asegurar que los procesos y recursos adecuados están establecidos para: a) Proteger las configuraciones físicas y el capital intelectual de la organización. b) Asegurar que el proveedor del servicio tiene el control de sus configuraciones, las copias maestras y las licencias. c) Garantizar que la información de la configuración está actualizada, controlada y es visible. d) Asegurar que un cambio, una entrega, un sistema o un entorno es conforme a los requisitos contratados o especificados y que los registros de la configuración son exactos. Periódicamente se deberían realizar auditorías de la configuración, antes y después de un cambio importante, después de un desastre y a intervalos aleatorios. Las deficiencias y las no conformidades se deberían registrar, evaluar e iniciar una acción correctiva, actuar sobre ellas; y se deberían realimentar a las partes correspondientes así como establecer un plan de mejora del servicio. NOTA: Normalmente hay dos tipos de auditoría de la configuración: a) Auditoría funcional de la configuración - Un examen formal para verificar que un elemento de configuración ha alcanzado el rendimiento y características funcionales especificadas en sus documentos de configuración. b) Auditoría física de la configuración - Un examen formal de la configuración “según sale de fábrica” de un elemento de configuración para verificar su conformidad con sus documentos de configuración del producto. Las actividades básicas de la gestión de la configuración son: planificación e implantación; identificación; control; seguimiento de estado e informes; y verificación y auditoría. Los documentos que se exigen explícitamente en el proceso de gestión de la configuración son los registros de configuración y los registros de deficiencias.


98


La gestión de la configuración tiene interfaces con el proceso de gestión de cambios, con el proceso de gestión de entregas y con los procesos de contabilidad de activos financieros. Estas interfaces deben estar documentadas (Figuras 4.2.2, 4.2.3 y 4.2.4).

Planificar la gestión de la configuración en línea con la gestión de cambios y definir la información que se debe registrar Designar a un gestor responsable para todos los activos y configuraciones principales

Plan de gestión de la configuración

Política en la que se defina qué se entiende por elemento de configuración (CI) y sus componentes constituyentes

El plan debe incluir: -Alcance, objetivos, políticas, normas, roles y responsabilidades -Procedimientos de control de cambios y configuración -Requisitos de seguimiento, trazabilidad y realización de auditorías -Definición de la interfaz con la gestión de entregas -Proceso de control de interfaz -Gestión de proveedores Incluidas relaciones y documentación

Definir la interfaz con los procesos de contabilidad de activos financieros Proporcionar mecanismos de identificación, control y seguimiento de versiones de CIs

Figura 4.2.2 Gestión de la configuración

Guía La gestión de la configuración incluye las siguientes actividades: • Planificación • Identificación • Control • Seguimiento del estado • Verificación • Informes La meta, los objetivos, el alcance y las prioridades de la gestión de la configuración deben estar alineados con los objetivos del negocio. El alcance de la gestión de la configuración se detalla en el paso de identificación. La identificación está relacionada con la definición y mantenimiento de convenciones de nomenclatura y números de versión de componentes físicos de la infraestructura de TI, junto con documentación, las relaciones entre ellos y los atributos correspondientes. Las líneas base de configuración del hardware existente y futuro se describen mediante clústeres de CIs.



99

Incluidas relaciones y dependencias entre CIs

Identificar CIs

Restringido a los CIs autorizados

Marcar CIs

Registrar CIs

Registros de configuración (CMDB)

Todos los activos se deben clasificar según su importancia para el servicio y el nivel de protección que requieran

Evitar cualquier modificación de CIs sin la documentación de control correspondiente

Mantener los CIs en un entorno seguro

Mantener la integridadde los CIs

Control read and update access to CMDB

Copias maestras de elementos electrónicos de configuración

Controlar copias maestras de elementos electrónicos de configuración en bibliotecas seguras

CMDB

Referenciar las copias maestras a registros de configuración

CMDB actualizada

Figura 4.2.3 Gestión de la configuración (cont.)

La pregunta básica para la identificación de componentes de TI es: “¿Qué servicios y componentes asociados de la infraestructura de TI tienen que estar controlados por disciplinas de Gestión del Servicio y qué información se necesita para ello?” Para desarrollar un sistema de identificación es necesario tomar decisiones acerca del alcance y el nivel de detalle de la información que se va a registrar. Para cada propiedad (característica) Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

100


Medir una línea base de los CIs apropiados antes de una entrega

Línea base de CIs

Proporcionar información sobre impacto a gestión de cambios

Programa de auditorías

Informes para todas las partes afectadas

Proporcionar información sobre datos de configuración

Informes de gestión de la configuración

Programar auditorías

Programa de auditorías

Verificar y auditar activamente la CMDB para emprender acciones correctivas

Informe con: - Registros de deficiencias - Acciones correctivas emprendidas - Resultado de las acciones correctivas

Incluyen: - Información de versiones - Ubicación de CIs y versiones maestras - Interdependencias - Estado de CIs

Interfaces: Procesos de contabilidad de activos financieros Mejora continua (Actuar): - Sugerir mejoras para SIP Gestión de cambios: - Presentar solicitudes de cambio - Programar auditorías de configuración antes y después de cambios importantes - Proporcionar información sobre impacto a gestión de cambios Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes Gestión de la disponibilidad y la continuidad del servicio: - Permitir el acceso a la CMDB cuando no esté permitido el acceso normal de oficina - Programar auditorías de configuración después de un desastre Gestión de la seguridad de la información: - Incluir en la CMDB información sobre activos que sean relevantes para la seguridad de la información - Mantener un inventario de activos de información Gestión de incidencias: - Intercambiar la información relevante

Figura 4.2.4 Gestión de la configuración (cont.)

se debe identificar a un propietario o grupo de interés. Cuantas más propiedades se registren, mayor esfuerzo habrá que hacer para actualizar la información. La pregunta básica enunciada anteriormente se puede descomponer en otras más detalladas para determinar la información que se va a registrar. Por ejemplo: Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


101

• ¿De qué recursos se dispone para recopilar y actualizar la información? • ¿Qué grado de madurez tienen los procesos administrativos y logísticos? • ¿A qué niveles instala, cambia, desarrolla o distribuye componentes la organización, independientemente del componente principal? • ¿Qué actividades realizadas por terceros tienen que ser medibles y mantenerse bajo control? • ¿Qué componentes afectarán a los servicios en caso de sufrir una avería y qué información se necesita para diagnosticar dicha avería? • ¿Qué componentes de coste elevado tienen que estar protegidos contra robos o pérdidas? • ¿Cuáles son las necesidades de información presentes y futuras de los otros procesos? • ¿Qué requisitos están asociados con lo estipulado en el SLA? • ¿Qué información se necesita para los cobros? • ¿Son realistas los objetivos o es preferible dejar algunas cosas para más adelante? Las respuestas a estas preguntas ofrecen información sobre diversas actividades. Hay que tomar una decisión sobre el alcance (extensión) de la CMDB, el nivel de detalle y el nivel de desglose (profundidad). Por lo que se refiere al alcance, la Figura 4.2.5 muestra las relaciones entre un servicio y los componentes de la CMDB. Por debajo de este alcance quedan los otros CIs necesarios para el servicio. Controlar estas relaciones hace que resulte más sencillo determinar el impacto de incidencias sobre los servicios. También es posible generar un informe de todos los componentes que se utilizan en un servicio. Toda esta información puede ser útil para planificar la introducción de mejoras en el servicio. El CI “servicio” también puede tener relaciones con otros CIs, como acuerdos con el cliente en forma de acuerdo de nivel de servicio. En el ejemplo de la figura, el Servicio B queda completamente fuera del alcance de la CMDB; como consecuencia, no todos los CIs que contribuyen al “Servicio A” están incluidos en el alcance de la CMDB, lo que significa que no se puede dar un soporte completo al Servicio A. Alcance CI 1 Servicio A

Infraestructura de TI

CI 2

Servicio B

CI 3 PABX

LAN 2

Aplicación A

CI 6

CI 4 Módulo A

Sistema 21

Línea 1 (digital)

NIC 12

Línea 2 (digital)

CI 7

CI 5 Módulo B

CI 8 Módem 5

Figura 4.2.5 Alcance de la CMDB


Línea 3 (analógica)

102


Una vez determinado el número de áreas en el alcance, se puede pasar a identificar los elementos del ciclo de vida de CIs que van a estar incluidos en el alcance. Para ello hay que resolver cuestiones como: ¿Se deben incluir CIs en la CMDB cuando su estado sea “en desarrollo” o “en pedido”, o bien se deben incluir sólo cuando hayan sido incorporados a la infraestructura? La ventaja de incluir productos en desarrollo es que sus especificaciones no se pueden modificar sin realizar consultas y que su transferencia al entorno de gestión resulta más sencilla. Esta decisión afectará a la actividad de monitorización de estado, pero también puede ampliar el alcance de la gestión de la configuración en términos de ciclo de vida del producto, lo que supone un aumento de recursos. Determinar el nivel de detalle de atributos para cada tipo de CI es muy importante para definir la gestión de la configuración, ya que de ello depende la información disponible sobre CIs individuales y los nombres y atributos incluidos. Para determinar el nivel de detalle es necesario buscar un equilibrio entre los requisitos de gestión de cambios, gestión de incidencias, gestión de problemas y otras disciplinas de gestión, así como la carga de trabajo asociada y los recursos necesarios para dar soporte a la gestión de la configuración. Las relaciones entre CIs son útiles para diagnosticar errores, predecir la disponibilidad de servicios y valorar cambios. Es posible registrar muchas relaciones diferentes, tanto físicas como lógicas: • Relaciones físicas − Forma parte de: Es la relación padre-hijo del CI; por ejemplo, un disco duro forma parte de un ordenador personal y un módulo de software forma parte de un programa (Figura 4.2.6). − Está conectado a: Por ejemplo, un ordenador personal conectado a un segmento de LAN. − Se necesita para: Por ejemplo, el hardware necesario para ejecutar una aplicación. • Relaciones lógicas − Es copia de: Copia de un modelo estándar, línea base o programa. − Está relacionado con: Un procedimiento, manual, documentación, un SLA o un área de clientes. − Es utilizado por: Por ejemplo, un CI necesario para la provisión de un servicio o un módulo de software utilizado por diversos programas. Para definir la profundidad de la CMDB, o los niveles de desglose de un sistema o componente, hay que crear una jerarquía de componentes y elementos (Figura 4.2.7) seleccionando los CIs padres y definiendo el número de niveles de desglose de CIs. El nivel más alto está formado por la propia infraestructura de TI, mientras que el más bajo es el más detallado sobre el que se puede ejercer control. Incluir un CI en la CMDB sólo es útil si el control de ese CI y la información relacionada redundan en beneficio de otros procesos de ISO 20000. Las implantaciones suelen empezar a un nivel elevado, tras lo cual se van introduciendo niveles más bajos de forma selectiva, especialmente cuando se implanta la gestión de entregas.



Relaciones padre-hijo

103

A1

A1

A 3.1

Sistema A A3

A 3.2

A 3.3

A4

Figura 4.2.6 Relaciones padre-hijo entre CIs (Fuente: OGC) Infraestructura de TI

Hardware

Software

Suite 1

Programa 1-1

Red

Documentación

Suite 2

Programa 1-2

Módulo 1-2-1

Programa 1-3

Módulo 1-2-2

Figura 4.2.7 Desglose de la CMDB (Fuente: OGC)

En la definición de la CMDB hay que tener en cuenta las siguientes reglas generales: • Cuantos más niveles haya, más información habrá que gestionar; esto aumenta la carga de trabajo y hace que la CMDB sea más grande y compleja. • Cuantos menos niveles haya, se tendrá menos control y menos información sobre la infraestructura de TI. También se utilizan variantes cuando coexisten distintas formas de un CI, lo que implica una relación paralela. Existen versiones, por ejemplo, si se utilizan al mismo tiempo una versión nueva y otra antigua de un mismo CI, lo que implica una relación en serie. El uso eficaz de estos dos conceptos facilita la planificación de cambios. Cada CI debe tener un nombre único y sistemático que permita distinguirlo de otros CIs. La opción más sencilla consiste en un simple sistema de numeración, tal vez dividido en distintos intervalos para cada área. Se pueden generar nuevos números cada vez que se cree un nuevo CI. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

104


Si es posible, los nombres deben tener sentido para facilitar la comunicación con los usuarios. Estas convenciones de nomenclatura también se pueden usar para poner etiquetas físicas a los CIs de forma que sean fácilmente identificables durante auditorías, labores de mantenimiento y registros de incidencias. Para cada tipo de CI se debe definir el desarrollo detallado de la CMDB, sus atributos y relaciones. Los atributos se utilizan para almacenar información sobre el tipo de CI. Los atributos indicados en la Tabla 4.2.1 pueden ser útiles para configurar CIs de infraestructura en una CMDB. Atributo Número/etiqueta o número de código de barras de CI

Copia o número de serie Número de identificación de herramienta de auditoría

Número de modelo/referencia de catálogo

Nombre de modelo

Fabricante Categoría Tipo

Fecha de caducidad de la garantía Número de versión Ubicación

Responsable propietario Fecha de responsabilidad Origen/suministrador Licencia Fecha de suministro

Descripción Identificación exclusiva del CI. Suele ser un número de registro asignado automáticamente por la base de datos. Aunque no todos los CIs pueden llevar una etiqueta física, todos ellos tienen un número exclusivo. Número de identificación del suministrador en forma de número de serie o de licencia. Las herramientas de auditoría suelen tener sus propios identificadores, que pueden ser distintos para cada área. Este atributo proporciona un vínculo para este entorno. Identificación exclusiva empleada en el catálogo por el suministrador. Cada versión de un modelo tiene un número distinto (por ejemplo, PAT-NL-C366-4000-T). Nombre completo del modelo, que suele incluir un identificador de versión (por ejemplo, PII MMX 400 MHz). Fabricante del CI. Clasificación del CI (por ejemplo, hardware, software o documentación). Descripción del tipo de CI con detalles sobre la categoría (por ejemplo, configuración de hardware, paquete de software o módulo de programa). Fecha en que caduca la garantía. Número de la versión del CI. Ubicación del CI (por ejemplo, la biblioteca o medio donde residen los CIs software o el centro/ sala donde están los CIs hardware). Nombre y/o designación del propietario o persona responsable del CI. Fecha en que la persona anterior se hizo responsable del CI. El origen del CI (por ejemplo, desarrollado en la organización o adquirido por el suministrador X). Número de licencia o referencia al acuerdo de licencia. Fecha en que el CI fue suministrado a la organización.



Atributo Fecha de aceptación Estado (actual) Estado (previsto) Coste Valor residual después de depreciación Comentarios

105

Descripción Fecha en que el CI fue aceptado y aprobado por la organización. Estado actual del CI (por ejemplo, “en pruebas”, “activo” o “retirado”). El siguiente estado previsto del CI, con fecha e indicación de la acción a realizar. Coste de adquisición del CI. Valor actual del CI después de su depreciación. Campo de texto para comentarios (por ejemplo, para describir las diferencias entre variantes).

Tabla 4.2.1 Ejemplos de atributos

Dependiendo de la herramienta de Gestión del Servicio, los eventos (incidencias, por ejemplo) se pueden incluir en la CMDB como atributos de CIs o de otra manera. En general, se indican los números de los CIs correspondientes en los registros de incidencias, problemas y cambios. Sea cual sea el método seleccionado, se deben mantener las relaciones entre el CI y los registros como se indica en la Tabla 4.2.2. Atributo Número de Solicitud de Cambio (RFC) Número de problema Número de incidencia

Descripción Números de RFCs activas o abiertas previamente para el CI. Números de problemas activos o abiertos previamente para el CI. Números de incidencias relacionadas con el CI.

Tabla 4.2.2 Otros registros relacionados con CIs

El mantenimiento de las relaciones entre CIs es una parte importante de la gestión de la configuración. Dependiendo del tipo de base de datos, estas relaciones se pueden incluir como atributos de CIs o en una tabla aparte (Tabla 4.2.3). Atributo Relaciones de CIs padres Relaciones de CIs hijos Otras relaciones

Descripción Clave o número de CI de los CIs padres. Clave o número de CI de los CIs hijos. Relaciones entre el CI y otros CIs, aparte de las relaciones padre-hijo ya mencionadas (por ejemplo, un CI “utiliza” o “está conectado a”).

Tabla 4.2.3 Atributos de relaciones

Algunas bases de datos disponen de un método que permite ver un registro histórico de atributos y relaciones. Esto puede ser útil para obtener información sobre tiempo de parada, reparaciones y mantenimiento en los campos de “Estado actual”, así como para llevar un seguimiento de los propietarios anteriores. Puede ser necesario mantener listas de atributos con información técnica sobre cada tipo de CI. También se deben crear vínculos con otras fuentes de información fiable sobre: ubicaciones, Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

106


usuarios, departamentos, números de teléfono, titulares de presupuestos y números de presupuestos. Existen más opciones, pero siempre hay que tener en cuenta la carga de trabajo y los métodos de control de cambios necesarios para el mantenimiento de estos archivos. Una línea base de configuración es una instantánea de un grupo de CIs en un momento concreto. Se puede utilizar como: • Un producto con soporte/autorizado que se puede incorporar a la infraestructura de TI (estas líneas base están incluidas en el catálogo de productos). • CIs estándar para registrar información de costes (elementos de coste). • Puntos de partida para el desarrollo y las pruebas de nuevas configuraciones. • Puntos de marcha atrás en caso de problemas con nuevas configuraciones después de cambios. • Un estándar para la entrega de configuraciones a usuarios (por ejemplo, una “estación de trabajo estándar”). • Un punto de partida para el suministro de nuevo software. Una estación de trabajo estándar es un ejemplo habitual de línea base de producto. Al limitar el número de estaciones de trabajo estándar diferentes, resulta más fácil estimar el impacto y los recursos necesarios para el despliegue y las pruebas de nuevas funciones y mejoras. Las líneas base también se pueden usar para establecer una política de combinación y planificación de cambios (por ejemplo, para Paquetes de Entrega). Las líneas base ayudan a reducir los costes de gestión y facilitan la planificación de proyectos. Otra aplicación útil de las líneas base es el catálogo de productos, que contiene una lista de las configuraciones certificadas que se pueden usar en la infraestructura de TI y que los usuarios pueden solicitar. En este caso, un CI nuevo es una copia del catálogo con un número exclusivo y una etiqueta. Antes de añadir un producto al catálogo siempre hay que analizar su caso de negocio. El ciclo de vida de un componente se puede dividir en varias fases, cada una de ellas con un código de estado asignado. Esta división depende de las características de la infraestructura de TI que la organización quiera registrar. Mantener un registro de la fecha de cada cambio de estado puede proporcionar información útil sobre el ciclo de vida de un producto: fecha de pedido, fecha de instalación y mantenimiento y soporte necesarios. El estado de un componente también puede determinar su posible uso. Por ejemplo, si se efectúa un seguimiento del estado de los repuestos no operativos, es posible que este hardware no se pueda desplegar en otros lugares sin una consulta previa (por ejemplo, como parte de un plan de recuperación ante desastres). El siguiente es un ejemplo de una posible clasificación de estados: • CIs nuevos – En desarrollo/en pedido – Probado – Aceptado • CIs existentes – Recibido – Solicitud de Cambio (RFC) abierta para el CI (se ha pedido una nueva versión) Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


107

– Cambio aprobado e incluido en los planes (se proporcionará un nuevo CI y documentación, que también es un CI) – Mantenimiento en curso – Parado • CIs archivados – Retirado – Borrado – Eliminado – Robado – Vendido o alquiler no renovado – En archivo a la espera de donación, venta o destrucción – Destruido • Todos los CIs – En reserva – Pedido recibido o versión modificada disponible – En pruebas – Entregado para instalación – Activo (CI en uso) – Repuesto La información se tiene que gestionar de una manera eficaz para mantener actualizada la CMDB. Siempre que una actividad cambie las características registradas de un CI o las relaciones entre CIs, el cambio debe quedar registrado en la CMDB. Nota: Las características de los CIs sólo se pueden modificar mediante cambios debidamente autorizados por la gestión de cambios; la gestión de incidencias únicamente puede cambiar el estado de un CI existente para reflejar la realidad de una situación (por ejemplo, una parada del sistema). La gestión de la configuración controla todos los componentes de TI recibidos por la organización y garantiza que están registrados en el sistema. El hardware se puede registrar en el momento del pedido o la entrega, mientras que el software se puede registrar cuando se incluye en la Biblioteca de Software Definitivo (DSL) o en la Biblioteca de Medios Definitivos (DML). Una de las tareas de control consiste en garantizar que los CIs sólo se registran si han sido autorizados y están incluidos en el catálogo de productos. Por este motivo, la gestión de la configuración mantiene una relación muy estrecha con la gestión de proveedores, la gestión de incidencias, la gestión de problemas y la gestión de cambios. Si en la infraestructura de TI se introducen cambios coordinados por la gestión de cambios, la gestión de la configuración tendrá que incorporar esta información a la CMDB. La gestión de la configuración impone requisitos sobre la madurez de otros procesos en la organización, y especialmente sobre los procesos de gestión de cambios, gestión de entregas y los procesos del departamento de compras. Para garantizar que la situación real refleja la CMDB autorizada, la gestión de la configuración monitoriza las acciones siguientes cuando: • Se añade un CI. • Cambia el estado de un CI; por ejemplo, “encendido” o “parado” (útil para gestión de la disponibilidad). Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

108


• Cambia el propietario de un CI. • Cambia la relación de un CI con otro CI. • Se elimina un CI. • Cambian las relaciones de un CI con un servicio, con la documentación o con otros CIs. • Se renueva o modifica la licencia de un CI. • Se modifican los detalles de un CI después de una auditoría. La gestión de la configuración también tiene la responsabilidad de hacer que se resuelva cualquier problema que pueda surgir en un proceso. Las auditorías se utilizan para verificar que la situación actual continúa reflejando los datos de la CMDB. Por ejemplo, las herramientas de auditoría pueden realizar análisis automáticos de estaciones de trabajo y generar informes sobre la situación actual y el estado de la infraestructura de TI. Esta información permite comprobar y actualizar la CMDB. Se pueden realizar auditorías en las situaciones siguientes: • Después de la implantación de la nueva CMDB • Un tiempo después de la implantación • Antes y después de cambios importantes • Después de un proceso de recuperación ante desastres • Aleatoriamente cuando el gestor de la configuración considere que la información puede ser incorrecta Las herramientas de auditoría no deben tener capacidad para modificar automáticamente la CMDB cuando se detecten discrepancias. Todas las discrepancias indican que se han omitido procesos de la gestión de cambios, por lo que su investigación y resolución corresponden a la gestión de cambios. El factor crítico de éxito para la gestión de la configuración consiste en mantener actualizada la información de la base de datos. Esto significa que se tienen que cumplir todos los requisitos de la gestión de cambios y la gestión de entregas y que para que se registre información debe existir siempre un grupo de interés. Es muy importante que la implantación de la gestión de la configuración se divida en varias fases. Los intentos de forzar en exceso el alcance de la gestión de la configuración en un solo paso están generalmente condenados al fracaso. Los registros mantenidos antes de la implantación del proceso tienen que ser retirados para evitar duplicaciones. El éxito de la introducción del proceso se verá favorecido si se consiguen algunos éxitos rápidos y si los elementos de registro del proceso se asignan a personal que no sólo tiene los conocimientos precisos, sino también la actitud adecuada. Los informes de gestión de la configuración pueden incluir los siguientes elementos: • Información sobre la calidad del proceso. • Número de diferencias detectadas entre los registros y la situación real durante una auditoría (deltas). • Número de ocasiones en que se ha detectado que una configuración no estaba autorizada. • Número de ocasiones en que no se pudo localizar una configuración registrada. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


109

• Diferencias de nivel de atributos descubiertas por auditorías. • Tiempo necesario para procesar una solicitud de registro de información. • Lista de CIs para los que se registraron cambios o incidencias por encima de un número determinado. • Información estadística sobre la estructura y composición de la infraestructura de TI.

4.2.3 Procesos de control: Gestión de cambios (9.2) Objetivo: Asegurar que todos los cambios son evaluados, aprobados, implementados y revisados de una manera controlada. Las especificaciones ISO 20000-1 dicen: Los cambios en los servicios y la infraestructura deben tener un ámbito claramente definido y documentado. Todas las peticiones de cambio se deben registrar y clasificar, por ejemplo en urgentes, de emergencia, importantes, menores. Se debe evaluar el riesgo, el impacto y los beneficios para el negocio de las peticiones de cambio. El proceso de gestión de cambios debe incluir la forma en que puede darse marcha atrás o corregir cada cambio si no se realiza con éxito. Los cambios se deben aprobar y tras ello deben ser comprobados, y deben ser implementados de una forma controlada. Se debe revisar el éxito de todos los cambios y, en caso contrario, se deben decidir y llevarse a cabo acciones correctivas tras la implementación. Deben existir políticas y procedimientos para controlar la autorización e implementación de cambios de emergencia. La fechas planificadas para la implementación de los cambios se deben utilizar como base para la planificación de cambios y entregas. Se debe mantener y comunicar a las partes correspondientes la planificación que contenga los detalles de todos los cambios aprobados para su implementación y las fechas propuestas. Los registros de cambios se deben analizar regularmente para detectar incrementos en el volumen de cambios, tipos recurrentes frecuentemente, tendencias emergentes y cualquier otra información relevante. Los resultados y conclusiones obtenidos a partir del análisis de los cambios se deben registrar. Las acciones de mejora identificadas para la gestión de cambios se deben registrar y debe proporcionar información de entrada al plan de mejora del servicio.


110


El Código de buenas prácticas ISO 20000-2 dice: Planificación e implantación Los procesos y procedimientos de gestión de cambios deberían garantizar que: a) Los cambios tienen claramente definido y documentado su alcance. b) Sólo son aprobados los cambios que proporcionan beneficios al negocio, por ejemplo: comerciales, legales, regulatorios y estatuarios. c) Los cambios son planificados en base a la prioridad y al riesgo. d) Los cambios a las configuraciones pueden ser verificados durante la implementación del cambio. e) Cuando sea requerido, el plazo para la implementación de los cambios es supervisado y para identificar propuestas de mejora. f ) Puede demostrarse cómo un cambio es: 1) Generado, registrado y clasificado (con las referencias a los documentos que dieron origen al cambio). 2) Evaluado en relación al impacto, la urgencia, el coste, los beneficios y el riesgo del cambio en el servicio, en los clientes y en los planes de despliegue. 3) Revertido y remediado, si no tuvo éxito. 4) Documentado, por ejemplo, la solicitud de cambio está asociada a los elementos de configuración afectados, a la versión actualizada de la implementación y a los planes de despliegue. 5) Aprobado o rechazado por la autoridad de cambios, dependiendo de su tipo, tamaño o riesgos. 6) Implementado por el responsable designado dentro de los grupos responsables de los componentes a ser cambiados. 7) Probado, verificado y entregado. 8) Cerrado y revisado. 9) Planificado, supervisado e incluido en un informe. 10) Asociado a incidencias, problemas, otro cambio y a los registros de elementos de configuración, cuando sea apropiado. El estado de los cambios y las fechas de implementación planificadas se deberían usar como base para la planificación del cambio y del despliegue. La información de planificación debería estar disponible para las personas afectadas por el cambio. Cuando se pueda ocasionar una perdida del servicio durante el horario normal del servicio, las personas afectadas deberían acordar el cambio antes de su implementación. Cierre y revisión de una solicitud de cambio Todos los cambios se deberían revisar en relación a su éxito o fallo después de la implementación y cualquier mejora debería ser registrada. Se debería realizar una revisión después de la implementación en los cambios principales para comprobar que: a) El cambio cumple sus objetivos. b) Los clientes están satisfechos con los resultados. c) No ha habido efectos colaterales inesperados. Toda no conformidad se debería registrar y tomarse las acciones pertinentes. Cualquier debilidad o deficiencia identificada en la revisión del proceso de gestión de cambios, debería alimentar los planes de mejora del servicio. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


111

Cambios de emergencia En ocasiones se requiere la realización de cambios de emergencia, y cuando sea posible, se debería seguir el proceso de cambio, aunque algunos detalles se documenten a posteriori. Cuando el proceso de emergencia se salte algunos requisitos del proceso de gestión de cambios, el cambio debería cumplir estos requisitos tan pronto como sea posible. Los cambios de emergencia se deberían justificar por quien los implementa y deberían ser revisados después del cambio para verificar que era una verdadera emergencia. Informes, análisis y acciones de la gestión de cambios Los registros de los cambios se deberían analizar de forma periódica, para detectar incrementos en el nivel de cambios, frecuencia de los tipos recurrentes, tendencias emergentes y cualquier otra información relevante. Los resultados y las conclusiones derivados del análisis de los cambios se deberían registrar y actuar sobre ellos. La Figura 4.2.8 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Las actividades básicas del proceso de gestión de cambios consisten en registrar, aceptar y clasificar solicitudes de cambio. Si un cambio es autorizado, se tiene que programar, implantar, cerrar y revisar. Los documentos exigidos explícitamente para la gestión de cambios son los registros de cambio y los registros para acciones de mejora. Una solicitud de cambio puede proceder de otros procesos, de un usuario o de un empleado. Estas interfaces con el proceso de gestión de cambios tienen que estar debidamente documentadas, al igual que la interfaz de la gestión de cambios con el proceso de mejora continua.

Guía El proceso de gestión de cambios aprueba o rechaza todas las Solicitudes de Cambios (RFC). El proceso está dirigido por el gestor de cambios, aunque las decisiones sobre los cambios más significativos se adoptan en el Comité de Cambios (CAB). El CAB incluye miembros de muchas partes de la organización, así como clientes y suministradores. La gestión de la configuración se encarga de proporcionar información sobre el impacto potencial de cada cambio propuesto. Las entradas de la gestión de cambios son: • RFCs procedentes de clientes, legislación o suministradores. • Información de la CMDB (específicamente, el análisis de impacto de los cambios). • Información procedente de otros procesos, como gestión de problemas y gestión de la capacidad. • Planificación de cambios (Lista de Cambios Planificados, FSC). Las salidas del proceso son: • Lista actualizada de cambios (FSC) • Disparadores para gestión de la configuración y gestión de entregas • Orden del día, actas y decisiones del CAB • Informes de gestión de cambios


112


Planificar la gestión de cambios

Interfaces: Todos los procesos relevantes: - Presentar solicitudes de cambio Mejora continua (Actuar): - Sugerir mejoras para SIP

Definir políticas y procedimientos para controlar los cambios de emergencia

Planificación e implantación de servicios nuevos o modificados: - Planificar y aprobar la implantación de servicios nuevos o modificados, incluyendo la financiación y los recursos adecuados; con aceptación formal

Gestión de entregas: - Controlar la implantación de servicios - Valorar el impacto de las solicitudes de cambios sobre los planes de entrega - Actualizar registros de cambios - Gestionar entregas de emergencia según el proceso de gestión de cambios de emergencia

Solicitud de cambio (RFC)

Gestión del nivel de servicio: - Controlar los cambios introducidos en SLAs y otros contratos

Controlar la implantación y el retiro de servicios

Incluida revisión post-implantación

Registrar RFC

Con un alcance bien definido y documentado para cambios en servicio e infraestructura

Registros de RFC

Incluye el impacto sobre: - Planes de disponibilidad y continuidad y documentos relacionados - Controles de seguridad - Evaluaciones de riesgos para la seguridad

Clasificar RFC: evaluar riesgo, impacto, beneficio para el negocio y coste

Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes - Estimar el coste y aprobar cambios en servicios

Aprobar y comprobar el cambio

Programación de cambios

Gestión de proveedores: - Gestionar los cambios introducidos en contratos y SLAs Gestión de la disponibilidad y la continuidad del servicio: - Evaluar el impacto de cualquier cambio sobre el plan de disponibilidad y continuidad del servicio - Controlar todos los cambios introducidos en la documentación de disponibilidad y continuidad del servicio - Vincular la documentación con la gestión de cambios Gestión de la seguridad de la información: - Valorar el impacto de los cambios sobre los controles de seguridad antes de implantar los cambios - Realizar evaluaciones de riesgos para la seguridad - Evitar que los cambios reduzcan la eficacia de los controles

Todos los cambios de emergencia tienen que acabar siguiendo el proceso de cambio estándar

Controlar los cambios introducidos en SLAs y otros contratos

Gestión de la configuración: - Programar auditorías de configuración antes y después de cambios importantes

Gestión de relaciones con el negocio: - Gestionar los cambios introducidos en contratos (en su caso) y SLAs

Política y procedimiento para cambios de emergencia

Programar el cambio

Implantar el cambio

Programación de cambios actualizada

Registros de cambios

Revertir o corregir los cambios fallidos Registros de acciones de mejora Registros de cambios

Analizar registros de cambios y revisar el cambio

Registros de acciones de mejora

Utilizar como entrada para SIP

Registros de análisis de cambios

Figura 4.2.8 Gestión de cambios


Comunicar la programación a las partes afectadas


113

La gestión de cambios utiliza las siguientes actividades para el procesamiento de cambios (Figura 4.2.9): • Registro • Aceptación • Clasificación • Planificación y aprobación • Coordinación • Evaluación Presentación de RFC; Registro Rechazo; posible RFC nueva Aceptación; Filtrado de RFCs

¿Es urgente?

Sí

No

Procedimientos de urgencia

Clasificación; categoría y prioridad

Planificación; impacto y recursos Puede ser iterativo Coordinación Construcción Pruebas

¿Funciona?

Sí

No

Iniciar plan de marcha atrás

Implantación

Evaluación y cierre

Figura 4.2.9 Actividades de la gestión de cambios según ITIL V2


114


En primer lugar hay que registrar todas las RFCs. Si se presenta una RFC para resolver un problema, también se debe registrar el número del error conocido. No todas las solicitudes de modificación se tratan como cambios; algunas tareas de gestión rutinarias, que están claramente definidas y cubiertas por procedimientos (cambios estándar) pero que no implican la modificación de la infraestructura, se pueden tratar como si fueran peticiones de servicio. El resultado es la siguiente clasificación de cambios: • Cambios estándar (como peticiones de servicio) - Cuando existen modelos de cambios aprobados y perfectamente definidos que se registran individualmente, pero que no son evaluados individualmente por la gestión de cambios; estos cambios son rutinarios. (Nota: No todas las peticiones de servicio son cambios.) • Cambios no estándar - Todas las demás modificaciones de la infraestructura gestionada que no son cambios estándar. Entre la información que puede contener una RFC figura la siguiente: • Número de identificación de la RFC. • Número del error conocido/problema asociado (en su caso). • Descripción e identificación de los correspondientes CIs. • Motivo del cambio, incluidos justificación y beneficio para el negocio. • Versión actual y nueva de los CIs que se vayan a cambiar. • Nombre, ubicación y número de teléfono de la persona que presenta la RFC. • Fecha de presentación. • Estimación de recursos y escalas de tiempo. Una vez registradas las RFCs, la gestión de cambios llevará a cabo una valoración inicial para comprobar si alguna de las RFCs está poco clara o si es ilógica, impracticable o innecesaria. Estas solicitudes son rechazadas especificando el motivo para ello. La persona que haya presentado la solicitud debe tener siempre la oportunidad de defender su posición. Un cambio conduce a la modificación de los datos en la CMDB; por ejemplo: • Un cambio en el estado de un CI existente. • Un cambio en la relación entre un CI y otros CIs. • Un nuevo CI o una variación de un CI existente. • Un nuevo propietario o ubicación de un CI. Si la RFC es aceptada, la información necesaria para seguir adelante con el procesamiento del cambio se incluye en un registro de cambio. En primer lugar se determinan la prioridad y la categoría: • La prioridad indica la importancia de un cambio en relación con otras RFCs. Puede variar entre baja y alta (máxima) y depende de la urgencia, la escala de tiempos y la necesidad de cambio para el negocio. • La categoría se determina en función del impacto del cambio sobre el riesgo para los servicios y la disponibilidad de recursos. El impacto puede oscilar entre leve y grave.



115

Posteriormente se añade al registro la siguiente información: • Recomendaciones del gestor de cambios • Fecha y hora de la autorización • Fecha prevista para la implantación del cambio • Planes de back-up • Requisitos de soporte • Plan de implantación • Información sobre los encargados de la construcción y la implantación • Fecha y hora reales del cambio • Fecha de la evaluación • Resultados de pruebas y problemas detectados • Motivos para rechazar la solicitud (en su caso) • Información sobre la evaluación y el escenario La gestión de cambios planifica los cambios mediante un calendario o Lista de Cambios Planificados (FSC). La FSC contiene detalles de todos los cambios aprobados y las fechas previstas para su implantación. Los miembros del CAB asesoran sobre la planificación de cambios importantes, la disponibilidad de personal, los costes y los aspectos afectados del servicio, además de garantizar la participación de los clientes. El CAB funciona así como un comité asesor. La gestión de cambios goza de una autoridad delegada, ya que actúa en representación de la dirección de TI. Es posible que los cambios más importantes tengan que ser aprobados por la dirección de TI antes de llegar al CAB. Esta aprobación puede incluir aspectos financieros, técnicos y de negocio. Para que la planificación resulte eficaz es necesario que la gestión de cambios se mantenga en contacto con las oficinas del proyecto y con todos los demás miembros de la organización encargados de construir e implantar los cambios. También la comunicación del plan de cambios se tiene que realizar con la máxima eficacia. Previa consulta con los departamentos de TI afectados, el CAB puede especificar ventanas de tiempo periódicas para la implantación de cambios aprovechando los momentos que minimicen el impacto sobre el servicio. Los mejores momentos podrían ser los fines de semana o fuera del horario habitual de oficina. Del mismo modo se pueden establecer períodos durante los cuales no esté permitido realizar cambios (o sólo unos pocos), como durante las horas de oficina o al final del año fiscal, cuando todos los departamentos de usuarios están cerrando sus cuentas. La información sobre la planificación de un cambio se debe distribuir antes de la reunión del CAB, al igual que los documentos relevantes para los puntos del orden del día. • El orden del día de las reuniones del CAB tiene que incluir algunos puntos fijos, como: • Cambios no autorizados • Cambios autorizados que no hayan sido presentados al CAB • RFCs que deban ser valoradas por los miembros del CAB • Cambios abiertos y cerrados • Evaluaciones de cambios anteriores A la hora de estimar los recursos necesarios y el impacto del cambio, los miembros del CAB, el gestor de cambios y todas las demás partes involucradas (identificadas por el CAB) deben tener Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

116


en cuenta los siguientes aspectos: • Capacidad y rendimiento de los servicios afectados • Fiabilidad y capacidad de recuperación • Planes de gestión de la continuidad de los servicios de TI • Planes de marcha atrás • Seguridad • Impacto del cambio sobre otros servicios • Registros y aprobación • Costes y recursos necesarios (soporte y mantenimiento) • Número y disponibilidad de los especialistas necesarios • Duración necesaria del ciclo del cambio • Nuevos recursos que deban ser adquiridos y probados • Impacto sobre las operaciones • Posibles conflictos con otros cambios Los miembros del CAB también pueden asesorar sobre la prioridad. Los cambios aprobados se comunican a los especialistas en los productos correspondientes para que puedan construir e integrar los cambios. La construcción puede incluir la creación de una nueva versión de software con nueva documentación, manuales, procedimientos de instalación, un plan de marcha atrás y cambios de hardware. La gestión de cambios se encarga del control y la coordinación. Para ello cuenta con el apoyo de la gestión de entregas y la dirección de línea, que tienen que garantizar que se han asignado los recursos apropiados para implantar los planes. Como parte de la entrega de un cambio se debe redactar un procedimiento de marcha atrás para invertir el cambio si no ofrece el resultado necesario. La gestión de cambios no debería aprobar el cambio si no existe un procedimiento de marcha atrás. También es necesario redactar un plan de comunicación en caso de que el cambio tenga algún impacto sobre el entorno del usuario. Durante la fase de construcción se prepara igualmente un plan de implantación. El procedimiento de marcha atrás, la implantación del cambio y el resultado previsto del cambio se tienen que someter a pruebas completas, teniendo en cuenta los criterios definidos anteriormente por el CAB. En la mayor parte de los casos, las pruebas requieren un laboratorio o un entorno de pruebas independiente. Las primeras fases de las pruebas pueden ser realizadas por los encargados de la construcción, pero no se debe implantar ningún cambio sin someterlo a algunas pruebas independientes. Estas pruebas suelen ser de dos tipos: • Pruebas de aceptación del usuario - La comunidad del negocio (el cliente del cambio, por lo general) prueba la funcionalidad del cambio. • Pruebas de aceptación de operaciones - Pruebas independientes realizadas por los encargados del soporte y mantenimiento de la infraestructura modificada, como el centro de atención al usuario. Si no se puede probar un cambio de forma adecuada, es posible que se pueda aplicar el cambio a un pequeño grupo piloto de usuarios para evaluar los resultados antes de implantarlo a una escala mayor.



117

Cualquier miembro del departamento afectado que sea responsable de gestionar la infraestructura de TI puede recibir el encargo de implantar un cambio en esa infraestructura. La gestión de cambios tiene que hacer que se cumpla el programa del cambio. Debe existir un plan de comunicación que indique claramente a quién se tiene que informar del cambio (por ejemplo, los usuarios, el centro de atención al usuario y la gestión de red). Con la posible excepción de los cambios estándar, todos los cambios implantados se tienen que evaluar. El CAB decide si es necesario efectuar algún seguimiento. Para ello se deben tener en cuenta las siguientes cuestiones: • ¿Ha conducido el cambio al objetivo deseado? • ¿Están los usuarios satisfechos con el resultado? • ¿Ha habido algún efecto secundario? • ¿Se han superado los esfuerzos y los costes estimados? • ¿Se han cumplido los plazos? • ¿Qué ha salido mal? La RFC se puede cerrar si el cambio ha tenido éxito. Los resultados se incluyen en la Revisión PostImplantación (PIR) o en la evaluación del cambio. Si, por el contrario, el cambio no ha tenido éxito, el proceso se reinicia en el punto en que falló utilizando un método distinto. Normalmente es aconsejable dar marcha atrás en el cambio y crear una nueva RFC basada en la RFC original, puesto que seguir adelante con un cambio frustrado suele empeorar más las cosas. El uso de procedimientos de evaluación con un límite de tiempo concreto puede ayudar a impedir que se ignoren las evaluaciones de cambios. Dependiendo de la naturaleza del cambio, la evaluación se puede realizar al cabo de unos días o de unos meses. Por muy buena que sea la planificación, siempre puede haber cambios que tengan una prioridad absoluta. Los cambios urgentes son muy importantes y se deben llevar a cabo lo antes posible. En la mayor parte de los casos es necesario desviar para estos cambios los recursos dedicados a otras actividades. Los cambios urgentes pueden tener un gran impacto sobre el trabajo planificado. Por lo tanto, el objetivo es que el número de cambios urgentes o imprevistos (prioridad “máxima”) sea lo más bajo posible. Algunas medidas preventivas consisten en: • Garantizar que los cambios se soliciten a tiempo, antes de que pasen a ser urgentes. • Al corregir errores debidos a un cambio mal preparado, no se debe revertir la situación más allá de una versión anterior llamada Estado Previo de Confianza; posteriormente se tiene que preparar con todo cuidado una implantación mejorada del cambio. A pesar de estas medidas, existe la posibilidad de que surjan cambios urgentes que requieran procedimientos para tratarlos con rapidez y sin que la gestión de cambios pierda el control del proceso. Si hay tiempo suficiente, el gestor de cambios puede organizar una reunión de emergencia del CAB en la que participen únicamente los miembros necesarios para evaluar, autorizar y asignar recursos para el cambio. Si no se dispone de tiempo, o si la petición se presenta fuera del horario de oficina, tiene que haber un método alternativo para obtener la autorización. El proceso CAB/EC no tiene que ser necesariamente una reunión en persona, sino que también puede tratarse de una llamada telefónica.


118


Es posible que no haya tiempo suficiente para realizar las pruebas normales, por lo que después de la implantación se deben ejecutar todas las fases necesarias de los procedimientos normales de prueba. De esta forma se garantiza la realización de las pruebas omitidas anteriormente, la actualización de los archivos (registros de cambios y CMDB) y la posibilidad de efectuar un seguimiento del cambio (“¿qué es lo que ha cambiado?”). El objetivo de la gestión de cambios es conseguir un equilibrio entre flexibilidad y estabilidad. Para reflejar la situación de la organización en cada momento se pueden preparar informes de gestión que cubran los siguientes aspectos: • Número de cambios implantados en un período (en total y para cada categoría de CI) • Lista de causas de cambios y RFCs • Número de cambios implantados con éxito • Número de marchas atrás y sus motivos • Número de incidencias relacionadas con los cambios implantados • Gráficos y análisis de tendencias en períodos determinados Los KPIs para la gestión de cambios son: • Número de cambios realizados por unidad de tiempo y categoría • Velocidad de implantación de cambios • Número de cambios rechazados • Número de incidencias debidas a cambios • Número de marchas atrás relacionadas con cambios • Coste de los cambios implantados • Número de cambios realizados dentro del plazo y con los recursos previstos Es posible combinar varias RFCs en una sola entrega, en cuyo caso un único plan de marcha atrás será suficiente si algo va mal. Este tipo de entrega conjunta puede ser considerada un cambio en sí misma aunque conste de varios cambios, cada uno de los cuales debe ser aprobado por separado. La implantación de entregas corresponde a la gestión de entregas, que se discute en la siguiente sección.

4.2.4 Proceso de gestión de entregas (10.1) Objetivo: Entregar, distribuir y realizar el seguimiento de uno o más cambios en la entrega en el entorno de producción. Las especificaciones ISO 20000-1 dicen: NOTA: El proceso de gestión de entregas se debería integrar con los procesos de gestión de la configuración y de gestión de cambios. Se debe documentar y acordar la política de entrega que establezca la frecuencia y el tipo de la entregas. El proveedor del servicio debe planificar con el negocio la entrega de los servicios, sistemas, software y hardware. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


119

Los planes sobre cómo desplegar una entrega se deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes, usuarios, personal de operaciones y de soporte. El proceso debe incluir la forma en que se dé marcha atrás o se corrige la entrega si no se realiza con éxito. Los planes deben registrar los entregables y las fechas de la entrega, y hacer referencia a las peticiones de cambio, errores conocidos y problemas relacionados. El proceso de gestión de entregas debe proporcionar la información adecuada al proceso de gestión de incidencias. Las peticiones de cambio se deben evaluar en cuanto a su impacto en los planes de entregas. Los procedimientos de gestión de entregas deben incluir la actualización y el cambio de la información de configuración y los registros de cambio. Las entregas de emergencia se deben gestionar de acuerdo a un proceso definido que realice la interfaz con el proceso de gestión de cambios de emergencia. Se debe establecer un entorno controlado de pruebas de aceptación para construir y probar todas las entregas previamente a su distribución. Las entregas y su distribución se deben diseñar e implementar de forma que la integridad del hardware y del software se mantenga a lo largo de la instalación, la manipulación, el empaquetado y la provisión. Se debe medir el éxito y el fallo de las entregas. Las mediciones deben incluir las incidencias relacionados con la entrega en el periodo siguiente a su despliegue. Los análisis deben incluir la evaluación del impacto en el negocio y en el personal de operación y soporte de TI, y deben proporcionar información de entrada al plan para la mejora del servicio. El Código de buenas prácticas ISO 20000-2 dice: Generalidades La gestión de entregas debería coordinar las actividades del proveedor del servicio, los diferentes proveedores y el negocio para planificar y desplegar una entrega a lo largo de un entorno distribuido. Son esenciales una buena planificación y gestión para empaquetar y distribuir una entrega con éxito, y para gestionar los impactos y riesgos asociados al negocio y a las TI. Se debería planificar con el negocio la entrega de los sistemas de información, las infraestructuras, los servicios y la documentación afectados. Todas las actualizaciones asociadas a la documentación se deberían incluir en la entrega, por ejemplo: los procesos de negocio, los documentos de apoyo y los acuerdos de nivel de servicio. Se debería evaluar el impacto de todos los elementos de configuración, nuevos o cambiados, requeridos para efectuar los cambios autorizados. El proveedor del servicio se debería asegurar que los aspectos técnicos y no técnicos de la entrega son considerados de forma conjunta. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

120


Los elementos de la entrega deberían poder ser trazables y no ser modificables. Sólo se deberían aceptar en el entorno de producción las entregas adecuadas, probadas y aprobadas. Política de entrega Debería existir una política de entrega que incluya: a) La frecuencia y tipos de entregas. b) Los roles y las responsabilidades para la gestión de entregas. c) La autoridad para pasar la entrega a los entornos de pruebas de aceptación y de la producción. d) Una identificación y descripción única para todas las entregas. e) Una aproximación en torno a la agrupación de los cambios en una entrega. f ) Una aproximación para la automatización de los procesos de construcción, instalación, y distribución de la entrega para ayudar a su receptibilidad y a su eficiencia. g) La verificación y la aceptación de una entrega. Planificación de la entrega y del despliegue El proveedor del servicio debería trabajar conjuntamente con el negocio para asegurar que los elementos de configuración que se van a desplegar en una entrega son compatibles entre sí y con los elementos de configuración del entorno de destino. La planificación de la entrega debería asegurar que los cambios de los sistemas de información, infraestructuras, servicios y documentación afectados son acordados, autorizados, programados, coordinados y que se realiza un seguimiento de los mismos. La entrega y el despliegue se deberían planificar en etapas ya que los detalles del despliegue podrían no ser conocidos inicialmente. La planificación de una entrega y del despliegue normalmente debería incluir: a) Las fechas de la entrega y la descripción de los entregables. b) Los cambios y problemas relacionados, errores conocidos cerrados o resueltos por esta entrega y errores conocidos que hayan sido identificados durante las pruebas de la entrega. c) Los procesos relacionados para la implementación de una entrega a lo largo de todo el negocio y las diferentes unidades geográficas. d) El modo en el que se dará marcha atrás de la entrega o en que ésta se remediará si no se concluye con éxito. e) Los procesos de verificación y aceptación. f ) La comunicación, preparación, documentación y formación para los clientes y personal de apoyo. g) La logística y los procesos implicados para realizar la compra, el almacenamiento, la expedición, la conexión, la aceptación y la puesta a disposición de los bienes. h) Los recursos de apoyo necesarios para asegurar el mantenimiento de los niveles de servicio. i) La identificación de dependencias, los cambios relacionados y los riesgos asociados que pueden perjudicar el paso sin complicaciones de una entrega a los entornos de pruebas de aceptación y de producción. j) La autorización de la entrega. k) El calendario de auditorías del entorno de producción cuando sea necesario asegurar, para actualizaciones de gran tamaño, que el entorno de producción está en el estado esperado en el momento de instalar la entrega. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


121

Desarrollo o compra de software Se deberían verificar en el momento de la recepción, las entregas de sistemas de información y de software provenientes de equipos de desarrollo propios, desarrolladores de sistemas, integradores u otras organizaciones. El proceso completo se debería documentar en el plan de gestión de la configuración. Diseñar, construir y configurar una entrega Los procesos de gestión de entregas y distribución se deberían diseñar e implementar para: a) Asegurar que existe conformidad con la arquitectura de sistemas, la Gestión del Servicio y las normas de infraestructura del proveedor del servicio. b) Mantener la integridad durante la construcción, instalación, manipulación, empaquetado y entrega. c) Usar bibliotecas de software y repositorios relacionados para gestionar y controlar los componentes durante los procesos de construcción y de entrega. d) Asegurar que los riesgos estén claramente identificados y que se pueden llevar a cabo acciones de recuperación si se requieren. e) Habilitar verificaciones antes de la instalación para comprobar que la plataforma de destino satisface los requisitos previos. f ) Habilitar verificaciones que se comprueben que una entrega está completa cuando llega a su destino. Las salidas de este proceso deberían incluir las notas de la entrega, las instrucciones de instalación y el software instalado y hardware ya instalados, en relación a la línea de referencia de la configuración. Las salidas de la entrega se deberían entregar al grupo responsable de las pruebas. Los procesos de construcción, gestión de entregas y distribución se deberían automatizar para reducir errores, asegurando que el proceso es repetible y que se pueden desplegar rápidamente las nuevas entregas. Verificación y aceptación de la entrega El resultado final debería ser una aprobación basada en el grado en el que el paquete completo de la entrega recoge la totalidad de los requisitos. Los procesos de verificación y aceptación deberían: a) Verificar que el entorno controlado de las pruebas de aceptación se ajusta a los requisitos del entorno de producción de destino. b) Asegurar que la entrega se ha creado a partir de versiones bajo el control de gestión de la configuración y que se han instalado en el entorno de pruebas de aceptación usando el proceso de producción planificado. c) Verificar que se ha completado el nivel adecuado de pruebas, por ejemplo, pruebas funcionales y no funcionales, pruebas de aceptación por el negocio, pruebas en los procedimientos de construcción, despliegue de versiones, distribución e instalación. d) Asegurar que la entrega es probada y satisfacce las necesidades de los clientes del negocio y del personal del proveedor del servicio. e) Asegurar que la autoridad apropiada en cuanto a la gestión de entregas aprueba cada etapa de las pruebas de aceptación.


122


f ) Verificar antes de la instalación que la plataforma de destino satisface los requisitos previos de software y hardware. g) Verificar que la entrega está completa cuando llega a su destino. Documentación La documentación apropiada debería estar disponible en su totalidad y almacenada según la gestión de la configuración en referencia al elemento de configuración desplegado. Esta documentación debería incluir: a) La documentación de apoyo, por ejemplo, los acuerdos de nivel de servicio. b) La documentación de apoyo, por ejemplo, la esquema del sistema, los procedimientos de instalación y de soporte, las ayudas para el diagnóstico y las instrucciones de operación y administración. c) Los procesos de construcción, despliegue de versiones, instalación y distribución. d) Los planes de contingencia y marcha atrás. e) La planificación de la formación para los responsables del servicio, el personal de apoyo y los clientes. f ) Una línea de referencia de la configuración para la entrega, incluyendo elementos de configuración asociados tales como documentación del sistema, entornos de pruebas, documentación de pruebas y versiones de las herramientas de construcción y desarrollo. g) Los cambios, problemas y errores conocidos relacionados. h) Las evidencias de la autorización de la entrega y las evidencias relacionadas de la verificación y la aceptación. Si un sistema o servicio no cumple completamente con los requisitos especificados, antes de pasar a producción se debería identificar y registrar mediante la gestión de la configuración y la gestión de problemas. La información sobre errores conocidos se debería comunicar a la gestión de incidencias. Si la entrega es rechazada, retrasada o cancelada, se debería informar a la gestión de cambios. Despliegue, distribución e instalación Se debería revisar el plan de despliegue y se deberían añadir detalles, si es necesario, para asegurar que se van a llevar a cabo todas las actividades necesarias. Es importante que la entrega sea ejecutada de un modo seguro para su destino en el estado esperado. Los procesos de despliegue, distribución e instalación deberían asegurar que: a) Todas las zonas de almacenamiento de hardware y software son seguras. b) Existen procedimientos adecuados para el almacenamiento, expedición, recepción y eliminación de bienes. c) Se planifican y completan las comprobaciones sobre las instalaciones físicas, el entorno, las instalaciones eléctricas y otros servicios. d) Se notifican las nuevas entregas al personal del negocio y del proveedor del servicio. e) Se eliminan los productos, servicios y licencias que quedan sin utilidad tras la nueva entrega. Después de una distribución de software en una red es esencial comprobar que la entrega está completa y es operativa cuando llega a su destino. Los registros de activos y de la gestión de la configuración se deberían actualizar con la ubicación y el propietario del software y el hardware tras una instalación llevada a cabo con éxito. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


123

Se debería usar un cuestionario de satisfacción y aceptación por parte del cliente de la instalación para registrar el éxito o el fracaso de dicha instalación. Todos los resultados de las encuestas de satisfacción de los clientes deberían constituir una realimentación para la gestión de las relaciones con el negocio. Post-implantación y despliegue de la entrega Se debería medir y analizar el número de incidencias relacionadas con una entrega en el periodo inmediatamente posterior a un despliegue para evaluar su impacto en el negocio, en las operaciones y en los recursos de personal de apoyo. El proceso de gestión de cambios debería incluir una revisión post-implantación Las recomendaciones se deberían incluir en un plan de mejora del servicio. La Figura 4.2.10 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. Los pasos principales del proceso de gestión de entregas son: desarrollo de una política de entregas; diseño, construcción y configuración; pruebas y aceptación; despliegue, distribución e instalación; y comprobación de la entrega. Las salidas de la comprobación de la entrega son registros del éxito o el fracaso de la entrega, que a su vez pasan a ser entradas para un plan de mejora del servicio. El único documento exigido explícitamente para la gestión de entregas es la política de entregas, mientras que los únicos registros que se exigen son los de fechas de entrega y entregables, con referencia a solicitudes de cambio, errores conocidos y problemas relacionados. ISO 20000 define tres interfaces para el proceso de entrega: 1. Con el proceso de gestión de cambios - Para evaluar el impacto de las solicitudes de cambio sobre los planes de entrega. 2. Con el proceso de gestión de cambios - Para actualizar los registros de cambios. 3. Con el proceso de gestión de emergencias - Para gestionar entregas de emergencia. Las otras interfaces definidas son la interfaz con el proceso de gestión de incidencias para transmitir la información adecuada y la interfaz con el proceso de gestión de la configuración para actualizar los registros de información sobre activos y configuraciones.

Guía Como ya se ha dicho, es posible combinar varias RFCs en una sola entrega. Las entregas pueden estar planificadas con un objetivo funcional para el negocio, generalmente como entregas de mantenimiento de aplicaciones concretas. Pueden incluir hardware y software y su implantación es responsabilidad de la gestión de entregas. Es aconsejable definir una política para esta área y comunicarla a la organización de TI y a los clientes. El objetivo de la política debe ser evitar las interrupciones innecesarias para el usuario (“rehacer el camino todas las semanas”).


124


Documentar y definir la política de entregas

Política de entregas

Crear el entorno de pruebas de aceptación

Especifica la manera en que se va a revertir o corregir la entrega en caso de no tener éxito

Evaluar el impacto de RFCs sobre el plan de entrega

Planificar el despliegue de la entrega e informar a gestión de incidencias

Notas de la entrega Instrucciones de instalación Línea base de configuración Plan de despliegue

Diseñar, construir y configurar la entrega

Plan de entrega y despliegue

Notas de la entrega Instrucciones de instalación Línea base de configuración

Probar y aceptar la entrega

Identificar y registrar faltas de conformidad (errores conocidos) con los requisitos

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP Gestión de la configuración: - Actualizar registros de información sobre activos y configuraciones Gestión de cambios: - Evaluar el impacto de RFCs sobre los planes de entrega - Actualizar registros de cambios - Gestionar entregas de emergencia según el proceso de gestión de cambios de emergencia

Informe de faltas de conformidad para gestión de problemas y gestión de incidencias

Gestión de incidencias: - Intercambiar la información relevante

Registros de éxitos y fracasos de la entrega y oportunidades de mejora

Certificar la completitud y el cumplimiento de requisitos

Visado

Actualizar los registros de cambios y la configuración

Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes

Medir y analizar el éxito de la entrega

Corregir/revertir la entrega si no tiene éxito

Requisitos

Registros de éxitos y fracasos de la entrega y oportunidades de mejora

Registra fechas de entrega y entregables, con referencia a las correspondientes solicitudes de cambios, errores conocidos y problemas Incluye planes para comunicación, preparación y formación

En un entorno controlado de pruebas de aceptación Incluyendo el software adquirido

Desplegar, distribuir e instalar la entrega (emergencia)

Encuesta de clientes

Especifica la frecuencia y el tipo de las entregas


Visado por la autoridad de entregas Interfaz definida con el proceso de gestión de cambios de emergencia Incluyen:- Medidas de incidencias relacionadas con la entrega - Evaluación del impacto sobre los recursos del personal de soporte, operaciones de TI y negocio Documentación: - Documentación de soporte, como SLAs, listas de sistemas, procedimientos de instalación y soporte, herramientas de diagnóstico o instrucciones de operación y administración - Procesos de construcción, entrega, instalación y distribución - Planes de contingencia y marcha atrás - Programas de formación - Línea base de configuración - Cambios, problemas y errores conocidos relacionados - Evidencia de autorización, verificación y aceptación Incluye actualizaciones de toda la documentación asociada

Figura 4.2.10 Gestión de entregas



125

El proceso de gestión de entregas incluye las siguientes actividades: • Política y planificación de entregas • Diseño, construcción y configuración de entregas • Pruebas y aceptación de entregas • Planificación de despliegue • Comunicación, preparación y formación • Distribución e instalación de entregas Estas actividades no siempre se ejecutan en el orden indicado. La política y planificación de entregas se puede definir cada seis meses o un año, mientras que otras actividades suelen ser diarias. La Figura 4.2.11 muestra las actividades de la gestión de entregas. Entorno de desarrollo

Entorno controlado de pruebas

Entorno de producción

Gestión de entregas Política de entregas

Planificación de entregas

Diseño y desarrollo (o pedido y adquisición) de software

Construcción y configura ción de la entrega

Pruebas de ajuste al propósito

Aceptación de la entrega

Planificación de despliegue

Comunicación, preparación y formación

Distribución e instalación

Base de Datos de Gestión de la Configuración (CMDB) y Biblioteca de Software Definitivo (DSL)

Figura 4.2.11 Actividades de la gestión de entregas según ITIL V2 (Fuente: OGC)

Para cada sistema, el gestor de entregas debe desarrollar una política de entregas en la que se defina cómo y cuándo se configuran las entregas. Las entregas más importantes se pueden planificar por anticipado junto con el número de versión o la identificación de la entrega, de forma que los cambios se puedan incorporar en los momentos más adecuados. El gestor de entregas también especifica a qué nivel es posible distribuir CIs de forma independiente (unidades de entrega). Esto depende de la naturaleza del sistema sometido a control de entregas: • El impacto potencial de la entrega sobre otros componentes. • El número de personas-horas y la duración del ciclo para construir y probar cambios aislados, comparado con el esfuerzo que conlleva compilarlos e implantarlos de forma simultánea. • La dificultad de la instalación en los centros de los usuarios. • La complejidad de las dependencias entre el nuevo software y hardware y el resto de la infraestructura de TI; cuanto más fácil resulte aislar el software o hardware, más sencillo será probarlo. Antes de planificar una entrega es necesario reunir información sobre el ciclo de vida del producto, los productos que se deben entregar, la descripción del servicio de TI relevante y los niveles de servicio, junto con la autorización de las correspondientes RFCs. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

126


La planificación de una entrega debe incluir los siguientes puntos: • Coordinar los contenidos de la versión. • Acordar el programa, los centros y las unidades organizativas. • Confeccionar el calendario de entrega. • Preparar un plan de comunicación. • Realizar visitas para determinar el hardware y software que se está utilizando. • Definir roles y responsabilidades. • Obtener presupuestos detallados y negociar con los suministradores sobre nuevo hardware, software y servicios de instalación. • Preparar planes de marcha atrás. • Preparar un plan de calidad para la entrega. • Planificar la aceptación de la entrega por la organización de gestión y los usuarios. Los resultados de esta actividad forman parte del plan de cambio e incluyen planes para la entrega, planes de pruebas y criterios de aceptación. Es conveniente desarrollar procedimientos estándar para diseñar, construir y configurar entregas. Una entrega puede estar basada en conjuntos de componentes (CIs) desarrollados por la propia organización o adquiridos a terceros y configurados. Las instrucciones de instalación y configuración de entregas también se deben considerar parte de la entrega y se pondrán, como CIs, bajo el control de la gestión de cambios y la gestión de la configuración. Es recomendable configurar y probar todo el hardware y software en un entorno de pruebas antes de su instalación definitiva. La configuración y el registro de los componentes software y hardware de una entrega se deben realizar con el máximo cuidado para garantizar su reproducibilidad. Se tienen que redactar instrucciones de operación para utilizar siempre el mismo conjunto de elementos de configuración. Es frecuente que se reserve hardware normalizado para utilizarlo exclusivamente en la compilación o creación de imágenes. Es aconsejable automatizar esta parte del proceso para que sea más fiable. En entornos de desarrollo de software, esta actividad se conoce con el nombre de gestión de construcción y es responsabilidad de la gestión de entregas. Un plan de marcha atrás a nivel de toda la entrega define las actividades necesarias para recuperar el servicio en caso de que haya algún problema con la entrega. La creación de planes de marcha atrás es responsabilidad de la gestión de cambios, aunque la gestión de entregas tiene que colaborar para garantizar la viabilidad de dichos planes. Lo mejor es satisfacer por adelantado los requisitos del plan de marcha atrás, como realizar copias de seguridad o disponer de un segundo servidor. El plan de marcha atrás tiene que estar incluido en el análisis de riesgos del cambio y debe haber sido aceptado por los usuarios. El proceso de construcción de la entrega puede incluir la compilación y vinculación de módulos software o el llenado de bases de datos con datos de pruebas o de otro tipo, como tablas de códigos postales, tasas de impuestos, zonas horarias o tablas de divisas, además de información de usuarios. Para ello es frecuente utilizar guiones de instalación automatizados, que se guardan en la DSL junto con los planes de marcha atrás. Las entregas completas deben estar identificadas en la CMDB como configuraciones estándares para facilitar su uso ante futuros requisitos. Los planes



127

de pruebas cubren la prueba y aceptación de la calidad del software, hardware, procedimientos, instrucciones de operación y guiones de despliegue antes de la entrega, y posiblemente también su evaluación después de la entrega. Igualmente se deben probar los guiones de instalación. La información necesaria para esta actividad incluye: • Definición de la entrega • Calendario de entrega • Instrucciones para configurar y construir la entrega • Descripción de los elementos que hay que comprar o para los que se debe adquirir una licencia • Guiones de instalación automatizados y planes de pruebas • Copias originales del software para su inclusión en la DSL • Procedimientos y planes de marcha atrás Antes de la implantación, la entrega debe ser sometida a una prueba funcional por representantes de los usuarios y a una prueba operativa por personal de gestión de TI, quienes tendrán en cuenta la operación técnica, las funciones, los aspectos operativos, el rendimiento y la integración con el resto de la infraestructura. Las pruebas deben incluir también los guiones de instalación, los procedimientos de marcha atrás y cualquier cambio que se introduzca en los procedimientos de gestión. Cada uno de los pasos tendrá que ser aceptado formalmente por la gestión de cambios. El último paso consiste en la aprobación de la entrega para su implantación. La gestión de cambios debe organizar la aceptación formal por parte de los usuarios y el visado de la entrega por los desarrolladores antes de que la gestión de entregas pueda iniciar el despliegue. Las entregas sólo se deben aceptar en un entorno de pruebas controlado en el que sea posible reproducir un determinado estado de configuración. Este estado de referencia para la entrega tiene que estar especificado en la definición de la entrega, que estará registrada en el CMDB. Si la entrega no es aceptada, será devuelta a la gestión de cambios como cambios fallidos. Los resultados de esta actividad incluyen: • Procedimientos de instalación probados • Componentes de la entrega probados • Errores conocidos y defectos en la entrega • Resultados de pruebas • Documentación de soporte y gestión • Lista de sistemas afectados • Instrucciones de operación y herramientas de diagnóstico • Planes de contingencia y marcha atrás probados • Programa de formación para personal, gestores y usuarios • Documentos firmados de aceptación • Autorización firmada de la entrega Al plan de entrega redactado en las fases anteriores se añade ahora información sobre las actividades y el calendario exacto de implantación, es decir, una planificación de despliegue: • Calendario, lista de tareas y recursos humanos necesarios. • Lista de los CIs que se deben instalar y retirar, junto con la forma en que se van a retirar. • Plan de actividades para cada centro de implantación, teniendo en cuenta las posibles fechas de entrega y, en el caso de una organización internacional, las zonas horarias. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

128


• Envío de notas de la entrega y otras comunicaciones a las partes afectadas. • Planes para la adquisición de hardware y software. • Adquisición, almacenamiento seguro, identificación y registro de todos los nuevos CIs en la CMDB para la entrega. • Actualización del calendario y reuniones de revisión con la dirección, los departamentos de gestión, la gestión de cambios y representantes de los usuarios. Un despliegue se puede implantar de diversas formas: • Despliegue completo de la entrega (método “Big Bang”). • Despliegue de la entrega por fases, con varias opciones: – Incrementos funcionales (todos los usuarios reciben nuevas funciones al mismo tiempo) – Incrementos de localización (por grupos de usuarios) – Evolutivo (las funciones se van ampliando por fases) El personal que mantiene contacto con los clientes (centro de atención al usuario y gestión de relaciones con el cliente), el personal operativo y los representantes de la organización de usuarios tienen que conocer los planes y su posible impacto sobre las actividades rutinarias. Esto se puede conseguir mediante sesiones de formación conjunta, cooperación y participación conjunta en la aceptación de la entrega. Es necesario comunicar las responsabilidades y comprobar que todo el mundo las conoce. Si el despliegue de la entrega se realiza por fases, se debe informar de ello a los usuarios, comunicándoles también los planes previstos y cuándo recibirán las nuevas funciones. Los cambios introducidos en acuerdos de nivel de servicio (SLAs), acuerdos de nivel operativo (OLAs) y contratos de soporte (UCs) se deben comunicar por anticipado a todo el personal afectado. La gestión de entregas monitoriza los procesos de logística para la adquisición, almacenamiento, transporte, entrega y cesión de software y hardware. El proceso incluye procedimientos, registros y documentos de soporte (como hojas de embalaje), por lo que puede proporcionar información fiable a la gestión de la configuración. La instalación donde se almacene el hardware y el software tiene que ser segura y sólo puede acceder a ella el personal autorizado. Siempre que sea posible, se recomienda utilizar herramientas personalizadas para la distribución e instalación de software. De esta forma se reducirá el tiempo y los recursos necesarios para la distribución, además de aumentar la calidad. Por lo general, estas herramientas también permiten comprobar más fácilmente el éxito de la instalación. Antes de iniciar una instalación, es conveniente comprobar que el entorno donde se va a instalar la entrega cumple todas las condiciones (espacio suficiente en disco, seguridad, controles o limitaciones ambientales como aire acondicionado, espacio en piso y alimentación eléctrica/ SAI). Una vez realizada la instalación, hay que actualizar la información en la CMDB para facilitar la verificación de los acuerdos de licencia.



129

La planificación e implantación de la gestión de entregas depende en gran medida de la implantación de la gestión de la configuración y la gestión de cambios. Debe incluir la planificación e implantación inicial de las capacidades de gestión de entregas, seguida de una revisión y mejora continuas de: • Políticas de entregas que incluyan niveles, tipos, unidades, identificación, frecuencia y fases de entregas, el alcance de los entregables controlados y la documentación necesaria. • Procedimientos de entrega que cubran todas las actividades de gestión de entregas anteriormente descritas. • Roles y responsabilidades de todo el personal, y especialmente del de gestión de entregas. Herramientas, incluidas herramientas de gestión de cambios, herramientas de CMDB y herramientas de gestión de la configuración software.

4.3 Alineación entre el negocio y las Tecnologías de la Información 4.3.1 Proceso de la provisión del servicio: Gestión del nivel de servicio (6.1) Objetivo: Definir, acordar, registrar y gestionar los niveles de servicio. Las especificaciones ISO 20000-1 dicen: Se deben acordar por las partes, y registrar, el conjunto total de los servicios a ser provistos, junto a los correspondientes objetivos de nivel de servicio y las características de la carga de trabajo que deben soportar. Cada servicio ofrecido se debe definir, acordar y documentar en uno o más acuerdos de nivel de servicio. Se deben acordar y registrar por todas las partes relevantes los SLAs, junto con los acuerdos de servicio de soporte, los contratos con suministradores y los correspondientes procedimientos. Los SLAs deben estar bajo el control de la gestión de cambios. Los SLAs se deben revisar periódicamente por las partes, para asegurar que se encuentran actualizados y continúan siendo eficaces con el transcurso del tiempo. Los niveles de servicio se deben monitorizar y se deben generar informes de dichos niveles con relación a los objetivos, mostrando tanto la información actual como las tendencias. Las razones para las no conformidades se deben comunicar y revisar. Las acciones de mejora definidas durante este proceso se deben registrar y constituyen una entrada al plan de mejora del servicio. El Código de buenas prácticas ISO 20000-2 dice: Catálogo de servicios Todos los servicios deberían estar definidos en un catálogo de servicios. Este catálogo puede ser referenciado desde el SLA y debería utilizarse para recoger aquellos aspectos considerados como Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

130


demasiado cambiantes para ser introducidos en el SLA. El catálogo de servicios debería ser mantenido y estar actualizado en todo momento. NOTA: El catálogo de servicios puede incluir información genérica como: a) El nombre del servicio b) Los objetivos (por ejemplo tiempo de respuesta o de instalación de una impresora, tiempo para reiniciar un servicio tras un fallo importante) c) Datos de contacto d) Horario del servicio y excepciones e) Disposiciones de seguridad El catálogo de servicios es un documento clave para establecer las expectativas del cliente y debería ser fácilmente accesible y estar ampliamente disponible tanto para los clientes como para el personal de apoyo. Acuerdos de nivel de servicio (SLAs) Todo servicio debería estar formalmente documentado en un acuerdo de nivel de servicio (SLA). El SLA debería ser autorizado formalmente por la dirección del cliente y los representantes del proveedor de servicios. El SLA debería estar sujeto a la gestión de cambio, así como el servicio que describe. El presupuesto y las necesidades del cliente deberían ser los elementos en que se base el contenido, la estructura y los objetivos del SLA. Los objetivos, respecto de los cuales debería medirse el servicio prestado, se deberían definir desde la perspectiva del cliente. Los SLAs deberían incluir únicamente un conjunto adecuado de objetivos para centrar la atención en los aspectos más importantes del servicio. NOTA 1: Demasiados objetivos pueden generar confusión y conllevar un exceso de gastos. El contenido mínimo que debería tener un SLA, o que se debería referenciar en él, es el siguiente: a) Descripción breve del servicio. b) Período de validez y/o mecanismo de control de cambios del SLA. c) Detalles sobre la autorización. d) Descripción breve de las comunicaciones, incluida la generación de informes. e) Datos de contacto de las personas autorizadas a actuar ante emergencias, participar en la resolución de incidencias y problemas, así como en la recuperación del servicio o en la aplicación de soluciones temporales. f ) Horario de servicio, por ejemplo de 09:00 h a 17:00 h, excepciones al mismo (por ejemplo fines de semana o periodos vacacionales), periodos críticos para el negocio y cobertura fuera del horario. g) Interrupciones planificadas y acordadas, incluido el aviso que se debe dar y número por periodo. h) Responsabilidades del cliente, por ejemplo seguridad. i) Responsabilidades y obligaciones del proveedor del servicio, por ejemplo seguridad. j) Directrices sobre impactos y prioridades. k) Procesos de escalado y de notificación. l) Procedimientos de reclamación. m) Objetivos del servicio. n) Límites de la carga de trabajo (superior e inferior), por ejemplo la capacidad del servicio de soportar un número acordado de clientes o un volumen de trabajo o la capacidad de procesamiento del sistema. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


131

o) Detalles de alto nivel de la gestión financiera, por ejemplo códigos de imputación, etc. p) Acciones a llevar a cabo en caso de interrupción del servicio. q) Procedimientos de mantenimiento interno. r) Glosario de términos. s) Servicios de soporte y otros relacionados con el propio servicio. t) Las excepciones a las cláusulas incluidas en el SLA. NOTA 2: La información volátil o común a varios SLAs (como datos de contacto) se puede referenciar desde el SLA sin que esto suponga un impacto en la calidad de los procesos de SLM siempre que los documentos de referencia estén también bajo el control del proceso de gestión de cambios. NOTA 3: En el SLA se suele hacer referencia al plan de continuidad y a los detalles de la contabilidad y del presupuesto. NOTA 4: El glosario de términos normalmente suele ser el único y común a todos los documentos, incluyendo el catálogo de servicios. Proceso de gestión del nivel de servicio (SLM) Los cambios importantes en el negocio, debidos, por ejemplo, al crecimiento, fusiones y reorganizaciones del negocio, y los cambios en los requisitos del cliente, pueden implicar el ajuste de los niveles de servicio, su redefinición o incluso su suspensión temporal. El proceso SLM debería ser flexible para adecuarse a estos cambios. El proceso SLM debería asegurar que el proveedor del servicio continúa focalizado en el cliente durante la planificación, implantación y la gestión continua del servicio prestado. Se debería dar al proveedor del servicio la información adecuada para permitirle que comprenda las motivaciones y requisitos del negocio del cliente. El proceso SLM debería gestionar y coordinar a quienes contribuyen al nivel de servicio, para incluir: a) Acuerdo en los requisitos del servicio y en las características de la carga de trabajo esperada del servicio. b) Acuerdo en los objetivos de servicio. c) Medición e informe de los niveles de servicio conseguidos, cargas de trabajo y explicaciones cuando no se alcanzan los objetivos acordados. d) Inicio de acción correctiva. e) Entrada al programa de mejora del servicio. El proceso debería animar tanto al proveedor del servicio como al cliente a desarrollar una actitud proactiva con objeto de garantizar que ambos tienen una responsabilidad compartida sobre el servicio. La satisfacción del cliente es una parte importante de la gestión del nivel de servicio pero debería reconocerse que es una medida subjetiva, mientras que los objetivos de servicio incluidos en el SLA deberían ser medidas objetivas. El proceso SLM debería trabajar conjuntamente con los procesos de gestión de relaciones con el negocio y gestión de proveedores.


132


Acuerdos de servicios de soporte Los servicios de soporte de los cuales depende el servicio prestado se deberían documentar y acordar con cada suministrador de servicios. Esto incluye los grupos internos que proveen parte del servicio ofrecido por el proveedor del servicio. La Figura 4.3.1 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. La gestión del nivel de servicio consiste en una serie de actividades: • Elaborar un catálogo de servicios • Acordar el servicio que se va a ofrecer • Monitorizar los niveles de servicio • Informar de los resultados • Revisar los niveles de servicio Poniendo en práctica el principio de mejora continua, la revisión de los niveles de servicio tiene que conducir a la definición de un plan de mejora del servicio. Los cambios que se introduzcan en los acuerdos de nivel de servicio tienen que estar controlados por la gestión de cambios. Se debe documentar la interfaz entre la gestión del nivel de servicio y el proceso de gestión de cambios, así como la interfaz con el proceso de mejora continua que evalúa, registra, prioriza y autoriza todas las mejoras propuestas.

Guía La gestión del nivel de servicio incluye las siguientes actividades: • Identificación de necesidades • Definición de requisitos • Contratación de niveles de servicio • Monitorización de rendimiento • Informe de rendimiento • Revisión de rendimiento ISO 20000 contempla un proceso independiente para informes del servicio, por lo que los pasos de comunicación y revisión se discutirán en la Sección 4.3.2, informes del servicio. La calidad percibida de un servicio depende de las expectativas del cliente, de la gestión continua de las percepciones del cliente, de la estabilidad del servicio y de la aceptabilidad de los costes. Por lo tanto, la mejor forma de ofrecer una calidad adecuada es empezar discutiendo los requisitos o posibles problemas con el cliente. La experiencia indica que, en general, tampoco los clientes tienen una idea clara de sus expectativas. En ocasiones dan por supuesto que recibirán determinados aspectos del servicio, aunque no existan acuerdos claros. Estos aspectos supuestos (implícitos) de los servicios de TI suelen causar mucha confusión, lo que una vez más pone de manifiesto la necesidad de que los gestores del nivel de servicio conozcan lo mejor posible a sus clientes para poder ayudarles a tener una opinión clara sobre los servicios y niveles de servicio que necesitan y el coste correspondiente. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Acordar y registrar servicios, objetivos específicos y características de carga de trabajo

Registros de servicios, objetivos específicos y características de carga de trabajo

SLA Presupuesto y necesidades del negocio del cliente

Definir, acordar y documentar cada uno de los servicios suministrados

Contratos de suministradores Acuerdos de servicios de soporte

133

Para cada grupo de clientes y servicio, definen: - Máximo período continuo permitido con pérdida de servicio - Máximos períodos permitidos con servicio degradado - Niveles permitidos de degradación de servicio durante períodos de recuperación de servicio - Participación conjunta en planes de disponibilidad y continuidad

Procedimientos correspondientes

Acciones de mejora

Catálogo de servicios

Monitorizar niveles de servicio con referencia a objetivos específicos


Comunicar niveles de servicio con referencia a objetivos específicos

Informe de nivel de servicio

Revisar el informe de nivel de servicio y registrar acciones de mejora

Acciones de mejora

Con motivos de faltas de conformidad


Mantener el catálogo de servicios


Interfaces: Mejora continua (Actuar): - Gestionar actividades de mejora - Sugerir mejoras para SIP Gestión de cambios: - Controlar el SLA - Presentar una solicitud de cambio Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes Gestión de relaciones con el negocio: - Revisar el SLA y los niveles de servicio Gestión de proveedores Gestión de la disponibilidad y la continuidad del servicio: - Acordar niveles de servicios para cada grupo de clientes y servicio - Evaluar el impacto sobre la documentación de continuidad del servicio antes de acordar los requisitos del cliente

Figura 4.3.1 Gestión del nivel de servicio


134


Los requisitos del cliente tienen que estar expresados en valores medibles para que puedan contribuir al diseño y monitorización de los servicios de TI. Si no se ha llegado a un acuerdo con el cliente acerca de las métricas a utilizar, resulta difícil verificar si el servicio ha satisfecho o no alguno de los acuerdos. La gestión del nivel de servicio desempeña un papel clave en la comprensión y definición de las necesidades del cliente. El primer paso para cerrar SLAs sobre servicios de TI presentes o futuros debe ser la identificación y definición de las necesidades del cliente en los requisitos de nivel de servicio. Además de hacerlo una vez durante el proceso, esta actividad también se debe realizar periódicamente a partir de informes y revisiones, a petición del cliente o cuando convenga a la organización de TI. Esta actividad puede cubrir servicios nuevos o ya existentes. Definir el alcance y la profundidad de los requisitos del cliente se considera un proceso de diseño dentro de la gestión del nivel de servicio. Según el modelo ISO 9001 de aseguramiento de la calidad, un proceso de diseño debe incluir los siguientes pasos: • Diseño • Desarrollo • Producción • Instalación • Mantenimiento El proceso de diseño tiene que estar gestionado para garantizar que los resultados al final del proceso corresponden a los requisitos del cliente. Durante el proceso de diseño, el término “externo” hace referencia a la comunicación con clientes, mientras que “interno” se refiere al soporte técnico dentro de la organización de TI. El proceso de diseño consta de varios pasos, desde la identificación de los requisitos de cliente y su definición en normas claras hasta el desarrollo de los requisitos técnicos para la provisión del servicio. El primer paso para cuantificar servicios de TI nuevos o existentes consiste en definir o redefinir en términos generales las expectativas del cliente acerca del servicio. Estas expectativas se formalizan en requisitos documentados de nivel de servicio, que deben incluir a toda la organización del cliente. Este paso se considera normalmente la parte más difícil de la gestión del nivel de servicio. El gestor del nivel de servicio tiene que estar preparado para reunirse con la organización del cliente al principio de esta fase. Lo primero que hay que preguntarse, es qué es lo que se exige al servicio de TI y de qué elementos debe constar el servicio. Un servicio técnico puede conllevar el uso de una infraestructura limitada, como una Red de Área Ancha (WAN). Dicho servicio puede ser una parte de un servicio compuesto, como el acceso a un completo sistema de información que incluya toda la infraestructura subyacente (WAN, LAN, estaciones de trabajo y aplicaciones). Los usuarios tienen que estar divididos en grupos durante estas reuniones. El gestor del nivel de servicio prepara una lista de grupos de usuarios y de sus requisitos y autoridad. Para definir los requisitos de nivel de servicio se necesita la siguiente información: • Una descripción (desde la perspectiva del cliente) de las funciones que debe ofrecer el servicio. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


135

• Las horas y días en que el servicio debe estar disponible. • Los requisitos de continuidad del servicio. • Las funciones de TI necesarias para la provisión del servicio. • Referencias a los métodos operativos o normas de calidad en vigor que haya que tener en cuenta en la definición del servicio. • Una referencia al SLA que se deba modificar o sustituir, en su caso. La fase de diseño dará como resultado un documento de requisitos de nivel de servicio, que estará firmado por el gestor del nivel de servicio y el cliente. Los requisitos de nivel de servicio también se pueden modificar mientras el departamento trabaja en el diseño, la adquisición y la implantación. Dichos cambios pueden estar relacionados con la viabilidad de las funciones o los costes previstos y tienen que ser aprobados por ambas partes. Durante la fase de especificación se desarrollan en detalle los requisitos de nivel de servicio para convertirlos en normas internas. El objetivo de esta fase es proporcionar la siguiente información: • Una descripción inequívoca y detallada de los servicios de TI y de sus componentes. • Las especificaciones de la forma de implantación y provisión del servicio. • Las especificaciones del procedimiento necesario de control de la calidad. Se recomienda distinguir los elementos de la documentación para uso interno de los que son para uso externo (Figura 4.3.2). Las especificaciones para uso externo están relacionadas con los objetivos acordados con los clientes y son las que controlan el proceso de diseño. Se definen en colaboración con la organización del cliente y forman la entrada para las especificaciones para uso interno. Dirección del negocio U s u a r i o s

Revisión interna

Documentos externos: - Requisitos de nivel de servicio - Acuerdo de nivel de servicio - Catálogo de servicios

f i n a l e s Control de documentos

Documentos internos: - Hojas de especificaciones - Acuerdos de nivel operativo - Contratos de soporte

Departamento de TI

Figura 4.3.2 Fase de especificación


S u m i n i s t r a d o r e s

136


Las especificaciones para uso interno se refieren a los objetivos internos de la organización de TI, que se deben cumplir para satisfacer las demandas del cliente. La separación entre especificaciones internas y externas resulta especialmente útil una vez iniciado el proceso de gestión del nivel de servicio, ya que evita que la organización de TI moleste a sus clientes con detalles técnicos. A partir de ese momento, gestionar los niveles de servicio consiste en mantener alineadas las especificaciones internas y externas. A esto contribuyen el control de documentos y las revisiones internas, que permiten mantener registros de documentos relacionados, gestionar versiones y organizar auditorías periódicas Las hojas de especificaciones (especificaciones del servicio) describen en detalle lo que el cliente desea (elemento externo) y el impacto que eso tiene sobre la organización de TI (elemento interno). no es necesario que estén firmadas por las dos partes, aunque tienen que estar sujetas al control de documentos. El catálogo de servicios se puede preparar a partir de las especificaciones de servicios. Esto permite incluir inmediatamente en las hojas de especificaciones y en el catálogo de servicios cualquier cambio en los niveles de servicio. Finalmente, se revisa o se crea el SLA de acuerdo con las hojas de especificaciones revisadas. Toda la información de gestión (indicadores clave del rendimiento) y las especificaciones para proveedores internos y externos se deben incluir en un único plan de calidad del servicio que contenga amplia información sobre las contribuciones realizadas a los servicios de TI por cada proceso de Gestión del Servicio. Al terminar la fase de especificación, la organización de TI habrá convertido las necesidades de negocio en configuraciones y recursos de TI. Esta información se utiliza para redactar o modificar los siguientes documentos: • Acuerdo de nivel de servicio - Al desarrollar la estructura del SLA, se recomienda empezar definiendo los aspectos generales (como los servicios de red para toda la empresa) y desarrollar un modelo general de SLA basado en servicios antes de iniciar las negociaciones. Los SLAs pueden tener una estructura jerárquica (como la organización del cliente) reflejada en un acuerdo marco con diversos niveles, cada uno de ellos con su propio nivel de detalle. Los niveles superiores incluyen acuerdos sobre servicios generales para la organización, mientras que los inferiores contienen información relevante para clientes y servicios específicos. La estructura de un SLA depende de distintas variables como: – Aspectos físicos de la organización, como su escala y complejidad. – Aspectos culturales, como el idioma y la relación entre la organización de TI y el cliente. – La naturaleza de las actividades de negocio (términos y condiciones) y su horario (5 x 8 horas o 7 x 24 horas). • Acuerdos de nivel operativo (OLAs) y contratos de soporte (UCs) - Cualquier OLA o UC existente debe ser revisado durante el proceso de diseño. Todas las partes implicadas tienen que conocer los OLAs o UCs que afecten a la provisión de un servicio concreto. La gestión de la configuración puede ayudar a aclarar los vínculos con las hojas de especificaciones. • Catálogo de Servicios - Los siguientes consejos pueden resultar útiles para elaborar un Catálogo de Servicios: – Utilizar el idioma del cliente, evitando términos técnicos y usando la terminología del negocio correspondiente. – Tratar de ver las cosas desde el punto de vista del cliente y utilizar ese enfoque para identificar la información relevante. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


137

– Presentar la información de forma atractiva, ya que la organización de TI usará tal documento para presentarse a sus clientes. – Poner el documento a disposición del mayor número posible de grupos de interés (por ejemplo, publicándolo en una página de intranet o en CD-ROM). Sólo es posible monitorizar los niveles de servicio si están definidos con claridad desde el principio y corresponden a los objetivos acordados. Los niveles de servicio se tienen que medir desde la perspectiva del cliente. La monitorización no se puede limitar a los aspectos técnicos, sino que debe incluir también aspectos de procedimientos. Por ejemplo, los usuarios pensarán que un servicio no está disponible mientras no se les informe de que ha sido restablecido. La gestión de la disponibilidad y la gestión de la capacidad proporcionan información sobre la implantación de los objetivos técnicos asociados con los niveles de servicio. En algunos casos también se recibirá información de los procesos de soporte del servicio, y especialmente de la gestión de incidencias. Sin embargo, medir parámetros internos no es suficiente, puesto que no guardan relación con la percepción del usuario. También tiene que ser posible medir otros parámetros como el tiempo de respuesta, el tiempo de escalado y el tiempo de soporte. Sólo se obtendrá una imagen completa si se combina información de gestión de sistemas y de la Gestión del Servicio. En muchas organizaciones donde se está introduciendo la gestión del nivel de servicio, se discute la conveniencia de asociar sanciones al incumplimiento de las condiciones del SLA. Se trata de una cuestión compleja, ya que la gestión del nivel de servicio está basada en la interacción del departamento de TI con los usuarios de servicios de TI, que a menudo pertenecen a la misma organización. En una situación así, donde tanto el departamento de TI como los usuarios persiguen los mismos objetivos corporativos, resulta dudoso que las sanciones (y especialmente las de tipo financiero) contribuyan al interés común. Puede ser mucho más conveniente alcanzar acuerdos sobre las medidas a tomar para evitar el incumplimiento de los niveles de servicio. No obstante, las sanciones pueden ser importantes si el proveedor de servicios de TI recibe un servicio de un proveedor de TI externo, en cuyo caso es mucho más probable que se utilice un contrato de soporte (UC) legalmente vinculante en lugar de un SLA. Los niveles de servicio se deben revisar periódicamente teniendo en cuenta los siguientes aspectos: • Acuerdos de nivel de servicio desde la revisión anterior. • Problemas relacionados con los servicios. • Identificación de tendencias del servicio. • Cambios en servicios dentro de los niveles de servicio acordados. • Cambios en procedimientos y estimaciones del coste de nuevos recursos. • Consecuencias del incumplimiento de los niveles de servicio acordados. Si los servicios de TI no cumplen los niveles de servicio acordados, se pueden acordar acciones de mejora como: • Desarrollo de un Programa de Mejora del Servicio. • Asignación de personal adicional y otros recursos. • Modificación de los niveles de servicio definidos en el SLA. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

138


• Modificación de los procesos y procedimientos. • Modificación de los acuerdos de nivel operativo y los contratos de soporte. El éxito de la gestión del nivel de servicio depende de los siguientes CSFs: • Un gestor del nivel de servicio con buenos conocimientos de TI y del negocio y con una organización de soporte, si es necesario. • Misión y objetivos bien definidos para el proceso. • Campaña de concienciación para informar sobre el proceso, fomentar su conocimiento y recabar apoyos. • Tareas, autoridades y responsabilidades bien definidas para el proceso, distinguiendo entre control del proceso y tareas operativas (contactos con el cliente). Los siguientes KPIs pueden servir para determinar la eficacia y la eficiencia del proceso de gestión del nivel de servicio: • Elementos de servicio incluidos en SLAs. • Elementos del SLA con soporte de OLAs y UCs. • Elementos de los SLAs que se monitorizan y en los que se detecten defectos. • Elementos de los SLAs que se revisen periódicamente. • Elementos de los SLAs que cumplan los niveles de servicio acordados. • Defectos identificados y cubiertos por un plan de mejora. • Acciones emprendidas para eliminar los defectos identificados. • Tendencias identificadas con respecto a los niveles reales de servicio.

4.3.2 Proceso de la provisión del servicio: Generación de informes del servicio (6.2) Objetivo: Generar en plazo los informes acordados, fiables y precisos, para informar de la toma de decisiones y para una comunicación eficaz. Las especificaciones ISO 20000-1 dicen: Se debe describir claramente cada informe de servicio, incluyendo su identificador, el propósito, la audiencia y los detalles del origen de los datos. Los informes de servicio se deben generar para verificar si se cumplen los requisitos y necesidades de los usuarios. Los informes de servicio deben incluir: a) El rendimiento y comportamiento frente a los objetivos de nivel de servicio. b) Las no conformidades y problemas relacionados, por ejemplo con los SLAs o agujeros de seguridad. c) Las características de la carga de trabajo, por ejemplo volumen o utilización de recursos. d) Los informes de los resultados de los principales eventos, por ejemplo las principales incidencias y cambios. e) La información sobre tendencias. f ) El análisis de satisfacción. Las decisiones de gestión y las acciones correctivas deben tener en cuenta los aspectos destacados en los informes de servicio y deben comunicarse a las partes afectadas. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


139

El Código de buenas prácticas ISO 20000-2 dice: NOTA: El éxito de todos los procesos de Gestión del Servicio depende del uso de la información proporcionada en los informes de servicio. Política Los requisitos para la generación de informes para clientes y para gestión interna se deberían acordar y ser registrados. La supervisión del servicio y la generación de informes abarcan todos los aspectos medibles del servicio, proporcionando datos actuales e históricos. Cuando existan múltiples proveedores, suministradores principales y suministradores subcontratados por éstos, los informes deberían reflejar las relaciones entre ellos. Por ejemplo, un suministrador principal debería informar sobre la totalidad del servicio que presta, incluyendo cualquier servicio realizado por un tercero y que forme parte del que el suministrador principal gestiona como parte del servicio al cliente. Propósito de los informes del servicio y verificación de su calidad Los informes de servicio se deberían generar a tiempo, y ser claros, fiables y concisos. Se deberían adecuar a las necesidades de quien lo recibe y ser suficientemente precisos para poder ser utilizados como herramienta de apoyo en la toma de decisiones.La presentación debería ayudar a comprender los informes de forma que sean fácilmente asimilables, por ejemplo usando gráficos. Se deberían generar distintos tipos de informes: a) Informes reactivos, que muestran lo que ha ocurrido. b) Informes proactivos, que avisen por adelantado de eventos significativos con objeto de permitir que se puedan realizar acciones preventivas (por ejemplo, informes sobre inminentes rupturas de los SLAs). c) Distribución previa de informes que muestren las actividades planificadas. Informes de servicio El proveedor del servicio debería generar informes para los clientes y para la dirección, que cubran los siguientes aspectos: a) Comportamiento frente a objetivos de nivel de servicio, por ejemplo informes de caídas del servicio, logros. b) No conformidades frente a normas. c) Características de la carga de trabajo y volumen de la información, por ejemplo incidencias, problemas, cambios y tareas, clasificación, ubicación, clientes, tendencias estacionales, combinación de prioridades, número de solicitudes de ayuda. d) Informes de resultados después de eventos de alto nivel, por ejemplo cambios y entregas. e) Información de tendencias por periodos (por ejemplo diaria, semanal, mensual). f ) Informes que incluyan información de cada proceso, por ejemplo número de incidencias y de preguntas más frecuentes, componentes de la infraestructura poco fiables, tareas que consumen gran número de recursos económicos, técnicos o humanos. g) Informes para destacar cargas de trabajo futuras o planificadas. La Figura 4.3.3 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos.


140


Acordar y registrar requisitos para informes del servicio

Describir informes del servicio

Elaborar informes del servicio

Informe del servicio

Comunicar las decisiones de la dirección y las acciones correctivas a las partes afectadas

Interfaces: Todos los procesos relevantes: - Proporcionar información Mejora continua (Actuar): - Sugerir mejoras para SIP

Requisitos de informes del servicio

Descripciones de informes del servicio

Informe del servicio

Incluyen: - Identidad - Propósito - Destinatarios - Detalles de la fuente de datos Incluye: - Grado de cumplimiento de los objetivos específicos de nivel de servicio - Faltas de conformidad y posibles problemas - Características de carga de trabajo - Informes de rendimiento después de eventos de importancia - Información de tendencias y análisis de satisfacción

Tipos de informes: - Informes reactivos: Qué ha ocurrido - Informes proactivos: Anticipación de eventos importantes - Informes de planificación: Actividades planificadas Incluyen: - Información de cada uno de los procesos - Datos que destaquen cargas de trabajo previstas para el futuro Reflejan las relaciones entre suministradores.

Gestión del nivel de servicio: - Comunicar niveles de servicio con referencia a objetivos específicos

Figura 4.3.3 Informes del servicio

El enfoque a cliente es uno de los principios de la gestión de la calidad, por lo que la elaboración de informes del servicio es una actividad importante que forma parte de la gestión del nivel de servicio. Las actividades de informes del servicio descritas en esta subsección de la norma están encaminadas a satisfacer las necesidades y los requisitos de gestión interna y del cliente. Estas actividades tienen una interfaz con todos los procesos que se usan para adquirir información. La elaboración de informes del servicio no es una actividad que ejecute exclusivamente el proveedor de servicios, puesto que también los suministradores tienen que informar de su servicio al proveedor de servicios. Los informes de servicio de un suministrador deberían reflejar posibles relaciones entre suministradores.



141

Guía Se deben presentar informes de cliente (informes del servicio) en los intervalos especificados en el SLA. Estos informes comparan los niveles de servicio acordados con los niveles de servicio medidos en la práctica. Por ejemplo, se pueden presentar informes sobre: • Disponibilidad y tiempo de parada durante un período especificado. • Tiempos medios de respuesta durante períodos de máxima actividad. • Ratios de transacciones durante períodos de máxima actividad. • Número de errores funcionales en el servicio de TI. • Frecuencia y duración de degradaciones del servicio. • Número medio de usuarios durante períodos de máxima actividad. • Número de intentos de evadir la seguridad con éxito y fallidos. • Proporción de la capacidad del servicio empleada. • Número de cambios completados y abiertos. • Coste del servicio suministrado. A diferencia de los informes de nivel de servicio, los informes de gestión no se elaboran para el cliente, sino para controlar o gestionar el proceso interno. Pueden contener métricas sobre los niveles de servicio reales, además de tendencias como: • Número de SLAs contratados. • Número de veces que se ha incumplido un SLA. • Coste de la medición y monitorización de los SLAs. • Satisfacción del cliente según los resultados de las encuestas. • Estadísticas de incidencias, problemas y cambios. • Progreso de acciones de mejora.

4.3.3 Proceso de la provisión del servicio: Elaboración de presupuesto y contabilidad de los servicios de TI (6.4) Objetivo: Presupuestar y contabilizar los costes de la provisión del servicio. Las especificaciones ISO 20000-1 dicen: NOTA: Esta sección cubre la elaboración de presupuestos y de la contabilidad de los servicios de TI. En la práctica, muchos proveedores del servicio estarán involucrados en facturar por tales servicios. Sin embargo, dado que la facturación es una actividad opcional, no está cubierta por la norma. Se recomienda a los proveedores que si hacen uso de la facturación, el mecanismo para hacerlo esté plenamente definido y entendido por las partes. Todas las prácticas contables en uso se deberían alinear con las prácticas contables más amplias de la organización del proveedor del servicio. Debe haber políticas y procedimientos claros para: a) Presupuestar y contabilizar todos los componentes, incluyendo los activos de tecnologías de la información, recursos compartidos, gastos generales, servicios suministrados externamente, personas, seguros y licencias. b) La repercusión de costes indirectos y la asignación de costes directos a servicios. c) El control económico efectivo y la autorización. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

142


Los costes se deben presupuestar con suficiente detalle para permitir el control económico efectivo y la toma de decisiones. El proveedor del servicio debe monitorizar e informar de los costes contra el presupuesto, revisar las previsiones económicas y gestionar los costes en consonancia. Los costes de los cambios en el servicio se deben valorar y aprobar a través del proceso de gestión de cambios. El Código de buenas prácticas ISO 20000-2 dice: Generalidades Esta sección cubre la realización de los presupuestos y de la contabilidad para los servicios de TI. En la práctica, muchos proveedores están implicados en la facturación del servicio. Sin embargo, dado que la facturación es una actividad opcional, no está cubierta por esta norma. Se recomienda a los proveedores del servicio que cuando lleven a cabo la facturación, el mecanismo empleado para ello esté definido en detalle y sea atendido por todas las partes implicadas. La responsabilidad sobre muchas de las decisiones financieras va a estar fuera del ámbito de la Gestión del Servicio y también podrían dictarse externamente los requisitos acerca de qué información financiera se debe facilitar, de qué manera y con qué frecuencia. Las disposiciones de esta sección están enfocadas en las prácticas que se deberían seguir para satisfacer los requisitos de la norma. Sin embargo, se pueden tener en cuenta requisitos más amplios en el caso de que impacten en alguna de las políticas y procedimientos definidos. Todas las prácticas contables utilizadas deben estar alineadas con las prácticas contables generales en la organización del proveedor del servicio. Política Debería existir una política para la gestión financiera de los servicios. La política debería definir los objetivos a ser cumplidos por la realización de los presupuestos y la contabilidad. La política debería definir también el nivel de detalle necesario para la elaboración de los presupuestos y la contabilidad, teniendo en cuenta: a) Los tipos de costes a ser contabilizados. b) El reparto de los gastos generales, por ejemplo reparto en partes iguales, reparto porcentual o reparto basado en el tamaño de los elementos variables empleados. c) La granularidad del negocio del cliente, por ejemplo unidades de negocio tomadas como una sola, divididas en departamentos o según las diferentes ubicaciones. d) Las reglas para manejar las variaciones frente al presupuesto, por ejemplo el nivel de variación necesario para que se escale a la alta dirección. e) Los enlaces o vinculación con la gestión del nivel de servicio. El nivel de inversión en los procesos de elaboración del presupuesto y contabilidad debería estar basado en las necesidades de detalles financieros que tengan los clientes, el proveedor del servicio y los proveedores, según esté definido en la política. NOTA: Los proveedores del servicio que operen en un entorno comercial podrían necesitar invertir mucho más esfuerzo y tiempo en la gestión financiera. Contrariamente, para aquellos proveedores del servicio que sólo necesiten la simple identificación de los costes, esta gestión puede ser mucho más simple. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


143

La realización de los presupuestos y la contabilidad se deberían realizar por todos los proveedores del servicio, cualesquiera que fueran sus otras políticas en cuanto a gestión financiera. Elaboración del presupuesto La elaboración del presupuesto debería tener en cuenta los cambios planificados de los servicios durante el periodo presupuestario y, en el caso de que las necesidades presupuestarias excedan los fondos disponibles, planificar la gestión que se va a hacer del déficit. La elaboración de los presupuestos puede tener en cuenta factores tales como variaciones estacionales y cambios planificados a corto plazo en los costes y facturación de los servicios. El seguimiento de los costes frente al presupuesto debería facilitar lo antes posible la información de las variaciones frente al presupuesto. Se debería establecer un proceso para gestionar las implicaciones de las variaciones frente al presupuesto. La elaboración de los presupuestos y el seguimiento de los costes deberían dar soporte a la planificación de la operación de cambios en los servicios para que los niveles de dichos servicios puedan mantenerse a lo largo del año. Contabilidad Los procesos de contabilidad se deberían usar para realizar el seguimiento de los costes hasta el nivel de detalle acordado durante un periodo de tiempo también acordado. Las decisiones sobre la provisión del servicio deberían estar basadas en comparaciones sobre la eficiencia en costes. Los modelos de costes deberían ser capaces de mostrar los costes de la provisión del servicio. Los estados de cuentas deberían mostrar las situaciones de excesos y defectos de gasto así como las repercusiones de dichas situaciones y deberían permitir al lector entender los costes de niveles bajos de servicio o de pérdidas de servicio. La Figura 4.3.4 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. En la gestión financiera de la organización de un proveedor de servicios se pueden distinguir actividades de elaboración y control de presupuestos, contabilidad y cobros.

Guía Un sistema eficaz de control de costes tiene que cumplir los siguientes criterios: • Facilitar el desarrollo de una estrategia de inversión que permita aprovechar la flexibilidad ofrecida por la moderna tecnología. • Identificar prioridades en el uso de recursos. • Cubrir los costes de todos los recursos de TI que utilice la organización, incluyendo la actualización de la información relevante. • Facilitar las decisiones cotidianas de la dirección, de manera que se puedan adoptar decisiones a largo plazo con el mínimo riesgo financiero posible. • Ser flexible y capaz de responder rápidamente a cambios en las actividades de negocio. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

144


Definir políticas y procesos sobre gestión financiera de servicios de TI

Política y gestión financiera de servicios de TI

Incluye activos de TI, recursos compartidos, gastos generales, servicios externos, personal, seguros y licencias

Presupuesto y contabilidad de todos los componentes Crear previsión financiera

Incluye modelos de costes

Previsión financiera

Distribuir costes indirectos y asignar costes directos a servicios Monitorizar y comunicar costes en relación al presupuesto

Revisar las previsiones financieras

Previsión financiera

Informes de costes

Revisión de previsiones financieras

Controlar finanzas y autorizaciones

Interfaces: Todos los procesos relevantes: - Presupuesto y contabilidad de todos los componentes Mejora continua (Actuar): - Sugerir mejoras para SIP Proceso de gestión de cambios: - Estimar el coste y aprobar cambios en servicios - Presentar solicitudes de cambio Informes del servicio: - Recibir información

Figura 4.3.4 Presupuestos y contabilidad de los servicios de TI

La Figura 4.3.5 muestra el ciclo financiero de elaboración y control de presupuestos, contabilidad y cobros. El objetivo de la elaboración y control de presupuestos es planificar y controlar las actividades de una organización. La planificación corporativa y estratégica determina los objetivos a largo plazo de Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Necesidades de TI en las actividades de negocio

Planes de TI (incluyendo presupuestos)

Contabilidad

Identificar objetivos financieros

Métodos de control de costes

145

Cobros

Métodos de cobro

Información sobre tarifas planificadas Gestión del Nivel de Servicio

Gestión Financiera

Figura 4.3.5 El ciclo financiero

un negocio. Los presupuestos definen los planes financieros para los objetivos durante el período cubierto por el presupuesto, que normalmente oscila entre uno y cinco años. Dependiendo de la política financiera del negocio, se pueden seguir dos métodos de elaboración de presupuestos: • Presupuesto incremental - En el caso de presupuestos incrementales, las cifras del año anterior sirven de base para el nuevo presupuesto, que se ajusta para reflejar los cambios previstos. • Presupuestos de base cero - Este método se inicia con un papel en blanco (la “base cero”). Se ignora todo lo anterior, por lo que los gestores tienen que justificar todas sus peticiones de recursos en términos de coste presupuestario. Esto significa que se evalúan todos y cada uno de los gastos antes de decidir si se aprueban y cuál debe ser su coste. Es evidente que este método requiere mucho más tiempo, por lo que normalmente sólo se utiliza cada pocos años y se prefiere el método incremental para los años restantes. El proceso de elaboración y control de presupuesto comienza con la identificación de los factores clave que limitan el crecimiento de la empresa. En muchos casos se trata del volumen de ventas, aunque también puede ser la falta de espacio o materiales. Es frecuente que el presupuesto venga determinado por restricciones financieras. Este proceso incluye la definición de los siguientes presupuestos secundarios (en lo que sigue se ignoran los procesos de aprobación seguidos en cada negocio): • Presupuesto de ventas y marketing - Si el presupuesto está determinado por el volumen de ventas, el departamento de marketing se ocupa de una parte importante del proceso. La elaboración de un buen presupuesto exige la evaluación y el análisis precisos de los clientes, mercados, regiones de venta y productos. • Presupuesto de producción - El presupuesto de producción contiene información detallada sobre los servicios que se deben suministrar (cantidades, tiempos de entrega, personas-hora y materiales). • Presupuestos administrativos - En función del servicio que se vaya a suministrar, se determinan los presupuestos generales de los distintos departamentos, como producción, ventas y distribución, o investigación y desarrollo. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

146


• Presupuestos de costes e inversiones - El presupuesto de costes es resultado de los planes contemplados en los presupuestos anteriores, mientras que el presupuesto de inversiones identifica el gasto asociado a la sustitución y adquisición de los medios de producción. Los proyectos de inversión que se hayan iniciado el año anterior también pueden influir en el presupuesto de inversiones. El año financiero (fiscal) es la opción más habitual a la hora de elegir el período presupuestario. Este período se divide a su vez en meses u otros períodos, como ventanas de cuatro semanas, con el fin de realizar comparaciones entre las cifras presupuestadas y reales. Algunos negocios no sólo elaboran presupuestos anuales detallados, sino también una previsión general para un período de tres o cinco años. De esta forma, la dirección sénior puede conocer las expectativas a más largo plazo. Para que una organización de TI funcione como un negocio es fundamental identificar y comprender todos los costes imputables a TI. Para ello se emplea la contabilidad. Se deben determinar todos los costes, aunque no se vayan a cobrar a los clientes. Una de las actividades contables más importantes consiste en definir elementos de coste. Esta estructura se mantiene fija durante un año, tras lo cual se puede modificar. En la mayor parte de los casos se elige un método de contabilidad de costes cuando se introduce una estructura de elementos de coste en el negocio, lo que significa que la estructura de elementos de coste tiene que ser compatible con los métodos adoptados por el negocio. Lo normal es que se registren costes para cada departamento, cliente o producto. Sin embargo, lo ideal es que la estructura refleje los servicios suministrados. Aunque el proceso no se utilice para imputar costes, suele resultar útil basar la estructura de tipos de coste en una estructura de servicios como la empleada en un catálogo de servicios. La Figura 4.3.6 muestra un ejemplo de estructura jerárquica de los elementos de servicio creados por la organización de TI para la prestación de servicios. En esta estructura, los elementos de servicio de nivel más bajo soportan a los elementos de servicio de nivel superior. Cuanto más alta sea la posición de un elemento en esta estructura, más relevante es su función para el negocio. A partir de los elementos de servicio se definen los elementos de coste, que a su vez se dividen en unidades de coste para personal, hardware, software y gastos generales. La ventaja de estructurar los elementos de coste a partir de los elementos de servicio reside en que permite ver con claridad el gasto en hardware, software y soporte del servicio. Además de una estructura basada en costes directos, también se puede decidir cómo asignar costes indirectos a los servicios. Cuanto más detallada sea la estructura de servicios, más fácil será comprender los costes. Un catálogo menos detallado podría contener sólo tres estaciones de trabajo estándar que incluyeran todo. En ese caso, el diagrama tendría sólo tres columnas y muchos menos elementos de coste. Resultaría más claro, pero también ofrecería información menos detallada.



Aplicación de negocio Cuentas

147

Aplicación de negocio Gestión de Relaciones

Emulador de terminal Entorno IBM

Aplicación de negocio Datos de marketing Emulador de terminal otro entorno

Intranet, Extranet e Internet Servicios de información Aplicaciones colaborativa Servicios de correo y directorio Aplicaciones generales de negocio

Aplicaciones de oficina

Servicios de archivos e impresión Sistema operativo Windows Vista Estación de trabajo Línea base A Ordenador de sobremesa potente

Sistema operativo Windows XP Estación de trabajo Línea base B Thin Client

Estación de trabajo Línea base C Ordenador portátil

Servicios de red (LAN y WAN)

Figura 4.3.6 Ejemplo de una estructura de servicios

A continuación se elaboran los presupuestos del año entrante para cada elemento de servicio y coste, basándose en la experiencia previa y en estimaciones de crecimiento para el año entrante. Estos presupuestos se monitorizan todos los meses para identificar nuevas tendencias (un crecimiento imprevisto, por ejemplo) y, en su caso, responder de acuerdo con la política de negocio. La imputación de costes interna es una herramienta muy eficaz para conseguir que los usuarios empleen con más cuidado los recursos de TI. No obstante, cobrar por los servicios de TI no resulta tan útil si los titulares de presupuestos en las organizaciones de los clientes no tienen que pagar por otros servicios como el teléfono, el alojamiento, la sala de correo, la comida o la administración de personal. En otras palabras: la imputación de costes tiene que ser compatible con las políticas financieras de la organización. Si se considera que el cobro es adecuado, los titulares de presupuestos pueden hacer frente a los costes operativos, que repercuten en el precio de sus productos y servicios. Los cobros se emplean normalmente para recuperar todos los costes en que se ha incurrido, en cuyo caso la organización de TI funciona como una unidad de negocio. Esto sólo es posible cuando se conocen los costes operativos reales de los servicios de TI. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

148


Es conveniente definir políticas de imputación de costes antes de fijar un precio. Existen diferentes políticas que se pueden elegir en función de los objetivos de la gestión financiera. También es posible introducir el cobro por fases y usar una política distinta para cada fase. Las políticas de imputación de costes son: • Comunicación de información - Se informa de la imputación de costes a los gestores del cliente para que conozcan los costes del uso de servicios de TI en sus departamentos. Para ello se puede elegir entre dos opciones: – Calcular los costes correspondientes a cada unidad de negocio e informar a los gestores interesados. – Como la anterior, pero incluyendo los costes que se van a cobrar siguiendo un método de cobro específico. • Flexibilidad de precios - Los precios se fijan y se cobran con periodicidad anual. Si el proveedor de servicios decide invertir en un servicio porque se utiliza con más frecuencia, el contrato puede incluir una cláusula para cobrar los costes adicionales. La alternativa es ofrecer más capacidad a otros clientes potenciales. • Cobro por noción - Los costes se facturan, pero no es necesario pagarlos. Esto permite a la organización de TI adquirir experiencia en el uso del proceso y corregir posibles errores en el sistema de cobro. También ofrece al cliente la oportunidad de acostumbrarse al cobro. No obstante, este método de imputación de costes sólo es útil si finalmente se recuperan los costes, ya que de lo contrario no se llegará a tener conciencia de ellos. Con frecuencia resulta difícil fijar el precio de un servicio. El establecimiento de precios incluye las siguientes actividades: • Decidir el objetivo del cobro. • Determinar los costes directos e indirectos. • Determinar las tasas de mercado. • Analizar la demanda de servicios. • Analizar el número de clientes y la competencia. Para determinar el precio de un servicio, la organización tiene que empezar por determinar el objetivo y el beneficio previsto para los clientes y el personal de TI. El precio es una de las cuatro P del marketing: Producto, Precio, Promoción y Puesto (lugar). El precio no sólo es importante para recuperar los costes en que se ha incurrido, sino que también influye en la demanda del producto. Una estrategia de precios flexibles puede ser útil para promocionar productos, para retirarlos o para distribuir la demanda de sistemas. Los ingresos obtenidos con otros servicios pueden ayudar a costear un servicio nuevo que tiene pocos clientes. Los costes de un servicio tienen que estar claramente identificados antes de que se pueda elegir una estrategia de establecimiento de precios. Dependiendo de la política de imputación de costes, el cliente recibe una factura o una comunicación del uso real de servicios de TI. Los costes se tratan en las reuniones periódicas con el cliente previstas en el proceso de gestión del nivel de servicio, que recibe la siguiente información: • Gasto en servicios de TI por cliente • Diferencia entre los cobros reales y estimados Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


149

• Métodos de imputación de costes y contabilidad empleados • Disputas sobre cobros, con sus causas y soluciones El proceso de gestión financiera tiene que presentar a la dirección de TI informes periódicos sobre aspectos como: • Costes y beneficios generales de los servicios de TI • Análisis de costes para cada departamento de TI, plataforma y otras unidades relevantes • Costes correspondientes al sistema de gestión financiera • Planificación de futuras inversiones • Comparación entre los resultados planificados y reales • Oportunidades de reducción de costes Antes de introducir la gestión financiera hay que informar a los usuarios, al personal y a la dirección de TI del objetivo que se persigue, así como de los costes, beneficios y posibles problemas asociados con la introducción. Los CSFs para la introducción de un sistema eficaz de imputación de costes son: • Los usuarios deben conocer los servicios por los que se les cobra. • Los usuarios deben conocer los métodos de imputación de costes para que puedan controlar sus costes (por ejemplo, mediante acuerdos o informes en términos de unidades de rendimiento cuantificables). • El sistema de monitorización de costes debe proporcionar detalles y justificación de gastos. • La Gestión de Servicios de TI debe contar con sistemas bien equilibrados que ofrezcan servicios de TI eficaces a un precio razonable. • La dirección de TI debe ser consciente del impacto y los costes que conlleva la introducción de la gestión financiera y estar plenamente comprometida. • La gestión de la configuración debe proporcionar información relevante sobre la estructura de los servicios para poder definir un sistema de contabilidad apropiado. Los siguientes indicadores de rendimiento pueden ayudar a controlar el proceso: • Análisis coste-beneficio preciso de los servicios suministrados. • Los clientes consideran que los métodos de imputación de costes son razonables. • La organización de TI cumple sus objetivos financieros. • Cambia el uso de los servicios por parte del cliente. • Se presentan informes puntuales a la gestión del nivel de servicio.

4.3.4 Procesos de relaciones: Generalidades (7.1) Las especificaciones ISO 20000-1 dicen: Los procesos de relación describen los dos aspectos relacionados con la gestión de proveedores y con la gestión de las relaciones con el negocio. El Código de buenas prácticas ISO 20000-2 dice: Los procesos de relación describen los dos aspectos relacionados de la gestión de proveedores y la gestión de relaciones con el negocio. Esta norma se dirige hacia el rol de un proveedor del servicio, el cual Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

150


cumple un papel entre los suministradores, que proporcionan bienes o servicios a dicho proveedor del servicio, y los clientes, que reciben los servicios. Tanto los suministradores, como los clientes pueden ser internos y externos a la organización del proveedor del servicio. Las relaciones externas se formalizarán mediante contratos. Las relaciones internas se formalizarán mediante acuerdos de servicio o de soporte interno que son a menudo designados como acuerdos de nivel operacional. La Figura 4.3.7 muestra una representación simplificada de las relaciones. Gestión de Proveedores

Suministrador

Gestión de Relaciones con el Negocio

Proveedor de servicios

Cliente

Figura 4.3.7 Procesos de relaciones

Como muestra la Figura 4.3.7, el proveedor del servicio juega un papel dentro de la cadena de suministro, en la cual cada eslabón debería añadir valor, de forma que el proveedor del servicio que recibe bienes o servicios procedentes del suministrador, entrega un servicio mejorado al cliente. A modo de aclaración, dentro de esta sección el término proveedor del servicio se utiliza siempre para describir la organización a la que se dirige este documento, independientemente del papel, o sentido en la cadena, que tiene en el proceso que se describe. En la práctica, las relaciones raramente son así de simples, sino que implican múltiples participantes, asumiendo papeles, tanto como suministradores, como clientes y con conexiones de negocio entre muchos de ellos de forma directa o bien mediante el proveedor del servicio. Los procesos de relación deberían asegurar que todas las partes: a) Entienden y satisfacen las necesidades del negocio. b) Entienden las capacidades y limitaciones. c) Entienden las responsabilidades y las obligaciones. Estos procesos también deberían asegurar que los niveles de satisfacción del cliente son apropiados y que se comunican y entienden las necesidades futuras del negocio. El alcance, los roles y las responsabilidades de las relaciones con el negocio y las relaciones con los suministradores deberían definirse y acordarse. Esto debería incluir la identificación de todos los grupos de interés, los contactos y los medios y frecuencia de la comunicación. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


151

La Figura 4.3.8 muestra cómo se pueden visualizar los procesos generales de relación en lenguaje BPM. Definir y acordar el alcance, los roles y las responsabilidades de las relaciones con el negocio y los suministradores Identificar y documentar a los grupos de interés y los clientes del servicio

Grupos de interés y clientes del servicio

Designar a personas responsables del proceso de relaciones con el negocio y satisfacción del cliente Identificar contactos con grupos de interés y las líneas y frecuencia de comunicación

Planificar reuniones formales Al menos una vez al año

Antes y después de cambios importantes

Asistir a la revisión del servicio para discutir cambios

Emitir registros de revisión del servicio

A intervalos acordados

Actas Cambios de alcance del servicio, SLA, contrato o necesidades de negocio Registros de revisión del servicio

Actas

Mantener reuniones intermedias y emitir nuevos registros para SIP

RFC si es necesario Responder a cambios importantes y nuevas necesidades de negocio

Para discutir sobre rendimiento, logros, posibles problemas y planes de acción

Interfaces: Mejora continua del servicio (Actuar): - Sugerir mejoras para SIP - Recibir informes de progreso Proceso de gestión de cambios: - Presentar solicitudes de cambio - Gestionar los cambios introducidos en contratos (en su caso) y SLAs Gestión del nivel de servicio: - Revisar el SLA y los niveles de servicio Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes

Figura 4.3.8 Gestión de relaciones con el negocio Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

152


El enfoque a cliente es uno de los ocho principios de la gestión de la calidad, por lo que la gestión de relaciones con el negocio es un proceso importante. Un proveedor de servicios tiene que controlar los procesos de su propia organización para poder ofrecer al cliente servicios de TI de calidad, pero también debe controlar los servicios de los suministradores que contribuyen al negocio del proveedor de servicios.

4.3.5 Procesos de relaciones: Gestión de las relaciones con el negocio (7.2) Objetivo: Establecer y mantener una buena relación entre el proveedor del servicio y el cliente, basándose en el entendimiento del cliente y de los fundamentos de su negocio. Las especificaciones ISO 20000-1 dicen: El proveedor del servicio debe identificar y documentar quienes son los actores principales y los clientes de los servicios. El proveedor del servicio y los clientes se deben reunir, al menos una vez al año, para la revisión del servicio y para discutir cualquier cambio en el alcance del mismo, en el SLA, en el contrato (si existe) o en las necesidades del negocio. Se deben mantener reuniones a intervalos acordados para discutir el comportamiento y las prestaciones, los cumplimientos, asuntos varios y planes de acción. Estas reuniones se deben documentar. A las reuniones puede invitarse a otros actores relacionados con el servicio. Los cambios al contrato(s), si existen, y al SLAs deben ser el resultado de las reuniones mencionadas, cuando sea apropiado. Estos cambios deben estar sujetos al proceso de gestión de cambios. El proveedor del servicio debe permanecer al tanto de las necesidades del negocio y de los principales cambios en el mismo para preparar una respuesta a dichas necesidades. Debe existir un proceso de reclamaciones. La definición de la reclamación formal sobre el servicio debe estar acordada con el cliente.Todas las reclamaciones formales sobre el servicio son registradas por el proveedor del servicio, investigadas, controladas emprendiendo acciones sobre ellas, informadas y formalmente cerradas. Cuando una reclamación no sea resuelta mediante los canales normales, el cliente debe disponer de un mecanismo de escalado. El proveedor del servicio debe tener una o varias personas asignadas como responsable(s) de gestionar la satisfacción del cliente y todo el proceso de gestión de relaciones con el negocio. Debe existir un proceso de medición periódica de la satisfacción del cliente para obtener información y comentarios, y actuar en consecuencia. Las acciones de mejora que se identifiquen durante este proceso se deben registrar y utilizar como información de entrada para un plan de mejora del servicio.



153

El Código de buenas prácticas ISO 20000-2 dice: Revisiones del servicio El proveedor del servicio y los clientes deberían realizar revisiones del servicio, al menos anualmente, o antes y después de cambios importantes. La revisión debería considerar el comportamiento previo, tratar las necesidades de negocio actuales y previstas, y proponer cualquier cambio necesario en el alcance del servicio y los SLAs. Otros grupos de interés implicados como por ejemplo subcontratistas, clientes, grupos de usuarios u otros grupos representativos, pueden ser invitados a participar en las reuniones de revisión. El proveedor del servicio y los clientes deberían también acordar los procedimientos de revisión parcial para tratar el progreso, los logros y los problemas detectados. Estas reuniones deberían planificarse y ser notificadas a los grupos de interés para los que sean relevantes. El proveedor del servicio debería planificar y registrar todas las reuniones formales, registrar los problemas tratados y realizar el seguimiento de las acciones acordadas. El proveedor del servicio debería establecer una relación con sus clientes de manera que éstos puedan estar al tanto de las necesidades del negocio y de los cambios principales para poder prepararse para dar una respuesta a los mismos. Reclamaciones del servicio El proveedor del servicio y los clientes deberían acordar un procedimiento formal de reclamaciones que elimine cualquier ambigüedad sobre qué constituye una reclamación y cómo se debería gestionar. El proveedor del servicio debería poner en marcha un proceso para tomar las acciones adecuadas en la resolución de los problemas. El proceso debería identificar a la persona de contacto en el proveedor del servicio al que dirigir las reclamaciones formales. El proveedor del servicio debería registrar, investigar, tomar acciones, elaborar informes y cerrar formalmente todas las reclamaciones de servicio. Las reclamaciones más relevantes se deberían revisar periódicamente y ser escaladas a la alta dirección si no se resuelven dentro de los plazos acordados con los clientes. Los proveedores del servicio deberían analizar periódicamente las reclamaciones registradas para identificar tendencias y elaborar informes con este análisis para los clientes. Los resultados de tal análisis se deberían usar cuando sea apropiado para el establecimiento de un plan de mejora del servicio. Medición de la satisfacción del cliente Se debería medir la satisfacción del cliente para permitir al proveedor del servicio comparar el desempeño con los objetivos de satisfacción de clientes y con encuestas previas. El alcance y la complejidad de la encuesta se deberían concebir de forma que los clientes puedan responder fácilmente y sin que se requiera un excesivo tiempo para cumplimentar de una manera adecuada dicha encuesta. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

154


Se deberían investigar las variaciones significativas en los niveles de satisfacción para llegar a entender las razones de las mismas. Los análisis de tendencias u otras comparaciones solo deberían realizarse sobre preguntas comparables y entre métodos de muestreo comparables. Los resultados y conclusiones de las encuestas de satisfacción del cliente se deberían tratar con el cliente. Se debería acordar un plan de acción, utilizándolo como entrada para un plan de mejora del servicio sobre cuyo progreso se informe al cliente. Las felicitaciones sobre el servicio se deberían documentar y dar a conocer al equipo que esté prestando el servicio. Según el principio de enfoque a cliente de la gestión de la calidad, las organizaciones dependen de sus clientes y, por tanto, tienen que comprender sus necesidades presentes y futuras, cumplir sus requisitos y hacer todo lo posible por superar sus expectativas. La gestión de relaciones con el negocio exige dos procesos explícitamente: • Gestión de quejas (Figura 4.3.9) • Gestión de satisfacción del cliente (Figura 4.3.10) Los documentos necesarios para la gestión de relaciones con el negocio incluyen un documento sobre las partes interesadas y los clientes del servicio, las actas de las reuniones de relaciones con el negocio, registros de quejas formales sobre el servicio y registros de acciones de mejora. El proceso de gestión de relaciones con el negocio tiene una interfaz con el proceso de gestión de cambios, que controla los cambios introducidos en contratos (en su caso) y SLAs.

Guía La Figura 4.3.11 ilustra las comunicaciones en horizontal entre los clientes y la organización de TI para soporte y coordinación. Las comunicaciones en vertical afectan a políticas, control e informes. El principal reto de la gestión de relaciones con el negocio consiste en garantizar una relación buena y eficaz a todos los niveles entre la organización de TI y la organización del cliente. Es importante que desde el principio se defina exactamente qué se entiende por “usuario” y “cliente”: El usuario es quien “está al teclado”, el empleado que utiliza los servicios de TI para sus actividades de rutina. El cliente es quien “paga las facturas”, la persona autorizada a alcanzar un acuerdo con la organización de TI sobre la provisión de servicios de TI (por ejemplo, un acuerdo de nivel de servicio) y que es responsable de garantizar el pago de los servicios de TI. Evidentemente, hay multitud de casos en que el cliente que “paga las facturas” también puede ser el usuario que “está al teclado”.



Acordar la definición de queja formal sobre el servicio

Identificar el punto de contacto para la presentación de quejas formales Acordar el procedimiento de gestión de quejas formales

Registrar todas las quejas sobre el servicio

Registros de quejas del servicio

Investigar las quejas sobre el servicio

Resolver las quejas sobre el servicio

Informar de las quejas sobre el servicio

Cerrar formalmente las quejas sobre el servicio

Posibilidad de escalado

Revisar periódicamente las quejas pendientes de resolución y proceder a su escalado si es necesario

Registros de quejas del servicio

Analizar periódicamente los registros de quejas para identificar tendencias

Tendencias

Informar del análisis a los clientes

Tendencias


Tendencias

Figura 4.3.9 Gestión de relaciones con el negocio: Gestión de quejas


155

156


Obtener medidas de satisfacción



Comparar los resultados con los objetivos de satisfacción y los resultados de encuestas anteriores

Investigar y comprender las variaciones significativas en los niveles de satisfacción

Discutir con el cliente los resultados de las encuestas de satisfacción y acordar un plan de acción

Registrar las acciones de mejora identificadas



Utilizar como entrada para SIP Plan de mejora del servicio Informar al cliente sobre el progreso de la mejora del servicio

Documentar comentarios positivos

Comentarios positivos

Comunicar los comentarios positivos al equipo responsable de la provisión del servicio

Figura 4.3.10 Gestión de las relaciones con el negocio: Gestión de satisfacción del cliente

La gestión de relaciones con el negocio desempeña un importante rol en el desarrollo del alineamiento estratégico entre la organización de TI y la organización que adquiere los servicios de TI. En la práctica, se trata fundamentalmente de mantenerse en contacto con la organización del cliente y explorar las posibilidades de vincular los objetivos estratégicos de ambas organizaciones. Ésta puede ser la base de una relación a largo plazo en la que la organización de TI mantiene un enfoque a cliente y propone soluciones de TI que ayudan al cliente a cumplir sus objetivos de Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


157

Organización de TI

Organización del cliente Gestión de Relaciones con el Cliente de TI Estratégica

Táctica

Operativa

Gestores de negocio

Titulares de presupuestos Directores de departamento Jefes de proyecto Usuarios

Alineamiento estratégico

Niveles de servicio Solicitudes de cambio Soporte

Demanda

Gestión de TI

Política

Gestión del nivel de servicio

Informes

Gestión de cambios Gestión de incidencias Centro de atención al usuario Producción Suministro

Figura 4.3.11 Gestión de las relaciones con el negocio

negocio. La naturaleza dinámica de las dos organizaciones obliga también a coordinar la velocidad de los cambios. Los acuerdos con el cliente sobre los servicios que se van a suministrar se desarrollan en propuestas de nivel de servicios a través de la gestión del nivel de servicio. Si el cliente desea introducir una intranet, por ejemplo, es necesario llegar a un acuerdo sobre la disponibilidad, el soporte al usuario, la implantación de solicitudes de cambio y el coste. Estos acuerdos se fijan en un acuerdo de nivel de servicio (SLA). Si la organización del cliente quiere introducir cambios (ampliación o modificación) en los servicios de TI contemplados en los acuerdos que forman parte del SLA, tendrá que presentar una solicitud de cambio (RFC). Una vez realizada la instalación, hay que actualizar la información y el estado del CI en la CMDB para facilitar la verificación de los acuerdos de licencia. La Figura 4.3.11 no sólo ofrece información sobre las comunicaciones en horizontal y en vertical, sino también sobre el horizonte de planificación de los procesos. La coordinación a nivel estratégico tiene un horizonte de planificación de varios años. La gestión del nivel de servicio afecta a los acuerdos de nivel táctico y su horizonte de panificación es de aproximadamente un año. La gestión de cambios, el centro de atención al usuario y la gestión de incidencias afectan al nivel operativo y tienen un horizonte de planificación de meses, semanas, días o incluso horas. Las encuestas de satisfacción del cliente (CSS) pueden ser encuestas periódicas de tipo formal o bien estudios realizados por el centro de atención al usuario. En ambos casos se selecciona a varios interlocutores al azar y se les hacen algunas preguntas sobre su percepción de la calidad del servicio de TI. La información recopilada con las encuestas del centro de atención al usuario se debe considerar como un complemento a la CSS completa. Tanto el texto de las preguntas como su contenido se tienen que elegir con mucho cuidado. Las preguntas tienen que afectar a áreas que sean importantes para el cliente, comenzando siempre con las preguntas más importantes. Los participantes en la encuesta deben recibir copias de los resultados, incluyendo detalles de las acciones propuestas para las áreas de mejora. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

158


Los resultados de la CSS deben servir para realizar un análisis de tendencias con el fin de conseguir una mejora continua en la percepción del cliente hasta llegar a un objetivo óptimo. En circunstancias normales, un mejor rendimiento lleva a un aumento en las expectativas del cliente.

4.3.6 Procesos de relaciones: Gestión de proveedores (7.3) Objetivo: Gestionar los suministradores para garantizar la provisión sin interrupciones de servicios de calidad. Las especificaciones ISO 20000-1 dicen: NOTA: 1 El ámbito de esta norma excluye la selección de suministradores. NOTA 2: Los suministradores pueden ser utilizados por el proveedor del servicio para el suministro de alguna parte del servicio. Es el proveedor del servicio quien debe demostrar el cumplimiento de estos procesos de gestión de proveedores. Pueden existir relaciones complejas, como demuestra el siguiente diagrama utilizado a modo de ejemplo. El proveedor del servicio debe tener documentados los procesos de gestión de proveedores y debe designar un gestor responsable del contacto con cada suministrador. Los requisitos, alcance, nivel de servicio y procesos de comunicación a ser proporcionados por el suministrador(es) se deben acordar por todas las partes y documentar en los SLAs u otros documentos. Los SLAs con los suministradores se deben alinear con los SLAs del negocio. Las interfaces entre los procesos utilizados por cada parte deben ser acordadas y documentadas. Todos los roles y relaciones entre suministradores principales y subcontratados deben estar claramente documentados. Los suministradores principales deben ser capaces de demostrar que tienen procesos para garantizar que los subcontratistas cumplen con los requisitos contractuales. Se debe disponer de un proceso para la revisión detallada del contrato o del acuerdo formal, con periodicidad mínima anual, que garantice que las necesidades y obligaciones contractuales del negocio se siguen cumpliendo. Los cambios al contrato(s), si existen, y los SLAs deben ser el resultado de estas revisiones o de aquellas requeridas en cualquier momento. Cualquier cambio debe estar sujeto al proceso de gestión de cambios. Debe existir un proceso para tratar los desacuerdos contractuales. Debe existir un proceso para gestionar la finalización normal o anticipada de un servicio, o la trasferencia del mismo a un tercero. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


159

Se debe monitorizar y revisar el comportamiento y las prestaciones frente a los objetivos de nivel de servicio. Las acciones de mejora identificadas durante este proceso se deben registrar y utilizar como información de entrada al plan de mejora del servicio.

Suministrador 1

Negocio

Proveedor de servicios (puede ser interno o externo)

Suministrador 2

Suministrador principal 3

Suministrador subcontratado 4

Figura 4.3.12 Ejemplo de relación entre proveedores de servicios y suministradores

El Código de buenas prácticas ISO 20000-2 dice: Introducción Los procedimientos de gestión de proveedores deberían garantizar que: a) El suministrador entiende sus obligaciones frente al proveedor del servicio. b) Los requisitos acordados y legítimos son cumplidos dentro del alcance y los niveles de servicio acordados. c) Los cambios son gestionados. d) Se registran las transacciones de negocio entre todas las partes. e) Se puede controlar la información sobre el desempeño de todos los suministradores y actuar en consecuencia. Gestión de contratos El proveedor del servicio debería designar un responsable para hacerse cargo de los contratos y acuerdos con los suministradores. En el caso de que haya todo un grupo de personal involucrado en esta tarea, debería existir un proceso común para asegurar que la información sobre el desempeño de los suministradores está controlada y se actúa consecuentemente. Debería existir una persona de contacto definida dentro de la organización del proveedor del servicio que sea el responsable de la relación con cada suministrador. Todos los contratos con suministradores deberían contener una planificación de las revisiones para evaluar si los objetivos de negocio para el suministro de un servicio siguen siendo válidos. Debería existir un proceso claramente definido para la gestión de cada contrato. El proceso para la modificación de contratos debería estar también claramente definido. Cualquier cambio a este procedimiento se debería notificar formalmente a todos los suministradores afectados.


160


Se debería mantener una lista de puntos de contacto dentro de las respectivas organizaciones (la del suministrador y la del proveedor del servicio). Si un contrato incluye penalizaciones o bonificaciones, se deberían establecer claramente sus fundamentos y elaborar un informe del cumplimiento de los requisitos. Definición del servicio Para cada servicio y suministrador el proveedor del servicio debería mantener: a) Una definición de servicios, roles y responsabilidades. b) El alcance del servicio. c) Un proceso de gestión de contratos, los niveles de autorización y un plan de extinción del contrato. d) Las condiciones de pago, si son relevantes. e) Los parámetros de informe y el registro acordados sobre el desempeño alcanzado. Gestión de múltiples suministradores Debería quedar claro si el proveedor del servicio trata con todos los suministradores de forma directa o mediante un suministrador principal que toma la responsabilidad de los suministradores subcontratados. El suministrador principal debería registrar los nombres, responsabilidades y relaciones entre todos los suministradores subcontratados y ponerla a disposición del proveedor del servicio si así lo requiere. El proveedor del servicio debería obtener evidencias de que los suministradores principales gestionan formalmente a los suministradores subcontratados; guiándose, cuando sea apropiado, por los requisitos incluidos en la Norma ISO/IEC 20000-1. Gestión de los conflictos contractuales Tanto el proveedor del servicio como el suministrador deberían funcionar conforme a un proceso para gestionar los conflictos, el cual se debería definir o referenciar dentro del contrato. Debería existir un procedimiento o itinerario para poder escalar los conflictos que no puedan ser resueltos mediante el procedimiento ordinario. El proceso debería asegurar que los conflictos son registrados, investigados, que se toman acciones necesarias sobre ellos y que se cierran formalmente. Finalización del contrato El proceso de gestión de contratos debería contemplar la extinción del contrato (tanto planificada, como prematura). También debería proporcionar un mecanismo de transferencia del servicio a otra organización. La Figura 4.3.13 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos. La relación con el suministrador se basa en acuerdos de nivel de servicio y otros documentos contractuales que describen los requisitos que deben cumplir los servicios del suministrador. Por lo tanto, la gestión de la relación con el suministrador y el control del contrato son procesos muy importantes. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Documentar el proceso de gestión * de proveedores Acordar y documentar las interfaces del proceso **** Acordar y documentar los requisitos, el alcance, el nivel de servicio y los procesos de comunicación que se vayan a adquirir con los suministradores

****

Proceso de gestión de proveedores Interfaces del proceso

SLAs de suministradores u otros documentos

Obtener evidencia de que los suministradores principales gestionan * a los subcontratistas Documentar todos los roles y relaciones entre suministradores *** principales y subcontratados Demostrar que los subcontratistas pueden cumplir los requisitos

161

Roles y relaciones

Incluyen: - Calendario de revisiones - Condiciones de penalizaciones y bonificaciones, en su caso - Referencia a procesos para gestionar disputas - Lista de puntos de contacto en las distintas organizaciones - Definición de servicios, roles y responsabilidades - Alcance del servicio - Proceso de gestión de contratos, niveles de autorización y un plan de abandono de contrato - Condiciones de pago, en su caso - Parámetros de elaboración de informes y registros de rendimiento

Incluye nombres y responsabilidades

***

Designar a un gestor de contratos para cada suministrador * Resolver disputas contractuales

**

Gestionar la finalización del servicio

*

Monitorizar y revisar el rendimiento de los suministradores en relación a objetivos * específicos Informe de conformidad

Identificar y registrar acciones de mejora



Registro de disputas

Con vía de escalado -Finalización prevista -Finalización anticipada -Transferencia a otra organización

Informe de conformidad


Efectuar una revisión del contrato o acuerdo formal *

Cambiar el contrato


RfCs

Interfaces: Procesos de suministradores - Documentar interfaces Mejora continua (Actuar): - Sugerir mejoras para SIP Proceso de gestión de cambios: - Gestionar los cambios introducidos en contratos y SLAs

Roles responsables: * ** *** ****

Proveedor de servicios Proveedor de servicios y suministrador principal Suministrador principal Todas las partes afectadas

Gestión del nivel de servicio Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes

Figura 4.3.13 Gestión de proveedores Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

162


La norma exige explícitamente la existencia de procesos documentados de gestión de proveedores. En estos procesos se deben definir las actividades necesarias para efectuar una revisión del contrato, para resolver disputas contractuales y para gestionar la finalización de los servicios. Si hay múltiples suministradores, el suministrador principal debe contar con procesos para controlar los servicios de todos los suministradores. Los documentos exigidos explícitamente para la gestión de proveedores son los acuerdos de nivel de servicio de los suministradores y los registros de acciones de mejora. El proceso de gestión de proveedores tiene interfaces con procesos de suministradores, con el proceso de gestión de cambios y con el proceso de mejora continua. Estas interfaces deben estar documentadas.

Guía Una organización tiene por lo general muchos suministradores, la mayor parte de los cuales proporcionan servicios o productos que el negocio utiliza como activos que dan soporte a la cadena de valor del negocio, aunque estén controlados por el cliente. Los tipos de suministradores y sus contratos pueden tener una influencia decisiva sobre la estructura organizativa y sobre todo el marco de trabajo de SLAs. En el caso de los suministradores clave, la relación resulta especialmente importante y la calidad del servicio puede ser determinante para la cadena de valor. Esto afecta a la relación con la organización de TI a tres niveles: • Estratégico - Formas de asociación, como la externalización de una parte importante de la provisión de servicios. • Táctico - Relaciones que fomentan la actividad comercial y la interacción de negocios. • Operativo - Productos y servicios, especialmente si se puede encontrar con facilidad una alternativa. Para suministrar los servicios es preciso que se desarrollen y mantengan relaciones adecuadas. Los tipos más habituales de relación son: • Suministrador interno - Formaliza el suministro de una parte de una organización a otra parte de la misma organización. • Fuente de suministro única, doble o múltiple - La fidelidad a un único suministrador se puede traducir en precios más favorables o en una relación más especializada y comprometida, mientras que el uso de múltiples suministradores puede reducir la dependencia de uno solo y favorece la competencia en precios. • Asociación - Las relaciones de asociación se establecen a nivel ejecutivo, requieren alianzas estratégicas y se basan en riesgos compartidos. • Externalización - Es cada vez más común y, por lo general, consiste en transferir la responsabilidad de la entrega del servicio de suministradores internos a suministradores externos. Existen diversos factores que pueden influir en la relación o combinación de relaciones elegidas. Una herramienta de posicionamiento estratégico, como los perfiles mostrados en la Figura 4.3.14, puede ayudar a una organización a elegir el enfoque más adecuado.



163

Suministrador importante

Suministrador estratégico

Activo de alto valor y bajo riesgo

Servicio de alto valor y alto riesgo

Valor para el negocio

Riesgo creciente Suministrador útil

Suministrador importante

Activo de bajo valor y bajo riesgo

Servicio de bajo valor y alto riesgo

Conexión con suministradores

Figura 4.3.14 Perfiles de relaciones con suministradores

Sea cual sea la relación adoptada, tiene que estar apuntalada por un contrato o acuerdo de nivel de servicio (o un acuerdo de nivel operativo para suministradores internos). Lo único que hace esta formalización es documentar elementos de la relación, pero su éxito dependerá también de factores humanos y de negocio. La relación formalizada debe contemplar: • Alcance y cobertura • Planteamiento y responsabilidad de documentación • Gestión de contratos • Gestión de cambios y revisiones • Gestión de relaciones y rendimiento • Gestión de riesgos, costes y beneficios • Criterios de aceptación de rendimiento • Criterios de aceptación de disponibilidad • Criterios de coste • Límites acordados de rendimiento, disponibilidad y volumen de coste • Cláusulas legales


164


4.4 Entrega de servicios de TI 4.4.1 Gestión de la continuidad y disponibilidad del servicio (6.3) Objetivo: Asegurar que los compromisos de continuidad y disponibilidad acordados con los clientes pueden cumplirse bajo todas las circunstancias. Las especificaciones ISO 20000-1 dicen: Se deben identificar los requisitos de disponibilidad y de continuidad del servicio sobre la base de los planes de negocio, los SLAs y las evaluaciones del riesgo. Los requisitos deben incluir los derechos de acceso y los tiempos de repuesta, así como la disponibilidad extremo a extremo de los componentes del sistema. Los planes de disponibilidad y continuidad del servicio se deben desarrollar y revisar al menos una vez al año, para asegurar que los requisitos cumplen lo acordado bajo todas las circunstancias, desde la normalidad hasta la pérdida grave del servicio. Estos planes se deben mantener para asegurar que reflejan los cambios acordados, requeridos por el negocio. Los planes de disponibilidad y de continuidad del servicio se deben probar de nuevo cuando se produzca un cambio importante en el entorno del negocio. El proceso de gestión de cambios debe evaluar el impacto de cualquier cambio sobre los planes de disponibilidad y continuidad del servicio. La disponibilidad se debe medir y registrar. Se debe investigar la indisponibilidad no planificada y se deben llevar a cabo las acciones necesarias. NOTA: Cuando sea posible, se deben predecir problemas potenciales y tomar medidas preventivas. Los planes de continuidad del servicio, la lista de contactos y la base de datos de gestión de la configuración deben estar disponibles incluso en el caso de que no sea posible el acceso normal a las oficinas. El plan de continuidad del servicio debe incluir la actividad de vuelta a la normalidad. El plan de continuidad del servicio debe aprobarse de acuerdo a las necesidades del negocio. Todas las pruebas de continuidad se deben registrar y tras las pruebas fallidas se deben elaborar planes de acción. El Código de buenas prácticas ISO 20000-2 dice: NOTA: Los desastres o fallos del servicio pueden ocurrir por muchas razones, incluyendo la denegación del servicio, ataques, virus, acceso no permitido a las instalaciones o un desastre natural.



165

Generalidades Los requisitos de continuidad y disponibilidad se deberían identificar sobre la base de las prioridades del negocio del cliente, los acuerdos de nivel de servicio y los riesgos evaluados. El proveedor del servicio debería mantener una capacidad suficiente para el servicio junto con planes fácilmente realizables, diseñados para asegurar que los requisitos acordados pueden ser alcanzados en todas las circunstancias, desde el funcionamiento habitual hasta los casos de caídas graves del servicio. El proveedor del servicio debería planificarse para satisfacer los datos conocidos de incrementos y decrementos de volumen de usuarios, picos o caídas previstos de la demanda y cualquier otro cambio futuro conocido. Los requisitos deberían incluir los derechos de acceso y tiempos de respuesta, así como la disponibilidad de los componentes del sistema. La gestión de la disponibilidad y continuidad del servicio deberían trabajar conjuntamente con el objetivo de asegurar que se mantengan los niveles de servicio acordados. Estos requisitos deberían tener una influencia capital en las acciones, esfuerzos y recursos destinados para satisfacer la disponibilidad de los servicios que los soportan. Los procesos que aseguran que se mantiene la disponibilidad requerida, deberían incluir aquellos elementos de la provisión del servicio que estén bajo el control bien del propio cliente o de otros proveedores del servicio. Actividades y supervisión de la disponibilidad La gestión de la disponibilidad debería: a) Supervisar y registrar la disponibilidad del servicio. b) Mantener datos históricos precisos. c) Realizar comparaciones con los requisitos definidos en los SLAs para identificar no conformidades con los objetivos de disponibilidad acordados. d) Documentar y revisar las no conformidades. e) Predecir la disponibilidad a futuro. f ) Cuando sea posible, se deberían predecir los posibles problemas y llevar a cabo las acciones preventivas. Se debería asegurar la disponibilidad de todos los componentes del servicio, registrando y llevando a cabo las acciones correctivas. Estrategia de continuidad del servicio El proveedor del servicio debería desarrollar y mantener una estrategia que defina el enfoque general a seguir para satisfacer las obligaciones de continuidad del servicio. Esta estrategia debería incluir la evaluación de riesgos y tener en cuenta los horarios de servicio acordados y los periodos críticos del negocio. El proveedor del servicio debería acordar lo siguiente con cada grupo de clientes y servicios: a) Los periodos máximos aceptables de pérdida continuada del servicio. b) Los periodos máximos aceptables de degradación del servicio. c) Los niveles aceptables de degradación del servicio durante un periodo de recuperación del servicio. La estrategia de continuidad debería ser revisada con una periodicidad acordada, al menos anualmente. Cualquier cambio a la estrategia debería ser acordado formalmente. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

166


Planificación y prueba de la continuidad del servicio El proveedor del servicio debería asegurar que: a) Los planes de continuidad tienen en cuenta las dependencias entre el servicio y los componentes de los sistemas. b) Se registran y mantienen los planes de continuidad del servicio y el resto de documentos requeridos para dar soporte a la continuidad del servicio. c) La responsabilidad para activar los planes de continuidad está claramente asignada y los planes establecen claramente la responsabilidad para la toma de las acciones necesarias frente a cada objetivo. d) Las copias de seguridad de los datos, los documentos, el software y cualquier equipo y personal necesario para la restauración del servicio están disponibles de forma rápida ante un desastre o un fallo importante del servicio. e) Al menos un copia de todos los documentos relativos a la continuidad del servicio debería estar almacenada y ser mantenida en una localización remota y segura, junto al equipamiento que sea necesario para permitir su uso. f ) El personal conoce y asume su rol para activar y/o ejecutar los planes y tiene acceso a la documentación relativa a la continuidad del servicio. Los planes de continuidad del servicio y la documentación relacionada (por ejemplo los contratos) deberían estar ligados a los procesos de gestión de cambios y gestión de contratos. Los planes de continuidad del servicio y la documentación relacionada (por ejemplo los contratos) deberían evaluarse respecto al impacto previamente a que se aprueben los cambios en el sistema y en el servicio, y previamente a acordar los nuevos requisitos del cliente o bien cambios en éstos siempre que sean significativos. Se deberían llevar a cabo pruebas con una frecuencia suficiente, para asegurar que los planes de continuidad son efectivos y permanecen así, aun cuando se producen cambios en los sistemas, procesos, personal y necesidades del negocio. El cliente y el proveedor del servicio deberían estar implicados conjuntamente en las pruebas, basadas en un conjunto acordado de objetivos. Los fallos en las pruebas se deberían documentar y revisar para proveer de información a un plan de mejora del servicio. La Figura 4.4.1 muestra cómo se puede visualizar esta parte de la norma en lenguaje BPM. Los procesos de gestión de la disponibilidad y la continuidad del servicio contienen actividades que garantizan la disponibilidad de los sistemas en todo momento. ISO 20000 contempla un sistema combinado de gestión de la disponibilidad y la continuidad del servicio, pero en la práctica se trata de dos procesos diferentes, aunque estrechamente relacionados. La planificación y las pruebas de la disponibilidad y de la continuidad del servicio se pueden realizar como un solo conjunto de actividades, mientras que las actividades de monitorización y gestión de la disponibilidad y de gestión de la continuidad del servicio se deben ejecutar por separado.



Debería incluir evaluación de riesgos y tener en cuenta: - Horas de servicio acordadas - Períodos críticos de negocio

Desarrollar, mantener y revisar una estrategia de continuidad del servicio

Al menos una revisión al año Los cambios se deben acordar formalmente

Planes de negocio

SLAs Evaluaciones de riesgos

Requisitos de disponibilidad y continuidad del servicio

Identificar requisitos de disponibilidad y continuidad del servicio

Requisitos de disponibilidad y continuidad del servicio

Desarrollar y mantener planes de disponibilidad y continuidad del servicio

Planes de disponibilidad y continuidad del servicio

Mejora continua (Actuar): - Sugerir mejoras para SIP Gestión de cambios: - Presentar solicitudes de cambio - Evaluar el impacto de cualquier cambio sobre el plan de disponibilidad y continuidad del servicio - Controlar todos los cambios introducidos en la documentación de disponibilidad y continuidad del servicio - Vincular la documentación con la gestión de cambios

Proceso de gestión de la configuración: - Permitir el acceso a la CMDB cuando no sea posible el acceso normal de oficina - Programar auditorías de configuración después de un desastre Gestión del nivel de servicio: - Acordar Niveles de Servicio para cada grupo de clientes y servicio - Evaluar el impacto sobre la documentación de continuidad del servicio antes de acordar los requisitos del cliente Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes

Incluyendo: - Derechos de acceso - Tiempos de respuesta - Disponibilidad de extremo a extremo de componentes de sistemas Disponibles cuando no sea posible el acceso normal de oficina, junto con listas de contactos y la CMDB Incluyen el regreso a las condiciones normales de operación Con: - Datos conocidos de aumentos o descensos del volumen de usuarios - Picos y valles de carga de trabajo - Cualquier otro cambio que se pueda producir en el futuro

Interfaces:

Proceso de gestión de contratos: - Vincular la documentación con la gestión de contratos

167

Deberían tener en cuenta: - Dependencias entre componentes de sistemas y servicios - Asignación de la responsabilidad de invocar planes de continuidad - Asignación de responsabilidades sobre objetivos

Mantener la suficiente capacidad del servicio para cumplir los requisitos Garantizar que el personal comprende su rol y tiene acceso a documentos de continuidad del servicio Conservar y mantener todos los documentos y equipos de continuidad del servicio en un lugar seguro

Incluyendo factores externos (cliente y otros proveedores externos de servicios) Con acceso rápido a: - Copias de respaldo de datos, documentos y software - Equipos y personal necesarios para restaurar el servicio en caso de fallo grave

Al menos una copia de todos los documentos, junto con los equipos necesarios para su uso

Figura 4.4.1 Procesos de gestión de la continuidad y disponibilidad del servicio


168


Los procesos de gestión de la disponibilidad y la continuidad del servicio tienen interfaces con los procesos de gestión de cambios y gestión de la configuración. Para garantizar la continuidad del servicio es preciso que sea posible acceder a la CMDB cuando no sea posible el acceso normal de oficina. El proceso de gestión de cambios evalúa el impacto de cualquier cambio sobre el plan de disponibilidad y continuidad del servicio, además de controlar todos los cambios que se introduzcan en la documentación de disponibilidad y continuidad del servicio. Las interfaces entre los procesos de gestión de la disponibilidad y la continuidad del servicio y los procesos de gestión de cambios y gestión de la configuración deberían estar documentadas (Figura 4.4.2).

Guía La gestión de la continuidad de los servicios de TI (ITSCM) forma parte de la gestión de la continuidad del negocio (BCM) y depende de la información que proporciona el proceso BCM. La disponibilidad de los servicios de TI se garantiza combinando medidas de reducción de riesgos, como instalar sistemas fiables con opciones de recuperación (sistemas redundantes y de respaldo). La Figura 4.4.3 muestra las actividades de ITSCM. Para iniciar ITSCM hay que hacer lo siguiente: • Definir la política - Esta política tiene que estar basada en la Política de Continuidad del Negocio y se debería implantar lo antes posible. Es necesario comunicar la política a toda la organización para que todos los afectados sean conscientes de la necesidad de ITSCM. La dirección tiene que demostrar su compromiso. • Definir el alcance y las áreas relevantes - Para seleccionar el planteamiento y los métodos de la evaluación de riesgos y del análisis de impacto en el negocio se utilizan condicionantes de aseguramiento, normas de calidad como la serie ISO 9000, normas de gestión de la seguridad como BS 7799 y principios generales de política de negocio. También se identifica la estructura de gestión apropiada, como responsabilidades asignadas y una estructura de procesos que permita hacer frente a posibles desastres. • Asignar recursos - La creación de un entorno de ITSCM puede exigir una inversión considerable en recursos y personal. También es necesario ofrecer formación para que el personal pueda dar soporte a los requisitos y la estrategia. • Establecer la organización del proyecto - Se recomienda emplear un método formal de gestión de proyectos, como PRINCE2TM, con el apoyo de software de planificación. Antes de analizar los servicios de TI, es aconsejable identificar los motivos por los que la empresa tiene que incluir la gestión de la continuidad de los servicios de TI en su gestión de la continuidad del negocio, así como el impacto potencial de una interrupción grave de los servicios. En algunos casos el negocio puede sobrevivir durante algún tiempo, por lo que lo más importante es restaurar los servicios; en otros, el negocio no puede funcionar sin servicios de TI y debe hacer hincapié en la prevención. La mayor parte de los negocios intentan encontrar un equilibrio entre ambos extremos. Se realiza un análisis de los servicios de TI que son esenciales para el negocio (como sistemas de información, aplicaciones ofimáticas, aplicaciones de contabilidad y correo electrónico) y que deben estar disponibles según los acuerdos de nivel de servicio. En el caso de algunos servicios Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Realizar pruebas de continuidad y registrar los resultados

Registros de pruebas de continuidad

En caso de cambio importante Planes de disponibilidad y continuidad del servicio

Requisitos de SLAs

Registros de disponibilidad

Incorporar los fallos de las pruebas en un plan de acción

Registros de pruebas de continuidad

Plan de acción

Probar o volver a probar los planes de disponibilidad y continuidad del servicio

Planes probados de disponibilidad y continuidad del servicio

Monitorizar y registrar la disponibilidad

Registros de disponibilidad

Identificar, documentar y revisar faltas de conformidad con los requisitos de disponibilidad

169

De acuerdo con las necesidades del negocio

Registros de faltas de conformidad

Investigar faltas de disponibilidad no planificadas

Adoptar las acciones (correctivas) apropiadas

Registros de acciones correctivas

Predecir la disponibilidad futura y posibles problemas

Adoptar acciones preventivas


Revisar los planes de disponibilidad y continuidad del servicio

Figura 4.4.2 Procesos de gestión de la continuidad y disponibilidad del servicio: Proceso de disponibilidad


170


Fase 1 Inicio

Iniciar BCM

Fase 2

Análisis de impacto en el negocio

Requisitos y estrategia

Evaluación de riesgos

Estrategia de continuidad de los servicios de TI Fase 3

Organización y planificación de la implantación

Implantación

Implantar acuerdos de respaldo

Implantar medidas de reducción de riesgos

Desarrollar planes de recuperación

Desarrollar procedimientos Pruebas iniciales

Revisión y auditoría

Pruebas

Gestión de cambios

Educación y concienciación

Formación

Aseguramiento Fase 4 Gestión operativa

Figura 4.4.3 Modelo del proceso de ITSCM (según el modelo BCM de la OGC, actualmente centrado en ITSCM)

que no son esenciales, se puede llegar al acuerdo de proporcionar un servicio de emergencia con capacidad y disponibilidad limitadas. No obstante, los niveles de servicio durante la recuperación ante desastres sólo se pueden modificar de común acuerdo con el cliente. Para servicios críticos se debe buscar un equilibrio entre prevención y opciones de recuperación. A este análisis sigue una evaluación de las dependencias entre servicios y recursos de TI. La información de la gestión de la disponibilidad se utiliza para analizar hasta qué punto los recursos de TI desempeñan una función crítica para el soporte de los servicios de TI discutidos Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


171

anteriormente. La gestión de la capacidad proporciona información sobre la capacidad necesaria. Es preciso determinar la interrupción máxima que pueden sufrir estos servicios, desde la pérdida inicial de servicio hasta su completa restauración. Esta información se usará posteriormente para identificar las opciones de recuperación para cada servicio. Un análisis de riesgos puede ayudar a identificar los riesgos a los que está expuesto un negocio y ofrece a la dirección información muy importante sobre medidas de prevención. Mantener un plan de recuperación ante desastres puede resultar relativamente costoso, por lo que conviene empezar considerando la posibilidad de usar medidas de prevención. Una vez agotadas dichas medidas, hay que determinar si existen todavía riesgos que puedan exigir un plan de contingencia. La Figura 4.4.4 muestra los vínculos entre el análisis de riesgos y la gestión de riesgos; este ejemplo está basado en el Método de Análisis y Gestión de Riesgos de la antigua Agencia Central de Informática y Telecomunicaciones (CCTA), la actual OGC. Activos

Amenazas

Vulnerabilidades

Análisis de riesgos

Riesgos Gestión de ariesgos Contramedidas (prevención y recuperación)

Figura 4.4.4 Modelo de evaluación de riesgos de la CCTA (Fuente: OGC)

El modelo consta de cuatro pasos: • En primer lugar hay que identificar los componentes de TI relevantes (activos), como edificios, sistemas, datos, etc. Para que esta identificación sea eficaz es preciso documentar el propietario y el propósito de cada componente. • El siguiente paso consiste en analizar las amenazas a que están expuestos los activos y sus dependencias, y estimar la probabilidad (alta, media o baja) de que se produzca un desastre. Por ejemplo, un sistema de alimentación eléctrica poco fiable en una zona con muchas tormentas se puede considerar una amenaza. • A continuación hay que identificar y clasificar la vulnerabilidad (alta, media o baja) de los activos. Un pararrayos puede ofrecer cierto grado de protección contra las tormentas eléctricas, pero sigue existiendo la posibilidad de que la red y los sistemas informáticos sufran daños graves. • Finalmente, se evalúan las amenazas y las vulnerabilidades en el contexto de los componentes de TI para obtener una estimación de los niveles de riesgo. Hay que distinguir entre reducción de riesgos (prevención), acciones de recuperación de la actividad del negocio y opciones de recuperación de TI. Se pueden adoptar medidas de prevención


172


en función de los resultados del análisis de riesgos, teniendo siempre en cuenta los costes de las medidas y los niveles de los riesgos que se intenta prevenir. Si existen riesgos que no se pueden evitar con medidas de prevención, es necesario eliminarlos mediante una planificación de la recuperación. Para garantizar la continuidad del negocio hay que contar con las siguientes opciones de recuperación: • Personal y alojamiento - Tratamiento de instalaciones alternativas, mobiliario, transporte y distancias de desplazamiento, así como el personal básico para dar soporte al negocio. • Redes y sistemas de TI - Las opciones de recuperación se discuten más abajo. • Servicios de soporte: Electricidad, agua, teléfono, correo y servicios de mensajería. • Archivos - Ficheros, documentos, sistemas basados en papel y materiales de referencia. • Servicios de terceros - Proveedores de servicios de Internet y correo electrónico, por ejemplo. Existen diversas opciones para la recuperación de servicios de TI: • No hacer nada - Hay pocos negocios que puedan funcionar eficazmente con este planteamiento. Pese a ello, se debe explorar esta opción en todos los servicios para ver si puede resultar aceptable, por ejemplo, como solución a corto plazo. • Regreso a un sistema manual (basado en papel) - Esta opción suele ser inaceptable para servicios que sean críticos para el negocio, ya que no habrá suficiente personal con experiencia en el uso de sistemas tradicionales. Sin embargo, los sistemas basados en papel pueden ser una opción viable para servicios de menor importancia. • Acuerdos recíprocos - Esta opción se puede usar si dos organizaciones tienen hardware similar y acuerdan ofrecerse una a otra sus instalaciones en caso de desastre. Para ello es necesario que los dos negocios alcancen un acuerdo y garanticen la coordinación, de modo que ambos entornos sean intercambiables. La gestión de la capacidad tiene que encargarse de que la capacidad reservada para este fin no se utilice para otras cosas o se pueda liberar rápidamente. Esta opción no resulta tan atractiva en los actuales entornos informáticos distribuidos, donde hay una mayor demanda de sistemas con alta disponibilidad y potencia de procesamiento individual, como cajeros automáticos y banca on-line. • Recuperación gradual (respaldo en frío) - Esta opción puede ser adecuada para negocios que pueden operar durante algún tiempo (72 horas, por ejemplo) sin servicios de TI. Permite disponer de una sala de ordenadores vacía en una instalación fija previamente acordada, o bien de una sala de ordenadores móvil que se traslada hasta la sede del negocio (instalación portátil). La sala de ordenadores cuenta con alimentación eléctrica, aire acondicionado, instalaciones de red y conexiones telefónicas. Esta opción de recuperación se puede contratar a un suministrador externo. Es necesario establecer acuerdos independientes con suministradores para garantizar la rápida entrega de componentes de TI. La ventaja de este método es que las instalaciones están siempre disponibles. Los beneficios y los costes son distintos para instalaciones fijas y portátiles. • Recuperación intermedia (respaldo en templado) - Esta opción permite acceder a un entorno operativo similar, en el que los servicios pueden continuar con normalidad tras un breve período de transición (24-72 horas). Existen tres versiones de esta opción: – Interna (reserva mutua): Esta opción proporciona una recuperación completa con un tiempo de transición mínimo. Las organizaciones con varios sistemas distribuidos suelen optar por esta variante del planteamiento, que consiste en que parte de la capacidad necesaria está reservada en cada sistema. La gestión de la capacidad se encarga de monitorizar esta Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


173

capacidad de reserva (de modo similar a lo que ocurre en la opción de recuperación por acuerdos recíprocos). – Externa: Un servicio comercial ofrecido a distintos clientes por organizaciones externas de recuperación. Los costes se dividen entre los clientes y dependen del hardware y el software necesarios y del período de cesión de las instalaciones (16 semanas, por ejemplo). Los acuerdos suelen cubrir el período necesario para preparar las instalaciones de respaldo en frío. Este método resulta relativamente caro y es probable que las instalaciones se encuentren a cierta distancia. – Móvil: Esta opción proporciona una caravana con toda la infraestructura necesaria lista para su uso. La caravana funciona como sala de ordenadores y dispone de sistemas de control de ambiente, como aire acondicionado. Las conexiones de electricidad, datos y telecomunicaciones tienen que estar situadas en puntos especiales a cierta distancia del edificio. Entre las ventajas que ofrece esta opción figuran los rápidos tiempos de respuesta y la proximidad a la sede del negocio. Esta opción sólo se puede utilizar con un número limitado de plataformas hardware. Algunos de los principales suministradores de hardware ofrecen este servicio con varias caravanas equipadas con configuraciones de hardware estándar. La caravana visita el negocio en los momentos acordados (una vez al año, por ejemplo) para probar los acuerdos de recuperación. • Recuperación inmediata (arranque en caliente, respaldo en caliente) - Esta opción ofrece una recuperación inmediata o muy rápida de los servicios (en menos de 24 horas, por ejemplo). Para conseguirlo se utiliza un entorno de producción idéntico, con replicación de los datos o incluso de los procesos de producción, todo ello en estrecha colaboración con la gestión de la disponibilidad. En la mayor parte de los casos es posible combinar distintas opciones. Por ejemplo, una caravana con un centro informático de operaciones (arranque en caliente móvil) puede ofrecer una solución temporal hasta que se preparen instalaciones portátiles y se reciban los nuevos ordenadores centrales (arranque en frío móvil). La operación normal quedará restaurada cuando se haya vuelto a equipar el edificio y se hayan trasladado a él los nuevos ordenadores centrales. Una vez se ha determinado la estrategia de negocio y se han elegido las opciones necesarias, hay que implantar la ITSCM y desarrollar en detalle los planes para las instalaciones de TI. Es necesario crear una organización para implantar los procesos de ITSCM. Dicha organización puede incluir equipos de gestión (gestor de crisis), coordinación y recuperación para cada servicio. Debe existir un plan general del máximo nivel en el que se contemplen los siguientes aspectos: • Plan de respuesta de emergencia • Plan de evaluación de daños • Plan de recuperación • Plan de registros vitales (qué hacer con los datos, incluyendo registros en papel) • Planes de relaciones públicas y gestión de crisis Todos estos planes se utilizan para evaluar emergencias y responder a ellas. A continuación es posible decidir si se debe iniciar el proceso de recuperación del negocio, en cuyo caso hay que activar los planes del siguiente nivel. Esto incluye: • Plan de servicios y alojamiento • Plan de redes y sistemas informáticos Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

174


• Plan de telecomunicaciones (accesibilidad y enlaces) • Plan de seguridad (integridad de datos y redes) • Plan de personal • Planes administrativos y financieros Junto con la gestión de la disponibilidad, se adoptan medidas de prevención para reducir el impacto de una incidencia. Estas medidas pueden incluir: • Uso de alimentación eléctrica de respaldo y SAIs • Sistemas tolerantes a fallos • Almacenamiento en el exterior y sistemas RAID El arranque también puede incluir acuerdos de respaldo que cubran personal, edificios y telecomunicaciones. Incluso durante el período de contingencia, es posible efectuar un arranque restaurando la situación normal y adquiriendo nuevos componentes de TI. Se pueden cerrar por adelantado acuerdos latentes con los suministradores, de manera que existan pedidos firmados para el suministro de componentes en el momento especificado y al precio acordado. Cuando se produce el desastre, el suministrador puede procesar el pedido sin necesidad de tener que preparar un presupuesto. Estos contratos latentes se tienen que actualizar todos los años para que reflejen los nuevos precios y modelos. En la actualización hay que tener en cuenta las líneas base de gestión de la configuración. Para elaborar acuerdos de respaldo se pueden llevar a cabo las siguientes actividades: • Negociar con terceros el uso de instalaciones de recuperación en el exterior • Mantener y equipar las instalaciones de recuperación • Adquirir e instalar hardware de respaldo (contratos latentes) • Gestionar contratos latentes Los planes de recuperación deben ser detallados y estar sujetos a un control formal de cambios, identificando todos los procedimientos necesarios para su soporte. Se tienen que comunicar a todos aquéllos que participen en los planes o se vean afectados por ellos. En general, un plan de recuperación contempla cambios en la infraestructura y en los niveles de servicio acordados. Por ejemplo, la migración a una nueva plataforma de gama media puede implicar que, en caso de ser necesaria la recuperación, no exista una unidad equivalente en las instalaciones de respaldo para arranque externo en caliente. Por este motivo, la gestión de la configuración desempeña un rol muy importante en la monitorización de las líneas base de configuración especificadas en el plan de recuperación. El plan de recuperación debe incluir todos los elementos relevantes para la restauración de las actividades de negocio y los servicios de TI, como: • Introducción - Describe la estructura del plan y las instalaciones de recuperación previstas. • Actualización - Discute los acuerdos y procedimientos para el mantenimiento del plan y efectúa un seguimiento de cambios en la infraestructura. • Lista de rutas - Si el plan está dividido en secciones, cada una de las cuales especifica las acciones que debe realizar un grupo específico, la lista de rutas indica qué secciones se deben enviar a qué miembros del personal. • Inicio de recuperación - Describe cuándo y en qué condiciones se activa el plan. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


175

• Clasificación de contingencias - Si el plan incluye procedimientos para distintas contingencias, dichos procedimientos tienen que estar descritos aquí en términos de gravedad (baja, media o alta), duración (día, semana o semanas) y daño (pequeño, limitado o grave). • Secciones especializadas - El plan debe estar dividido en secciones basadas en los seis grupos o áreas que cubre el plan. Dichas áreas son: – Administración: Cómo y cuándo se activa el plan, qué miembros de la dirección y el personal participan, y dónde se encuentra el centro de control. – Infraestructura de TI: Elementos de hardware, de software y de telecomunicaciones que debe ofrecer el sistema de recuperación, procedimientos de recuperación y contratos latentes para la adquisición de nuevos componentes de TI. – Personal: Personal necesario en las instalaciones de recuperación y, si las instalaciones están lejos del negocio, servicios de transporte y alojamiento. – Seguridad: Instrucciones de protección contra robos, incendios y explosiones en las sedes central y remota, junto con información sobre instalaciones externas de almacenamiento como cámaras y almacenes. – Centros de recuperación: Información sobre contratos, personal con funciones específicas, seguridad y transporte. – Restauración: Procedimientos para restaurar la situación normal (en el edificio, por ejemplo), condiciones para la activación de dichos procedimientos y contratos latentes. El plan de recuperación proporciona un marco de trabajo para la elaboración de procedimientos de recuperación. Es fundamental que se desarrollen procedimientos eficaces que todo el mundo pueda seguir para participar en la recuperación. Dichos procedimientos deben contemplar: • La instalación y prueba de hardware y componentes de red. • La restauración de aplicaciones, bases de datos y datos. Estos y otros procedimientos relevantes se deben adjuntar al plan de recuperación. Las pruebas iniciales de los planes, procedimientos y componentes técnicos afectados son un aspecto crítico de ITSCM. Las pruebas se deberían realizar en casos bien definidos y con objetivos y criterios de éxito claros. Se tienen que efectuar nuevas pruebas después de cambios importantes y al menos una vez al año. El departamento de TI es responsable de probar la eficacia de los elementos de TI de los planes y procedimientos. Estas pruebas pueden estar anunciadas o no, pero la participación en ellas de miembros apropiados de la dirección del negocio fomentará el entendimiento mutuo y hará que resulte más fácil conseguir el soporte y el compromiso del negocio. Una formación eficaz del personal de TI y otros departamentos, junto con la concienciación de todo el personal y la organización, son esenciales para cualquier proceso de continuidad de los servicios de TI. Es posible que el personal de TI tenga que formar a otros miembros de los equipos de recuperación del negocio para que estén familiarizados con el proceso y puedan proporcionar soporte durante las operaciones de recuperación. La formación y las pruebas deben incluir las instalaciones de contingencia, tanto internas como externas. Los planes se deberían revisar y verificar periódicamente para comprobar que están actualizados. Esto afecta a todos los aspectos de ITSCM. En el área de TI, esta auditoría se debe realizar siempre Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

176


que se produzca un cambio significativo en la infraestructura de TI, como la introducción de nuevos sistemas, redes y proveedores de servicios. También se deben realizar auditorías si hay algún cambio en la estrategia de negocio o en la estrategia de TI. Las organizaciones con cambios rápidos y frecuentes pueden implantar un programa periódico para verificar los conceptos de ITSCM. Todos los cambios de planes y estrategia se deben implantar bajo la dirección de la gestión de cambios, que desempeña un rol muy importante para mantener actualizados todos los planes de ITSCM y para analizar el impacto de cualquier cambio sobre el plan de recuperación. El aseguramiento consiste en la verificación de que el proceso (procedimientos y documentos) y sus entregables tienen la calidad adecuada para satisfacer las necesidades de negocio de la empresa. Los factores críticos de éxito (CSFs) para la gestión de la continuidad de los servicios de TI son: • Un proceso eficaz de gestión de la configuración • El soporte y compromiso de toda la organización • Herramientas eficaces y actualizadas • Formación específica para todos aquéllos que participen en el proceso • Pruebas periódicas del plan de recuperación Los indicadores clave del proceso (KPIs) son: • Número de defectos detectados en los planes de recuperación • Pérdida de ingresos debida a un desastre • Coste del proceso En caso de que se produzca un desastre, se deben preparar informes de gestión sobre su causa y efecto, así como sobre el resultado de la gestión. Cualquier punto débil que se detecte tendrá que ser corregido con planes de mejora. Los informes de gestión del proceso ITSCM incluyen también informes de evaluación de pruebas de planes de recuperación, que se utilizan para aseguramiento. El proceso informa igualmente sobre el número de cambios introducidos en los planes de recuperación como resultado de cambios significativos en otros procesos. Es posible que se elaboren también informes sobre nuevas amenazas. Por lo que se refiere a la gestión de la disponibilidad, se deben duplicar los elementos esenciales siempre que sea posible y usar sistemas de detección y corrección de fallos para conseguir altos niveles de disponibilidad. Es frecuente que, en caso de avería, se activen sistemas automáticos de reserva. Pese a ello, también se deben adoptar medidas organizativas que puede proporcionar la gestión de la disponibilidad. La gestión de la disponibilidad puede comenzar tan pronto como el negocio haya definido claramente sus requisitos de disponibilidad para el servicio. Se trata de un proceso continuo que sólo termina cuando se retira un servicio.



177

Las entradas del proceso de gestión de la disponibilidad (Figura 4.4.5) son: • Requisitos de disponibilidad del negocio. • Evaluación de impacto para todos los procesos de negocio con soporte de TI. • Requisitos de disponibilidad, fiabilidad y capacidad de mantenimiento para los componentes de TI en la infraestructura. • Datos sobre fallos que afecten a servicios o componentes, generalmente en forma de informes y registros de incidencias y problemas. • Datos de monitorización y configuración de servicios y componentes. • Niveles de servicio alcanzados, en comparación con los niveles de servicio acordados para todos los servicios cubiertos por el SLA. Salidas: • Criterios de diseño de disponibilidad y recuperación para servicios de TI nuevos y modificados. • Tecnología necesaria para obtener la capacidad de recuperación necesaria en la infraestructura, con el fin de reducir o eliminar el impacto de componentes defectuosos de la infraestructura. • Garantías de disponibilidad, fiabilidad y capacidad de mantenimiento de los componentes de la infraestructura necesarios para el servicio de TI. • Informes sobre los niveles alcanzados de disponibilidad, fiabilidad y capacidad de mantenimiento. • Requisitos de monitorización de disponibilidad, fiabilidad y capacidad de mantenimiento. • Un plan de disponibilidad para la mejora proactiva de la infraestructura de TI. • Planes de acción y medidas adoptadas como actividades reactivas después de incumplimientos del SLA. Requisitos de disponibilidad del negocio

Criterios de diseño de disponibilidad y recuperación

Evaluación de impacto en el negocio

Evaluación de riesgos y capacidad de recuperación de la infraestructura de TI

Requisitos de disponibilidad, fiabilidad y capacidad de mantenimiento Datos de incidencias y problemas

Gestión de la disponibilidad

Objetivos específicos acordados de disponibilidad, fiabilidad y capacidad de mantenimiento Informes sobre niveles alcanzados de disponibilidad, fiabilidad y capacidad de mantenimiento

Datos de monitorización y configuración

Monitorización de la disponibilidad

Logros de nivel de servicio

Planes de mejora de la disponibilidad Planes de acción Medidas adoptadas después de incumplimientos del SLA

Figura 4.4.5 Entradas y salidas de la gestión de la disponibilidad (Fuente: OGC)


178


La gestión de la disponibilidad incluye una serie de actividades clave de planificación y monitorización: • Planificación: – Determinación de los requisitos de disponibilidad – Diseño para la disponibilidad – Diseño para la capacidad de recuperación – Gestión de aspectos de seguridad – Gestión del mantenimiento – Desarrollo del plan de disponibilidad • Monitorización: – Mediciones e informes Antes de cerrar un SLA hay que determinar los requisitos de disponibilidad, incluyendo tanto nuevos servicios de TI como cambios en los servicios existentes. Es necesario decidir lo antes posible si la organización de TI puede cumplir los requisitos y cómo va a hacerlo. Esta actividad tiene que identificar: • Funciones clave de negocio • Definición acordada de parada de los servicios de TI • Requisitos cuantificables de disponibilidad • Impacto cuantificable de paradas imprevistas en los servicios de TI sobre las funciones de negocio • Horario comercial • Acuerdos sobre ventanas de mantenimiento Definir lo antes posible y con claridad los requisitos de disponibilidad es fundamental para evitar que surjan confusiones y diferencias de interpretación. Los requisitos del cliente se tienen que comparar con lo que se puede ofrecer en la realidad. Si existen diferencias, hay que determinar el correspondiente impacto sobre el coste. Las vulnerabilidades que afecten a los niveles de disponibilidad se deben identificar lo antes posible. De esta forma se evitarán costes excesivos de desarrollo, gastos imprevistos en fases posteriores, Puntos Únicos de Fallo (SPOF), cobros de costes adicionales por los suministradores y retrasos en las entregas. Un buen diseño, basado en niveles de disponibilidad apropiados, permitirá cerrar contratos de mantenimiento eficaces con los suministradores. El proceso de diseño utiliza diversas técnicas, como Análisis de Impacto de Fallos de Componente (CFIA) para identificar SPOFs, Método de Análisis y Gestión de Riesgos de la CCTA (CRAMM) o cualquier otra técnica de gestión de riesgos, así como técnicas de simulación. Si no es posible alcanzar los niveles de disponibilidad acordados, la mejor opción consiste en determinar si se puede mejorar el diseño. El uso de nuevas tecnologías, otros métodos, una estrategia de entrega distinta, un diseño mejor o diferente y herramientas de desarrollo puede facilitar el cumplimiento de los objetivos.



179

Si los requisitos son especialmente exigentes, se puede considerar la posibilidad de usar otra tecnología de tolerancia a fallos, otros procesos (gestión de incidencias, gestión de problemas y gestión de cambios) o recursos adicionales de Gestión del Servicio. Los recursos financieros disponibles determinan en gran medida las posibles opciones. Es muy complicado conseguir una total disponibilidad sin interrupciones, por lo que hay que considerar períodos planificados de falta de disponibilidad. Dichos períodos se pueden usar para iniciar acciones preventivas, como actualizaciones de hardware y software. Estas ventanas permiten también la implantación de cambios. Si se interrumpe un servicio de TI, es importante que la incidencia se resuelva de forma rápida y eficaz para recuperar los niveles acordados de disponibilidad. El diseño para recuperación incluye, por ejemplo, un proceso eficaz de gestión de incidencias con procedimientos apropiados de escalado, comunicación, respaldo y recuperación. La seguridad y la fiabilidad mantienen una relación muy estrecha. Un mal diseño de seguridad de la información puede afectar a la disponibilidad del servicio, mientras que un diseño eficaz de seguridad de la información hace que sea más fácil conseguir una alta disponibilidad. En la fase de planificación hay que tener en cuenta las cuestiones de seguridad y analizar su impacto sobre la provisión de servicios. Algunas de las cuestiones clave de seguridad son las siguientes: • Determinar quién tiene autorización para acceder a áreas seguras. • Determinar cuáles son las autorizaciones críticas que se pueden conceder. Las mediciones y los informes son dos actividades importantes de la gestión de la disponibilidad, puesto que forman la base para verificar acuerdos de servicio, resolver problemas y definir propuestas de mejora. La falta de disponibilidad de los servicios se puede reducir tratando de limitar cada una de las fases del ciclo de vida extendido de la incidencia, como se ve en la Figura 4.4.6: • Detección/registro - El tiempo desde que se produce una incidencia hasta que se detecta. • Diagnóstico - La fase siguiente, que dura hasta que se realiza un diagnóstico. • Reparación - La fase siguiente, necesaria para realizar reparaciones físicas. • Recuperación - El tiempo necesario para que el sistema vuelva a estar operativo. • Restauración - El tiempo necesario para restaurar totalmente el servicio y ponerlo a disposición del cliente. Los servicios se deben recuperar rápidamente si dejan de estar disponibles para los usuarios. El Tiempo Medio de Restauración del Servicio (MTRS) es el tiempo necesario para que una función (servicio, sistema o componente) vuelva a estar operativa después de un fallo. Los análisis de la respuesta MTRS a distintos factores son útiles para mejorar el rendimiento y el diseño de servicios. Es posible reducir el tiempo MTRS gestionando cada uno de sus componentes. Es importante que los informes de disponibilidad estén redactados desde la perspectiva del cliente. Estos informes ofrecen fundamentalmente información sobre la disponibilidad del servicio para funciones esenciales de negocio, servicios de aplicaciones, y la disponibilidad de los Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

180


datos (perspectiva de negocio), en lugar de información sobre la disponibilidad de componentes técnicos de TI. Detectada

Registrada

Diagnosticada

Reparada

Recuperada

Restaurada

INCIDENCIA

Tiempo de detección

INCIDENCIA

Tiempo de registro

Tiempo de diagnóstico

Tiempo de reparación

Tiempo de recuperación

Tiempo de restauración

Tiempo de parada, tiempo de restauración del servicio

Tiempo de disponibilidad, tiempo entre fallos

Factor de capacidad de mantenimiento

Factor de fiabilidad

Tiempo entre incidencias del sistema

Figura 4.4.6 El ciclo de vida extendido de la incidencia

El plan de disponibilidad es uno de los productos más importantes de la gestión de la disponibilidad. No se trata del plan de implantación de la gestión de la disponibilidad, sino de un plan a largo plazo que afecta a la disponibilidad durante un período de varios años. Debe describir la situación actual y posteriormente se puede ampliar para que incluya actividades de mejora de los servicios existentes y directrices, así como planes para nuevos servicios y directrices para mantenimiento. Para que el plan sea preciso y completo es necesario un enlace con áreas como la gestión del nivel de servicio, la gestión de la continuidad de los servicios de TI, la gestión de la capacidad, la gestión financiera y el desarrollo de aplicaciones (directamente o a través de la gestión de cambios). Para que sea eficiente, la gestión de la disponibilidad tiene que usar diversas herramientas para las siguientes actividades: • Determinar el tiempo de parada • Registrar información histórica • Generar informes • Realizar análisis estadísticos • Realizar análisis de impactos La gestión de la disponibilidad utiliza información procedente de los registros de gestión de incidencias, la CMDB y la base de datos de gestión de la capacidad. La información puede estar almacenada en una base de datos de gestión de la disponibilidad (AMDB). Actualmente existe una gran variedad de métodos y técnicas de gestión de la disponibilidad que facilitan la planificación, la mejora y la elaboración de informes. Por ejemplo: • Análisis de Impacto de Fallos de Componente (CFIA) - Utiliza una matriz de disponibilidad con los componentes estratégicos y sus roles en cada servicio. Una CMDB eficaz, que defina las relaciones entre servicios y recursos de producción, puede resultar muy útil para desarrollar esta matriz. La Figura 4.4.7 muestra un ejemplo de matriz CFIA. Los elementos de configuración Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


181

marcados con una “X” son elementos importantes de la infraestructura de TI (análisis horizontal). Los servicios que están frecuentemente marcados con una “X” son complejos y muy sensibles a fallos (análisis vertical). Este método también se puede aplicar a dependencias de suministradores externos (CFIA avanzado). • Análisis del Árbol de Fallos (FTA) - Es una técnica que permite identificar la cadena de sucesos que conducen al fallo de un servicio de TI. Para cada servicio se genera un árbol empleando símbolos booleanos. El árbol se recorre desde abajo hacia arriba. El método FTA distingue entre los siguientes sucesos: – Sucesos básicos: Entradas del diagrama (círculos), como cortes de electricidad y errores de operarios; estos sucesos no se investigan. – Sucesos resultantes: Nodos del diagrama que resultan de una combinación de sucesos anteriores. – Sucesos condicionales: Sucesos que sólo se producen bajo ciertas condiciones, como un fallo del aire acondicionado. – Sucesos disparadores: Sucesos que causan otros sucesos, como un apagado automático iniciado por un SAI. Los sucesos se pueden combinar mediante operaciones lógicas, como: – Operación AND: El suceso resultante se producirá si se producen todas las entradas simultáneamente. – Operación OR: El suceso resultante se producirá si se producen una o más entradas. – Operación XOR: El suceso resultante se producirá si sólo se produce una de las entradas. – Operación de inhibición: El suceso resultante se producirá si no se cumplen las condiciones de la entrada. • Método de Análisis y Gestión de Riesgos de la CCTA (CRAMM) - Describe una forma de identificar contramedidas justificables para proteger la confidencialidad, la integridad y la disponibilidad de la infraestructura de TI. • Cálculos de disponibilidad - Las métricas descritas anteriormente se pueden usar para alcanzar con el cliente acuerdos sobre disponibilidad de servicios. Estos acuerdos se incluyen en el acuerdo de nivel de servicio. El porcentaje de disponibilidad se calcula restando el tiempo de parada real al tiempo de servicio acordado, dividiendo el resultado por el tiempo de servicio acordado y multiplicando por 100. • Análisis de Interrupción de Servicios (SOA) - Es una técnica que permite identificar las causas de fallos para investigar la eficacia de la organización de TI y sus procesos, así como para presentar e implantar propuestas de mejora. Tiene las siguientes características: – Amplio alcance: No se limita a la infraestructura, sino que cubre también procesos, procedimientos y aspectos culturales. – Análisis de problemas desde la perspectiva del cliente. – Implantación conjunta a cargo de representantes del cliente y la organización de TI (equipo SOA). Entre sus ventajas figuran un planteamiento más eficiente, la comunicación directa entre el cliente y el suministrador, y una base más amplia para propuestas de mejora. • Puesto de Observación Técnica (TOP) - Cuando se utiliza el método TOP, un equipo especializado de expertos en TI se concentra en un único aspecto de la disponibilidad. Este método puede ser apropiado cuando las herramientas de rutina no proporcionan suficiente soporte. TOP también permite combinar los conocimientos y experiencias de diseñadores y administradores de sistemas. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

182


El aspecto más importante de este método es que se trata de un planteamiento eficaz, eficiente e informal que da resultados rápidamente. Elemento de Configuración: Ordenador 1 Ordenador 2 Cable 1 Cable 2 Enchufe 1 Enchufe 2 Segmento de Ethernet Router Enlace WAN Router Segmento NIC Servidor Software de sistema Aplicación Base de datos

Servicio A

Servicio B

B

B B B B X X X X X X X A B B B X

B X X X X X X A B B B X

X A B ""

= = = =

Servicio no disponible en caso de fallo Configuración a prueba de fallos A prueba de fallos, con tiempo de transición Ningún impacto

Figura 4.4.7 Matriz CFIA

Servicio interrumpido

¿Fuera de las horas de servicio?

Inhibición

Sistema interrumpido

OR

Red interrumpida Ordenador Aplicación interrumpido interrumpida

Línea normal interrumpida

AND Línea de respaldo interrumpida

Figura 4.4.8 Análisis del Árbol de Fallos (Fuente: OGC)

Los factores críticos de éxito (CSFs) para la gestión de la disponibilidad son: • El negocio debe tener objetivos y requisitos de disponibilidad claramente definidos. • La gestión del nivel de servicio debe estar preparada para formalizar acuerdos. • Ambas partes deben tener las mismas definiciones de disponibilidad y parada. • Tanto el negocio como la organización de TI deben ser conscientes de los beneficios que aporta la gestión de la disponibilidad.



183

Los siguientes indicadores clave del proceso (KPIs) muestran la eficacia y la eficiencia de la gestión de la disponibilidad: • Porcentaje de disponibilidad (tiempo de disponibilidad) de cada servicio o grupo de usuarios • Duración de paradas • Frecuencia de paradas Los informes de disponibilidad para el cliente ya han sido discutidos anteriormente. Las siguientes métricas se pueden utilizar para controlar el proceso: • Tiempos de detección • Tiempos de respuesta • Tiempos de reparación • Tiempos de recuperación • Uso correcto de métodos apropiados (CFIA, CRAMM, SOA) • Grado de implantación del proceso: servicios, SLAs y grupos de clientes cubiertos por SLAs Es posible determinar algunas métricas para cada servicio, equipo o dominio de la infraestructura (entorno de estaciones de trabajo, centro de cálculo y red).

4.4.2 Gestión de la capacidad (6.5) Objetivo: Asegurar que el proveedor del servicio tiene, en todo momento, la capacidad suficiente para cubrir la demanda acordada, actual y futura, de las necesidades del negocio del cliente. Las especificaciones ISO 20000-1 dicen: La gestión de la capacidad debe elaborar y mantener un plan de capacidad. La gestión de la capacidad debe estar dirigida a las necesidades del negocio y debe incluir: a) Los requisitos de capacidad, rendimiento y comportamiento, actuales y previstos. b) La identificación de pía/os, umbrales y costes para las actualizaciones del servicio. c) La evaluación de los efectos sobre la capacidad de actualizaciones anticipadas del servicio, peticiones de cambio, y nuevas tecnologías y técnicas. d) La previsión del impacto de cambios externos, por ejemplo cambios legislativos. e) Los datos y los procesos para poder realizar análisis predictivos. Se deben identificar métodos, procedimientos y técnicas para la monitorización de la capacidad del servicio, el ajuste del comportamiento y de las prestaciones del servicio y la provisión de la adecuada capacidad. El Código de buenas prácticas ISO 20000-2 dice: Los requisitos actuales y esperados del negocio en relación al servicio se deberían conocer en términos de lo que el negocio va a necesitar para dar servicio a sus clientes. Las previsiones de negocio y las estimaciones de carga de trabajo se deberían traducir a requisitos específicos y quedar documentadas. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

184


El resultado de las variaciones en la carga de trabajo o en el entorno debería ser predecible; se deberían recoger y analizar datos actuales e históricos de utilización de componentes y recursos, al nivel adecuado, con el fin de dar soporte al proceso. La gestión de la capacidad debería ser el punto focal de todas las cuestiones de rendimiento y capacidad. El proceso debería ofrecer soporte directo al desarrollo de servicios nuevos y a la modificación de los mismos realizando un dimensionamiento y una modelización de servicios. Se debería generar un plan de capacidad donde se documente el rendimiento real de la infraestructura y los requisitos esperados, con la frecuencia suficiente para tener en cuenta el ritmo de cambios de los servicios y de los volúmenes de servicio, la información de los informes de gestión de cambios y del negocio del cliente. Dicho informe debería elaborarse al menos anualmente. Se deberían documentar las opciones existentes junto con su coste para cumplir con los requisitos del negocio, así como las soluciones recomendadas para conseguir los objetivos de nivel de servicio tal como están definidos en el SLA. Debería existir una buena comprensión de la infraestructura técnica y sus capacidades presentes y las que estén proyectadas. Las principales actividades del proceso de gestión de la capacidad consisten en monitorizar, ajustar y ofrecer capacidad. La Parte 1 de ISO 20000 exige explícitamente métodos, procedimientos y técnicas para ejecutar estas actividades una vez elaborado un plan de capacidad (Figura 4.4.9). El Código de buenas prácticas recomienda algunos procesos y documentos adicionales.

Guía El coste de TI no se debe tanto a las inversiones en capacidad como a su gestión. Por ejemplo, un aumento excesivo de la capacidad de almacenamiento afectará a las operaciones de copia de respaldo en cinta y hará que se tarde más tiempo en encontrar archivos guardados en la red. Una buena gestión de la capacidad permitiría al proveedor de servicios, por ejemplo, detectar que las 18 iniciativas estratégicas de TI para el año en curso harán que se quede obsoleta la actual solución de copias de respaldo. Con esta información, el gestor de la capacidad puede distribuir el coste de la nueva solución de copias de respaldo entre las 18 iniciativas para que se conozca con exactitud el coste de cada una de ellas. Esta forma de actuar es proactiva. Si, por el contrario, no existe gestión de la capacidad, la organización de TI no reaccionará hasta que se haya superado la ventana para copias de respaldo. En este caso el cliente verá a la organización de TI como una fuente de gasto que “no hace más que pedir dinero”, y todo se deberá a que la organización no ha tenido una actitud proactiva al definir las expectativas y asignar costes por adelantado. La gestión de la capacidad consta de tres subprocesos o niveles de análisis de la capacidad: • Gestión de la capacidad del negocio - Su objetivo es comprender las necesidades presentes y futuras del negocio, para lo cual obtiene información del cliente (por ejemplo, de planes estratégicos o de marketing) y realiza análisis de tendencias. Este subproceso es eminentemente proactivo. • Gestión de la capacidad del servicio - Su objetivo es determinar y comprender el uso de servicios de TI, ya que para garantizar que se pueden alcanzar y cumplir los acuerdos de Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Producir y mantener un plan de capacidad

Plan de capacidad

185

Tiene en cuenta las necesidades del negocio e incluye: – Requisitos de rendimiento y capacidad presentes y previstos – Escalas de tiempos, umbrales y costes identificados para actualizaciones de servicios – Evaluación de los efectos de actualizaciones previstas de servicios, solicitudes de cambios, nuevas tecnologías y técnicas sobre la capacidad – Impacto previsto de cambios externos – Datos y procesos que permitan realizar análisis predictivos Documenta: – Rendimiento presente de la infraestructura y requisitos previstos – Opciones para cumplir los requisitos de negocio, indicando su coste Recomienda soluciones para garantizar el cumplimiento de los objetivos específicos del SLA Tiene en cuenta:

– El índice de cambio en los servicios y los volúmenes de servicio

– La información incluida en los informes de gestión de cambios

– El negocio del cliente Identificar métodos, procedimientos y técnicas Traducir predicciones y estimaciones en requisitos

Para monitorizar la capacidad del servicio, ajustar el rendimiento del servicio y ofrecer una capacidad adecuada Requisitos de capacidad

Dimensionar y modelar servicios

Capturar datos de utilización

Datos sobre utilización presentey pasada

Datos sobre utilización presente y pasada

Analizar datos de utilización

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes

Figura 4.4.9 Gestión de la capacidad


186


servicio apropiados es necesario conocer el rendimiento y los picos de carga. Este subproceso tiene fuertes vínculos con la gestión del nivel de servicio en lo que se refiere a la definición y negociación de acuerdos de servicio. • Gestión de la capacidad de los recursos - Su objetivo es determinar y comprender el uso de los componentes y la infraestructura de TI. Los recursos incluyen, por ejemplo, el ancho de banda de red, la capacidad de procesamiento o la capacidad de disco. Es necesario detectar problemas potenciales lo antes posible para poder gestionar estos recursos de manera eficaz. La organización también se tiene que mantener informada de los avances técnicos. La monitorización activa de tendencias es otra actividad de este subproceso. La Figura 4.4.10 ilustra algunas de las actividades esenciales en esta área.

Ajuste

Implantación (mediante gestión de cambios)

Análisis

Monitorización

Informes de excepciones de SLM

Umbrales de SLM

Informes de excepciones de utilización de recursos

CDB

Umbrales de utilización de recursos

Figura 4.4.10 Actividades iterativas de la gestión de la capacidad (Fuente: OGC)

El plan de capacidad describe los requisitos de capacidad presentes y futuros de la infraestructura de TI, así como los cambios previstos en la demanda de servicios de TI, sustitución de componentes obsoletos y avances técnicos. El plan de capacidad define también los cambios necesarios para poder ofrecer los niveles de servicio acordados en los SLAs a un coste razonable, junto con los requisitos futuros de nivel de servicio. Debe incluir: • Expectativas de rendimiento • Puntos de actualización • Coste previsto de las actualizaciones de infraestructura (coste de capital, recurrente, operativo y de personal) Estas cifras se deben actualizar periódicamente en entornos dinámicos.



187

Hasta cierto punto, el plan de capacidad es la salida más importante de la gestión de la capacidad. Las salidas incluyen con frecuencia un plan anual que está sincronizado con el presupuesto o los planes financieros, así como planes trimestrales con detalles de los cambios previstos de capacidad. Todo ello da como resultado un conjunto coherente de planes en el que el nivel de detalle aumenta a medida que se aproxima el horizonte de planificación. El modelado es una potente herramienta de gestión de la capacidad que se emplea para prever el comportamiento de la infraestructura. Las herramientas existentes para gestión de la capacidad van desde herramientas de medición y estimación hasta completas herramientas para pruebas y prototipos. Las primeras son baratas y se suelen usar en actividades de rutina, mientras que las últimas sólo se utilizan normalmente en proyectos de implantación a gran escala. Entre ambos extremos se encuentran diversas técnicas que son más precisas que una estimación y más baratas que un modelo piloto completo. Entre estas herramientas figuran, por orden creciente de coste, las siguientes: • Norma general • Proyección lineal (análisis de tendencias) • Modelado analítico • Simulación • Evaluación de líneas de referencia (evaluación comparativa) (la más precisa) • Sistema real El dimensionamiento de aplicaciones se centra en los recursos necesarios para la operación de servicios nuevos o modificados (como servicios en desarrollo o en fase de mantenimiento), o bien en los servicios que puede ser necesario adquirir si lo solicita el cliente. Estas predicciones incluyen información sobre los niveles de rendimiento previstos, los recursos necesarios y su coste. Esta disciplina es especialmente importante durante las primeras fases de desarrollo del producto y en puntos clave de proyectos de desarrollo. Para la dirección es muy importante disponer de información clara sobre el hardware necesario, así como sobre otros recursos de TI y los costes previstos en esta fase. También facilita la redacción de SLAs o requisitos de nivel de servicio nuevos o modificados. El dimensionamiento de aplicaciones puede exigir un esfuerzo considerable en entornos grandes o complejos. En primer lugar, la gestión de la capacidad acuerda con los desarrolladores los requisitos de nivel de servicio que deberá satisfacer el servicio. Una vez el servicio ha llegado a la fase de entrega y aceptación, se compara su rendimiento con los objetivos específicos de nivel de servicio para garantizar que se pueden cumplir sin problemas. Una de las salidas del dimensionamiento de aplicaciones es el efecto de variaciones de la carga de trabajo. Esta información se puede usar para predecir cuál será la capacidad necesaria si, por ejemplo, el número de usuarios aumenta un 25%. Otra característica de la carga de trabajo es la evolución de los requisitos de capacidad con el tiempo (picos por día/semana/año y crecimiento futuro).


188


El objetivo de la monitorización de componentes de la infraestructura es garantizar el cumplimiento de los niveles de servicio acordados. Entre los recursos que hay que monitorizar figuran, por ejemplo, el uso de CPUs, el uso de discos, el uso de la red y el número de licencias. Los datos de la monitorización se tienen que analizar. Un análisis de tendencias permite predecir el crecimiento futuro y detectar posibles “cuellos de botella”, lo que puede llevar a iniciar proyectos de aumento de la eficiencia o a la adquisición de nuevos componentes de TI. Para analizar actividades es preciso tener un conocimiento completo de la infraestructura en su conjunto, de los procesos de negocio y de las relaciones entre los elementos de gestión de la capacidad del negocio, el servicio y los recursos. El ajuste optimiza sistemas para la carga de trabajo real o prevista, a partir de datos de monitorización debidamente interpretados y analizados. El objetivo de la implantación es introducir capacidad nueva o modificada. Si para ello se necesita un cambio, la implantación incluye también el proceso de gestión de cambios. El objetivo de la gestión de la demanda es influir en la demanda de capacidad. Por ejemplo, si un usuario ejecuta durante el día un informe de SQL mal escrito (bloqueando la base de datos y generando una cantidad desmesurada de tráfico en la red), el gestor de la capacidad puede recomendar la creación de un trabajo para ejecutar el informe durante la noche, de manera que el usuario lo tenga sobre su mesa por la mañana. La gestión de la demanda proporciona información importante para la elaboración, monitorización y posible ajuste del plan de capacidad y los SLAs. La gestión de la demanda también puede incluir el uso de cobro diferencial para influir en el comportamiento de clientes y usuarios, controlando la demanda en períodos de mucho uso. La creación y población de la base de datos de gestión de la capacidad (CDB) consiste en recopilar y actualizar información técnica, información de negocio y cualquier otra información que pueda ser relevante para la gestión de la capacidad. Es posible que no se pueda almacenar toda la información de capacidad en una sola base de datos física. Cada administrador de redes o sistemas informáticos puede elegir el planteamiento que considere más conveniente. En muchos casos, la CDB es en realidad un conjunto de bases de datos que contienen toda la información necesaria sobre capacidad (Figura 4.4.11). La calidad del proceso de gestión de la capacidad depende de los siguientes factores críticos de éxito: • Previsiones y expectativas de negocio precisas • Comprensión de la estrategia de TI y precisión de su planificación • Conocimiento de tecnologías presentes y futuras • Cooperación con otros procesos • Capacidad para demostrar un buen control de costes



Previsiones de negocio

Datos de servicios

Datos técnicos

189

Datos financieros

Datos de utilización

CDB

Informes de gestión

Planes de capacidad

Informes atécnicos

Figura 4.4.11 Fuentes de información para la CDB

El éxito de la gestión de la capacidad viene determinado por los siguientes indicadores clave del rendimiento: • Predictibilidad de la demanda del cliente - Identificación de tendencias y evolución de la carga de trabajo con el tiempo, y precisión del plan de capacidad. • Tecnología - Opciones para medir el rendimiento de todos los servicios de TI, el ritmo de implantación de nuevas tecnologías y la capacidad para cumplir en todo momento los acuerdos fijados en SLAs, aunque se utilicen tecnologías antiguas. • Coste - Reducción del número de compras precipitadas, reducción de la sobrecapacidad costosa o innecesaria, y elaboración temprana de planes de inversión. • Operaciones - Reducción del número de incidencias debidas a problemas de capacidad o rendimiento, capacidad para satisfacer en todo momento la demanda del cliente, y grado de importancia que se concede al proceso de gestión de la capacidad. Los informes de gestión proporcionados por el proceso de gestión de la capacidad incluyen, por una parte, información de control de procesos en términos de: • Características del plan de capacidad • Recursos utilizados para implantar el proceso • Progreso de las actividades de mejora Por otra parte, incluyen también informes de excepciones sobre aspectos tales como: Discrepancias entre la capacidad real y planificada • Tendencias en las discrepancias • Impacto sobre los niveles de servicio • Aumento/descenso esperado de los niveles de capacidad y uso a corto y largo plazo • Umbrales que, en caso de alcanzarse, pueden requerir la adquisición de capacidad adicional Estos informes de gestión de la planificación y el rendimiento de la capacidad tienen que estar a disposición de todas las partes interesadas (negocio, aplicación y organización de TI). Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

190


4.4.3 Gestión de la seguridad de la información (6.6) Objetivo: Gestionar la seguridad de la información de manera eficaz para todas las actividades del servicio. Las especificaciones ISO 20000-1 dicen: NOTA: ISO/IEC 17799 Tecnologías de la Información. Código de prácticas para la gestión de la seguridad de la información, proporciona una guía para la gestión de la seguridad de la información. La dirección, con la autoridad apropiada, debe aprobar una política de seguridad de la información, que debe comunicarse a todo el personal implicado y, cuando sea adecuado, a los clientes. Unos controles adecuados de seguridad deben ayudar a: a) Implantar los requisitos de la política de seguridad de la información. b) Gestionar los riesgos asociados al acceso al servicio o a los sistemas. Los controles de seguridad deben estar documentados. La documentación debe describir los riesgos a los que están asociados los controles, la manera de utilizarlos y el mantenimiento de los mismos. El impacto de los cambios sobre los controles se debe evaluar antes de que los cambios sean implementados. Los servicios que impliquen el acceso de organizaciones externas a los sistemas de información y a los servicios, deben estar basados en un acuerdo formal que defina todos los requisitos de seguridad necesarios. Las incidencias de seguridad se deben comunicar y registrar tan pronto como sea posible de acuerdo a los procedimientos de gestión de incidencias.Se deben poner en marcha procedimientos para asegurar que todas las incidencias de seguridad son investigadas, y que se toman medidas al respecto. Se deben poner en marcha mecanismos para poder cuantificar y monitorizar los tipos, volúmenes e impacto de las incidencias y el mal funcionamiento de la seguridad. Las acciones de mejora identificadas durante este proceso se deben registrar y servir como información de entrada al plan de mejora del servicio. El Código de buenas prácticas ISO 20000-2 dice: Generalidades La seguridad de la información es el resultado de un sistema de políticas y procedimientos diseñados para identificar, controlar y proteger la información y cualquier equipamiento empleado junto con el almacenamiento, transmisión y procesamiento de dicha información. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


191

El personal del proveedor del servicio con roles de especialista en seguridad de la información debería estar familiarizado con la Norma ISO/IEC 17799. Tecnologías de la información. Técnicas de seguridad. Código de prácticas para la gestión de la seguridad de la información. Identificación y clasificación de los activos de información El proveedor del servicio debería: a) Mantener un inventario de los activos de información (por ejemplo, ordenadores, sistemas de comunicación, documentos y otra información) que son necesarios para la provisión del servicio. b) Clasificar cada activo de acuerdo con su criticidad para el servicio y el nivel de protección que éste requiera, así como nombrar a un propietario que sea el responsable de proporcionar dicha protección. c) La responsabilidad para la protección de los activos debería recaer en el propietario de dichos activos, aunque estos pueden delegar las responsabilidades de la gestión diaria de la seguridad. Prácticas para la evaluación de los riesgos de seguridad La evaluación de los riesgos de seguridad debería: a) Ser realizada con una periodicidad acordada. b) Ser registrada. c) Ser mantenida durante los cambios (cambios de las necesidades del negocio, de procesos o de configuraciones). d) Ayudar a entender en qué podría impactar uno de los servicios gestionados. e) Proveer de información para las decisiones referentes a los tipos de controles a establecer. Riesgos para los activos de información Los riesgos para los activos de información se deberían evaluar en función de: a) Su naturaleza (por ejemplo: funcionamiento defectuoso del software, errores de operación, fallos de comunicación). b) Probabilidad. c) Impacto potencial para el negocio. d) Experiencias pasadas. Seguridad y disponibilidad de la información Al evaluar los riesgos, se debería prestar atención a los siguientes puntos: a) Revelación de información sensible a partes no autorizadas. b) Información inexacta, incompleta o inválida (por ejemplo: información fraudulenta). c) Información que quede inservible para su uso (por ejemplo: debido a un corte de energía eléctrica). d) Daño físico o destrucción de los equipos necesarios para proveer los servicios. También se deberían tener en cuenta los objetivos de la política de seguridad de la información, las necesidades para satisfacer los requisitos específicos de los clientes respecto a la seguridad (por ejemplo: niveles de disponibilidad) y los requisitos legales o regulatorios que apliquen.


192


Controles Además de otros controles que puedan ser justificables y aconsejados en esta parte de la Norma ISO/ IEC 20000 (por ejemplo: en la continuidad del servicio), los proveedores del servicio deberían aplicar los siguientes controles como una buena práctica en gestión de la seguridad de la información: a) La alta dirección debería definir la política de seguridad de la información, comunicarla a su personal y a sus clientes y asegurarse de que se implanta eficazmente. b) Los roles y las responsabilidades para la gestión de la seguridad de la información se deberían definir y asignar a un puesto de trabajo. c) Un representante del equipo de dirección (el rol puede ser desempeñado por un propietario que sea un responsable sénior) debería supervisar y mantener la eficacia de la Política de Seguridad de la Información. d) El personal que ejerza un rol significativo en seguridad debería recibir formación en seguridad de la información. e) Todo el personal debe ser concienciado acerca de la política de seguridad de la información. f ) Debería haber apoyo de expertos en la evaluación de riesgos y en la implantación de los controles. g) Los cambios no deberían comprometer la operación efectiva de los controles. h) Se debería hacer un informe de las incidencias de seguridad de la información siguiendo los procedimientos de gestión de incidencias y, también, se debería iniciar una respuesta a dichas incidencias. Documentos y registros Los registros se deberían analizar periódicamente para proporcionar información a la dirección en cuanto a: a) Eficacia de la política de seguridad de la información. b) Las tendencias que aparezcan en las incidencias de seguridad de la información. c) Dar entrada de información a un plan de mejora del servicio. d) Tener bajo control el acceso a la información, los activos y los sistemas. La gestión de la seguridad de la información debería estar documentada de una manera fiable. El Código de buenas prácticas para la gestión de la seguridad de la información ISO/IEC 17799 ofrece una guía sobre el proceso en la Subsección 6.6 de la norma para la provisión de servicios de TI de calidad. Como consecuencia, la Parte 2 de ISO 20000 especifica que el personal del proveedor de servicios con roles especializados en la seguridad de la información debe estar familiarizado con ISO/IEC 17799. ISO 20000 requiere explícitamente una política de seguridad de la información, así como controles de seguridad documentados, registros de incidencias de seguridad y registros de acciones de mejora. Los procedimientos que se exigen explícitamente para la gestión de la seguridad de la información son procedimientos para investigar incidencias de seguridad y emprender las acciones pertinentes (Figuras 4.4.12 y 4.4.13). La gestión de la seguridad de la información tiene interfaces con los procesos de gestión de cambios, gestión de incidencias, gestión de la configuración y mejora continua.



Documentar el ISMS

ISMS

Definir la política de seguridad de la información

Política de seguridad de la información

193

Roles y responsabilidades asignados

Definir y asignar roles y responsabilidades

Designar al propietario responsable de proteger los activos de información Aprobar la política de seguridad de la información


Comunicar la política al personal afectado y a los clientes Llegar a un acuerdo sobre el acceso de organizaciones externas

Requisitos de seguridad en SLA


Documentar controles de seguridad

Acuerdos sobre acceso externo

Controles de seguridad

Incluyen: – Implantación de los requisitos de la política de seguridad de la información – Gestión de los riesgos asociados con el acceso al servicio o a los sistemas Describen:

– Los riesgos asociados a los Interfaces: Mejora continua (Actuar):

– Sugerir mejoras para SIP – Proporcionar información de gestión sobre tendencias en incidencias de

controles

– La forma de operación y mantenimiento de los controles

seguridad de la información

Gestión de la configuración: – Identificar y clasificar activos de información – Mantener un inventario de activos de información Gestión de cambios:

– Valorar el impacto de los cambios sobre los controles de seguridad antes de implantar los cambios

– Realizar evaluaciones de riesgos para la seguridad durante la introducción de cambios

– Evitar que los cambios reduzcan la eficacia de los controles – Emitir solicitudes de cambio Informes del servicio:

– Recibir información Presupuestos y contabilidad:

– Presupuesto y contabilidad de todos los componentes Proceso de gestión de incidencias:

– Comunicar y registrar incidencias de seguridad según el procedimiento de gestión de incidencias

– Investigar y gestionar todas las incidencias de seguridad – Monitorizar y cuantificar el tipo, volumen e impacto de las incidencias de seguridad Gestión de problemas: – Intercambiar información de gestión sobre tendencias en incidencias de seguridad de la información – Debería investigar las incidencias de seguridad

Figura 4.4.12 Gestión de la seguridad de la información


194


Concienciar al personal e implantar eficazmente la política de seguridad de la información

Formar al personal con roles de seguridad significativos

El personal de seguridad debe estar familiarizado con ISO/IEC 17799

Adquirir conocimientos de ISO/IEC 17799

Mantener un inventario de activos de información

Clasificar activos por su importancia y nivel de protección

A intervalos acordados

Efectuar una evaluación de riesgos de seguridad

Registros de evaluación de riesgos de seguridad

Maintain risk assessment (during changes)

Incluyen el impacto sobre servicios gestionados Los riesgos para activos de información se tienen que evaluar en función de: – Su naturaleza – Su probabilidad – El impacto potencial sobre el negocio – La experiencia previa Con especial atención a: – Divulgación de información a personas no autorizadas – Información inexacta, incompleta o no válida – Información que no se pueda utilizar – Daños físicos de los equipos necesarios Teniendo en cuenta: – Objetivos de la política – Cumplimiento de los requisitos de los clientes – Aplicación de normativas y requisitos legales Debe ser posible recurrir a ayuda experta

Analizar registros para informar a la dirección


Monitorizar y mantener la eficacia de la política de seguridad de la información

Acerca de: – Eficacia de la política de seguridad de la información – Tendencias detectadas en incidencias de seguridad de la información – Entrada para un plan de mejora del servicio – Control sobre el acceso a información, activos y sistemas

Figura 4.4.13 Gestión de la seguridad de la información (cont.)



195

Guía Las organizaciones y sus sistemas de información no dejan de cambiar, lo que obliga a revisar continuamente las actividades de gestión de la seguridad para garantizar su eficacia. La gestión de la seguridad es un ciclo infinito con fases sucesivas de Planificar, Hacer, Verificar y Actuar, como muestra la Figura 4.4.14. El cliente define los requisitos de negocio

Capítulo de seguridad/Acuerdo de Nivel de Servicio

Informes

Acuerdo entre cliente y proveedor

Según SLA

El proveedor de servicios de TI implanta los requisitos de seguridad del SLA PLANIFICAR:

MANTENER:

Acuerdos de Nivel de Servicio Contratos de Soporte Acuerdos de Nivel Operativo Políticas internas

Aprendizaje Mejora Planificación Implantación CONTROLAR:

¡Organizar! Creación del marco de gestión Asignación de responsabilidades EVALUAR: Auditorías internas Auditorías externas Autoevaluaciones Incidencias de seguridad

IMPLANTAR: Aumento de la concienciación Clasificación y gestión de recursos Seguridad del personal Seguridad física Gestión de la seguridad de hardware, redes, aplicaciones, etc. Control de accesos Resolución de incidencias de seguridad

Figura 4.4.14 El proceso de gestión de la seguridad (Fuente: OGC)

Los requisitos del cliente aparecen en la parte superior derecha como entradas del proceso. La sección sobre seguridad del acuerdo de nivel de servicio (SLA) define estos requisitos en términos de los servicios de seguridad y del nivel de seguridad exigido. El proveedor de servicios comunica estos acuerdos a la organización mediante un plan de seguridad que define normas de seguridad o acuerdos de nivel operativo. Posteriormente se implanta este plan, se evalúa la implantación y se procede a actualizar el plan y su implantación. La gestión del nivel de servicio informa al cliente sobre estas actividades. De esta forma, el cliente y el proveedor de servicios forman un proceso cíclico completo: el cliente puede modificar los requisitos en función de los informes, mientras que el proveedor de servicios puede ajustar el plan o su implementación según estas observaciones o bien tratar de modificar los acuerdos definidos en el SLA.


196


La actividad de control que aparece en el centro de la Figura 4.4.14 es el primer subproceso de la gestión de la seguridad y está relacionada con la organización y la gestión del proceso. Esto incluye el marco de gestión de la seguridad de la información, que describe los subprocesos: • Definición de planes de seguridad • Implantación de planes de seguridad • Evaluación de los planes de seguridad implantados • Incorporación de la evaluación a los planes anuales de seguridad (planes de acción) También se tienen en cuenta los informes proporcionados al cliente a través de la gestión del nivel de servicio. Esta actividad define los subprocesos, las funciones de seguridad y los roles y responsabilidades. También describe la estructura organizativa, los acuerdos de presentación de informes y la línea de control (quién enseña a quién, quién hace qué, cómo se informa de la implantación). Las siguientes medidas descritas en el Código de buenas prácticas de ISO/IEC 17799 se implantan con esta actividad: • Política – Desarrollo e implantación de políticas, conexiones con otras políticas – Objetivos, principios generales y significación – Descripción de los subprocesos – Asignación de funciones y responsabilidades para subprocesos – Conexiones con otros procesos de ISO 20000 y con su gestión – Responsabilidad general del personal – Tratamiento de incidencias de seguridad • Organización de la seguridad de la información – Marco de gestión – Estructura de gestión (estructura organizativa) – Asignación más detallada de responsabilidades – Creación de un comité de vigilancia de la seguridad de la información – Coordinación de la seguridad de la información – Determinación de herramientas (para análisis de riesgos y concienciación, por ejemplo) – Descripción del proceso de autorización para instalaciones de TI (previa consulta al cliente) – Asesoría especializada – Cooperación entre organizaciones, comunicaciones internas y externas – Auditoría independiente de sistemas de información – Principios de seguridad para acceso de terceros – Seguridad de la información en contratos con terceros El subproceso de planificación incluye la definición de la sección sobre seguridad en el SLA en colaboración con la gestión del nivel de servicio, así como las actividades relacionadas con la seguridad en los contratos de soporte. Los objetivos definidos en términos generales en el SLA se detallan ahora para especificarlos en forma de un acuerdo de nivel operativo. Este OLA se puede considerar como el plan de seguridad para una unidad organizativa del proveedor de servicios o como un plan de seguridad específico (por ejemplo, para cada plataforma de TI, aplicación y red). El subproceso de planificación también recibe información procedente de los principios de la política del proveedor de servicios (del subproceso de control), como “cada usuario debe tener Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


197

una identificación exclusiva” o “todos los usuarios recibirán en todo momento un nivel básico de seguridad”. Los acuerdos de nivel operativo para seguridad de la información (planes de seguridad específicos) se elaboran e implantan siguiendo los procedimientos normales. Esto significa que las actividades que se deban ejecutar en otros procesos se tendrán que coordinar con esos procesos. La gestión de cambios utiliza información procedente de la gestión de la seguridad para introducir los cambios necesarios en la infraestructura de TI. El subproceso de planificación se discute con la gestión del nivel de servicio para definir, actualizar y cumplir la sección sobre seguridad en el SLA. El SLA tiene que definir los requisitos de seguridad, utilizando términos medibles siempre que sea posible. La sección sobre seguridad en el acuerdo debe garantizar que se puede verificar el cumplimiento de todas las normas y los requisitos del cliente sobre seguridad. El objetivo del subproceso de implantación es implantar todas las medidas especificadas en los planes. Para facilitar este subproceso se puede utilizar la siguiente lista de comprobación. • Clasificación y gestión de recursos de TI – Información para el mantenimiento de los CIs en la CMDB – Clasificación de los recursos de TI según las directrices acordadas • Seguridad del personal – Tareas y responsabilidades en descripciones de puestos de trabajo – Filtrado – Acuerdos de confidencialidad para el personal – Formación – Directrices para el personal sobre tratamiento de incidencias y puntos débiles detectados en la seguridad – Medidas disciplinarias – Concienciación sobre seguridad • Gestión de la seguridad – Implantación de responsabilidades y separación de puestos de trabajo – Instrucciones de operación por escrito – Normas internas – La seguridad debe cubrir todo el ciclo de vida; tiene que haber directrices de seguridad para desarrollo de sistemas, pruebas, aceptación, operaciones, mantenimiento y retirada – Separación de los entornos de desarrollo y pruebas del entorno de producción – Procedimientos para el tratamiento de incidencias (por la gestión de incidencias) – Implantación de instalaciones de recuperación – Información para gestión de cambios – Implantación de medidas de protección contra virus – Implantación de medidas de gestión para ordenadores, aplicaciones, redes y servicios de red – Tratamiento y seguridad de soportes de datos • Control de accesos – Implantación de la política de accesos y control de accesos – Mantenimiento de los privilegios de acceso de usuarios y aplicaciones a redes, servicios de red, ordenadores y aplicaciones – Mantenimiento de barreras de seguridad en redes (firewalls, servicios de conexión telefónica, puentes y routers) Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

198


– Implantación de medidas para la identificación y autenticación de sistemas informáticos, estaciones de trabajo y ordenadores personales en la red Se necesita una evaluación independiente para valorar el rendimiento, así como para clientes y terceros. Los resultados pueden servir para actualizar e implantar las medidas acordadas con los clientes. La evaluación puede llevar a la adopción de cambios, en cuyo caso hay que definir y presentar una RFC para el proceso de gestión de cambios. Existen tres formas de evaluación: • Autoevaluaciones - Implantadas fundamentalmente por la organización de línea de los procesos. • Auditorías internas - Realizadas por auditores internos de TI. • Auditorías externas - Realizadas por auditores externos de TI. A diferencia de lo que ocurre en las autoevaluaciones, las auditorías no pueden ser realizadas por el mismo personal que participa en los otros subprocesos. De esta forma se garantiza la separación de responsabilidades. Un departamento interno de auditoría se puede encargar de realizar las auditorías. Las evaluaciones también pueden tener lugar en respuesta a incidencias de seguridad. Las actividades principales son: • Verificar la conformidad con la política de seguridad y la implantación de los planes de seguridad. • Realizar auditorías de seguridad en sistemas de TI. • Identificar el uso inadecuado de recursos de TI y actuar en consecuencia. • Encargarse de los aspectos de seguridad de otras auditorías de TI. La seguridad requiere mantenimiento, ya que los riesgos pueden variar debido a cambios en la infraestructura de TI, la organización y los procesos de negocio. El mantenimiento de seguridad incluye el mantenimiento de la sección sobre seguridad en el SLA, así como el mantenimiento de los planes detallados de seguridad (acuerdos de nivel operativo). El mantenimiento se efectúa en función de los resultados del subproceso de evaluación y de una valoración de los cambios en los riesgos. Estas propuestas se pueden introducir en el subproceso de planificación o bien en el mantenimiento del SLA en su conjunto. El resultado en ambos casos puede ser la inclusión de actividades en el plan anual de seguridad. Todos los cambios están sometidos al proceso normal de gestión de cambios. Los informes no son un subproceso, sino una salida de los otros subprocesos. Se elaboran para proporcionar información acerca del rendimiento conseguido en materia de seguridad y para informar a los clientes sobre asuntos de seguridad. La presentación de estos informes suele ser uno de los requisitos del acuerdo con el cliente.



199

Los siguientes son algunos ejemplos de informes programados y de los sucesos que pueden incluir: • El subproceso de planificación – Informa sobre el grado de conformidad con el SLA y los KPIs acordados para seguridad. – Informa sobre los contratos de soporte y cualquier problema asociado con ellos. – Informa sobre acuerdos de nivel operativo (planes de seguridad internos) y los principios de seguridad del propio proveedor (en la línea base, por ejemplo). – Informa sobre planes anuales de seguridad y planes de acción. • El subproceso de implantación – Informa sobre el estado de implantación del proceso de seguridad de la información. – Presenta una lista de incidencias de seguridad y de respuestas a esas incidencias, incluyendo opcionalmente una comparación con el período del informe anterior. – Identifica tendencias en incidencias. – Informa sobre el estado del programa de concienciación. • El subproceso de evaluación – Informa sobre el rendimiento de los subprocesos. – Informa sobre el resultado de auditorías, revisiones y evaluaciones internas. – Informa sobre avisos e identificación de nuevas amenazas. Para informar sobre incidencias de seguridad definidas en el SLA, el proveedor de servicios debe tener un canal directo de comunicación con un representante del cliente (el responsable de seguridad de la información corporativa, por ejemplo) a través del gestor de nivel de servicio, el gestor de incidencias o el gestor de seguridad. También se tiene que definir un procedimiento de comunicación en circunstancias especiales. Salvo en circunstancias especiales, los informes se transmiten a través de la gestión del nivel de servicio. Los factores críticos de éxito son: • Participación del usuario en el desarrollo del proceso. • Responsabilidades claras y separadas. Los indicadores del rendimiento de la gestión de la seguridad son los mismos que los que se discutieron en la Sección 4.3.1 para la gestión del nivel de servicio, ya que se refieren a los asuntos de seguridad cubiertos por el SLA.

4.5 Soporte de servicios de TI Las especificaciones ISO 20000-1 dicen: La gestión de incidencias y la gestión de problemas son procesos separados, aunque ambos están fuertemente relacionados.


200


El Código de buenas prácticas ISO 20000-2 dice: Establecimiento de prioridades Los objetivos para la resolución deberían estar basados en la prioridad. La prioridad se debería basar en el impacto y la urgencia. El impacto se debería basar en el nivel de daño real o potencial al negocio del cliente. La urgencia se debería basar en el tiempo entre la detección del problema o del incidente y el momento en que se produce el impacto sobre el negocio del cliente. La planificación de la resolución de incidencias o problemas debería tener en cuenta, como mínimo, lo siguiente: a) La prioridad. b) Las habilidades disponibles. c) Los requisitos de competencia para los recursos. d) El esfuerzo/coste necesario para proporcionar el método de resolución. e) El tiempo transcurrido para proporcionar un método de resolución. NOTA: La prioridad se utiliza durante toda la Gestión del Servicio pero es fundamental para la gestión de incidencias y de problemas. Soluciones provisionales Siempre que sea necesario, la gestión de problemas debería desarrollar y mantener soluciones provisionales para permitir a la gestión de incidencias ayudar a los usuarios o al personal a restablecer el servicio. Un error conocido sólo se debería cerrar cuando se haya aplicado satisfactoriamente un cambio correctivo o el error deje de existir (por ejemplo, porque el servicio ya no se utilice). La gestión de problemas debería tener acceso a la información sobre las áreas de negocio afectadas por los problemas. Se debería almacenar y mantener en la base de datos de conocimiento, la información sobre las soluciones provisionales, su aplicabilidad y su efectividad. Las prioridades de la gestión de incidencias y problemas dependen del impacto y la urgencia de un problema o una incidencia. El impacto depende de la escala del daño. La urgencia por resolver el problema o la incidencia depende del tiempo que transcurre desde la detección hasta el momento en que el negocio del cliente recibe el impacto. Tanto la gestión de incidencias como la gestión de problemas tienen que estar programadas en función de la prioridad y de otros factores objetivos de negocio que se mencionan en el Código de buenas prácticas.



201

4.5.1 Procesos de resolución: Gestión de incidencias (8.2) Objetivo: Restaurar el servicio acordado con el negocio tan pronto como sea posible o responder a peticiones de servicio. Las especificaciones ISO 20000-1 dicen: Se deben registrar todas las incidencias. Se deben adoptar procedimientos para gestionar el impacto de las incidencias. Los procedimientos deben definir el registro, la priorización, el impacto en el negocio, la clasificación, la actualización, el escalado, la resolución y el cierre formal de todas las incidencias. Se debe mantener informado al cliente del progreso de la incidencia sobre la que haya informado o de su petición de servicio, y se le debe advertir por adelantado sobre si sus niveles de servicio no se pueden conseguir, acordando con él las acciones a tomar. Todo el personal implicado en la gestión de incidencias debe tener acceso a información relevante como, por ejemplo errores conocidos, resoluciones de problemas y la base de datos de gestión de la configuración. Los incidentes graves se deben clasificar y gestionar de acuerdo con un proceso. El Código de buenas prácticas ISO 20000-2 dice: Generalidades NOTA 1: El proceso de gestión de incidencias puede ser proporcionado por un servicio de atención al cliente, que actúe como punto de contacto diario con los usuarios. NOTA 2: La gestión de incidencias debería ser: a) Un proceso tanto proactivo como reactivo, que responda a los incidentes que afecten, o que eventualmente pudieran, afectar al servicio. b) Un proceso centrado en la restauración del servicio a los clientes y no en la determinación de la causa de las incidencias. El proceso de gestión de incidencias debería incluir lo siguiente: a) La recepción, el registro, la asignación de prioridad y la clasificación de las llamadas. b) La resolución de primera nivel o la derivación. c) La consideración de cuestiones de seguridad. d) El seguimiento y la gestión del ciclo de vida de las incidencias. e) La verificación y el cierre de las incidencias. f ) El contacto de primera nivel con los clientes. g) El escalado. Se puede informar sobre incidentes mediante llamadas telefónicas, buzón de voz, visitas, cartas, faxes o mensajes de correo electrónico, o bien los avisos pueden ser registrados directamente por los clientes que Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

202


tengan acceso al sistema de registro de incidencias, o se pueden registrar automáticamente mediante un software de supervisión automática. Todas las incidencias se deberían registrar de modo que la información relevante se pueda recuperar y analizar. El progreso (o su ausencia) de la resolución de la incidencia se debería comunicar a las partes real o potencialmente afectadas. Todas las acciones se deberían consignar en el registro de la incidencia. El personal de gestión de incidencias debería tener acceso a una base de conocimientos actualizada que contenga información sobre técnicos especialistas, incidencias anteriores, problemas relacionados y errores conocidos, soluciones provisionales y listas de comprobación, que ayuden a restablecer el servicio en la empresa. Siempre que sea posible, se debería proporcionar al cliente los medios necesarios para continuar con sus actividades empresariales, aunque sea con un servicio degradado (por ejemplo inhabilitando una función defectuosa). El objetivo es minimizar la repercusión sobre las actividades empresariales del cliente. Cuando la causa del problema siga sin determinarse pero se haya establecido una solución provisional, se deberían registrar los detalles para utilizarlos durante el diagnóstico continuo del problema y cuando se produzcan incidencias similares. Una incidencia sólo debería cerrarse definitivamente cuando el usuario que haya notificado dicha incidencia haya podido confirmar que la incidencia se ha resuello y el servicio ha sido restablecido. Incidencias graves Se debería definir claramente qué constituye un incidente grave y quién está capacitado para llevar a cabo cambios en el funcionamiento habitual del proceso de incidencias/problemas. Todas las incidencias graves deberían tener en todo momento un gestor responsable claramente definido. La designación como responsable de una incidencia grave debería proporcionar los niveles de autoridad individual adecuados para la función de coordinar y controlar todos los aspectos de la resolución. Esto debería incluir la responsabilidad del escalado y una comunicación eficaz entre todas las áreas implicadas en la resolución y con los clientes que se vean afectados por dicha incidencia grave. NOTA: Este nivel de autoridad puede ser temporal y aplicarse sólo mientras dure la incidencia grave. El proceso para un incidencia grave debería incluir una revisión que proporcionará información al plan de mejora del servicio.



Incluye: - Definición de incidencia grave - Asignación de autoridad para desviar el proceso normal - Designar a un gestor responsable de la incidencia grave

Preparar el tratamiento de incidencias graves

Dar acceso a información relevante

Como errores conocidos, resoluciones de problemas y CMDB Como especialistas técnicos, incidencias anteriores, errores conocidos y problemas relacionados, soluciones provisionales y listas de comprobación

Recibir llamadas

Registrar incidencias

Registros de incidencias

Definir el impacto de las incidencias en el negocio



Priorizar incidencias

Registros de incidencias actualizados

Clasificar incidencias


Resolver incidencias

Verificar la resolución

Cerrar incidencias

203

Incluyen peticiones de servicio (que se consideran un tipo de incidencia) e incidencias graves La prioridad establece los objetivos específicos de resolución. La prioridad debe estar basada en el impacto y la urgencia. El impacto indica el daño en el negocio del cliente. La urgencia indica la necesidad de una resolución rápida en el negocio del cliente. La programación se basa en prioridades, recursos disponibles, tiempo y coste

Bien en el primer nivel, bien por derivación.

Cuando la persona que comunicó la incidencia haya confirmado la resolución de la incidencia y el restablecimiento del servicio En caso de incidencia grave: incluir una revisión que sirva de entrada a un SIP

Interfaces: Mejora continua (Actuar): - Sugerir mejoras para SIP - Revisar incidencias graves Gestión de cambios: - Presentar peticiones de cambio Gestión de entregas, gestión de la configuración y gestión de problemas: - Intercambiar la información relevante Informes del servicio: - Recibir información Gestión de la seguridad de la información: - El proceso de gestión de incidencias cubre incidencias de seguridad

Figura 4.5.1 Gestión de incidencias


204


ISO 20000 requiere explícitamente procedimientos para gestionar el impacto de las incidencias. Las actividades necesarias para estos procedimientos se describen en detalle como registro, priorización, impacto en el negocio, clasificación, actualización, escalado, resolución y cierre formal. Los registros de incidencias son la salida que debe producir el registro de incidencias (Figuras 4.5.1 y 4.5.2). Efectuar un seguimiento de las incidencias en todo su ciclo de vida


Actualizar registros de incidencias

Escalar incidencias


Con detalles de soluciones provisionales

Si no es posible mantener los niveles de servicio y se ha acordado una acción: - Advertir al cliente por anticipado

Informar al cliente acerca del progreso de las incidencias comunicadas

Revisar incidencias graves


Figura 4.5.2 Gestión de incidencias (cont.)

La gestión de incidencias tiene interfaces con la gestión de problemas y con la gestión de la configuración, en ambos casos para proporcionar información sobre errores conocidos, resoluciones de problemas, contenidos de la CMDB, especialistas técnicos, soluciones provisionales y listas de comprobación. Las dos interfaces deben estar documentadas.

Guía La Figura 4.5.3 muestra los pasos que componen el proceso: • Aceptación y registro de la incidencia • Clasificación y soporte inicial • Comparación de la incidencia con registros de errores conocidos e incidencias anteriores • Investigación y diagnóstico • Resolución y recuperación • Cierre • Seguimiento y monitorización de progreso Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


205

Aceptación y registro de la incidencia

Clasificación y soporte inicial

Petición de servicio sí

Seguimiento y monitorización de progreso; escalado si es necesario

no Procedimiento de petición de servicio

Comparación

¿Coinciden? no Investigación y diagnóstico

sí

Resolución y recuperación

no

¿Resuelta? sí Cierre de la incidencia

Figura 4.5.3 Proceso de gestión de incidencias

Todas las incidencias deben quedar registradas inmediatamente. En la mayor parte de los casos, esta tarea corresponde al centro de atención al usuario. Las incidencias pueden ser detectadas por: • Un usuario que comunica la incidencia al centro de atención al usuario. • Un sistema que detecta un evento en una aplicación o infraestructura técnica (como cuando se supera un umbral crítico), lo registra como una incidencia en el sistema de registro de incidencias y lo envía a un grupo de soporte, si es necesario. • Un operador del centro de atención al usuario que se encarga de registrar la incidencia. • Un miembro de otro departamento de TI que registra la incidencia en el sistema de registro de incidencias o la comunica al centro de atención al usuario. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

206


El registro consta de los siguientes pasos: • Asignar a la incidencia un número de referencia - En la mayor parte de los casos, el sistema asigna automáticamente un número de referencia exclusivo a la incidencia; este número se suele comunicar al usuario para que le sirva de referencia en comunicaciones posteriores. • Registrar información básica de diagnóstico - Fecha y hora, síntomas, usuario, persona encargada del problema, ubicación e información del servicio o hardware afectado. • Añadir información sobre la incidencia - Más información sobre la incidencia (procedente de un guión o entrevista, por ejemplo) o de la CMDB (generalmente basada en la relación definida en la base de datos). • Emitir alertas - Si una incidencia tiene un impacto elevado (como la avería de un servidor importante), se avisa a los otros usuarios y departamentos de gestión. Antes de registrar una incidencia, hay que comprobar si tenemos abierta alguna similar. Si la hay, y se trata de la misma que nos han reportado, se debe actualizar la información de la incidencia, o bien registrarla por separado, y vincularla al registro principal de dicha incidencia. Es conveniente que las opciones de clasificación sean lo más amplias posible, aunque eso exigirá un mayor nivel de compromiso por parte del personal. En ocasiones se intenta combinar en una sola lista diversos aspectos de clasificación, como el tipo, el grupo de soporte y el origen. Esto puede generar confusión, por lo que se recomienda usar varias listas cortas. En primer lugar hay que asignar a las incidencias una categoría y subcategoría basándose, por ejemplo, en el probable origen de la incidencia o en el correspondiente grupo de soporte: • Procesamiento central - Acceso, sistema, aplicación. • Red - Router, segmento, hub y dirección IP. • Estación de trabajo - Monitor, tarjeta de red, unidad de disco, teclado. • Uso y funcionalidad - Servicio, capacidad, disponibilidad, respaldo, manual. • Organización y procedimientos - Pedido, solicitud, soporte, comunicación. • Petición de servicio - Presentada por el usuario al centro de atención al usuario para solicitar soporte, provisión, información, consejo o documentación. Se puede incluir en un procedimiento independiente o tratarla de la misma forma que otras incidencias. A continuación se asigna la prioridad para que los grupos de soporte puedan prestar a la incidencia la atención necesaria. La prioridad se suele indicar con un número que depende de la urgencia (¿es necesario encontrar pronto una solución?) y del impacto (¿causará muchos daños si no se soluciona?). Prioridad = Urgencia * Impacto Para identificar los servicios relacionados con la incidencia se puede utilizar una lista que haga referencia al SLA correspondiente. Esta lista incluirá también los tiempos de escalado para cada servicio de acuerdo con el SLA. Teniendo en cuenta la prioridad y el SLA, se informará a los usuarios afectados sobre el tiempo máximo estimado para resolver la incidencia (duración del ciclo) y sobre cuándo aparecerá nueva información sobre el progreso. Estas cronologías quedan registradas en el sistema. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


207

El estado de la incidencia indica su posición en el flujo de trabajo. Algunos de los estados posibles son: • Nueva • Aceptada • Planificada • Asignada • Activa • Suspendida • Resuelta • Cerrada Una vez terminada la clasificación, se comprueba si anteriormente ha habido una incidencia similar y, en caso afirmativo, si existe alguna solución provisional o permanente. Esta actividad se denomina comparación. Si se encuentran otros problemas o errores conocidos con los mismos síntomas, la incidencia se puede vincular a ellos. El centro de atención al usuario traslada a un grupo de soporte con más experiencia o competencia técnica todas las incidencias para las que no exista una solución inmediata o que queden fuera de su ámbito de competencia. Este grupo de soporte investiga y resuelve la incidencia, o bien la traslada a otro grupo de soporte. Esta actividad de traslado, que recibe también el nombre de escalado funcional, suele estar basada en la categoría asignada a la incidencia. En la definición de categorías también se puede tener en cuenta la estructura de los grupos de soporte. Un buen traslado de incidencias es fundamental para que la gestión de incidencias sea eficaz, por lo que “el número de incidencias a las que se ha dado traslado correctamente” debe ser uno de los KPIs para la calidad del proceso de gestión de incidencias. Después de analizar y resolver con éxito la incidencia, el grupo de soporte registra la solución en el sistema. En el caso de algunas soluciones será necesario presentar una solicitud de cambio (RFC) a la gestión de cambios. En el peor de los casos, la incidencia se mantiene abierta si no se encuentra ninguna solución. Una vez implantada la solución, el grupo de soporte devuelve la incidencia al centro de atención al usuario, que a su vez se pone en contacto con la persona que comunicó la incidencia para verificar la resolución. La incidencia se puede cerrar si se confirma que ha sido resuelta correctamente; de lo contrario, se tiene que reiniciar el proceso en el punto apropiado. A continuación hay que actualizar el registro con la categoría y prioridad final de la incidencia, los servicios/usuarios/ clientes afectados y los componentes (CIs) identificados como causa de la incidencia. Como propietario de todas las incidencias, el centro de atención al usuario es responsable de monitorizar el progreso y de informar al usuario acerca del estado de la incidencia. Los comentarios del usuario pueden resultar útiles después de un cambio de estado, como cuando se vuelve a dar traslado a la incidencia o se produce un cambio en la duración prevista del ciclo. El control del proceso se basa en los informes dirigidos a los distintos grupos. El gestor de incidencias se encarga de elaborar estos informes, así como de preparar una lista de distribución y un calendario de informes. Los informes pueden ser muy detallados y estar personalizados para las siguientes funciones: Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

208


• Gestor de incidencias - Informe para: – Identificar eslabones perdidos en el proceso – Identificar conflictos con SLAs – Efectuar un seguimiento del proceso – Identificar tendencias • Gestión de líneas de TI - Informe dirigido a la dirección del grupo de soporte para facilitar el control en cada una de las áreas del grupo de soporte. Requiere información sobre: – Progreso en la resolución de incidencias – Duración del ciclo de la incidencia en los distintos grupos de soporte • Gestión del nivel de servicio - Informe sobre la calidad de los servicios prestados; también puede ir dirigido a clientes. • Gestores de otros procesos de Gestión del Servicio - Los informes dirigidos a los gestores de otros procesos tendrán un carácter eminentemente informativo; la gestión de incidencias puede proporcionar la siguiente información basada en los registros de incidencias: – Número de incidencias comunicadas y registradas – Número de incidencias resueltas, subdivididas por tiempo de resolución – Número de incidencias no resueltas y su estado – Incidencias por período, grupo de clientes, grupo de soporte y resolución de acuerdo con el SLA – Incidencias por categoría y prioridad para cada grupo de soporte Los CSFs para la gestión de incidencias son: • Una CMDB actualizada que ayude a estimar el impacto y la urgencia de las incidencias • Una base de conocimiento, como una base de datos actualizada de problemas/errores conocidos, que permita reconocer incidencias y encontrar soluciones provisionales o permanentes • Un sistema automatizado adecuado para el registro, seguimiento y monitorización de incidencias • Fuertes vínculos con la gestión del nivel de servicio para conseguir prioridades y tiempos de resolución apropiados Entre los posibles KPIs figuran los siguientes: • Número total de incidencias • Tiempo medio de resolución (por prioridad) • Porcentaje de incidencias resueltas según los objetivos específicos del SLA • Porcentaje de incidencias resueltas por el primer nivel de soporte (sin dar traslado de ellas) • Coste medio de soporte por incidencia • Incidencias resueltas por cada estación de trabajo o empleado del centro de atención al usuario • Incidencias resueltas sin visitar al usuario • Número (o porcentaje) de incidencias con clasificación inicial correcta • Número (o porcentaje) de incidencias a las que se ha dado traslado correctamente

4.5.2 Proceso de resolución: Gestión de problemas (8.3) Objetivo: Minimizar los efectos negativos sobre el negocio de las interrupciones del servicio, mediante la identificación y el análisis proactivo de la causa de los incidentes, y la gestión de los problemas para su cierre. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


209

Las especificaciones ISO 20000-1 dicen: Se deben registrar todos los problemas identificados. Se deben adoptar procedimientos para identificar, minimizar y evitar el impacto de las incidencias y de los problemas. Estos procedimientos deben definir el registro, la clasificación, la actualización, el escalado, la resolución y el cierre de todos los problemas. Se deben llevar a cabo acciones preventivas para reducir los problemas potenciales, por ejemplo las derivadas de análisis de tendencias de volúmenes y tipos de incidencias. Se deben remitir al proceso de gestión de cambios los cambios necesarios para corregir la causa subyacente de problemas. Para que resulte eficaz la resolución de problemas, se debe supervisar, revisar y elaborar informes sobre ella. El equipo de gestión de problemas debe ser responsable de garantizar que esté disponible, para la gestión de incidencias, la información actualizada sobre errores conocidos y problemas corregidos. Las acciones de mejora identificadas durante este proceso se deben registrar e incluir en el plan de mejora del servicio. El Código de buenas prácticas ISO 20000-2 dice: Alcance de la gestión de problemas El proceso de gestión de problemas debería investigar las causas subyacentes de las incidencias. La gestión de problemas debería prevenir de una manera proactiva la repetición o la duplicación de las incidencias o de los errores conocidos, de acuerdo con los requisitos del negocio. Inicio de la gestión de problemas Se deberían clasificar las incidencias para ayudar a determinar las causas de los problemas. La clasificación puede hacer referencia a los problemas y cambios existentes. NOTA: Cuando se registren incidencias por primera vez, su categorización se verá influenciada por otros factores que incluyen el servicio, el área de negocio afectada y los síntomas que se presenten. Errores conocidos Cuando la investigación de la gestión de problemas haya identificado la causa del origen de un incidente y un método para resolver las incidencias, el problema se debería clasificar como un error conocido. Se deberían registrar todos los errores conocidos tomando como referencia los servicios real o potencialmente afectados además del elemento de configuración que se sospeche que causa el error en cuestión. La información sobre los errores conocidos en los servicios que se estén introduciendo en el entorno productivo se debería pasar a la Gestión del Servicio y se debería registrar en la base de datos de conocimiento, junto con las soluciones provisionales existentes. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

210


Un error conocido no se debería cerrar hasta que se haya resuelto satisfactoriamente. NOTA: El cliente o el proveedor del servicio pueden decidir que la resolución resulta demasiado cara o que no aporta beneficio al negocio. En este caso, esto debería quedar claramente documentado. No obstante, el error conocido debería permanecer abierto, puesto que aún existe la posibilidad de que se produzcan incidencias a consecuencia de este error y es posible que se necesiten soluciones provisionales y/o una reconsideración de la decisión para resolver el error. Resolución de problemas Cuando la causa raíz se haya identificado y se haya tomado una decisión para resolver el error, la resolución se debería conducir a través del proceso de gestión de cambios. Comunicación La información sobre soluciones provisionales, arreglos permanentes o el progreso de los problemas se debería comunicar a las partes afectadas o puede requerirse para dar soporte a los servicios afectados. Seguimiento y escalado Se debería realizar un seguimiento del progreso de todos los problemas. Todos los problemas se deberían escalar a las partes apropiadas. El proceso debería cubrir: a) El registro de los cambios de las identidades de los responsables de la resolución de problemas durante el ciclo de vida de cada problema. b) La identificación de incidencias que incumplan los objetivos del nivel de servicio. c) La distribución de información en cascada a los clientes y colegas para que puedan llevar a cabo las acciones adecuadas para minimizar la repercusión del problema no resuelto. d) La definición de los puntos de escalado. e) El registro de los recursos empleados y de las acciones realizadas. Cierre de registros de incidencias y problemas El procedimiento de cierre del registro debería incluir comprobaciones para garantizar que: a) Los detalles de la resolución se hayan registrado con precisión. b) La causa esté categorizada para facilitar el análisis. c) Si es necesario, tanto el personal del cliente como el personal de soporte estén al corriente de la resolución. d) El cliente acepte que la resolución se ha conseguido. e) El cliente sea informado si no se va a llegar a una resolución o ésta no resulta posible. Revisiones de problemas Se deberían realizar revisiones de los problemas siempre que la investigación para esclarecer los problemas no resueltos, no habituales o de gran repercusión, las justifique. La finalidad de estas revisiones es encontrar mejoras para el proceso y evitar la repetición de incidencias o errores. Las revisiones de problemas son normalmente: a) Revisiones de los niveles de incidencias individuales y del estado de problemas respecto a los niveles de servicio. b) Revisiones de la dirección para resaltar los problemas que requieren una acción inmediata.



211

c) Revisiones de la dirección para determinar y analizar tendencias y para proporcionar información a otros procesos como, por ejemplo, el de educación y formación del cliente. Temas a tratar en las revisiones Las revisiones deberían incluir información de: a) Tendencias, por ejemplo, problemas e incidencias recurrentes, errores conocidos, etc. b) Problemas recurrentes de una determinada clasificación de componente o de ubicación. c) Deficiencias causadas por la subcontratación, la formación o la documentación. d) Falta de comformidad con la legislación, por ejemplo, conforme a normas, políticas y leyes. e) Errores conocidos en las entregas planificadas. f ) El compromiso del personal para resolver las incidencias y los problemas. g) Repetición de incidencias o problemas ya resueltos. Las mejoras del servicio del proceso de gestión de problemas se deberían registrar e incluir en un plan de mejora del servicio. La información se debería añadir a la base de conocimiento de la gestión de problemas. Toda la documentación relevante se debería actualizar, por ejemplo, las guías del usuario y la documentación del sistema. Prevención de problemas La gestión proactiva de problemas debería conducir a una reducción de las incidencias y de los problemas. Debería incluir referencias a la información que resulte de ayuda para el análisis como, por ejemplo: a) Activos y configuración b) Gestión de cambios c) Un error conocido y divulgado, información sobre las soluciones provisionales de los proveedores d) Información histórica sobre problemas similares La prevención de problemas debería abarcar desde la prevención de incidencias individuales, tales como las dificultades reiteradas para utilizar una determinada función de un sistema, hasta las decisiones estratégicas. Es probable que estas últimas requieran un gasto de implementación considerable, por ejemplo, la inversión en una red mejor; a este nivel, la gestión proactiva del problema se funde con la gestión de la disponibilidad. La prevención de problemas también incluye el suministro de información a los clientes para evitar que tengan que pedir ayuda en el futuro, por ejemplo, para prevenir incidencias causadas por la falta de conocimiento o la falta de formación del usuario. Al igual que en el caso de la gestión de incidencias, ISO 20000 exige explícitamente procedimientos detallados para la gestión de problemas. Estos procedimientos incluyen en parte las mismas actividades que el proceso de gestión de incidencias: registro, clasificación, actualización, escalado, resolución y cierre. La gestión de incidencias incluye además los pasos de priorización y definición del impacto en el negocio.


212


Adoptar procedimientos Registros de incidencias

Otras fuentes de información, como activos y configuraciones, errores conocidos y soluciones provisionales

Registros de problemas


Interfaces: Cliente: - Información sobre las áreas de negocio afectadas Mejora continua (Actuar): - Sugerir mejoras para SIP Gestión de cambios: - Presentar peticiones de cambio Informes del servicio: - Recibir información Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes Gestión de la seguridad de la información: - Intercambiar información de gestión sobre tendencias en incidencias de seguridad de la información - Gestión de problemas debería investigar las incidencias de seguridad Gestión de incidencias: - Intercambiar la información relevante


Con definición de puntos de escalado

Identificar problemas (de modo reactivo y proactivo)

Registrar problemas

Por ejemplo, con análisis de tendencias en el volumen y tipo de incidencias


Priorizar problemas

Registros de problemas actualizados

Clasificar problemas


Investigar e identificar la causa y clasificar el problema como error conocido

Error conocido

A partir de la identificación de incidencias que incumplen los objetivos específicos de nivel de servicio La prioridad establece los objetivos específicos de resolución. La prioridad debe estar basada en el impacto y la urgencia. El impacto indica el daño en el negocio del cliente. La urgencia indica la necesidad de una resolución rápida en el negocio del cliente. La programación se basa en prioridades, recursos disponibles, tiempo y coste.. Incluye: - Servicios que están o pueden estar afectados - CI cuyo fallo puede haber causado el error

Determinar la solución

Desarrollar y mantener soluciones provisionales

Soluciones provisionales

Resolver problemas

RFC

Incluyen: - Campo de aplicación - Eficacia

Monitorizar, revisar y comunicar la eficacia de la resolución También puede incluir una mejora en la formación de clientes Debe comprobar que: - Los detalles de la resolución están registrados - Se ha asignado a la causa una categoría - El cliente y el personal de soporte conocen la resolución - El cliente está conforme con la resolución - Se informa al cliente si no se encuentra una resolucón

Cerrar problemas

Actualizar registros de problemas

Escalar problemas


Registrar los recursos empleados, las acciones emprendidas, los cambios de personas responsables y los resultados de revisiones Junto con soluciones provisionales

Figura 4.5.4 Gestión de problemas para identificar, minimizar o evitar el impacto de incidencias y problemas



213

Efectuar un seguimiento del progreso de problemas Incluyendo: - Tendencias - Deficiencias - No conformidades - Errores conocidos en entregas planificadas - Compromiso del personal - Reaparición de problemas resueltos

Revisar el problema si es necesario


Informar sobre errores conocidos a todos los procesos ITSM cuando se introduce un servicio en el entorno de producción y registrar en la base de conocimiento

Registros de la base de conocimiento

Comunicar información sobre soluciones provisionales, soluciones permanentes o progreso de problemas

Junto con soluciones provisionales

A los clientes y el personal afectado

Figura 4.5.5 Gestión de problemas (cont.)

Los documentos que se requieren explícitamente en el proceso de gestión de problemas son registros de problemas y registros de acciones identificadas de mejora (Figuras 4.5.4 y 4.5.5). La gestión de problemas tiene interfaces con el proceso de gestión de cambios para gestionar los cambios necesarios. El proceso de gestión de incidencias y todos los demás procesos de Gestión del Servicio obtienen información actualizada del proceso de gestión de problemas. La otra interfaz de la gestión de problemas es con la mejora continua. Todas estas interfaces deben estar documentadas.

Guía Las entradas de la gestión de problemas son: • Detalles de incidencias, incluyendo soluciones provisionales. • Detalles de configuración procedentes de la base de datos de gestión de la configuración (CMDB). • Detalles facilitados por los suministradores acerca de los productos usados en la infraestructura, incluyendo detalles técnicos y los errores conocidos en dichos productos. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

214


• El catálogo de servicios y acuerdos de nivel de servicio. • Detalles sobre la infraestructura y su comportamiento, como registros de capacidad, medidas de rendimiento e informes de nivel de servicio. Las salidas son: • Una base de datos de errores conocidos, que en realidad es una parte de la base de datos de problemas • Solicitudes de cambio (RFCs) • Registros actualizados de problemas • Registros de problemas cerrados una vez eliminada la causa raíz • Información de gestión Las principales actividades de la gestión de problemas son: • Control de problemas • Control de errores • Gestión proactiva de problemas • Suministro de información

Seguimiento y monitorización de problemas

El objetivo básico del control de problemas es identificar la causa subyacente de los problemas y encontrar soluciones provisionales, convirtiendo así los problemas en errores conocidos. La Figura 4.5.6 ilustra el control de problemas. Identificación y registro de problemas

Clasificación de problemas

Investigación y diagnóstico de problemas

RFC, resolución de problemas y cierre

(Control de errores)

Figura 4.5.6 Control de problemas según ITIL V2 (Fuente: OGC)

En principio, cualquier incidencia de causa desconocida se debe considerar un problema. Sin embargo, en la práctica sólo vale la pena hacerlo si la incidencia se repite o se puede repetir, o bien si se trata de una sola incidencia importante. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


215

La actividad de “identificar problemas” se suele encargar a analistas de problemas, aunque también pueden colaborar otros empleados como el personal de gestión de la capacidad. Los detalles de un problema son similares a los de una incidencia, aunque en este caso no es necesario incluir información sobre el usuario. No obstante, las incidencias asociadas con el problema se tienen que identificar y relacionar con el problema. Los siguientes son ejemplos de situaciones en las que se identifican problemas: • El análisis de una incidencia indica que puede volverse a producir, y genera un importante volumen o tendencia. • El análisis de la infraestructura identifica puntos débiles en los que pueden surgir nuevas incidencias (análisis realizado también por la gestión de la disponibilidad y la gestión de la capacidad). • Se produce una incidencia grave que requiere una solución permanente para evitar que se vuelva a producir. • Los niveles de servicio están amenazados (capacidad, rendimiento y costes). • Las incidencias registradas no se pueden vincular a un error conocido o problema existente. El análisis de tendencias puede detectar áreas que requieren una mayor atención. Este esfuerzo adicional se puede expresar en términos de coste y beneficios para la organización (por ejemplo, identificando las áreas que necesitan más soporte y determinando su grado de importancia para los servicios suministrados). Esta evaluación se puede basar en la severidad (el “factor de daño” de las incidencias), que tiene en cuenta: • El impacto de las incidencias sobre las actividades de negocio • El número de incidencias • El número de usuarios y procesos de negocio afectados • El tiempo y coste necesarios para resolver las incidencias Los problemas se pueden clasificar por área (categoría). La identificación señala los CIs de nivel más bajo que afectan al problema. La clasificación va acompañada de un análisis de impacto, que determina la gravedad del problema y su efecto sobre los servicios (urgencia e impacto). A continuación se asigna una prioridad del mismo modo que en el proceso de gestión de incidencias. Finalmente, se asignan recursos y personal en función de la clasificación del problema y se reserva tiempo para su resolución. La clasificación incluye: • Categoría - Identifica el dominio relevante; por ejemplo, hardware o software. • Impacto - Efecto sobre el proceso de negocio. • Urgencia - Indica hasta qué punto es aceptable retrasar la solución. • Prioridad - Combinación de urgencia, impacto, riesgo y recursos necesarios. • Estado - Por ejemplo, problema, error conocido, resuelto o cerrado. La clasificación no es estática, sino que puede cambiar durante el ciclo de vida de un problema. Por ejemplo, la disponibilidad de una solución provisional o temporal puede reducir la urgencia y el impacto de un problema, mientras que la aparición de nuevas incidencias puede aumentar la urgencia y el impacto. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

216


La actividad de investigación y diagnóstico se repite varias veces, acercándose cada vez más a la resolución deseada. Es habitual que se intente reproducir la incidencia en un entorno de pruebas, para lo cual es posible que se necesite personal con más experiencia; por ejemplo, los especialistas de un grupo de soporte pueden colaborar en el análisis y diagnóstico del problema. Los problemas no se deben exclusivamente a hardware y software, sino que también pueden tener su causa en un error de documentación, humano o de procedimiento, como la entrega de una versión incorrecta de software. Por eso es útil incluir los procedimientos en la CMDB y someterlos al control de versiones. La mayor parte de los errores tienen su origen en componentes de la infraestructura. Una vez se conoce la causa y se ha identificado el CI (o combinación de CIs) responsable del problema, es posible establecer un vínculo entre el CI y la incidencia. A continuación se asigna al problema el estado de “error conocido” (o se vincula a un error conocido) y comienza el proceso de control de errores, que consiste en la monitorización y gestión de errores conocidos hasta su resolución, siempre que sea posible y apropiado. Para ello se presenta una RFC a la gestión de cambios y se evalúan los cambios en una Revisión Post-Implantación (PIR). El control de errores puede exigir la participación de muchos departamentos y cubre los entornos de producción y desarrollo (Figura 4.5.7). (Control de problemas)

Seguimiento y monitorización de errores

Identificación y registro de errores

Evaluación de errores

Registrar la resolución de errores

Cerrar el error y los problemas asociados

RFC

Cambio implantado con éxito

Figura 4.5.7 Control de errores según ITIL V2 (Fuente: OGC)

La gestión de problemas tiene que determinar la solución de negocio más apropiada a cada problema, teniendo en cuenta los acuerdos de nivel de servicio, los costes y beneficios, y los Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


217

niveles de impacto y urgencia del error conocido. Para ello hay que determinar si se necesita una solución temporal, una solución permanente, o ambos tipos de solución. También se puede tomar la decisión de no resolver un problema; por ejemplo, cuando no existe justificación de negocio para hacerlo. Sea cual sea la decisión adoptada, la información correspondiente al error conocido tiene que estar registrada y a disposición de la gestión de incidencias. Una vez identificada una solución apropiada, se dispondrá de suficiente información para presentar una RFC. La gestión de cambios se encarga de implantar la resolución a través de la RFC. Después de la implantación, los cambios necesarios para resolver problemas, errores conocidos y las incidencias asociadas tienen que ser revisados en una Revisión Post-Implantación (PIR) antes de que se puedan cerrar los registros asociados. Si el cambio ha tenido éxito, se puede proceder a cerrar todos los registros de problemas y errores conocidos, junto con los registros de las incidencias asociadas. En el caso de un registro de problema, su estado cambia a “resuelto” en la base de datos de problemas. De ello se informa a la gestión de incidencias para que se puedan cerrar también las incidencias asociadas con el problema. En el caso de problemas graves, se debe efectuar además otra revisión para averiguar: • Qué es lo que se ha hecho bien • Qué es lo que se ha hecho mal • Cómo se pueden hacer mejor las cosas la próxima vez • Cómo se puede evitar que vuelva a aparecer el fallo Nota: Muchas organizaciones implantan el proceso de modo que el problema sólo se pueda cerrar después de que se hayan cerrado las incidencias asociadas (y, por tanto, después de que la resolución haya sido verificada por el cliente); si no se han cerrado las incidencias asociadas, es necesario volver a abrir el problema. La actividad de seguimiento y monitorización monitoriza el progreso de problemas y errores conocidos durante todas las fases de su ciclo de vida. Estas acciones forman parte tanto del control de problemas como del control de errores. Los objetivos son: • Determinar si ha cambiado el impacto o la urgencia del problema y ajustar la prioridad asignada, si es necesario. • Monitorizar el progreso del diagnóstico y la implantación de una solución, así como el éxito de la RFC; para ello, la gestión de cambios informa periódicamente a la gestión de problemas sobre el progreso de las RFCs presentadas. En general, la gestión proactiva de problemas se ocupa de la calidad de los servicios y la infraestructura. Para evitar problemas, se tiene que concentrar en el análisis de tendencias y en la identificación de posibles incidencias antes de que se produzcan, para lo cual examina componentes que son débiles o están sobrecargados. Si hay varios dominios, se intenta evitar que los fallos que se producen en un dominio aparezcan también en los demás. También se identifican e investigan los puntos débiles en los componentes de la infraestructura. Una CMDB bien diseñada e implantada puede ayudar a realizar un análisis de escenarios (“Qué ocurre si …”) para detectar posibles puntos de fallo y actuar de forma proactiva para mitigar los riesgos.


218


Durante el proceso se transmite información sobre soluciones provisionales y temporales a la gestión de incidencias para que el centro de atención al usuario pueda informar lo antes posible a los usuarios afectados. La CMDB y el SLA pueden dar información sobre qué es lo que se debe comunicar y a quién. Los factores críticos de éxito para la gestión de problemas son: • Una buena definición del marco del proceso y del conjunto de objetivos, interfaces y recursos del proceso. • Un conjunto de procedimientos completo y bien documentado. • Buena información de gestión de incidencias y una cooperación eficaz entre la gestión de incidencias y la gestión de problemas. Los indicadores clave del rendimiento de la gestión de problemas son: • La reducción del número de incidencias debida a la gestión y resolución de problemas. • La reducción del tiempo necesario para resolver problemas. • Un descenso en el coste asociado con la resolución de fallos. Los parámetros del proceso también se deben comunicar para operaciones de gestión interna, con el fin de evaluar y controlar la eficiencia de la gestión de problemas. Los informes de gestión de problemas pueden ser muy completos y cubren las siguientes cuestiones: • Informes de tiempo - Divididos en control de problemas, control de errores y gestión proactiva de problemas, así como por grupo de soporte y suministrador. • Calidad de componentes - Los detalles de incidencias, problemas y errores conocidos se pueden usar para identificar componentes afectados por fallos frecuentes y para determinar si los suministradores cumplen sus obligaciones contractuales. • Eficacia de la gestión de problemas - Detalles sobre el número de incidencias antes y después de resolver un problema, problemas registrados, errores conocidos registrados y número de RFCs presentadas e implantadas con éxito. • Relación entre gestión de problemas reactiva y proactiva - Un aumento de las acciones proactivas, en lugar de reaccionar a las incidencias, indica un aumento en la madurez del proceso. • Calidad de los servicios en desarrollo - Informa de nuevos servicios y componentes y de sus errores conocidos. • Estado y planes de acción para problemas abiertos - Resumen de lo que se ha hecho hasta el momento y de lo que se va a hacer a continuación para reducir el impacto de problemas, incluyendo las RFCs planificadas y el tiempo y los recursos necesarios. • Propuestas de mejora de la gestión de problemas - Si la información de los factores anteriores indica que el proceso de gestión de problemas no satisface los objetivos estipulados en el plan de calidad del servicio, se pueden presentar propuestas para mejorar el proceso e identificar recursos adicionales.


Capítulo 5

El examen de Fundamentos de ISO/IEC 20000

Entre los aspirantes a obtener un certificado de gestión de la calidad del servicio figuran proveedores de servicios internos y externos, que desempeñan un rol o tienen interés en la gestión de la calidad del servicio aunque la organización no esté (aún) certificada. El certificado de Fundamentos de ISO/IEC 20000 para Gestión del Servicio está orientado fundamentalmente a esta amplia audiencia. Por otra parte, los clientes que tengan previsto exigir a sus proveedores de servicios que obtengan un certificado ISO/IEC 20000 podrán tener un mejor conocimiento de lo que pueden esperar de sus proveedores de servicios. Los requisitos para el examen son: 1. Comprender las definiciones y principios de la gestión de la calidad del servicio: a. El candidato comprende el concepto de calidad. b. El candidato comprende el concepto de servicio. c. El candidato comprende el concepto de Gestión del Servicio. d. El candidato comprende el concepto de procesos. e. El candidato comprende el concepto de mejora continua. 2. Comprender la posición de ISO 20000 en la Gestión de Servicios de TI: a. El candidato comprende el panorama actual de normas y marcos de trabajo. b. El candidato comprende los conceptos de prácticas de certificación. c. El candidato comprende el concepto de ISO 20000. 3. Especificaciones de calidad para Gestión de Servicios de TI: a. El candidato comprende las especificaciones de calidad para la gestión y mejora de procesos ITSM. b. El candidato comprende las especificaciones de calidad para el control de servicios de TI. c. El candidato comprende las especificaciones de calidad para la alineación entre el negocio y las Tecnologías de la Información. d. El candidato comprende las especificaciones de calidad para la provisión de servicios de TI. e. El candidato comprende las especificaciones de calidad para el soporte de servicios de TI.


220


4. Código de prácticas de Gestión de Servicios de TI: a. El candidato comprende las mejores prácticas para la gestión y mejora de procesos ITSM. b. El candidato comprende las mejores prácticas para el control de servicios de TI. c. El candidato comprende las mejores prácticas para la alineación entre el negocio y las Tecnologías de la Información. d. El candidato comprende las mejores prácticas para la provisión de servicios de TI. e. El candidato comprende las mejores prácticas para el soporte de servicios de TI.

5.1 Prerrequisitos No hay ningún criterio formal o prerrequisito que deban cumplir los candidatos que se deseen presentar al examen de Fundamentos de ISO 20000. No obstante, es conveniente que los candidatos asistan a un curso de formación acreditado (que puede ser un curso de autoestudio en Web). Se recomienda a los candidatos que deseen asistir a un curso de formación que elijan uno de los proveedores de cursos acreditados. Tampoco hay ningún criterio estricto para quienes deseen asistir a un curso de formación acreditado, aunque es necesario tener algún conocimiento de la Gestión de Servicios de TI y se recomienda haber obtenido el Certificado de Fundamentos de Gestión de Servicios de TI antes de asistir a un curso de formación sobre Fundamentos de ISO/IEC 20000.

5.2 Formato de examen El examen tiene una duración de una hora y consta de 40 preguntas que se deben contestar sin utilizar ningún libro. Para cada pregunta se ofrecen cuatro posibles respuestas, entre las que el candidato tendrá que elegir la correcta. Se concede un punto por cada respuesta correcta. Las preguntas de examen se eligen entre un banco de preguntas que se actualiza periódicamente. Las preguntas y exámenes se pueden usar más de una vez, por lo que los proveedores, candidatos y supervisores no están autorizados a conservar copias de los exámenes. Para que los candidatos puedan preparar bien el examen, todos los proveedores de cursos acreditados reciben un examen de ejemplo y una plantilla de calificación. Los exámenes que se realicen en ordenador o a través de la Web se califican automáticamente y el candidato conoce el resultado de forma inmediata. En el caso de exámenes en papel, se envían a la entidad examinadora o a un agente examinador para su calificación. Para aprobar es preciso obtener 26 puntos o más. Los candidatos que suspendan pueden repetir el examen. No existe límite para el número de veces que un candidato puede repetir el examen. La mayor parte de los candidatos se presentarán al examen después de asistir a un curso de formación acreditado. Los proveedores de cursos pueden cooperar con un Centro de Exámenes Autorizado (AEC) para que el examen se celebre en su centro. El AEC tendrá la responsabilidad de garantizar la integridad del proceso de examen y de enviar los exámenes realizados a la entidad examinadora o a un agente examinador.



221

Por lo general, las entidades y agentes examinadores dan a conocer un calendario público para indicar a los candidatos cuándo se pueden matricular y realizar el examen. La entidad examinadora publicará también todas las condiciones especiales (ampliación de plazos, por ejemplo) que se apliquen en caso de que los exámenes se realicen fuera del país de la entidad o del agente examinador.

5.3 Reclamaciones Los estudiantes que deseen presentar una reclamación deberán hacerlo ante el correspondiente proveedor de cursos, entidad examinadora o agente examinador. Las entidades y agentes examinadores disponen de un procedimiento de resolución de reclamaciones (DRP) que cubre su relación con proveedores de cursos y estudiantes. La resolución se hace pública, por ejemplo, en una página Web.

5.4 Preparación del examen de Fundamentos de ISO/IEC 20000 Hay un par de cosas que se puede hacer para aumentar sus posibilidades de éxito en el examen del Certificado de Fundamentos de ISO/IEC 20000. La primera de ellas, por supuesto, es tomárselo en serio.

5.4.1 Preparación para el examen • Asista a un curso de formación acreditado. Aprender los conceptos básicos de la gestión de la calidad del servicio es más divertido y eficaz si se hace entre un grupo de profesionales con experiencias comunes y con un instructor experimentado que posee amplios conocimientos teóricos y prácticos. • Dedique el tiempo necesario al estudio en solitario y al repaso de los materiales del curso, la documentación de ISO/IEC 20000 y éstaguía de formación. Como norma general, se recomienda dedicar unas 20 horas al estudio en solitario. • Discuta con sus amigos y compañeros de trabajo lo que aprenda en el curso de formación y en los libros. Compartir experiencias sobre mejores prácticas le ayudará a entender mejor los principios de la gestión de la calidad del servicio. • Utilice el examen de ejemplo más actualizado que le proporcione su entidad examinadora para prepararse para el tipo de preguntas que encontrará en el examen de Fundamentos.

5.4.2 Preparación para el día del examen • Prepare el desplazamiento hasta el centro de exámenes. Procure llegar 15 minutos antes de la hora del examen para poder relajarse, por ejemplo, con un café o un té. • Duerma bien la noche anterior y llegue descansado al examen. No estudie los materiales del curso hasta altas horas de la noche. • Elija ropa cómoda. No está representando a su empresa, sino a sí mismo. • No olvide llevar un documento válido de identificación (pasaporte o DNI).

5.4.3 Consejos prácticos durante el examen • Lea atentamente todas las preguntas. • Responda primero las preguntas sencillas.


222


• Antes de elegir una de las posibles respuestas a una pregunta, intente pensar su propia respuesta. La primera intuición suele ser la correcta. • Recuerde que sólo una de las posibles respuestas es correcta. Elija la que responda con más precisión a la pregunta planteada, aunque no refleje todo lo que haya aprendido sobre el tema en cuestión. • No complique la pregunta tratando de encontrar contraejemplos a la respuesta que le parece más apropiada. Las preguntas no están pensadas para engañar y, salvo en casos excepcionales, es muy probable que la mayor parte de las respuestas no contengan toda la verdad. • Compruebe que ha contestado todas las preguntas antes de que termine el tiempo de examen. Si tiene dudas, elija la respuesta que le parezca mejor. • No se ponga nervioso. Si se prepara bien, el examen no es tan difícil. ¡Usted puede!

5.5 Preguntas de ejemplo Las siguientes preguntas de ejemplo son una buena muestra del tipo de preguntas que encontrará en los exámenes reales. Puede utilizarlas como complemento al estudio del libro de introducción. Si desea preparar el examen aún mejor, puede solicitar el último examen de ejemplo a las entidades examinadoras o a un proveedor de formación acreditado. Los exámenes más recientes de las entidades examinadoras reflejan los últimos cambios y mejoras que se han introducido en los exámenes, o bien contienen una versión con respuestas incluidas, con comentarios y explicaciones de cada una de las opciones. Pregunta 1 Un planteamiento para desarrollar e implantar un sistema de gestión de la calidad consta de varios pasos. ¿Cuál de los siguientes no es un paso necesario? A. Acordar la política y los objetivos de calidad con el gestor de cambios. B. Determinar y proporcionar los recursos necesarios para alcanzar los objetivos de calidad. C. Determinar las necesidades y expectativas de los clientes y otras partes interesadas. D. Definir métodos para medir la eficacia y la eficiencia de cada proceso. A. Correcto. La política y los objetivos de calidad se deben acordar con más personas, no sólo con el gestor de cambios. B. Incorrecto. Este paso es necesario para desarrollar e implantar un sistema de gestión de la calidad. C. Incorrecto. Este paso es necesario para desarrollar e implantar un sistema de gestión de la calidad. D. Incorrecto. Este paso es necesario para desarrollar e implantar un sistema de gestión de la calidad.



223

Pregunta 2 Los procesos de relación describen las relaciones con el negocio y con los suministradores. ¿Qué es lo que tienen que garantizar los procesos de relación? A. Que todas las partes comprenden las necesidades de negocio, las responsabilidades y las obligaciones. B. Que se informa directamente al negocio y a los suministradores acerca de incidencias graves. C. Que en la cadena de suministro se mantienen niveles de servicio constantes para todos los servicios. D. Que se mantiene un contacto frecuente entre los suministradores y el negocio para resolver cuestiones que no resultan satisfactorias. A. Correcto. Los procesos de relación cubren la gestión de proveedores y la gestión de relaciones con el negocio, y tienen que garantizar que se comprenden las directrices de negocio del cliente, y que se conocen y documentan las responsabilidades y obligaciones de todas las partes. B. Incorrecto. El proceso para una incidencia grave debe incluir la comunicación a todas las áreas que participen en la resolución, así como a los clientes afectados. No obstante, forma parte del proceso de gestión de incidencias y es responsabilidad de un gestor designado para la incidencia grave, por lo que queda fuera del alcance de los procesos de relación. C. Incorrecto. No es necesario que los niveles de servicio sean constantes para todos los suministradores, y de hecho es poco probable que así ocurra. Sin embargo, es preciso que los niveles de servicio de los suministradores estén alineados con los del negocio, de manera que se puedan cumplir los acuerdos de nivel de servicio (SLAs) a los que se haya llegado con el cliente. D. Incorrecto. El negocio no debe mantener un contacto directo con los suministradores. El proveedor de servicios se encarga de gestionar a los suministradores para garantizar la calidad de los servicios suministrados al negocio. Pregunta 3 ¿Qué es lo que deben incluir los procedimientos de gestión de entregas, según ISO/IEC 200001:2005? A. La autorización e implantación de cambios de emergencia. B. La investigación y prevención de incidencias de seguridad. C. El registro de todas las incidencias detectadas. D. La actualización y modificación de la información de configuración y los registros de cambios. A. Incorrecto. Esto forma parte de los procedimientos de gestión de cambios. B. Incorrecto. Esto forma parte de los procedimientos de gestión de la seguridad de la información. C. Incorrecto. Esto forma parte de los procedimientos de gestión de incidencias. D. Correcto. Éste es un requisito contemplado en la norma. Los procedimientos de gestión de entregas deberán incluir la actualización y modificación de información sobre configuraciones y registros de cambios.


224


Pregunta 4 ¿Cuál de las siguientes normas se utiliza como guía para el gobierno de TI? A. CobiT® B. ISO 9000 C. ISO/IEC 20000 D. MOF A. Correcto. Es la guía de ISACA para el gobierno de TI. B. Incorrecto. Es la norma genérica para sistemas de gestión de la calidad. C. Incorrecto. Es la norma para Gestión de Servicios de TI. D. Incorrecto. Es el marco de trabajo de Microsoft para la Gestión del Servicio. Pregunta 5 El planteamiento Planificar-Hacer-Verificar-Actuar (PDCA) se puede aplicar a todos los procesos de ISO/IEC 20000. ¿Qué es lo que cubre la fase Actuar de esta metodología? A. La definición de los objetivos y procesos necesarios para obtener resultados que respondan a los requisitos del cliente y a las políticas de la organización. B. La implantación de los procesos. C. La monitorización y medición de procesos y servicios, y la comunicación de los resultados. D. La adopción de las medidas necesarias para mejorar de forma continua el rendimiento de los procesos. A. Incorrecto. Esta acción se realiza durante la fase Planificar de la metodología. B. Incorrecto. Esta acción se realiza durante la fase Hacer de la metodología. C. Incorrecto. Estas acciones se realizan durante la fase Verificar. D. Correcto. Esta acción se realiza durante la fase Actuar de la metodología. Pregunta 6 ¿Cómo se debe utilizar el ciclo de Deming? A. Como un modelo para mejora continua. B. Como un modelo para orientación de clientes. C. Como un modelo que se debe usar durante la fase de diseño del servicio. D. Como un modelo para calcular los costes de mejora de servicios. A. Correcto. Éste es el objetivo principal del ciclo. B. Incorrecto. El ciclo está enfocado a la mejora continua, y no a la orientación de clientes específicamente. C. Incorrecto. El modelo se puede usar durante la fase de diseño, pero está enfocado a la mejora continua durante todas las fases. D. Incorrecto. De esto se encargan los modelos de costes que forman parte del presupuesto y la contabilidad. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


225

Pregunta 7 ¿Cuál es la definición de disponibilidad? A. Un registro que contiene los detalles de aquellos elementos de configuración (CIs) a los que afecta un cambio autorizado y sobre cómo les afecta. B. Una instantánea del estado de un servicio o de un elemento de configuración (CI) individual en un momento concreto. C. Cualquier suceso que no sea parte del funcionamiento normal de un servicio y que cause, o pueda causar, una interrupción de dicho servicio o una disminución de su calidad. D. La capacidad de un componente o de un servicio para realizar su función requerida en un instante determinado o a lo largo de un período de tiempo definido. A. Incorrecto. Esta definición corresponde a un registro de cambio. B. Incorrecto. Esta definición corresponde a una línea base. C. Incorrecto. Esta definición corresponde a una incidencia. D. Correcto. Esta definición corresponde a la disponibilidad. Pregunta 8 Los servicios nuevos o modificados tienen que ser aceptados antes de su implantación en el entorno de producción. ¿Qué es lo que hay que hacer después de la implantación de un servicio nuevo o modificado? A. Se lleva a cabo una Revisión Post-Implantación (PIR) para comparar los resultados reales con los planificados. B. Se tiene que definir el método de conexión entre proyectos que crean o modifican servicios. C. No hay que hacer nada más; el servicio nuevo o modificado “sigue su curso” y se gestiona como un servicio normal. D. Se tiene que definir la manera en la que se va a revertir o corregir el cambio en caso de no tener éxito. A. Correcto. Esta cláusula forma parte de la norma. B. Incorrecto. Esto forma parte de la planificación de la Gestión del Servicio (Planificar) y no es relevante después de la implantación de servicios nuevos o modificados. C. Incorrecto. La norma especifica que se debe realizar una PIR. No se contempla la opción de no hacer nada. D. Incorrecto. Esta cláusula forma parte de la gestión de cambios y tiene que estar cumplida o definida antes de la implantación. Pregunta 9 ¿Qué es Six Sigma®? A. Un instrumento de calidad para medir defectos en salidas de procesos. B. Un modelo de madurez en seis pasos para mejorar la capacidad de procesos de negocio. C. Una norma que ha sido recientemente desarrollada para la mejora de procesos de TI. D. Un planteamiento estructurado y con base estadística para la mejora de procesos. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

226


A. Incorrecto. No es sólo un instrumento de calidad, sino que integra una metodología de mejora. B. Incorrecto. No es un modelo de madurez. C. Incorrecto. Fue desarrollado en la década de 1980 para procesos generales de negocio. D. Correcto. Pregunta 10 ¿Cuál es el objetivo de los procesos de gestión de la disponibilidad y la continuidad del servicio? A. Asegurar una comunicación eficaz con los clientes. B. Asegurar que los compromisos adquiridos con los clientes sobre niveles de servicio se pueden cumplir bajo todas las circunstancias. C. Asegurar que los compromisos adquiridos con los clientes sobre la disponibilidad y la continuidad del servicio se pueden cumplir bajo todas las circunstancias. D. Asegurar que los compromisos adquiridos con los proveedores sobre la disponibilidad y la continuidad del servicio se pueden cumplir bajo todas las circunstancias. A. Incorrecto. Una comunicación eficaz no es el objetivo de los procesos de gestión de la disponibilidad y la continuidad del servicio; está más relacionado con los informes del servicio. B. Incorrecto. La gestión de niveles de servicio es el objetivo del proceso de gestión del nivel de servicio. C. Correcto. Éste es el objetivo de los procesos de gestión de la disponibilidad y la continuidad del servicio. D. Incorrecto. La gestión de la disponibilidad y la continuidad del servicio es un proceso entre un suministrador y un cliente, no entre un suministrador y un proveedor. Pregunta 11 El personal debe contar con la formación y la experiencia necesarias para alcanzar un nivel de competencia apropiado. ¿Cuál de las siguientes es una de las mejores prácticas sobre competencia? A. Se deben mantener registros apropiados de educación, formación, conocimientos y experiencia. B. Debe haber al menos dos empleados que hayan recibido la formación adecuada para cada rol. C. Los empleados deben tener al menos una licenciatura relevante. D. Todo el personal debe haber recibido formación sobre seguridad según ISO/IEC 17799. A. Correcto. Ésta es una de las mejores prácticas incluidas en la norma. B. Incorrecto. Esto afecta a la disponibilidad de recursos, pero no es una de las mejores prácticas sobre competencia. C. Incorrecto. Lo que se requiere no es una licenciatura, sino la formación adecuada para el rol. D. Incorrecto. Esta formación es específica para seguridad, pero no es una de las mejores prácticas sobre competencia en general.



227

Pregunta 12 ¿A qué tipo de organizaciones beneficia ISO/IEC 20000? A. Organizaciones que deseen confirmar que se han implantado todas las directrices de ITIL®. B. Organizaciones que necesiten demostrar la alineación con los requisitos del cliente. C. Organizaciones que deseen certificar sus servicios. D. Distribuidores de herramientas que necesiten especificar los procesos del proveedor de servicios. A. Incorrecto. ITIL® va mucho más allá que ISO/IEC 20000, por lo que no será posible confirmar que se han implantado todas las directrices de ITIL®. B. Correcto. Este aspecto está incluido en el alcance de la norma. C. Incorrecto. Lo que se certifica es el sistema de gestión, no los servicios. D. Incorrecto. Los proveedores de servicios especifican sus procesos basándose en ISO/IEC 20000 y en ITIL®. Pregunta 13 ¿Qué información se debe registrar como línea base antes de implantar un plan de mejora del servicio? A. Una lista de cambios pendientes para el servicio. B. El número de empleados participantes. C. La calidad y los niveles de servicio. D. El tiempo empleado en la operación del proceso. A. Incorrecto. Esta medida puede ser necesaria para reducir el número de cambios pendientes, pero también puede haber otra información. B. Incorrecto. Esta medida puede ser necesaria para aumentar el número de empleados, pero también puede haber otra información. C. Correcto. La norma recomienda que la calidad y los niveles de servicio se recojan como una línea base para que se pueda medir la mejora real. D. Incorrecto. Esta medida puede ser necesaria para reducir el tiempo empleado, pero también puede haber otra información. Pregunta 14 ¿Dónde se define normalmente un servicio de TI para el cliente? A. En el marco de trabajo de TI. B. En el acuerdo de nivel operativo (OLA). C. En el catálogo de servicios o en el acuerdo de nivel de servicio (SLA). D. En el informe del servicio. A. Incorrecto. El marco de trabajo de TI proporciona una estructura para la Gestión del Servicio, pero no define el servicio propiamente dicho. B. Incorrecto. El OLA define un acuerdo de soporte subordinado al servicio principal para el cliente. C. Correcto. El servicio para el cliente se define en el catálogo de servicios o en el SLA. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

228


D. Incorrecto. El informe del servicio contiene datos sobre el rendimiento del servicio, pero no define el servicio. Pregunta 15 ¿Por qué es importante que los proveedores de servicios faciliten documentos y registros? A. Porque es uno de los requisitos (evidencia) para cumplir ISO/IEC 20000. B. Para poder registrar e identificar de forma única todos los elementos de configuración (CIs) en la base de datos de gestión de la configuración (CMDB). C. Para garantizar la eficacia de la planificación, operación y control de la Gestión del Servicio. D. Para garantizar que los empleados son conscientes de la relevancia e importancia de su trabajo. A. Incorrecto. El cumplimiento de ISO/IEC 20000 nunca debe ser el único objetivo por el que se preparan documentos. B. Incorrecto. Esto forma parte de la gestión de la configuración. C. Correcto. La Gestión del Servicio necesita documentos y registros para que el proveedor de servicios tenga evidencia de que mantiene el control. El cumplimiento de ISO/IEC 20000 nunca debe ser el único objetivo por el que se preparan documentos. D. Incorrecto. Esto forma parte de la competencia, la concienciación y la formación, y no es relevante para la documentación. Pregunta 16 ¿Cuál es la recomendación para la implantación de un cambio de emergencia? A. Sólo el máximo responsable debe autorizar los cambios de emergencia. B. Se debe omitir por completo el proceso de cambio. C. Se recomienda que haya un proceso independiente para cambios de emergencia. D. Se debe seguir el proceso de cambio siempre que sea posible. A. Incorrecto. La autorización de los cambios de emergencia forma parte del proceso y no existe ninguna recomendación sobre quién debe hacerlo. B. Incorrecto. No se recomienda omitir todo el proceso, aunque es posible omitir algunas actividades para realizarlas más tarde. C. Incorrecto. Tiene que haber una política independiente para cambios de emergencia, pero no se recomienda que haya un proceso independiente. D. Correcto. Se recomienda seguir el proceso de cambio siempre que sea posible, aunque las actividades omitidas se deben realizar lo antes posible. Pregunta 17 ¿A qué procesos debe facilitar la gestión de problemas información actualizada sobre errores conocidos y problemas corregidos? A. A todos los procesos de ISO/IEC. B. A la gestión de la disponibilidad.



229

C. A la gestión de la configuración. D. A la gestión de incidencias. A. Incorrecto. Según la norma, la gestión de problemas tiene que facilitar esta información al proceso de gestión de incidencias, no a todos los procesos de ISO/IEC. B. Incorrecto. Según la norma, la gestión de problemas tiene que facilitar esta información al proceso de gestión de incidencias. C. Incorrecto. Según la norma, la gestión de problemas tiene que facilitar esta información al proceso de gestión de incidencias. D. Correcto. La gestión de problemas tiene que facilitar esta información al proceso de gestión de incidencias para permitir la comparación de incidencias. Pregunta 18 ¿Por qué es importante la declaración de alcance para ISO/IEC 20000? A. Porque define las condiciones de la certificación del sistema de gestión. B. Porque detalla todas las empresas que han sido certificadas. C. Porque detalla todos los servicios que han sido certificados. D. Porque identifica los procesos que han quedado fuera del alcance. A. Correcto. La declaración de alcance demuestra que el sistema de gestión ha superado las pruebas necesarias para obtener la certificación. B. Incorrecto. El certificado sólo se puede conceder a una empresa (entidad legal única). C. Incorrecto. Lo que se certifica es el sistema de gestión, no los servicios. D. Incorrecto. Todos los procesos dentro del alcance de la norma deben ser sometidos a auditorías. Pregunta 19 Los objetivos específicos de resolución tienen que estar basados en prioridades. Cuando se programa la resolución de incidencias o problemas, ¿cuál de los siguientes aspectos no se debe tener en cuenta? A. Los conocimientos disponibles. B. Los conflictos entre requisitos de recursos. C. El esfuerzo o coste requerido por el método de resolución. D. El número de incidencias detectadas previamente para un elemento de configuración (CI) concreto. A. Incorrecto. Este aspecto es relevante para programar la resolución de incidencias o problemas. B. Incorrecto. Este aspecto es relevante para programar la resolución de incidencias o problemas. C. Incorrecto. Este aspecto es relevante para programar la resolución de incidencias o problemas. D. Correcto. Este aspecto no es relevante para programar la resolución, sino para identificar problemas.


230


Pregunta 20 ¿Cuál es la forma correcta de introducir un cambio en un contrato debido a una revisión general de un contrato autorizado? A. A través del proceso de gestión de relaciones con el negocio. B. A través del proceso de gestión de cambios. C. A través del representante del cliente. D. A través del proceso de gestión de proveedores. A. Incorrecto. El proceso de gestión de relaciones con el negocio se encarga de organizar reuniones de revisión del servicio en las que se discuten cambios en el alcance del servicio, SLA, contrato, etc. Los cambios en los contratos que sean consecuencia de estas reuniones estarán sometidos al proceso de gestión de cambios. B. Correcto. Todos los cambios introducidos en el contrato estarán sometidos al proceso de gestión de cambios. C. Incorrecto. Estos representantes participarán a través de otros procesos (como el proceso de gestión de relaciones con el negocio). D. Incorrecto. La gestión de proveedores se encarga de definir un proceso para realizar revisiones generales de un contrato. Todos los cambios introducidos en el contrato estarán sometidos al proceso de gestión de cambios.


Lista de abreviaturas

ACP ANSI AS BPM BS BSC BSI CAB CAP CCTA CEO CFIA CIO CI CISM CMDB CMM CMMI CobiT® CPD CRAMM CSI CSF CSS DML DSL EA EFQM ENAC

Accredited Course Provider American National Standards Institute Australian Standard Business Process Modeling British Standard Balanced Scorecard British Standard Institution Change Advisory Board Corrective Action Plan Central Computer and Telecommunications Agency Chief Executive Officer Component Failure Impact Analysis Chief Information Officer Configuration Item Certified Information Security Manager Configuration Management Database Capability Maturity Model Capability Maturity Model Integration Control Objectives for IT Continual Professional Development CCTA Risk Analysis and Management Method Continual Service Improvement Critical Success Factor Customer Satisfaction Surveys Definitive Media Library Definitive Software Library European co-operation for Accreditation European Foundation for Quality Management Entidad Nacional de Acreditación (España)


232

ESP FISM FSC FTA IAF IRCA IS IEC ISACA ISO ISM ISMS IT ITIL ITOCO ITSM ITSCM itSMF ITT JAB JQA KPI MI MISM MLA MOF MTRS NAB OGC OLA OSS PDCA PIR PRINCE2TM QMS RAID RCB RfC RfP ROI RvA SANS Institute SEI SIP SLA


External Service Provider Fellow of the Institute of Service Management Forward Schedule of Change Fault Tree Analysis International Accreditation Forum, Inc. International Register of Certificated Auditors Information System International Electrotechnical Commission Information Systems Audit and Control Association International Organization for Standardization Institute of Service Management Information Security Management System Information Technology Information Technology Infrastructure Library Input-Throughput-Output-Control-Outcome IT Service Management IT service continuity management IT Service Management Forum Invitation to Tender The Japan Accreditation Board For Conformity Assessment Japanese Quality Association Key Performance Indicator Management Information Member of the Institute of Service Management Multilateral Recognition Arrangement Microsoft Operations Framework Mean Time to Restore Service National Accreditation Body Office of Government Commerce Operational Level Agreement Operational Support System Plan-Do-Check-Act Post Implementation Review Projects In Controlled Environments Quality Management System Risks, Assumptions, Issues, Dependencies Registered Certification Body Request for Change Request for Proposal Return on Investment Raad voor Accreditatie (Comité de Acreditación, Holanda) SysAdmin, Audit, Network, Security Institute Software Engineering Institute Service Improvement Program Service Level Agreement


Lista de abreviaturas

SLM SOA SOX SPOF SQM TGA TOP TQM UC UKAS

Service Level Management Service Outage Analysis Sarbanes-Oxley Act Single Points Of Failure Service Quality Management Asociación Alemana de Acreditación Technical Observation Post Total Quality Management Underpinning Contract The United Kingdom Accreditation Service


233

234



Referencias

235

Referencias Sobre ISO/IEC 20000 • Bon, J. van (2006). ISO/IEC 20000, A Pocket Guide. Zaltbommel: Van Haren Publishing. • Bon, J. van (Ed.) (2008). ISO/IEC 20000, An Introduction. Zaltbommel: Van Haren Publishing. • Dugmore, J., & S. Lacy (2006). BIP 0030:2006. Achieving ISO/IEC 20000. Management decisions. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0031:2006. Achieving ISO/IEC 20000. Why people matter. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0032:2006. Achieving ISO/IEC 20000. Making metrics work. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0033:2006. Achieving ISO/IEC 20000. Managing end-toend service. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0034:2006. Achieving ISO/IEC 20000. Finance for service managers. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0035:2006. Achieving ISO/IEC 20000. Enabling change. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0036:2006. Achieving ISO/IEC 20000. Keeping the service going. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0037:2006. Achieving ISO/IEC 20000. Capacity management. London: BSI. • Dugmore, J., & S. Lacy (2006). BIP 0038:2006. Achieving ISO/IEC 20000. Integrated service management. London: BSI. • Gartner Inc., 2006. G00136652, ISO/IEC 20000 Has an Important Role in Sourcing Management. Gartner. • ISO (2006). ISO 9000 and ISO 14000 - An Introduction. ISO. Available through: www.iso. org/iso/en/iso9000-14000/index.html • ISO JTC 1/SC 7 (2005) ISO/IEC 20000-2 - Information technology - Service management Part 2: Code of practice. ISO. • ISO JTC 1/SC 7 (2005). ISO/IEC 20000-1 - Information technology - Service management - Part 1: Specification. ISO. • ISO TC 176/SC 1 (2000). ISO 9000:2000 - Quality management systems - Fundamentals and vocabulary. ISO. • ISO TC 176/SC 2 (2000). ISO 9001:2000 - Quality Management Systems - Requirements. ISO. • ISO (2001). Introduction and Support Package. Guidance on the Documentation Requirements of iso 9001:2000. Document: ISO/TC 176/SC 2/N525R. Disponible a través de: www.iso.org/ iso/en/iso9000-14000/explore/transition/2000rev7.html • itSMF UK (2007). ISO/IEC 20000 Certification web site. www.isoiec20000certification.com/ index.asp. • McFarlane, I., & J. Dugmore (2006). BIP 0015:2006. IT service management. Self assessment workbook. 2nd edition. London: BSI.


236


• Page, D. (2006). Top 10 tips to achieve ISO 20000. Available through: www.nccmembership.co.uk/pooled/articles/BF_WEBART/view.asp?Q=BF_WEBART_ 212190 • Read, D (2006). ISO/IEC 20000. Pitfalls of ISO/IEC 20000 certification programmes. White paper for PRO-ATTIVO.

Sobre las normas ISO 9000 • ISO (2006). Understand the basics. Disponible a través de: www.iso.org/iso/en/iso9000-14000/understand/index_one.html • ISO (2006). Explore further. Disponible a través de: www.iso.org/iso/en/iso9000-14000/explore/index_three.html • Tricker, Ray (2006). ISO 9001:2000 - The Quality Management Process. Zaltbommel: Van Haren Publishing.

Sobre normas de seguridad • Calder, A. (2006). Information Security based on ISO 27001/ISO 17799; A Management Guide. Zaltbommel: Van Haren Publishing. • ISO 17799:2005, Information technology - Security techniques - Code of practice for information security management. (2005). Geneva: International Organization for Standardization. • ISO 27001:2005, Information technology - Security techniques - Information Security management Systems - Requirements. (2005). Geneva: International Organization for Standardization

Sobre TQM • Bent, B.J. van der (2006). TQM - Total Quality Management. In J. van Bon (ed.) Frameworks for IT Management. Zaltbommel: Van Haren Publishing. • Bent, B.J. van der (1999). Organisatieleren: een zoektocht naar de geheugendragers en de rol van organisatiegeheugen in veranderingsprocessen. Rotterdam: Erasmus University. • Brassard, M. (Ed.) (1991). Memory jogger (tools for continual improvement). Salem, NH: GOAL/ QPC. • Conti, T. (1993). Building Total Quality. A guide for management. London: Chapman and Hall. • Crosby, P.B. (1979). Quality is Free. New York: McGraw-Hill. • Deming, W.E. (1986). Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering Study. • Deming, W.E. (1994, 2nd edition). The New Economics for Industry, Government, Education. Cambridge, MA: MIT Center for Advanced Engineering Study. • Garvin, D. (1988). Managing Quality. The Strategic and Competitive Edge. New York: The Free Press. • Hardjono, T, S. ten Have, & W. ten Have (1997). The European Way to Excellence. Brussels: Directorate-Generale III Industry, European Commission. • Imai, M. (1986). Kaizen. The key to Japan’s competitive success. New York: Random House Business Division. • Juran, J. (1988). Juran on Planning for Quality. New York: The Free Press. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Referencias

237

• MacLeod, A., & L. Baxter (2001). The Contribution of Business Excellence Models in Restoring Failed Improvement Initiatives. European Management Journal, Vol. 19, No. 4, 392403. • Mulè, G. (2007). EFQM - European Foundation for Quality Management Excellence Model. in J. van Bon (ed.) Frameworks for IT Management (second edition). Zaltbommel: Van Haren Publishing. • March, A. (1996). A Note on Quality: The Views of Deming, Juran, and Crosby. IEEE Engineering Management Review, Vol. 24, No. 1, 6-14. • Martin, P., & Tate, K. (1997). Project Management Memory jogger. Salem, NH: GOAL/QPC. • Nuland, Y. van, G. Broux, L. Crets, W. De Cleyn, J. Legrand, G. Majoor, & G. Vleminckx (1999). Excellent: A guide for the implementation of the EFQM-Excellence model. Leuven: Comatech. • Peach, R.W., Peach, B., & Ritter, D.S. (2000). Memory jogger 9000/2000 (implementing ISO 9001). Salem, NH: GOAL/QPC. • Ritter, D., & Brassard, M. (1998). The creative tools memory jogger (creative thinking). Salem, NH: GOAL/QPC. • Wentink, T. (1999). Kwaliteitsmanagement en organisatieontwikkeling. Den Haag: Lemma.

Páginas Web • www.iso.org • www.bsi-global.com • www.deming.org • www.efqm.org • www.ink.nl • www.juran.com • www.kaizen-institute.com • www.olkk.nl • www.vck.be

International Organization for Standardization British Standard Institution Deming Institute European Foundation for Quality Management Instuto de Calidad de Holanda Instituto Juran Instituto Kaizen On line kwaliteitskring, Círculo de calidad holandés Centro Belga de Gestión de la Calidad

Oportunidades de cualificación • www.isoiec20000certification.com - Información sobre cualificaciones en ISO/IEC 20000 de itSMF UK • www.exin-exams.com - Información sobre cualificaciones en ISO/IEC 20000 de EXIN • www.tuev-sued.de/it-zert - Información sobre cualificaciones en ISO/IEC 20000 de TÜV SÜD • www.irca.org/certification/certification_12.html - Información sobre cualificaciones en ISO/IEC 20000 de IRCA • www.afaq.org - Información sobre cualificaciones en ISO/IEC 20000 de AFAQ (ICA)


238



239

Índice alfabético A Acción correctiva 84 Activos 171, 191 Acuerdo de Nivel de Servicio (SLA) 30, 56, 62, 129, 136, 157, 227 Acuerdo de Nivel Operativo (OLA) 136 Adaptabilidad 18 Administrador de sistemas 39 Alcance 36, 75, 84 Alineamiento 156 Análisis de gaps 79, 82 Análisis de Impacto de Fallos de Componente (CFIA) 180 Análisis de Interrupción de Servicios (SOA) 181 Análisis del Árbol de Fallos (FTA) 181 Análisis de Tendencias 87, 215 Auditor 37, 39, 84 Auditoría de certificación 35, 38 Auditoría de renovación 38 Auditoría externa 198 Auditoría inicial 38 Auditoría interna 198 Auditoría previa 37 Auditorías de vigilancia 38 Auditor externo 39, 198 Auditor interno 39, 198 Autoevaluación 32, 198

B Base de Datos de Gestión de la Configuración (CMDB) 60, 94 Biblioteca de la Infraestructura de Tecnología de Información (ITIL¨) 7, 34, 45, 49, 227 Biblioteca de Software Definitivo (DSL) 107 Biblioteca electrónica 94 BS 15000 35, 45

C Calendario de auditoría 37 Calendario de cambios y entregas 109 Calidad 5

Cambio de emergencia 111, 119, 228 Cambio externo 183 Campo de aplicación 35 Capacidad 18 Características de carga de trabajo 129, 187 Categoría 114, 215 Catálogo de Servicios 129, 136, 227 Código de buenas prácticas 63 Código de Práctica 2, 52 Centro de Atención al Usuario 62, 205, 207 Certificación de empresas 2, 35 Certificación individual 3, 38 Ciclo de vida de la incidencia 179 Ciclo PDCA 6, 50, 224 Cierre formal 201, 204 Clasificación 201, 204, 209, 211, 215 Cálculo de disponibilidad 181 Cliente 9, 154 CMMI 33 CobiT® 33 Componente 8, 16, 21, 30 Compromiso de la dirección 66 Concienciación 72 Conjunto de actividades 10, 25 Consensor del sector 54 Consultor de gestión de la Calidad del Servicio 39 Consultor de Servicios de TI 39 Contabilidad de activos financieros 93 Contrato 61, 150, 159 Contrato de Soporte (UC) 136 Contrato de suministrador 129, 159 Control 27 Control de entregas 125 Control de la configuración 94, 95, 96 Control de la gestión 35 Control de seguridad 190, 192 Copias maestras 94 Criterios de auditoría 84 Cuadro de Mando Integral 87 Cuestionario 37


240

D Declaración de alcance 36, 229 Declaración de política 61 Deficiencia 97, 110 Definición del servicio 160 Definición de queja 152 Deming 6, 50, 224 Descripción de proceso 16, 55 Director de TI 39 Directrices de documentación 51 Directrices de negocio 79 DISC PD 0005 45 Disponibilidad 18, 60, 164, 176, 225, 226 Distribución 119, 122 Documentación 38, 54, 56 Documento 55, 57, 61, 67, 228

E Eficacia 27 Eficiencia 27 Elemento de Configuración (CI) 60, 93 Elementos de configuración digitales 94 Eliminación de un servicio 91 Empaquetado 119 Encuesta de satisfacción del cliente (CSS) 157 Enfoque a cliente 5, 8, 152 Enfoque coherente 5, 52, 54 Entidad de Certificación Registrada (RCB) 2, 35 Entidad Nacional de Acreditación (NAB) 35 Entorno de pruebas de aceptación 119, 121 Entrada 10, 27 Entrega 61, 118, 123 Entrega de emergencia 119 Error conocido 209, 214, 216 Escalabilidad 18 Escalado 160, 202, 207, 210 Especificación 2, 52 Estado 215 Estrategia de continuidad del servicio 165 Evaluación 30, 31, 37 Evaluación comparativa 32, 79 Evaluación de capacidad 30 Evaluación de madurez 30 Evaluación de riesgos 164, 165, 168


Evaluación de riesgos de seguridad 191 Evidencia 23, 56, 61, 65, 228 EXIN 42 Éxito rápido 79 Expectativas del cliente 9, 14, 222

F Factor Crítico de éxito (CSF) 86 Flujo de trabajo 26 Fondos 91 Formulario de solicitud 37 Foro Internacional de Acreditación (IAF) 35

G Gestión de contratos 159, 160 Gestión de disputas contractuales 158, 160 Gestión de la Calidad 5 Gestión de la Calidad del Servicio 1, 7 Gestión de la Calidad Total (TQM) 6 Gestión de quejas 154 Gestión de Servicios 62 Gestión de Servicios de TI (ITSM) 21 Gestor de la Calidad 39 Gestor del proceso 28 Gobierno 33, 224 Grupo de interés 34

H Herramientas 23

I Identificación proactiva 59, 208 Impacto 114, 200, 206, 215 Imparcialidad 41, 84 Incidencia 61, 201, 225 Incumplimiento 38 Independiente del marco de trabajo 1 Indicador Clave del Rendimiento (KPI) 86, 136 Informe de auditoría 32, 38, 61 Informe del servicio 138, 139, 227 Informe proactivo 139 Informe reactivo 139 Instalación 119, 122 Institución Británica de Normalización (BSI) 35, 45


Índice alfabético

Instrucción de Trabajo 16 ISO 9000:2005 14 ISO 9001:2000 7, 51 ISO 9004 51 ISO/IEC 9000 5, 8, 33, 46, 51 ISO/IEC 15504 33 ISO/IEC 17799 190, 196 ISO/IEC 20000 33, 44, 46, 51 ISO/IEC 27001 34 itSMF UK 42, 45

J Jefe de proyecto 39

L Lista de Cambios Planificados (FSC) 115 Límites de carga de trabajo 130 Línea base 225, 227 Línea base de configuración 94, 106, 121, 174 Línea de referencia 1, 31, 60

M Marcha atrás 116, 118, 126 Marco de trabajo 33 Matriz de disponibilidad 180 Mejora continua 7, 11, 28, 51, 86, 224 Mejora Continua del Servicio (CSI) 50, 59 Método de Análisis y Gestión de Riesgos de la CCTA (CRAMM) 171, 181 Metodología de procesos integrados 10, 52 Métrica 86 Modelado 187 Modelo de madurez 29, 79 Modelo ERSCR 27 Monitor 50 Monitorización 10, 217, 224 Monitorizar 72, 84

N Necesidades del cliente 9, 14, 222 Nivel de Madurez 29 Norma de calidad 54

241

O Objetividad 84 Objetivo específico de nivel de servicio 129 Objetivos de calidad 14, 32, 222 Objetivos de Mejora del Servicio 89 Obligaciones 2, 52 Observación 38 Operador ITSM 39 Operativo del proceso 28 Organización Internacional de Normalización (ISO) 51

P Partes interesadas 7, 9, 10 Percepción de la calidad 19 Personal competente 39 Petición de Servicio 114, 206 Plan de Acciones Correctivas (CAP) 38 Plan de Calidad del Servicio 136 Plan de capacidad 183, 186 Plan de continuidad del servicio 164, 166 Plan de disponibilidad 164, 180 Plan de entrega y despliegue 119, 120, 122, 127 Plan de Gestión de Servicios 65, 67, 75, 76, 77 Plan de Mejora del Servicio (SIP) 38, 74 Plan de pruebas 127 Planificación de los recursos 76 Política 14, 32 Política de calidad 14, 32, 88, 222 Política de entregas 118, 120, 123, 125 Política de Gestión de Servicios 65, 67 Política de Mejora del Servicio 87 Política de seguridad de la información 190, 192 Portabilidad 18 Presupuesto 54, 143, 144 Prioridad 114, 200, 206, 215 Problema 61, 208 Procedimiento 55, 56, 61, 67 Procedimiento de reclamaciones 153 Proceso 10, 25 Proceso de certificación 37 Proceso de gestión de quejas 152


242

Profesional/Gestor de Servicios de TI 39 Programa de auditoría 84 Programa de Reconocimiento Multilateral (MLA) 35 Propietario del proceso 28 Propietario responsable sénior 56, 65 Proveedor de servicios 62 Puesto de Observación Técnica (TOP) 181

R Recomendaciones 2, 52 Recuperación 168, 171 Recursos 54, 63 Reducción de riesgos 168 Registro 55, 56, 57, 61, 67, 228 Registro de cambio 60, 225 Registro de configuración 96, 97 Registro Internacional de Auditores Certificados (IRCA) 42 Relaciones de mutuo beneficio con los suministradores 13 Rendimiento 18, 51 Requisitos de la Gestión del Servicio 84 Requisitos del cliente 8, 14, 19, 65, 154, 227 Requisitos del negocio 62, 183 Resolución de incidencias 200, 229 Resolución de problemas 200, 210, 229 Responsabilidad 28, 56, 66, 67, 74, 77 Respuesta 27 Resultado 27 Resultados deseados 13, 14, 82 Revisión de Gestión de Servicios 67, 84 Revisión del servicio 152, 153 Revisión Post-Implantación (PIR) 87, 91, 117, 225 Revision de problemas 210 Rol 28, 39, 42, 77


Seguimiento 210, 217 Seguridad 18 Servicio 16 Servicio degradado 202 Servicio de TI 16 Sistema de Gestión 7, 13 Sistema de Gestión de la Calidad 10, 13, 31 Sistema de Gestión de la Calidad basado en procesos 10 Sistema de Gestión de Servicios de TI 2, 21 Sistema de Gestión genérico 51 Six Sigma 34 Solicitud de Cambio (RFC) 61, 114, 123 Suministrador 158, 223 Suministrador principal 139, 158, 160 Suministrador subcontratado 158 Supervisión de la Disponibilidad 165

T Tiempo Medio de Restauración del Servicio (MTRS) 179 Toma de decisiones con fundamento real 12 Trazabilidad 96 TÜV SÜD 42

U Urgencia 200, 206, 215 Usuario 9, 154

V Valoración de certificación 38 Valoración inicial 38, 114 Valoración interna 37 Verificación y aceptación de entregas 121 Verificación y auditoría de la configuración 97 Vinculaciones entre procesos 73

S Salida 10, 27 Satisfacción del cliente 51, 67, 131, 153, 154


ITIL Books Foundations of IT Service Management Based on ITIL®V3

English €39.95 excl tax

Now updated to encompass all of the implications of the V3 refresh of ITIL, the new V3 Foundations book looks at Best Practices, focusing on the Lifecycle approach, and covering the ITIL Service Lifecycle, processes and functions for Service Strategy, Service Design, Service Operation, Service Transition and Continual Service Improvement. ISBN 978 90 8753 057 0

(english edition)

Foundations of IT Service Management Based on ITIL® The bestselling ITIL® V2 edition of this popular guide is available as usual, with 13 language options to give you the widest possible global perspective on this important subject. English €39.95

ISBN 978 90 77212 58 5

(english edition)

excl tax

IT Service Management Based on ITIL® V3: A Pocket Guide A concise summary for ITIL®V3, providing a quick and portable reference tool to this leading set of best practices for IT Service Management. English €15.95

ISBN 978 90 8753 102 7

(english edition)

excl tax

Van Haren Publishing is a leading international publisher, specializing in best practice titles for IT management and business management. Van Haren Publishing publishes in 14 languages, and has sales and distribution agents in over 40 countries worldwide: www.vanharen.net Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

ISO/IEC 20000 ISO/IEC 20000: An Introduction Promoting awareness of the certification for organizations within the IT Service Management environment. ISBN 978 90 8753 081 5

(english edition)


Implementing ISO/IEC 20000 Certification: The Roadmap Practical advice, to assist readers through the requirements of the standard, the scoping, the project approach, the certification procedure and management of the certification. English €39.95 excl tax

ISBN 978 90 8753 082 2

(english edition)

ISO/IEC 20000: A Pocket Guide A quick and accessible guide to the fundamental requirements for corporate certification.

ISBN 978 90 77212 79 0

(english edition)


www.vanharen.net Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Other leading ITSM Books Metrics for IT Service Management A general guide to the use of metrics as a mechanism to control and steer IT service organizations, with consideration of the design and implementation of metrics in service organizations using industry standard frameworks. €39.95 excl tax

ISBN 978 90 77212 69 1

Six Sigma for IT Management


The first book to provide a coherent view and guidance for using the Six Sigma approach successfully in IT Service Management, whilst aiming to merge both Six Sigma and ITIL® into a single unified approach to continuous improvement. Six Sigma for IT Management: A Pocket Guide is also available. ISBN 978 90 77212 30 1

(english edition)

Frameworks for IT Management An unparalleled guide to the myriad of IT management instruments currently available to IT and business managers. Frameworks for IT Management: A Pocket Guide is also available. English €39.95

ISBN 978 90 77212 90 5

(english edition)

excl tax

IT Governance based on CobiT 4.1: A Management Guide Detailed information on the overall process model as well as the theory behind it. English €22.50

ISBN 978 90 8753 116 4

(english edition)

excl tax


www.vanharen.net




ISO-IEC 20000 - Una Introducción.pdf

Recommend Documents