9789087532932PROT_unlocked

5/10/2018 9789087532932PROT_unlocked - slidepdf.com

http://slidepdf.com/reader/full/9789087532932protunlocked 1/261

Copyright protected. Use is for Single Users only via a VHP Approved License.

For information and printed versions please see www.vanharen.net


http://slidepdf.com/reader/full/9789087532932protunlocked 2/261Copyright protected. Use is for Single Users only via a VHP Approved License.




La Biblioteca de Gestión de Servicios de TI

Libros de introducción, undamentos y para proesionales• Foundations o IT Service Management based on ITIL® (versión 2, en árabe, chino, alemán, inglés, rancés, italiano,

japonés, coreano, holandés, portugués de Brasil y ruso; danés y español)• Foundations o IT Service Management based on ITIL® V3 (en inglés, holandés, alemán, italiano y español; ediciones

en rancé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 or 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 or IT Service Management (en inglés y ruso)• Six Sigma or IT Management (en inglés y coreano)• The RP or IT Outsourcing - A Management Guide (en holandés)• Service Agreements - A Management Guide (en inglés)• Frameworks or 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 Certication - 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,

rancé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 or IT Management - A Pocket Guide (en inglés)• Frameworks or IT Management - A Pocket Guide (en inglés y holandés)

Otros• IT Service Management rom Hell!! (cubriendo versión 2, en inglés)• IT Service Management rom 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

ColoónTítulo: ISO/IEC 20000 - Una introducción

Editores: Jan van Bon (editor en jee, Inorm-IT)Selma Polter (coautora y editora, Inorm-IT)Tieneke Verheijen (coautora y editora, Inorm-IT)Mike Pieper (editor edición español, Inorm-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, Amersoort (Holanda)

Extractos de BS ISO/IEC 20000-1:2005 y BS ISO/IEC 20000-2:2005 reproducidos con autorización de laInstitución Británica de Normalización (BSI). Las Normas Británicas se pueden adquirir en ormato PDF en latienda on-line de BSI (http://www.bsi-global.com/en/Shop/) o en papel a través de los Servicios de Atención alCliente 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) orman un sistemaespecializado que omenta la normalización a nivel mundial. Los organismos nacionales que son miembros de ISO o IECparticipan 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ícos. Los comités técnicos de ISO e IEC colaboran en campos de interés común. Enesta tarea participan también otras organizaciones internacionales (gubernamentales y no gubernamentales) asociadas con ISOe IEC. En el campo de las Tecnologías de la Inormación, ISO e IEC han creado un comité técnico conjunto denominadoISO 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 porel comité técnico conjunto se transmiten a los organismos nacionales y se someten a votación. La publicación como NormaInternacional requiere la aprobación de al menos el 75% de los organismos nacionales con derecho a voto.

El nombre ocial de la norma es ISO/IEC 20000, aunque en la práctica se utiliza simplemente “ISO 20000” por ser másbreve y sencillo.

Si desea más inormación sobre Van Haren Publishing, envíe un corre electrónico a:

[email protected].

©Van Haren Publishing 2008Todos los derechos reservados. Queda prohibida la reproducción de esta publicación en orma alguna, ya seaimpresa, microlmada 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 editorano se hacen responsables de ningún daño que se pueda producir como consecuencia de errores y/u omisiones enesta publicación.

PRINCE2™, M_o_R ® e ITIL® son marcas comerciales registradas y marcas comerciales comunitarias registradasde la Ocina de Comercio del Gobierno, y están registradas en la Ocina 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 Inormación (ISACA)/Instituto de Gobierno de TI (ITGI).





V

Preacio

Por John Stewart, Director de Normas y Política de Adquisiciones en la Ocina de Comercio del Gobierno (OGC) del Reino Unido. A su trabajo y al del diunto Pete Skinner debemos el concepto

ITIL. John Stewart dirigió las primeras ases del desarrollo de ITIL y actualmente se ocupa de nuevodel 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 organizacionesdependen cada vez más de las Tecnologías de la Inormación para alcanzar sus objetivoscorporativos y satisacer sus necesidades de negocio. Esta mayor dependencia hace que cada vezsea más importante contar con servicios de TI de la máxima calidad, es decir, adaptados a loscambios en las necesidades de negocio y los requisitos de los usuarios. Este libro orma parte deuna serie de códigos de prácticas pensados para acilitar la gestión de la calidad en los servicios de

TI.” Estas líneas proceden del preacio de las publicaciones de la versión 1 de ITIL, la primera delas cuales ue 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 ascinantes y otras resultan absolutamente esperpénticas, pero ninguna de ellases cierta. La verdad es que, como desarrolladores de proyectos, propusimos la idea porque nospreocupaba ver que el Gobierno Británico, a pesar de depender cada vez de las Tecnologías de laInormación, dejaba su gestión a las distintas organizaciones y carecía de un enoque común o deuna denición clara de “lo que está bien”. Cuando nuestro Comité acordó nanciar los primerostrabajos de desarrollo, comenzamos a buscar ejemplos de buenas prácticas y colaboramos con los

distintos grupos de interés para conseguir un enoque coherente.

ITIL pertenecía al Gobierno Británico, que de esta orma se podía colocar “por encima delmercado”. Desde este punto de vista, ITIL tenía el potencial de convertirse en un estándar deacto para la Gestión de Servicios de TI. Al abogar por un mercado abierto y competitivo para laprovisión de servicios y productos basados en ITIL, nuestro objetivo era extender las ventajas delconcepto a organizaciones ajenas al sector público británico y, al mismo tiempo, conseguir queITIL se beneciara de las opiniones y aportaciones de una base mayor de grupos de interés.

ITIL es una especie de “lengua ranca” que avorece la adopción de un enoque más uniormepara la Gestión de Servicios de TI. Ayuda a los usuarios a no tener que reinventar la orma enque gestionan sus servicios de TI, ya que les orece 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 prioridadesiniciales: en primer lugar, el hecho de que publicáramos una Biblioteca de Gestión de la Calidadpoco después de los primeros volúmenes de ITIL; y en segundo lugar, la concesión (quizás porvez primera en el Gobierno Británico) del certicado ISO 9001 a nuestro trabajo sobre ITIL y temas anes.

Gracias al esuerzo de muchas organizaciones y personas, ITIL se ha convertido por derechopropio en un éxito internacional. Me gustaría dar las gracias al gran número de organizaciones





VI

que han centrado sus actividades en el mercado de ITIL, así como a la multitud de organizacionesde usuarios que han adoptado ITIL como base para la gestión de sus servicios de TI. Sin estasorganizaciones, 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 hacerpara omentar 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 muchomás ácil si existiera una norma internacional complementaria. Por eso quiero agradecer a lospromotores y desarrolladores de ISO 20000 la visión de uturo con que concibieron la norma,y sus esuerzos por hacerla realidad. Juntas, ISO 20000 e ITIL nos permitirán avanzar hacia unobjetivo común: mejorar las Tecnologías de la Inormación y aumentar la ecacia del soporte aempresas y gobiernos allí donde se utilicen.

Conío en que los lectores compartan este objetivo y puedan beneciarse de él.





VII

Agradecimientos

ISO/IEC 20000, la norma internacional sobre Gestión de Servicios de TI, está despertandomucha atención entre los proesionales. Muchas organizaciones y personas están interesadas en

las oportunidades que orece la norma y organizan encuentros para hablar de ello. El objetivo deeste libro es servir como guía de introducción a la norma para todos aquéllos que participen enun proyecto de certicació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 uturo, tendrán una granimportancia 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 deprimera editora, diseñó el índice de este libro y dedicó un gran esuerzo a preparar presentacionesgrácas 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, combinandosus 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 distintosprocesos incluidos en la norma.

El editor jee, Jan van Bon, se encargó del proyecto en su totalidad, asegurándose de que ellibro respondiera a las necesidades del mercado. También participó en la revisión nal de loscontenidos del libro, con particular atención a los grácos.

Debemos un agradecimiento especial al Sr. Leo van Selm, quien amablemente se oreció comocoautor 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 sobrecerticados para personas individuales y organizaciones.

La versión nal del manuscrito ue revisada por 30 personas, quienes realizaron su tarea con grandesdosis 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 acilitó la participación de los siguientes miembros deeste 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 decerticación, el Sr. Leo van Selm nos puso en contacto con otros colegas a quienes tambiéndeseamos agradecer su apoyo en el trabajo de revisión:• Michael Busch, de it SolutionCrew GmbH (Alemania)• David Cliord, 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 unieronal equipo por distintas vías:• Gérald Audenis, de ORSYP Consulting (Francia)• Rob van der Burg, de Microsot (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)• Alons Huber, de TÜV SÜD Inormatik 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 ueron consideradas por los editores y por elcoautor Leo van Selm, mejorando el manuscrito y adaptando sus contenidos a la opinión de losexpertos. Todos los revisores expresaron su satisacción con el proceso y certicaron su cierre.

Fiel a su objetivo de diundir los conocimientos sobre Mejores Prácticas, itSMF España noha 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 haparticipado un equipo multidisciplinar de considerable tamaño:• Antonio Cruz Andrade, de Quint Wellington Redwood• Francisco Gil - de Rene• Julio Ballesteros - de Quint Wellington Redwood• Isabel Diaz - de New Horizons Madrid• Manuel Diaz - de Teleónica España• Orlando Pereda - de Inormá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 enla traducción y adaptación al castellano de esta edición.

Conamos en que este libro sea una guía clara y amena a ISO/IEC 20000, y que le sirva parapreparar de la mejor orma posible los exámenes individuales y la certicación de la organización.Encontrará más inormación práctica sobre la certicación en la publicación que acompaña a estelibro: “Implementing ISO/IEC 20000 Certication, A Roadmap”. El equipo editorial recibirácon agrado todas las propuestas de mejora y las incorporará en uturas ediciones. Puede enviarsus comentarios al editor jee a la dirección [email protected].

Jan van Bon

Editor general de la Biblioteca de Gestión de Servicios de TI





X





XI

Índice

Preacio ��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 Qué es la calidad ��52�2 Qué es el servicio ��142�3 Qué es la Gestión de Servicios de TI ��212�4 Qué son los procesos ��242�5 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 ��333�2 Conceptos de prácticas de certicación ��353�3 Concepto de ISO 20000 ��44

4 Especifcaciones y Código de buenas prácticas para ISO 20000 ��63

4�1 Gestión y mejora de procesos de Gestión de Servicios de TI ��644�2 Control de servicios de TI ��914�3 Alineación entre el negocio y las Tecnologías de la Inormación ��1294�4 Entrega de servicios de TI ��1644�5 Soporte de servicios de TI ��199

5 El examen de Fundamentos de ISO/IEC 20000 �� 219

5�1 Prerrequisitos ��2205�2 Formato de examen ��2205�3 Reclamaciones ��221

5�4 Preparación del examen de Fundamentos de ISO/IEC 20000 ��2215�5 Preguntas de ejemplo ��222

Lista de abreviaturas ��231Reerencias��235Índice alabético ��239





XII





La calidad de la Gestión de Servicios de TI (ITSM) es uno de los requisitos más importantes parapoder orecer servicios que no pasen desapercibidos y sean muy valorados por el negocio. Conla publicación de la norma ISO 20000 para la Gestión de Servicios de TI, los principios ISOsobre gestión de la calidad se han combinado con los procesos ITSM estándares en el sector. Estacombinación se plasma en una norma internacional muy práctica y ácil de aplicar, que garantizala calidad de la Gestión de Servicios de TI y que tiene por objeto suministrar servicios gestionadosde 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 Serviciosde TI en todo el mundo. En los últimos años han surgido numerosas normas que se centranundamentalmente en la calidad y la provisión de servicios y que están basadas en las demandasde los clientes y el negocio. La norma ISO 20000 especica una serie de requisitos mínimosque deben cumplir todos los proveedores de servicios, además de denir una línea de reerenciaindependiente 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 queorece una orma de explorar la amplia guía de mejores prácticas, ya sea en la nueva versión deITIL® o en otros marcos de trabajo como CobiT®.

ISO 20000 es independiente de todos los marcos de trabajo; es “neutral” a ellos. No existeningún control denido o implícito entre la norma y los marcos de trabajo (como MOF, ITIL® y Modelos de Reerencia como el ITSM de HP o el IPW de Quint) o sus correspondientessistemas de cualicación. No obstante, existen muchos marcos de trabajo tanto públicos comoprivados (mejores prácticas internas) que pueden ayudar a garantizar el reconocimiento de lascapacidades. De hecho, la adopción de dichos marcos de trabajo puede signicar la consecuciónde la certicación ISO 20000.

Los proveedores internos y externos de servicios tienen el reto de demostrar que sus procesosde Gestión del Servicio aseguran la calidad que sus clientes exigen. De hecho, los proveedores

Capítulo 1

Introducción





2 ISO/IEC 20000 – Una introducción

externos de servicios ya están siendo instados a obtener la certicación ISO 20000 como parte dealgunas convocatorias de licitación.

Aunque cualquiera podría asegurar que una organización satisace los requisitos de ISO 20000, elprograma de certicación que gestiona itSMF UK aporta credibilidad al proceso. Este programa

supedita la concesión de la certicación ISO 20000 al resultado de auditorías realizadas porEntidades de Certicación Registradas (RCBs), basadas en ISO 20000 Parte 1 (“Especicaciones”).Esto garantiza que un proveedor de servicios diseña, implanta y gestiona un sistema de Gestiónde 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 SANS15000) indica que los programas de certicación para proveedores de servicios de TI generantambién una demanda de ormación y certicación, por ejemplo, para auditores, propietarios deprocesos, responsables de la Gestión del Servicio y consultores.

También se genera un mayor interés entre los proesionales de la Gestión de Servicios de TI, tantopor parte de los clientes como de los proveedores de servicios. En un uturo próximo es probableque sea imprescindible conocer ISO 20000 (en sus aspectos básicos, al menos) para poder aspirara muchos puestos de Gestión de Servicios de TI.

1.1 Cómo utilizar este libroEsta publicación, que se puede emplear como reerencia para los exámenes de Fundamentos deISO 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 lanorma, utilizando para ello grácos y una guía de mejores prácticas.

Este libro se puede usar también para preparar la certicación ISO 20000 de una empresa.Explica los requisitos de ISO 20000 y describe cómo satisacerlos empleando Mejores Prácticas.

Los lectores que participen directamente en un proceso de certicación también pueden utilizaresta publicación como guía para mejorar la calidad de los servicios que orecen.

El Capítulo 2 presenta los principios de gestión de la calidad del servicio, discutiendo la gestiónde 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ásde explicar el concepto de prácticas de certicación.

A continuación se presentan las distintas partes de la norma ISO 20000, incluyendo tanto losrequisitos como las mejores prácticas. Siempre que es posible, se utilizan grácos para distinguir laspartes exigidas por las especicaciones 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ómoprepararlo. Actualmente, itSMF UK, ISEB y EXIN/TÜV SÜD están preparando exámenespara evaluar la competencia individual en las prácticas de ISO 20000, incluyendo procesosde consultoría y auditoría basados en la norma. En el momento de redactar este texto sólo sedisponía de inormación sobre el programa de certicación de EXIN/TÜV SÜD, por lo que la

mayor parte de la inormación orecida en este libro está basada en ese material, incluyendo laspreguntas de ejemplo. No obstante, el libro incluye toda la inormación que necesita cualquierestudiante que se aproxime por primera vez a ISO 20000, y se puede usar para preparar cualquierexamen de ISO 20000 de nivel undamental.










Las empresas dependen cada vez más de servicios con un elevado nivel tecnológico. Hoy másque nunca, el éxito del negocio y de las Tecnologías de la Inormación se basa en su capacidad desatisacer las expectativas de una base de clientes cada vez más exigente. Escándalos de gobiernocorporativo 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 deque el sector de las Tecnologías de la Inormación adopte una metodología coherente, enocada alcliente 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 denición del concepto. A eso se dedica lapró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 dene de esta orma:

Se puede hablar de calidad cuando el cliente recibe todas las características que exige de unproducto (o servicio).

La gestión de la calidad incluye, por tanto, todo lo que hace la organización para garantizarque sus productos o servicios satisacen los requisitos de calidad de los clientes y cumplentodas las normas aplicables a esos productos o servicios.

Para el departamento de servicios de TI, la Gestión de la Calidad consiste en comprender laperspectiva del negocio sobre calidad y servicio y en asegurar que el servicio está diseñado y gestionado para cumplir estas especicaciones.

Capítulo 2

Principios de Gestión de laCalidad del Servicio






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 laorganización a satisacer las demandas del cliente interno o externo con el n de conseguiruna ventaja competitiva. Se trata de un término genérico que se utiliza para describir un

enorme conjunto de losoías, conceptos, métodos y herramientas.

Existen diversos métodos que permiten gestionar la calidad de un servicio de TI. Todos ellostienen su origen en las primeras décadas del siglo XX. Desde entonces las empresas han tratadosiempre de controlar la calidad de sus productos, impulsadas undamentalmente por la revolucióntecnológica. Este proceso recibió el nombre de Gestión de la Calidad Total (TQM) en la décadade 1980.

El ciclo Planifcar-Hacer-Verifcar-Actuar

William Edwards Deming partió de un sencillo diagrama de un ciclo de mejora de la calidad y le añadió el ciclo Planicar-Hacer-Vericar-Actuar (denominado ciclo PDCA e ilustrado en laFigura 2.1)1:• Planifcar - 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 planicadas.• Verifcar - Comprobación de que las actividades dan el resultado deseado.• Actuar - Ajuste de los planes en unción de los resultados de la ase de vericación.

1 Deming se inspiró en uno de sus proesores, Walter Shewhart, quien ya había propuesto un “ciclo de aprendizaje ymejora”�

Figura 2�1 El ciclo PDCA� La cuesta se sube siguiendo sucesivamente las ases P, D, C y A�

TIEMPO

CALIDAD

Mejorade la calidad

Sentido de giro

Gestión de la calidad1 PLANIFICAR2 HACER3 VERIFICAR4 ACTUAR

Aseguramientode lacalidad

I S O

/ I E C 2 0 0 0 0

P D

A C





Principios de Gestión de la Calidad del Servicio 7

Este círculo orma parte del sistema de mejora continua tanto en ISO 9000 como en ISO20000. Fue Joseph Juran quien introdujo el “concepto de mejora continua”. Este importante“padre undador” de TQM estableció el enoque a cliente como otro concepto undamental de laGestión de la Calidad Total. Un diálogo continuo con el cliente es imprescindible para garantizarque tanto el cliente como el suministrador saben lo que se espera de un servicio.

El tercer concepto introducido por Juran ue el del valor de cada asociado. Los empleadosinfuyen 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 hastaqué punto su trabajo ayuda a alcanzar los objetivos de la organización, de manera que se sientanautorizados y responsables para llevar a cabo las tareas que se les haya asignado. Esto mejorará lasatisacción de los empleados y omentará la productividad y la innovación. La ormación y losexá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 TILa gran importancia que adquirieron las Tecnologías de la Inormación en muchos sectoresdurante la década de 1980 hizo que aumentara la demanda de sotware y de modelos, métodosy herramientas para TI. Para un número de productos cada vez mayor (los del sector de laelectrónica de consumo o las comunicaciones, por ejemplo), el tiempo total de desarrollo pasó adepender undamentalmente del tiempo que se tardaba en desarrollar el sotware. Esto hizo queresultara especialmente importante mejorar la ecacia y la eciencia de los procesos de desarrollode sotware.

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 Inraestructura de Tecnología de Inormación (ITIL ®). Deeste 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 inormación es able y segura. No es posible mejorar los procesos de una organización si no se cuenta con inormacióncompleta y precisa que pueda servir de base en la toma de decisiones. El primer elemento cuyacalidad hay que garantizar es por tanto la inormación de gestión, ya que sirve y aecta a todos losdemás productos y procesos.

TQM combina distintos sistemas de gestión de la calidad, por lo que no existe ningunacerticación “ocial” para TQM. Junto con distintos premios a la calidad (como el PremioNacional de Calidad Malcolm Baldrige o los premios de la Fundación Europea para la Gestiónde la Calidad), la certicación ISO 9001:2000 indica que una organización se rige según losprincipios de TQM. Las empresas con certicación ISO 20000 tienen que haber superado unaauditoría basada en las mejores prácticas internacionales para ITSM.

2.1.3 Principios (componentes) de la gestión de la calidadLa buena gestión de una organización exige que sea dirigida y controlada de un modo sistemáticoy 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.






La norma ISO 20000 para Gestión de Servicios de TI debe mucho a ISO 9000, la normainternacional para gestión de la calidad. Entre otras cosas, incluye los ocho principios de lagestión de la calidad de ISO 9000 (Figura 2.2):• Enoque 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 benecio con los suministradores• Planteamiento de sistema para la gestión

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

Enoque a clienteTodas las organizaciones dependen de sus clientes. Eso las obliga a comprender las necesidadespresentes y uturas de los clientes, satisacer sus requisitos y hacer todo lo posible por superar susexpectativas.

Las principales ventajas del enoque a cliente son:• Aumento de los ingresos y de la cuota de mercado gracias a una respuesta más rápida y fexiblea las oportunidades que orece el mercado.

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

Relaciones con lossuministradores

Planteamientode sistema

para la gestión

Mejoracontinua

Implicación delas personas

Planteamientode procesos

LiderazgoPlanteamiento

basado en hechos

LOS OCHO

PRINCIPIOS

DE LA GESTIÓN

DE LA CALIDAD

Enfoque a cliente






• Uso más ecaz de los recursos de la organización para aumentar el grado de satisacción de losclientes.

En general, la aplicación del principio de enoque a cliente permite:• Desarrollar una estrategia corporativa basada en las necesidades uturas de los clientes.

• Analizar y comprender las necesidades y expectativas de los clientes, vinculando a ellas losobjetivos de la organización.

• Comunicar las necesidades y expectativas de los clientes a toda la organización.• Medir el grado de satisacción de los clientes y actuar en consecuencia.• Gestionar las relaciones con los clientes de una orma sistemática.• Conseguir un equilibrio entre la satisacción de los clientes y la de otras partes interesadas (como

propietarios, empleados, suministradores, nancieros, comunidades locales y el conjunto de lasociedad).

A veces hay que distinguir entre el cliente y el usuario de un servicio. La persona que pagapor el servicio es el cliente, pero no siempre coincide con la persona que lo utiliza y que es,por denición, el usuario. En última instancia, los requisitos del cliente son siempre lo másimportante, aunque es probable que el cliente tenga en cuenta las experiencias de los usuarios ala hora de evaluar los servicios recibidos.

LiderazgoLos líderes son los encargados de establecer la unidad de acción y los objetivos comunes de laorganización. Para ello deben crear y mantener un ambiente en el que todo el mundo se sientaplenamente 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 unicado.• Se minimiza la alta 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, nancieros, comunidades locales y el conjunto de la sociedad).• Tener una idea clara del uturo de la organización.• Denir metas y objetivos especícos que estimulen el progreso.• Crear y sostener valores comunes, ecuanimidad y modelos de comportamiento en todos los

niveles de la organización.• Fomentar la conanza y disipar temores.• Proporcionar a las personas los recursos, la ormación y la libertad que necesitan para actuar de

orma 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 permiteaprovechar al máximo el potencial de todos en benecio de la organización.






Las principales ventajas de la implicación de las personas son:• Una organización ormada 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 actores 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 unció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 ranca de todo tipo de asuntos y problemas.• Reducir los confictos dentro de la empresa.• Mejorar la orma en que los clientes perciben la organización.

Planteamiento de procesosGestionar actividades y los recursos correspondientes como un proceso permite alcanzar el

resultado deseado de una orma más eciente, 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 inormación en la Sección 2.4). Un proceso tiene entradas y salidas. Las organizacionesque persiguen la ecacia en su uncionamiento tienen que identicar y gestionar numerososprocesos que están relacionados entre sí, ya que es recuente que la salida de un proceso pasedirectamente a ser la entrada del siguiente proceso. La identicación y gestión sistemáticas de losprocesos 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 ecaz de los recursos.• Resultados mejorados, coherentes y predecibles.• Oportunidades de mejora enocadas y con prioridades asignadas.

La Figura 2.3 presenta un sistema de gestión de la calidad basado en procesos tal como se describeen ISO 9000. Aunque no muestra los procesos en detalle, deja claro que las partes interesadasdesempeñan un rol importante, ya que proporcionan entradas a la organización. Para monitorizarlos niveles de satisacción de las partes interesadas es necesario contar con inormación sobre su

percepción y determinar hasta qué punto se han satisecho sus necesidades y expectativas.






En general, la aplicación de una metodología de procesos permite:

• Concentrarse en los resultados previstos de las actividades integradas en el proceso.• Denir de orma sistemática las actividades necesarias para obtener el resultado deseado.• Denir con claridad las responsabilidades de la dirección para las actividades clave.• Analizar y medir la capacidad de las actividades clave.• Identicar las interaces de las actividades clave en y entre las distintas unciones de la

organización.• Concentrarse en los actores (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 elrendimiento de la organización y la satisacción de los clientes. Este punto debe ser un objetivopermanente 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 laorganización.• Flexibilidad para reaccionar con rapidez ante las oportunidades.

Mediciónanálisismejora

Responsabilidadde la dirección

Realizacióndel producto

Gestiónde recursos

ENTRADA SALIDAPROCESO

Requisitodel cliente

Satisfaccióndel cliente

Mejoracontinua

Verificar

Actuar

Planificar

Hacer

S i s t ema de Gestión de la Ca l i da d

PROCESOSDEPROVISIÓNDESERVICIO

PROCESOSDE CONTROL

PROCESODEENTREGA

Gestiónde la ConfiguraciónGestiónde Cambios

Gestiónde la Entrega

Gestiónde la Capacidad

Gestiónde la Disponibilidady la Continuidad del

Servicio

PROCESOSDERESOLUCIÓN

Gestiónde Incidencias

Gestiónde Problemas

Gestióndel Nivelde Servicio

Informes delServicio

PROCESOSDERELACIÓN

Gestiónde RelacionesconelNegocio

Gestiónde Proveedores

Gestiónde la Seguridaddela Información

Presupuestos y Contabilidadde los Servicios de TI

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






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 identicar áreas de mejora.• Denir 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 eectuar un seguimiento de la mejora continua.• Medir, vericar, 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 confictos 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 identicar nuevas oportunidades demejora. De esta orma, la mejora se convierte en una actividad continua. Los comentarios de losclientes y otras partes interesadas, las auditorías y la revisión del sistema de gestión de la calidadtambién pueden ayudar a detectar oportunidades de mejora.

Planteamiento basado en hechos para la toma de decisionesLas decisiones ecaces se basan siempre en el análisis de datos e inormación.

Principales ventajas:• Decisiones basadas en inormación precisa y completa.• Mayor capacidad para demostrar la ecacia 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 espreciso:• Garantizar que los datos y la inormación son lo sucientemente precisos y ables.• Hacer que los datos sean accesibles a quien los necesite.• Analizar los datos y la inormación empleando métodos válidos.

En general, la aplicación de este principio permite adoptar decisiones y acciones basadas en unanálisis de hechos que apoya a la experiencia y la sabiduría.

Relaciones de mutuo benefcio con los suministradores

Una organización y sus suministradores son mutuamente dependientes, por lo que una relaciónque sea beneciosa para las dos partes aumentará la capacidad de ambas para generar valor.






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 benecio con los suministradorespermite:• Establecer relaciones que equilibren las ganancias a corto plazo con las estimaciones a largo

plazo.• Compartir experiencias y recursos con los asociados.• Identicar y seleccionar a los suministradores clave.• Mantener una comunicación ranca y abierta.• Compartir inormación y planes uturos.

• Iniciar actividades conjuntas de desarrollo y mejora.• Inspirar, omentar y reconocer las mejoras y logros de los suministradores.

Planteamiento de sistema para la gestiónEl objetivo de un enoque sistemático es identicar, comprender y gestionar las relaciones entreprocesos, gestionándolos como un sistema. De esta orma, la organización puede alcanzar susobjetivos de una orma más ecaz y eciente.

Las principales ventajas del planteamiento de sistema son:• Integración y alineación de los procesos que permiten alcanzar con más acilidad los resultados

deseados.• Capacidad para concentrar esuerzos en los procesos clave.• Conanza de las partes interesadas en la coherencia, ecacia y eciencia 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 orma más ecaz y

eciente.• Comprender las dependencias mutuas entre los procesos del sistema.• Adoptar enoques estructurados que armonizan e integran procesos.• Comprender mejor los roles y responsabilidades necesarios para alcanzar objetivos comunes,

reduciendo así las barreras entre unciones.• Comprender la capacidad organizativa y denir las limitaciones de recursos antes de emprender

una acción.• Marcar objetivos especícos y denir cómo debe uncionar cada actividad dentro de un

sistema.• Mejorar continuamente el sistema por medio de medidas y evaluaciones.

Encontrará más inormación en la Sección 2.1.4.

2.1.4 Sistemas de gestión de la calidadUn sistema de gestión de la calidad es la orma en que una organización trabaja y gestionasu negocio. Dene la manera en que una organización gestiona la calidad de sus productos o






servicios. ISO 9000:2005 describe las características undamentales de los sistemas de gestión dela calidad y dene términos relacionados.

Como se indicó anteriormente, la satisacció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 denir los procesosque puedan contribuir a desarrollar un producto aceptable para el cliente y a mantener dichosprocesos bajo control. También proporciona un marco de trabajo para mejora continua,aumentando la satisacción de los clientes y otras partes interesadas. Todo ello hace que tantola organización como sus clientes tengan conanza en que los productos cumplirán siempre losrequisitos establecidos.

Un planteamiento para desarrollar e implantar un sistema de gestión de la calidad consta devarios pasos:

• Determinar las necesidades y expectativas de los clientes y otras partes interesadas.• Denir 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.• Denir métodos para medir la ecacia y la eciencia de cada proceso.• Medir la ecacia y la eciencia de cada proceso.• Determinar ormas de prevenir incumplimientos y eliminar sus causas.• Denir 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 lacalidad ya existente.

La política y los objetivos de calidad marcan el camino a seguir por la organización, ya quedeterminan los resultados deseados y ayudan a la organización a aprovechar sus recursos paraalcanzar dichos resultados. La política de calidad dene el marco de trabajo en el que se marcany revisan los objetivos de calidad. Por su parte, los objetivos de calidad tienen que ser coherentescon la política de calidad y con el compromiso de mejora continua, además de ser cuanticables.El cumplimiento de objetivos de calidad puede repercutir positivamente en la calidad de losproductos, en la ecacia operativa y en el rendimiento nanciero, y por tanto también en lasatisacción y la conanza 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 Inormación se consideraban una uente de productos:hardware, sistemas, sotware, ordenadores, etc. Esta situación ha cambiado, como demuestra lagran importancia de las TI para el negocio. Aunque las Tecnologías de la Inormación utilizan

productos para la provisión de servicios de TI, actualmente se consideran sobre todo un dominiode servicios. Pero, ¿cuál es la dierencia entre un producto y un servicio? Se puede expresar entérminos de las siguientes características:






• Los servicios son básicamente intangibles - Un servicio no es algo ísico que se pueda tocaro pesar. Consta de componentes tangibles (como el hardware que se usa para la prestación delservicio, la red o el disco donde está instalado el sotware), pero un servicio es mucho más quela 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 estemotivo, el aseguramiento proactivo de la calidad es mucho más importante para la gestión deservicios que cualquier vericació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 dierencia de las máquinas, pueden ser muy variables.Por ejemplo, un empleado del servicio de atención al cliente que haya pasado una mala nochepuede resultar bastante grosero durante la primera hora de su turno, pero su humor (y suservicio) puede mejorar mucho después de una taza de caé. Los productos tienden a parecersemás a las máquinas, por lo que sus variaciones se pueden gestionar más ácilmente.

• El usuario participa en la producción del servicio - Es recuente que no sea posible consumirun servicio si el usuario no lleva a cabo algunas acciones concretas. De esta orma, el usuario(y por tanto el cliente) también infuye en la calidad del servicio. Por el contrario, un productosuele ser el resultado de una acción unilateral de un proveedor externo.

• La satisacción es un concepto subjetivo - El consumo de servicios depende en parte delconsumidor (en este caso, el usuario de TI). Además, los servicios sólo se pueden medir unavez entregados, pero no antes. Los productos se pueden valorar, probar y evaluar antes decomprarlos, mientras que no es posible juzgar un servicio que no se ha recibido.

Muchas de las dierencias 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 diícilesde medir que los bienes tangibles, ya que son subjetivas. Por lo tanto, cuantos menos bienestangibles contenga un servicio, más diícil será medirlo de un modo objetivo.

Mayoríade bienes

Bienes que requierenmuchos servicios

Mezcla Servicios que requierenmuchos bienes

Mayoríade servicios

Parte tangible del producto Parte intangible del producto

Figura 2�4 Servicios y productos






2.2.2 Componentes de un servicio de TILa 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 acilitando los resultados que los clientes quieren conseguir sin incurrir en costes y riesgos especícos.

Pero, ¿qué es un servicio de TI si se mira en detalle? El servicio de TI es una salida de laorganización de TI (ya sea interna o externa), y no un resultado del negocio, donde el valor realse 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, cuandose combinan, orman 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 inormacióncon soporte, que se entrega a un cliente con unos niveles de calidad previamente acordados. Esta

composición menciona tres elementos:• Sistema de inormación• Soporte• Especicaciones de calidad

Las secciones que siguen explican cada uno de estos elementos.

Sistema de inormación (SI)El sistema de inormación (SI) es un sistema coherente de procesamiento de datos para el controlo soporte de inormación en uno o más procesos de negocio. Está ormado por Personas, Procesos

y Tecnología, y se puede usar (en colaboración con Proveedores asociados) para gestionar el áreade atención nal: Inormación (Figura 2.5).

Las personas que orman parte del servicio de TI son el personal encargado de garantizar que elservicio unciona de acuerdo con los requisitos. Realizan todas las actividades necesarias a lo largodel ciclo de vida del servicio para que el servicio cumpla en todo momento las especicaciones.Ningún servicio de TI puede durar mucho tiempo sin personas.

Los procesos se documentan en descripciones de procesos. Estos documentos contienen tambiénprocedimientos, instrucciones de trabajo y manuales. Una organización que no disponga deinstrucciones debidamente documentadas se verá pronto dependiendo únicamente de losconocimientos de su personal. Pero las personas cambian a menudo de trabajo, tienden aolvidar cosas o pueden no estar de acuerdo sobre algún tema concreto. Resulta diícil alcanzar lanormalización si no se parte de instrucciones bien documentadas y aceptadas.

Los expertos en TI están especialmente amiliarizados con el dominio tecnológico. Lainraestructura de Tecnologías de la Inormación se puede descomponer en varios elementos. Elconjunto de elementos más habitual sería: aplicaciones ejecutadas en sistemas de un entorno. Entérminos más técnicos se diría: [aplicaciones ] ejecutadas en [inraestructura técnica] empleando

[instalaciones ].






Dependiendo de la tecnología aplicada, estos dominios de alto nivel se pueden descomponertodavía más. Por ejemplo, la inraestructura técnica se puede dividir en hardware, sotwarede sistema y redes. Otro posible desglose podría incluir entidades de inraestructura comomiddleware, rmware, 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 desoporte se podría descomponer en sotware de aplicaciones y bases de datos, mientras que en unaarquitectura de tres líneas de soporte se podría hablar de una capa de presentación, una capa deprocesamiento y una capa de datos.

Las instalaciones se pueden descomponer, por ejemplo, en alimentación, temperatura y espacio.

SoporteEl segundo término importante en el contexto de un servicio de TI es “soporte”. El sistema deinormación (SI) necesita soporte para uncionar en todo momento según las especicaciones.Esto signica que se deben introducir cambios cuando sea necesario y que hay que restaurarel sistema si no unciona 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 eectuar estasacciones de soporte, que incluyen restaurar un servicio de TI que haya sido alterado, adaptar unservicio de TI si el cliente exige características dierentes y aumentar o reducir un servicio de TI.

Si todo ello se hace correctamente, el sistema de inormación uncionará según lo previsto paraacilitar los procesos de negocio.

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

Personas = personal

Información

Sistema deinformación

Requisitosde calidad

Serviciode TI

Disponibilidad

RendimientoCapacidad

SeguridadConfidencialidadEscalabilidadAdaptabilidad

Portabilidad

.......

Personas

Hardware

Softwarede sistema

Redes

Software deaplicaciones

Bases de datos

Instalaciones

Aplicaciones

Infraestructuratécnica

Tecnología

Tecnologías dela Información

Documentación Proceso






Calidad El sistema de inormación debe cumplir las especicaciones acordadas con el cliente, lo quesignica que se tienen que denir y aceptar sus atributos de calidad. En la práctica, la calidad deun servicio de TI se suele expresar como las características especícas del servicio que satisacenlas expectativas del cliente. Estas características se pueden reerir a aspectos de comportamiento

(como el tiempo de respuesta) o bien ser características más ísicas (como “un portátil”). Elcliente y el proveedor tienen relativa libertad para elegir las especicaciones de calidad de servicio,aunque algunos atributos son más habituales que otros:• La disponibilidad del sistema de inormación (SI) es el más importante y habitual de los

atributos de calidad de un servicio. Especica el tiempo y el lugar en que el SI debe estardisponible para el usuario.

• La capacidad es el segundo atributo esencial de calidad en la mayor parte de los casos. Indicala “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 reere a la velocidad a la que seprocesa la inormación desde el punto de vista del usuario. ISO 20000 considera el rendimientodentro de la gestión de la capacidad. El concepto de rendimiento de sistemas de inormaciónes totalmente dierente del rendimiento de TI, rendimiento de aplicaciones, rendimiento desistemas, 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, yaque lo que el usuario experimenta es la “salida unicada” de los rendimientos de todos loscomponentes del sistema de inormació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 condencialidad 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 perjudicarel 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 inraestructuray todo lo que sea necesario para garantizar la adaptabilidad de un sistema de inormación.

• La portabilidad puede ser importante para un cliente que desee contar con la posibilidad decambiar proveedores, ya sea con recuencia o en caso de nalización (normal o anticipada) deun contrato.

Los atributos de un servicio también pueden depender unos de otros. Por ejemplo, la hora de cierrede una incidencia puede infuir directamente en la disponibilidad del sistema de inormación.

2.2.3 Relación entre servicios de TI y calidadEs habitual que las organizaciones dependan de sus servicios de TI y esperen de ellos no sóloque den apoyo a la organización, sino también que orezcan nuevas opciones para hacer rente

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 lacalidad de sus servicios y prestar gran atención a la relación con sus clientes.






Como se explica en la sección anterior, un producto comprado en una tienda se puede valorar porsu calidad antes de comprarlo. La prestación de un servicio, por el contrario, es el resultado de lainteracción del proveedor con sus clientes y usuarios, por lo que no es posible valorar el serviciopor anticipado.

La calidad de un servicio depende de la orma en que interactúan el proveedor del servicio,el cliente y los usuarios. A dierencia de lo que ocurre en el proceso de abricación, el clientey el proveedor pueden introducir cambios una vez iniciada la prestación del servicio. Tantola percepción que el cliente y los usuarios tienen del servicio como la opinión del proveedordependen en gran medida de las expectativas y experiencias personales de cada uno. Esto signicaque el proceso de prestación de un servicio es una combinación de producción y uso en la queparticipan al mismo tiempo el proveedor y el cliente (usuarios).

La percepción del cliente y los usuarios es undamental para la provisión de servicios. Por lo

general, los clientes y usuarios recurren a las siguientes preguntas para valorar la calidad delservicio:• ¿Satisace 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 undamentalmente en las expectativas, que a su vez puedentener su origen en el diálogo entre proveedor y cliente o en cualquier otro actor. Estas expectativaspueden infuir más en la calidad percibida que la calidad técnica real de los servicios orecidos

por el proveedor. La percepción de un servicio es un aspecto undamental de la relación cliente-proveedor. No obstante, la percepción de la calidad puede verse aectada por varias dierencias o“gaps” (véase la Figura 2.6):• Gap 1 - La dierencia entre lo que los clientes esperan y la orma en que el proveedor entiende

esas expectativas; se debe a una alta de entendimiento o a una idea incorrecta de las necesidadeso deseos del cliente; la comunicación puede ser muy importante para eliminar esta dierencia.

• Gap 2 - La dierencia entre la orma en que el proveedor entiende las expectativas del clientey los diseños y normas del servicio denidos por el proveedor; se debe a la incapacidad detraducir los requisitos del cliente en especicaciones del servicio.

• Gap 3 - La dierencia entre los diseños y normas del servicio y el servicio que se orece realmente;se debe a la incapacidad del proveedor de orecer lo acordado.

• Gap 4 - La dierencia entre los servicios que se orecen realmente y lo que se ha dicho al clienteque va a recibir; se debe a una comunicación mala o incluso engañosa.

• Gap 5 - La dierencia entre el servicio tal como lo perciben los clientes y el servicio queesperaban recibir; puede tener muchas causas; puede ocurrir que un cliente reciba más de loque esperaba, pero la mayor parte de los problemas se deben a que el servicio no cumple lasexpectativas y el cliente está insatisecho.

Un diálogo continuo con el cliente (incluyendo a los empleados) es undamental para mejorar los

servicios y garantizar que tanto el cliente como el suministrador saben qué esperar del servicio. Laclave para ello es contar con un lenguaje común basado en conceptos mutuamente aceptados. Nosiempre es ácil conseguir que se entiendan distintas personas, pero el uso de una terminología






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

En un restaurante, por ejemplo, el camarero empezará explicando el menú y preguntará si elservicio es satisactorio cada vez que sirva un nuevo plato. El camarero coordina activamenteel suministro y la demanda a lo largo de la comida y utiliza esta experiencia con los clientespara mejorar el grado de satisacción de los clientes uturos.

La calidad de un servicio depende de hasta qué punto el servicio satisace los requisitos y expectativas del cliente (incluyendo a los usuarios). Para poder orecer calidad, el suministradortiene que evaluar de orma continua cómo se percibe el servicio y qué es lo que el cliente esperaen el uturo. Lo que para un cliente resulta normal puede ser visto como un requisito especialpor otro cliente. También es posible que un cliente se acostumbre a algo que consideraba especialhasta el punto de llegar a verlo como un servicio normal. Los resultados de la evaluación continuadel servicio pueden servir para determinar si es necesario modicar el servicio, si hay que orecermás inormación al cliente o si se debe cambiar el precio.

Un coste razonable puede ser considerado como un requisito secundario o derivado, ya que elcoste se decide una vez acordado lo que se espera del servicio. También es posible ver el coste comoun atributo de calidad que se debe considerar conjuntamente con otros atributos para alcanzar

un equilibrio global que resulte más satisactorio para el cliente. En este punto, el proveedor delservicio debe ser consciente de los costes en los que incurre y de los precios de mercado paraservicios similares.

Comunicación verbal Necesidades personales Experiencia previa

Servicio esperado

Gap 5

Gap 1

Gap 3

Gap 2

Gap 4

Servicio percibido

Servicio real

Traducción de expectativasen normas de calidad

Percepción de lasexpectativas del clientepor parte del proveedor

Comunicacionesexternas con

clientes

C liente

Prov eedor

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






El cliente no estará satisecho si el proveedor del servicio supera de vez en cuando las expectativaspero sin llegar a cumplirlas el resto del tiempo. Orecer una calidad constante es uno de losaspectos más importantes, pero también uno de los más diíciles, de la provisión de servicios.

Cuando se orece un servicio, la calidad general será la combinación de la calidad de diversos

procesos y componentes que juntos orman el servicio. Estos procesos y componentes crean unacadena cuyos eslabones infuyen unos en otros y en la calidad del servicio. Una coordinaciónecaz de los procesos y componentes requiere no sólo una calidad adecuada en la ejecución decada proceso, sino también un nivel de calidad uniorme.

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 puedancumplir los objetivos de negocio, hay que dedicar cada vez más atención a la Gestión de Serviciosde TI en lugar de al desarrollo de aplicaciones de TI. Un sistema de inormación (llamado enocasiones aplicación de TI) sólo ayuda a alcanzar los objetivos corporativos si está a disposición delos usuarios y si dispone de mantenimiento y gestión operativa en caso de allo o modicación.

Dentro del ciclo de vida de los productos de TI, la ase de operaciones supone la mayor parte delgasto. El presupuesto operativo (compuesto undamentalmente por costes de personal y costesacumulables asociados con el mantenimiento de sistemas de inormación) representa la partemá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). Porlo tanto, el éxito de las Tecnologías de la Inormación exige disponer de estrategias, procesos y sistemas de Gestión de Servicios de TI que sean ecaces y ecientes. Esto es válido para cualquiertipo de organización, ya sea grande o pequeña, pública o privada, con servicios de TI centralizadoso descentralizados, y con servicios de TI internos o externalizados. En todos los casos el serviciotiene que ser able, uniorme, 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 paragarantizar la calidad de los servicios de TI en producción, de acuerdo con los niveles deservicio acordados con el cliente.

La Gestión de Servicios de TI incluye la iniciación, el diseño, la organización, el control, laprovisión, el soporte y la mejora de los servicios de TI, adaptándose siempre a las necesidadesde la organización del cliente. Existen diversas reerencias que orecen guías prácticas para laGestión de Servicios de TI. Entre ellas guran 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®, omarcos de gobierno como CobiT®.

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






2.3.2 Ventajas y riesgos de la Gestión de Servicios de TILa principal ventaja de ITSM es que orece criterios cuantitativos de calidad para servicios deextremo a extremo con enoque a cliente. Ésta es la única base para una gestión madura de lainraestructura de TI, representada por componentes de TI y ajenos a TI que se agrupan enservicios durante la ase de operación y otras ases del ciclo de vida del servicio.

A continuación se da una lista de algunas ventajas y posibles problemas en el uso de mejoresprácticas de Gestión de Servicios de TI. Aunque en ningún caso pretende ser una lista denitiva,contiene algunas de las ventajas que se pueden obtener y algunos de los errores que se puedencometer cuando se emplean marcos de trabajo basados en procesos para la Gestión de Serviciosde TI.

Ventajas para el cliente o el usuario:• La provisión de servicios de TI tiene un mayor enoque 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 abilidad, 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 eciente y se concentra más

en los objetivos corporativos.• La organización de TI tiene más control sobre la inraestructura y los servicios de los que se

ocupa, por lo que los cambios son más áciles de gestionar.• Una buena estructura de procesos proporciona un marco de trabajo para la externalización

ecaz de elementos de los servicios de TI.• La adopción de mejores prácticas omenta un cambio de cultura hacia la prestación de servicios

y avorece la introducción de sistemas de gestión de la calidad basados en la serie ISO 9000 oen ISO 20000.

• Los marcos de trabajo pueden proporcionar marcos coherentes de reerencia para lascomunicaciones internas y con suministradores, así como para la normalización e identicaciónde procedimientos.

Dicultades y aspectos a tener en cuenta:• La introducción se puede prolongar mucho tiempo y, si no se diseña y planica correctamente,

puede exigir un esuerzo considerable e incluso un cambio de cultura en la organización; unexceso de ambición puede acabar siendo rustrante si no se alcanzan nunca los objetivos.

• La calidad del servicio se puede resentir si las estructuras de procesos se convierten en unobjetivo en sí mismas; en este caso, los procedimientos innecesarios o excesivamente complejosse 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 cadaproceso, cuáles son los indicadores de rendimiento apropiados y cómo se pueden controlar los

procesos.






• Es posible que la mejora en la provisión de servicios y las reducciones de costes no resultensucientemente visibles si no se dispone de datos de reerencia o si los objetivos denidos sonincorrectos.

• El éxito de la implantación requiere la participación y el compromiso del personal a todos losniveles 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 inviertelo suciente en ormación y herramientas de soporte; es posible que a corto plazo se necesitenrecursos y personal adicionales si la organización está ya sobrecargada con actividades rutinariasde 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 TIPara eectuar 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 automatizarlas tareas de gestión, como por ejemplo las de monitorización o las de distribución de sotware.

Otras herramientas, como las de centros de atención al usuario o las de Gestión del Servicio,acilitan la realización de las propias actividades. Estas herramientas permiten gestionar variosprocesos y con recuencia se denominan herramientas de fujo de trabajo, aunque no siempre sonmotores de fujo de trabajo.

El hecho de que las Tecnologías de la Inormación se centren undamentalmente en instalacionesautomatizadas (para el procesamiento de inormació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 deorma continua. El uso de herramientas para distribución de sotware y de herramientas parael control remoto de ordenadores acilita enormemente la gestión de inraestructuras remotas.Esto permite crear centros de operaciones centralizadas muy ecientes, desde donde es posiblemonitorizar 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 ácil recopilarevidencias de cara a obtener la cualicación ISO 20000. El cumplimiento de muchos de losrequisitos 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 requisitosde ISO 20000.

A pesar de todos los sistemas y las herramientas de Gestión del Servicio, “un tonto con herramientassigue siendo un tonto”. Por ello, el uso de herramientas tiene que estar basado en las mejoras deeciencia conseguidas con los procesos de Gestión del Servicio. Las herramientas deben tenersiempre en cuenta el contexto de personas, procesos y proveedores asociados, para poder dar losresultados 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 jarse por igual en todoslos aspectos.






2.4 Qué son los procesos

2.4.1 Ventajas y características de un enoque basado en procesos

Ventajas

Todas las organizaciones intentan hacer realidad su visión, misión, estrategia, objetivos y políticas, lo que signica que tienen que emprender las actividades apropiadas para ello. Parapoder controlar la serie de actividades que se realizan en las operaciones diarias, es importanteque dichas actividades y sus vínculos se gestionen desde el principio hasta el nal de la cadenade servicio.

Un restaurante, por ejemplo, tendrá que adquirir alimentos rescos que pueden cambiar segúnla estación. Los ches deben colaborar para orecer resultados uniormes, mientras que entreel servicio de mesa tampoco deben existir grandes dierencias. Un restaurante sólo recibirá

tres estrellas si consigue orecer el mismo nivel de alta calidad durante un período prolongadode tiempo. No siempre ocurre así, ya que puede haber cambios de camareros o ches quedecidan abrir sus propios restaurantes. Ningún método garantiza el éxito permanente. Oreceruna calidad elevada y constante también implica que hay que coordinar todas las actividadesnecesarias: cuanto mejor y más eciente sea el trabajo de la cocina, mayor será la calidad deservicio que se puede orecer a los clientes.

Entre estas actividades guran, por ejemplo, comprar legumbres, mantener reservas, pedirmateriales para publicidad, recibir a los clientes, limpiar las mesas, pelar patatas o prepararcaé. 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 lasactividades. Lo mejor es hacerlo de tal manera que se pueda ver la contribución de cada grupode 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 transerencia bien denidosen los que es posible monitorizar la calidad de los procesos. En el ejemplo del restaurante, sepodría separar la responsabilidad de comprar de la de cocinar, de manera que los ches no tenganque comprar nada y se puedan concentrar en sus actividades principales.

Aunque la mayor parte de los negocios siguen una organización jerárquica con departamentosque son responsables de las actividades de un grupo de empleados, los servicios de TI dependenpor lo general de varios departamentos o disciplinas. Por ejemplo, un servicio de TI que dé accesoa los usuarios a un programa de contabilidad en un ordenador central aecta a diversas disciplinas:el centro de inormática se encarga del acceso al programa y la base de datos, el departamento dedatos y telecomunicaciones garantiza el acceso al centro de inormática y el equipo de soporteinormático se ocupa de orecer a los usuarios una interaz de acceso a la aplicación.

Los procesos que abarcan varios departamentos (equipos) pueden monitorizar la calidad de unservicio 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 lasdemandas del cliente. La estructura de estos procesos puede garantizar el acceso a inormaciónútil sobre la provisión de servicios, de manera que sea posible mejorar la planicación y el controlde servicios.






Por otra parte, la descripción de la estructura de procesos proporciona un punto de reerenciacomún y estable que puede ayudar a mantener la calidad de los servicios de TI durante y despuésde reorganizaciones, incluyendo cambios de suministradores y asociados. Esto hace que losproveedores de servicios estén menos expuestos a los cambios organizativos y sean mucho másfexibles, ya que pueden adaptar su organización a cambios constantes de condiciones pero sin

alterar sus procesos esenciales. De esta orma, una tienda podría permanecer abierta durante unasobras de reconstrucción, por ejemplo. En la realidad pueden surgir problemas que hagan que estosea 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 actividadesse dividen en procesos que, una vez integrados, crean un marco de trabajo ecaz que aumenta lacapacidad y madurez de la Gestión de Servicios de TI. Cada uno de estos procesos cubre una omás tareas de la organización de TI, como el desarrollo de servicios, la gestión de inraestructuraso 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 objetivoconcreto.

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 procesospermite con recuencia detectar actividades de la organización que carecen de coordinación, queestán duplicadas, que se ignoran o que son innecesarias. Lo que hay que hacer es jarse en elobjetivo del proceso y en las relaciones con otros procesos. La Figura 2.7 muestra cómo se puedencombinar actividades de distintos elementos organizativos para ormar un proceso (indicado porlas líneas quebradas). La Figura 2.8 muestra un ejemplo de proceso.

Gestión de TI

Desarrollo

de software OperacionesCentro de atención

al usuario

Organización

de proyectos

Mantenimientode software y

gestión de

aplicaciones

Automatización

de oficina y

telecomunicaciones

Gestión de redes

SALIDA

ENTRADA

Figura 2�7 Procesos y departamentos (ejemplo)






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 orecen los resultados esperados.• Cómo aectan 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 enprocesos y enocado a servicios de lo que anteriormente se conocía como gestión de tecnologías dela inormación. Este desplazamiento de la inraestructura a los procesos ha llevado a la aparicióndel término “Gestión de Servicios de TI” para describir una disciplina basada en procesos y enocada a cliente.

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

2.4.2 Medida y control de procesosLos procesos están ormados por dos tipos de actividades: las actividades que contribuyen a laconsecución de metas (actividades operativas que se ocupan de la respuesta) y las actividadesasociadas con la gestión de metas (actividades de control). Las actividades de control garantizan

que las actividades operativas (el fujo de trabajo) se realizan en el momento previsto y en el ordencorrecto. En el procesamiento de cambios, por ejemplo, siempre se garantiza que se realiza unaprueba antes (y no después) de la puesta en producción de una entrega.

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 fujo de procesos






La Figura 2.9 ilustra esta losoía, que también se conoce como modelo ERSCR (ITOCO).Según este modelo, un proceso es una serie de actividades eectuadas para convertir una entrada en una salida y, nalmente, en un resultado:• Entrada• R espuesta

• Salida• Control• R esultado

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 alargo plazo del proceso (en términos de eectos signicativos). Las actividades de control permitenasociar la entrada y la salida de cada uno de los procesos con políticas y normas, con el n deorecer inormació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 nocumplan las normas o políticas mencionadas. De esta orma se generan cadenas de procesosque indican cuáles son las entradas de la organización y cuál es el resultado, así como puntos demonitorización en las cadenas para vericar la calidad de los productos y servicios que orece laorganización.

Las normas para la salida de cada proceso se tienen que denir de manera que toda la cadenade procesos en el modelo cumpla el objetivo corporativo. Si la salida de un proceso satisace losrequisitos establecidos, se dice que el proceso es ecaz para transormar su entrada en la salida.Para que sea realmente ecaz, también hay que tener en cuenta el resultado.

Si las actividades del proceso se realizan además con el mínimo coste y esuerzo, se dice que elproceso es eciente . La gestión de procesos utiliza la planicación y el control para garantizar que

los procesos se ejecutan de una orma ecaz y eciente.

normas y políticas

requisitos

eficiencia eficacia

consecuciónde objetivos

ENTRADA RESPUESTA SALIDA RESULTADO

CONTROL

Figura 2�9 Diagrama de procesos basado en el modelo ERSCR






2.4.3 Roles necesarios para la gestión de procesosLos 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 inorma al propietario delproceso. Los operarios del proceso se encargan de actividades denidas, sobre las que inorman al

gestor del proceso.

La dirección de la organización puede proporcionar control basándose en evaluaciones de lacalidad de cada proceso. En la mayor parte de los casos se habrán acordado previamente lasnormas y los correspondientes indicadores de rendimiento, lo que permite dejar el control diarioal gestor del proceso. El propietario del proceso evalúa los resultados basándose en un inormede indicadores de rendimiento y verica que cumplen la norma establecida. Sin unos indicadoresclaros, el propietario del proceso tendría dicultades para determinar si el proceso está bajocontrol y si se están implantando las mejoras planicadas.

Una persona o equipo puede desempeñar múltiples roles; por ejemplo, los roles de gestor de laconguración y gestor de cambios pueden corresponder a una misma persona.

2.5 Qué es la mejora continuaComo se explicó en la Sección 2.1.3, la mejora continua es uno de los ocho principios de lagestión de la calidad en ISO 9000. Es necesaria para mejorar el rendimiento y aumentar lasatisacción de los clientes y otras partes interesadas, y debe ser un objetivo permanente de laorganización.

La mejora continua mantiene en movimiento la rueda del ciclo PDCA, como se explica en laFigura 2.1 de la Sección 2.1.1.

La siguiente sección explica el uncionamiento de los modelos de madurez y su relación con lasevaluaciones de capacidad.

2.5.1 Modelos de madurezDesde el momento en que Richard Nolan introdujo en 1973 su “modelo por etapas” para aplicar lasTecnologías de la Inormación en las organizaciones, son muchos los que han propuesto modelosde mejora gradual. Estos modelos se convirtieron muy pronto en instrumentos adecuados paradesarrollar programas de mejora de la calidad, ayudando así a las organizaciones a ascender en laescala de madurez.

Es muy ácil encontrar docenas de variaciones sobre este tema en campos que van desdeel desarrollo de sotware, la adquisición, la ingeniería de sistemas, las pruebas de sotware, eldesarrollo de sitios Web, los Data Warehouses o la ingeniería de seguridad, hasta los centros deatenció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 tipode modelos se debe al Instituto de Ingeniería de Sotware (SEI) de la Universidad CarnegieMellon en los Estados Unidos, que propuso su Modelo de Madurez de la Capacidad de Sotware






(SW-CMM). El modelo CMM se copió y aplicó en la mayor parte de los casos mencionadosanteriormente, convirtiéndose en la práctica en el modelo de madurez estándar. Posteriormenteaparecieron nuevas ediciones del modelo CMM, como CMMI (Integración de CMM). Otromodelo 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ícos 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 losesuerzos heroicos de las personas que orman la organización, y no del uso de procesos deecacia probada. A pesar de este caos, las organizaciones con nivel de madurez 1 producen conrecuencia productos y servicios que uncionan, aunque suelen salirse del presupuesto y casinunca cumplen el calendario previsto.

• Nivel de Madurez 2: Reproducible (gestionado) - Los proyectos de la organización garantizanque los procesos se planican y ejecutan según la política establecida. Los procesos aectan a

los grupos de interés adecuados y son ejecutados por personas cualicadas y con los recursosnecesarios para producir salidas controladas. También son sometidos a un programa demonitorización, control y revisión, y se evalúa hasta qué punto responden a las descripcionesde procesos.

• Nivel de Madurez 3: Defnido - Los procesos están bien caracterizados y documentados y se describen en normas, procedimientos, herramientas y métodos. El conjunto de procesosestándar de la organización, que es la base para el nivel de madurez 3, está bien denido y mejora con el tiempo. Estos procesos estándar se utilizan para garantizar la coherencia entoda la organización. Los proyectos establecen sus procesos adaptando el conjunto de procesosestándar de la organización de acuerdo con las directrices correspondientes.

• Nivel de Madurez 4: Gestionado cuantitativamente - La organización y sus proyectosdenen objetivos cuantitativos de calidad y rendimiento de procesos y los utilizan comocriterios para la gestión de procesos. Los objetivos cuantitativos se basan en las necesidades delcliente, los usuarios nales, la organización y los encargados de implantar procesos. La calidady el rendimiento de procesos se entienden en términos estadísticos y se gestionan durante todala vida de los procesos.

• Nivel de Madurez 5: Optimización - Este nivel se centra en la mejora continua del rendimientode los procesos mediante mejoras incrementales e innovadoras de procesos y tecnologías. Sehan denido objetivos cuantitativos de mejora de los procesos de la organización, se revisancontinuamente para que refejen cambios en los objetivos de negocio y se utilizan como criteriospara mejorar el proceso de gestión. Se miden y evalúan los eectos de las mejoras desplegadas,comparándolos con los objetivos cuantitativos de mejora de los procesos. Tanto los procesosdenidos como el conjunto de procesos estándar de la organización se someten a actividadesde mejora cuanticables.

Estos modelos se aplicaron posteriormente en modelos de gestión de la calidad, como el de laFundación Europea para la Gestión de la Calidad (EFQM). Además de los modelos generales degestión de la calidad, existen diversas prácticas aceptadas por el sector como Six Sigma o TQM,que complementan a ITIL®.






Las normas y marcos existentes de mejores prácticas sirven de guía a las organizaciones quepersiguen la “excelencia operativa” en la Gestión de Servicios de TI. El tipo de guía que requierecada organización varía en unción de su ase de desarrollo.

Las normas ISO 9000 y 20000 hacen hincapié en la denición, descripción y diseño de procesos

y en el desarrollo y mantenimiento de un sistema de calidad que satisaga sus requisitos, porlo que se pueden considerar como una herramienta que permite a la organización alcanzar y mantener un nivel de madurez previamente denido para el sistema.

2.5.2 Evaluaciones de capacidad y su relación con modelos de madurezUna evaluación compara el rendimiento de un proceso con un estándar de rendimiento, quepuede estar estipulado en un acuerdo de nivel de servicio (SLA) o bien ser un estándar de madurezo un promedio calculado con empresas del mismo sector, en cuyo caso se habla de una evaluacióncomparativa.

Una evaluación para ISO 20000 es claramente una evaluación de capacidades, ya que indica si secumplen o no los requisitos de ISO 20000. En caso de cumplirse los requisitos, la organizacióntiene capacidad para orecer servicios con el nivel de calidad especicado en la norma. Unaevaluación de madurez indica el nivel de madurez alcanzado, lo que permite identicar lasacciones necesarias para llegar al siguiente nivel de madurez.

Las evaluaciones son la mejor orma de dar respuesta a la pregunta “¿cuál es la situación actual?”y determinar cuánto alta para alcanzar la “situación deseada”. El uso de un marco de trabajoaceptado 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 procesotenga 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 ecacia y la eciencia de cadacomponente, lo que acilita la identicación de áreas de mejora.

Es muy importante denir claramente el objeto de la evaluación, que debe estar basado en losobjetivos y el uso previsto de los inormes. 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 soporteal proceso.

• Completo - Se evalúan también la capacidad y el nivel de preparación para aceptar el proceso,así como la posibilidad de ormular y seguir una estrategia y unos objetivos para el proceso.

Todos estos resultados se pueden comparar con el modelo de madurez seleccionado.






Las evaluaciones resultan de utilidad en las siguientes ases:• Planifcar - Como punto de partida (línea de reerencia) para el rendimiento del proceso.• Hacer - Para medir si las estimaciones son correctas.• Verifcar - Para completar el balance e identicar otras posibles mejoras.

Las evaluaciones orecen 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 inormación sobre la dinámica

cultural de una organización.

• Pueden dejar de ser un medio para convertirse en un n 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 signica 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ásicassobre cada uno de los procesos evaluados:• ¿Está el proceso identicado y denido correctamente?• ¿Se han denido responsabilidades?• ¿Se han implantado y se mantienen los procedimientos?• ¿Es ecaz el proceso para alcanzar los resultados deseados?

El resultado de la evaluación dependerá de las respuestas a estas preguntas. La evaluación de unsistema de gestión de la calidad puede variar en alcance e incluir dierentes actividades, comoauditorí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 sistemade gestión de la calidad. Los resultados de una auditoría permiten evaluar la ecacia del sistemade 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 puedenser la base para una declaración interna de conormidad.Las auditorías externas son las realizadas por clientes de la organización o por otras personas en

representación de los clientes.






Las auditorías de terceros son las realizadas por organizaciones externas independientes. Estasorganizaciones suelen estar acreditadas y emiten certicaciones o registros de conormidad conrequisitos 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 ecaciay la eciencia 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 calidada los cambios en las necesidades y expectativas de las partes interesadas. La revisión incluye ladecisión sobre la necesidad de acciones.

Entre otras uentes de inormación, en la revisión del sistema de gestión de la calidad se utilizanlos inormes de auditorías.

AutoevaluaciónLa autoevaluación de una organización consiste en una revisión completa y sistemática de lasactividades y resultados de la organización, utilizando como reerencia el sistema de gestión de lacalidad o un modelo de excelencia.La autoevaluación permite tener una visión general del rendimiento de la organización y delgrado de madurez del sistema de gestión de la calidad. También ayuda a identicar áreas quenecesitan mejoras en la organización, así como a determinar prioridades.

Evaluación comparativa de itSMFTodas 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 reereal modelo de procesos es un diseño basado en la norma ISO 20000 y ampliado con gestión deoperaciones. Cada cuestionario detallado combina las cuestiones especícas de 20000-1 y 20000-2 con preguntas del modelo de madurez CMMI. Como resultado se obtienen listas detalladasde actividades de mejora del rendimiento que acilitan la obtención de la certicación. Losresultados deben ser validados por un consultor externo, ya que de lo contrario las organizacionestienden a asignarse una puntuación un 25% más alta de la real. También se necesita una base dedatos de conanza. Conocer la posición de la organización con respecto a la norma y el modeloCMM, junto con los resultados de otras organizaciones en cada campo, permite disponer de unainormación muy importante y hace que sea más ácil denir objetivos signicativos y realistas.





3.1 Panorama actual de normas y marcos de trabajoLa siguiente lista muestra varios marcos de trabajo que son importantes en el campo de la Gestiónde Servicios de TI, junto con su propósito y el tipo de organización al que van dirigidos:• CMMI

− Propósito: Aumentar la acilidad de uso de los modelos de madurez para ingeniería de sotwarey otras disciplinas mediante la integración de muchos modelos dierentes en un solo marcode trabajo.

− Tipo de organización: Organizaciones que buscan mejorar los procesos en toda la empresa.• CobiT®

− Propósito: Proporcionar una estructura uniorme para comprender, implantar y evaluarcapacidades, rendimiento y riesgos de TI con el objetivo undamental de cumplir losrequisitos de negocio.

− Tipo de organización: Organizaciones que deseen estructurar su gobierno.• ISO 9000

− Propósito: Demostrar la capacidad de una organización para satisacer los requisitos de susclientes a través de un Sistema de Gestión de la Calidad (QMS) bien documentado, fexible,estructurado y orientado al cliente.

− Tipo de organización: Cualquier organización que desee demostrar que tiene capacidad paraentregar productos o servicios siguiendo constantemente los mismos procesos.

• ISO 15504− Propósito: Proporcionar una guía que permita realizar valoraciones de capacidad con el n de

mejorar procesos.− Tipo de organización: Organizaciones tecnológicas que deseen valorar su capacidad en cada

una de las ases de un proceso y determinar la ecacia de sus procesos en relación con losobjetivos de la organización.

• ISO 20000

− Propósito: Fomentar la adopción de un planteamiento de procesos integrados que garantice laentrega de servicios bien gestionados que cumplan los requisitos del negocio y los clientes.

Capítulo 3

La posición deISO 20000 en la Gestión

de Servicios de TI






− Tipo de organización: Todos los proveedores de servicios de TI que deseen adoptar la normaglobal y quieran demostrar que tienen capacidad para entregar servicios de TI de calidad aclientes internos o externos.

• ISO 27001− Propósito: Reducir la vulnerabilidad de una organización a riesgos de seguridad de la

inormación mediante el uso de un Sistema de Gestión de la Seguridad de la Inormación(ISMS).

− Tipo de organización: Organizaciones que deseen mantener los riesgos bajo control y protegersus activos.

• ITIL ®

− Propósito: Proporcionar mejores prácticas para la Gestión de Servicios de TI, así como unconjunto de procesos integrados para la provisión y el soporte de servicios de TI de altacalidad.

− 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: Orecer 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 dedeectos para maximizar el rendimiento y minimizar la variación de procesos.

− Tipo de organización: Organizaciones que deseen conocer mejor el rendimiento de susprocesos y detectar las mejores oportunidades de mejora.

• Normas específcas de empresa Cada organización puede tener sus propias normas especícas. Estas normas se pueden basaren los modelos y marcos de trabajo anteriormente citados, pero están adaptadas especialmente

para cada organización. Las normas especícas de empresa pueden ser políticas relativas adistintos aspectos de la Gestión de Servicios de TI (como políticas de seguridad) o bien normasque aecten a la normalización o la arquitectura de TI. Por ejemplo, Microsot ha desarrolladoMOF (Microsot Operations Framework) a partir de ITIL para dar soporte a dierentesproductos Microsot. Las normas especícas de empresa deben satisacer los requisitos de altonivel de ISO 20000-1. Por otra parte, tiene que haber alineación entre la enorme variedad denormas especícas de empresa, marcos de trabajo y normas ISO. Al iniciar el proceso que llevaa la certicación ISO 20000 es importante analizar con todo cuidado las normas internas paracompararlas 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 normalmenteno es el único. Un grupo de interés se dene como:

Un grupo de interés es cualquier persona, grupo u organización que pueda aectar, ser aectada oconsiderarse aectada 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 denición indica que también son grupos de interés los clientes, los suministradores, losmiembros 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 certifcación Al recopilar la inormación básica de los procesos de Gestión de Servicios de ITIL® en una normainternacional de carácter ormal, BSI y ahora ISO dotan a los proveedores de servicios de losmedios necesarios para determinar el cumplimiento de estas mejores prácticas. Hasta la creaciónde BS 15000, el proceso ormal de certicación estaba enocado a individuos (Fundamentos de

ITIL®, Responsable de la Gestión de Servicios ITIL®, Proesional ITIL®), no a organizaciones.La certicación ISO 20000 no es una certicación ormal en ITIL®; de hecho, la norma nomenciona a ITIL® ni siquiera en la lista de reerencias. Pese a ello, los contenidos de la versión2 de ITIL® se pueden encontrar ácilmente en la norma (véase Sección 3.3.1). Con ISO 20000,un proveedor de servicios puede obtener un certicado internacional en Gestión de Servicios deTI orientado a organizaciones. Es de esperar que esto estimule la aceptación de la Gestión deServicios de TI como un campo de gran importancia.

3.2.1 Certifcación de empresas

La norma ISO/IEC 20000-1:2005 ha sido desarrollada como norma de certicación paraproveedores de servicios. Un proveedor de servicios que desee hacer público su compromiso conla calidad en la Gestión de Servicios de TI puede solicitar la certicación independiente para suorganización de TI.

Roles y responsabilidades Aunque cualquiera podría asegurar que una organización satisace los requisitos de ISO 20000,el programa de certicación que gestiona itSMF UK aporta credibilidad al proceso. Las entidadesautorizadas por itSMF UK (Entidades de Certicación Registradas o RCBs) son las que concedenla certicación. En la mayor parte de los países hay entidades locales de certicación (o sucursales

de entidades internacionales) que pueden llevar a cabo una auditoría de certicación. Las entidadesde certicación tienen que estar registradas ante la entidad nacional de certicación. Muchasde estas entidades nacionales están unidas en el Foro Internacional de Acreditación (IAF). Loscerticados emitidos por entidades que hayan sido acreditadas por miembros del Programa deReconocimiento Internacional (MLA) del IAF se consideran válidos en todo el mundo, ya queel MLA avala su credibilidad.

Este proceso de certicación y acreditación ha uncionado con éxito durante muchos años paratodos los certicados ISO y es una garantía para los clientes internacionales.

Campo de aplicaciónEl campo de aplicación consiste en el cumplimiento de las condiciones para la certicación. ISO20000 tiene un campo de aplicación muy amplio, lo que signica que los sistemas de Gestión delServicio son válidos para una gran variedad de proveedores de servicios. ISO 20000 es aplicablea proveedores de servicios internos y externos, a empresas grandes y pequeñas o a organizacionescomerciales y no comerciales.

Un proveedor de servicios que desee obtener la certicación puede ser una organización completao 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 sobrela gestión de todos los procesos ISO 20000, lo que signica que todos sus servicios y actividades






deben estar controlados por su sistema de Gestión del Servicio. Un proveedor de servicios que notenga control sobre estos procesos no podrá optar a una certicación ISO 20000.

Por ejemplo, si una empresa controla sólo algunos procesos, como la gestión de incidenciasy la gestión de problemas, no puede recibir la certicación ISO 20000. Tiene que orecer un

servicio de TI que incluya todos los procesos ISO 20000. Por otro lado, esto no signica que unproveedor de servicios no pueda externalizar las actividades de TI. Si, por ejemplo, un proveedorde servicios externaliza el centro de atención al usuario y las actividades asociadas en los procesosde gestión de incidencias y gestión de problemas, habrá actividades que ya no realice por símismo. No obstante, si ha denido cuál debe ser el rendimiento de esas actividades y puededemostrar que mantiene el control de la gestión a través de SLAs, análisis periódicos de inormesy la adopción de acciones, es posible que pueda recibir certicación para los servicios de TI quela organización orece a sus clientes.

AlcanceEl alcance del servicio prestado tiene que estar descrito en una declaración de alcance. Un proveedorde servicios puede obtener la certicación para todos los servicios que orece o bien para un paíso cliente concreto, siempre y cuando lo especique en una declaración de alcance que valide lacerticación para cada situación especíca. Por ejemplo, si una gran empresa multinacional sóloha recibido certicación para los servicios de TI internos en un país concreto, debe indicarlo enla declaración de alcance de ese certicado.

La estructura típica de una declaración de alcance es la siguiente:

El <servicio> suministrado por <nombre de la unidad organizativa del proveedor de servicios>a <nombre de la organización y/o la unidad organizativa del cliente> desde <ubicación y/oárea geográca>.

Como se ve, se debe mencionar el servicio (o servicios). También hay que incluir en la declaraciónde alcance el nombre de la organización (entidad legal), el nombre del receptor del servicio y laubicación o área geográca desde donde se suministra el servicio.

Ventajas de la certifcaciónISO 20000 proporciona un marco de trabajo y un enoque sistemático que permite gestionarlos procesos de Gestión de Servicios de TI de manera que el servicio de TI resultante satisagalas expectativas del cliente. La implantación de ISO 20000 ahorra dinero y aumenta la ecaciay eciencia de los procesos de negocio. La mayor parte de las empresas que han obtenido lacerticación ISO 20000 consiguen también procesos más ecientes, clientes más satisechos y servicios de más calidad.

Para los clientes, la certicación de los proveedores según las normas ISO signica la seguridadde que el desarrollo y la provisión de los servicios se realiza siguiendo documentos de reerenciaglobalmente aceptados. Por supuesto, esto quiere decir que clientes y suministradores están

capacitados para competir en los mercados de todo el mundo.






Obtener la certicación conlleva numerosas ventajas, aunque las empresas deben asegurarse deperseguir la certicación por los motivos correctos:• Para llegar a nuevos clientes, puesto que cada vez son más las empresas que consideran la

certicación ISO 20000 como un requisito esencial para establecer una relación comercial conun nuevo proveedor.

• Para acceder a mercados globales gracias al amplio reconocimiento de la norma ISO 20000.• Para disponer de mejor documentación para diversos nes.• Para dar a la empresa una ventaja competitiva y demostrar su compromiso con la calidad del

servicio.

Proceso de certifcaciónUna 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 satisacen los requisitos deISO 20000, el proveedor de servicios está listo para iniciar el proceso de certicación.

El proceso de certicación consta de siete pasos:1. Cuestionario2. Solicitud de valoración3. Auditoría previa opcional4. Auditoría inicial (ase 1)5. Auditoría de certicación (ase 2)6. Auditorías de vigilancia7. Auditorías de renovación

Estos pasos se discuten a continuación.

El proceso de certicación se inicia cuando la entidad de certicación seleccionada envía uncuestionario de datos sobre los requisitos y la empresa. Este cuestionario proporciona a la entidadde certicación la inormación que necesita para poder enviar un presupuesto.

Una vez tomada la decisión de continuar el proceso de certicación con la entidad seleccionada, secumplimenta el ormulario de solicitud y se envía a la entidad de certicación. Posteriormente seorganiza una visita inicial por parte de un auditor jee. Esta visita sirve para que los representantesde la empresa conozcan al auditor jee que va a evaluar el sistema de gestión para el que se solicitala certicación ISO 20000. El auditor explica el proceso de valoración y eectúa una revisióndel sistema de gestión existente. Se acuerda una echa para la valoración y un calendario deauditoría. La química interna del equipo es una parte importante de cualquier auditoría, como loes también tener buenos conocimientos del proceso, la empresa y el auditor jee.

Una auditoría previa es una evaluación de alto nivel que indica el grado de cumplimiento de losrequisitos de ISO 20000 por parte de la empresa. Si una organización no se ha sometido nunca aauditorías para obtener una ISO, esta auditoría previa preparará a la dirección y al personal paralo 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 previose puede implantar inmediatamente en el sistema de gestión para eliminar posibles problemasantes de que se inicie la auditoría ocial.






La auditoría inicial verica 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 auditorplanica la auditoría de certicación (ase 2). En esta sesión se discute y acuerda la declaraciónde alcance. También se realiza una valoración inicial de la documentación del sistema de gestióny de los documentos de procesos. Los allos o incumplimientos detectados por la auditoría se

incorporarán al Plan de Acciones Correctivas (CAP). El cliente deberá documentar cómo piensallevar a cabo los CAPs y presentar la inormación a la entidad de certicación para su vistobueno.

Durante la auditoría de certicación se eectúa una valoración objetiva de las prácticas y losprocedimientos organizativos con respecto al sistema de gestión documentado (revisado en laauditoría inicial). El auditor buscará registros (pruebas) de que el Sistema de gestión uncionasegún las especicaciones del sistema de gestión documentado. Una vez nalizada la valoración, elauditor presentará los resultados por escrito en un inorme. Los incumplimientos y observaciones

pasarán al CAP si se considera necesario. Si la auditoría naliza con éxito y se decide concederla certicación, se emite un certicado y se autoriza a la organización a utilizar la marca de laentidad de certicación y la marca de la correspondiente certicación ISO 20000.

También se acuerda un calendario de auditorías de vigilancia que se realizan periódicamentepara comprobar que se siguen cumpliendo los requisitos de la norma ISO 20000 y proponerCAPs si es necesario. Estas auditorías de vigilancia se llevan a cabo a lo largo de un ciclo de 3años con el n de vericar el correcto uncionamiento del sistema de gestión. A ellas hay queañadir las auditorías internas y las actividades continuas de monitorización y gestión dentro dela organización. La recuencia 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 verica la ejecución de los CAPs pendientes.• Durante un período de 3 años se verica 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 degestión).

La auditoría de renovación se realiza cada 3 años y es similar a la auditoría original. Normalmentelleva menos tiempo, puesto que el auditor ya conoce los sistemas (salvo que haya habido uncambio de alcance o de otro tipo). Se evalúan todos los controles para comprobar que el sistemade gestión sigue uncionando correctamente y, si es así, se renueva el certicado para otros 3 años.En caso contrario, las mejoras necesarias, los incumplimientos y las observaciones se incorporanal Plan de Mejora del Servicio (SIP) y al CAP para su resolución. A continuación se vuelve ainiciar el proceso de auditorías de vigilancia durante 3 años.

3.2.2 Certifcación personalLa cualicación internacional de proesionales en ISO 20000 (de acuerdo con el programa decualicación) es cada vez más importante, tanto para organizaciones como para proesionales

individuales. Alcanzar un nivel óptimo de proesionalismo debe ser una de las piedras angularesde los programas de mejora de servicios de TI. La implicación del personal en dichos programas sepuede incentivar oreciendo a los empleados una certicación reconocida internacionalmente.






Para obtener la certicación ISO 20000, las empresas tienen que demostrar que cuentan con unsistema de gestión de la calidad y con procesos ITSM (Gestión de Servicios de TI) bien denidos.Sin embargo, la norma ISO 20000-1: 2005 no se extiende demasiado en los requisitos que debecumplir el personal que participa en la provisión de los servicios. En la introducción se puedeleer:

Se da por supuesto que la ejecución de las cláusulas de esta parte de ISO 20000 se conará apersonas competentes y debidamente cualicadas.

¿Qué quiere decir esto? ¿Qué nivel de conocimiento de los procesos ITSM deben tener estas“personas competentes y debidamente cualicadas”? ¿Y cómo es posible medir de manera objetivael cumplimiento de este requisito?

Resulta dií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 educativosy de cualicación que incluyan deniciones claras y requisitos para los empleados puede acilitarnotablemente la aplicación de la norma.

Por otra parte, los clientes tienden a conar más en organizaciones que pueden presentarcerticados para demostrar que su personal está debidamente cualicado.

Un proyecto de certicación en ISO 20000 exige un alto grado de compromiso y conocimientosa la práctica totalidad del personal que participa en la provisión de servicios de TI. Los principiosde 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 ormación sobre calidad,Gestión de Servicios de TI y procesos de gestión y mejora en general, con el n de aumentarsus conocimientos y su motivación. El auditor, por su parte, debe tener amplios conocimientossobre Gestión de Servicios de TI para poder realizar auditorías de empresas según los requisitosde ISO 20000.

La tabla 3.1 muestra los roles que participan en la Gestión de Servicios de TI y en la gestión dela calidad. Para cada uno de estos roles se debe denir un plan de ormación que especiquelos conocimientos y competencias necesarios. Estos roles son sólo genéricos y no deben serinterpretados como descripciones de unciones o perles proesionales reales. Algunos de estosroles se pueden combinar en una sola unción.

Rol de Gestión de Servicios de TI Descripción breve

Director de TI Es responsable de (parte de) la organización de TI�Normalmente es también el propietario de uno o más procesosde Gestión de Servicios de TI�

Responsable de la Gestión del

Servicio/ Proesional de TI

Implanta, mejora y mantiene la provisión de servicios de TI ylos procesos subyacentes de una organización de TI� Este rolsuele incluir también las tareas de gestor de proceso�

Consultor de servicios de TI Asesora a una organización de TI sobre la introducción,mejora y mantenimiento de servicios de TI y los procesossubyacentes�

Operador ITSM Eectúa una o más de las actividades de un proceso�






Ventajas del programa de cualifcaciónObtener un certicado independiente es la mejor prueba de que se han satisecho plenamentelos requisitos del curso. Demuestra el compromiso de la persona por convertirse en alguiencompetente y valioso para su organización y para los clientes a los que da servicio.

Conseguir un certicado ayuda a los participantes a:• Reorzar 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 proesional.

El certicado 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 cualicadas para empleos que exijan conocimientos de

ISO 20000.• Conocimientos especícos precisos para realizar un trabajo de TI.• Incentivos, bonicaciones y retos para los empleados.

El programa de cualicación de ISO 20000 ha hecho que muchas empresas reconozcan lanecesidad de dar ormación a su personal de Gestión de Servicios de TI. Cualquier organizaciónque decida usar el marco de trabajo ISO 20000 para mejorar sus servicios de TI tiene que serconsciente de que muchos empleados participarán de una manera o de otra. Es probable quese necesiten muy pocos expertos, pero es undamental que el personal esté amiliarizado conla terminología y tenga conocimientos básicos sobre los principios de gestión de la calidad del

servicio.

Tabla 3�1 Roles de Gestión de Servicios de TI y gestión de la calidad del servicio

Rol de Gestión de Servicios de TI Descripción breve

Administrador de sistemas Instala y mantiene uno o más componentes de lainraestructura de TI�

Jee de proyecto Gestiona proyectos de inraestructura o ITSM (mejora de lacalidad)�

Gestor de la calidad Es responsable del sistema de gestión de la calidad de laorganización de TI�

Consultor de gestión de la calidad

del servicio

Asesora a una organización de TI sobre la introducción, mejoray mantenimiento de un sistema de gestión de la calidad�

Auditor externo Valora el sistema de gestión de la calidad de un proveedorde servicios de TI según los requisitos de ISO 20000 paraconceder una certicación externa�

Auditor interno Valora el sistema de gestión de la calidad de un proveedor deservicios de TI según los requisitos de ISO 20000 para detectaroportunidades de mejora�






Un curso sobre undamentos de ISO 20000 orece a los participantes una visión general deISO 20000 y de los principales procesos empleados para gestión de la calidad. También abrela puerta a los cambios de actitud, cultura y procedimientos que se necesitan para mejorar elenoque a cliente y la provisión de servicios de TI. El certicado de Fundamentos de ISO 20000es una recompensa para los participantes en el curso y una orma de medir los conocimientos y

la importancia de ISO 20000 en su organización. El programa de certicación de ISO 20000también ayuda a evaluar a los proveedores de ormación y los materiales para el curso.

Para desarrollar e implantar los planes de mejora de la calidad de los servicios de TI en unaempresa es necesario contar con proesionales bien cualicados en este campo. La piedra angularde este perl proesional debe ser una certicación adecuada en Gestión de Servicios de TI, queal n 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 actores:• La calidad de los instructores.• La planicació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 deormación acreditadas con el n de monitorizar la calidad de los cursos e introducir mejoras sies preciso.

Para obtener una cualicación reconocida internacionalmente suele ser necesario que el candidatoasista a un curso de ormación impartido por un proveedor acreditado.

Las reglas de acreditación garantizan:• La calidad de todos los proveedores de ormación sobre ISO 20000.• Los conocimientos y experiencia de los proesores en materia de Gestión de Servicios de TI,

calidad y educación.• La calidad de los materiales de ormación.• La adaptación de los contenidos del curso a los requisitos para los exámenes del programa de

cualicación en gestión de la calidad del servicio.

Los requisitos que deben cumplir los proveedores de cursos acreditados están publicados en lossitios Web de las entidades examinadoras.

Con el n 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 orece ormación sobre gestión de lacalidad del servicio y es ajena a los intereses de mercado de los proveedores de cursos.






Programa de cualifcaciónUna empresa que desee obtener la certicación ISO 20000 deberá dar ormación a todos losempleados que participen en la gestión de la calidad de los servicios de TI acerca de los requisitosconcretos de las Partes 1 y 2 de la norma, así como sobre temas más generales relacionados conla gestión de la calidad.

Hasta 2007, una persona sólo podía optar a la certicació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 Certifcados(IRCA), una entidad internacional de certicació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

Inormació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 jee de ITSMS• Auditor principal de ITSMS

También itSMF Francia y AFAQ AFNOR Certifcation han unido sus uerzas en el desarrollode un “programa de certicación de auditores jee para ISO/IEC 20000-1”: Auditor Jee de

Gestión de Servicios de TI de ICA ® (ISO/IEC 20000-1). ICA ® tiene acreditación ISO17024 concedida por COFRAC y orece este programa de certicación (que también cumple lanorma internacional ISO 17021) para garantizar que los auditores certicados son personas conexperiencia en ITSM, ISO/IEC 20000-1 y metodología de auditorías.

En 2007, EXIN y TÜV SÜD desarrollaron un programa de ormación y cualicación: “Programade cualicación en ISO/IEC 20000 para personas”. Este programa está diseñado según las normasde acreditación ISO (ISO 17024), por lo que puede ser reconocido por el Foro Internacionalde Acreditación (IAF). El programa de ormación y cualicación de EXIN/TÜV SÜD orecediversas certicaciones dirigidas a los siguientes roles de ITSM:• Fundamentos de ISO/IEC 20000• Proesional de ISO/IEC 20000 (5 posibles certicados)• 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 jee de ISO/IEC 20000

La Figura 3.1 muestra el programa de cualicación. La certicación personal orece actualmenteun programa de cualicación que reconoce internacionalmente los conocimientos de una persona

sobre gestión de la calidad de servicios de TI.






La dierencia principal con las otras opciones está en la estructura. El programa de certicación deEXIN/TÜV SÜD está ormado por “bloques”, cada uno de los cuales demuestra la competencianecesaria para un rol determinado. De esta orma, el bloque “Fundamentos de ISO 20000”puede ormar parte de distintas “ramas de certicación”.

Por ejemplo, un auditor o consultor que comience el proceso de certicación ISO 20000tendrá que aprobar el examen de Fundamentos de ISO 20000 y los exámenes apropiadosdel nivel proesional para demostrar que conoce todos los procesos. Esto signica aprobartres de cinco módulos posibles, incluyendo el módulo obligatorio de Gestión y Mejora. Unavez superado el nivel proesional, el auditor deberá seguir adelante por la rama de auditoríapara adquirir conocimientos más especializados, mientras que el consultor tendrá que elegirla rama de consultoría/gestión para especializarse en la implantación de ISO 20000 y lasdicultades que conlleva.

La tabla 3.2 indica la certicación más adecuada para cada rol de ITSM y gestión de la calidad.

Gestión de Servicios de TI según ISO/IEC 20000Programa básico de cualificación para personalResumen de certificados ofrecidos

RAMA DE GESTIÓN RAMA DE AUDITORÍA

NIVEL PROFESIONAL

NIVEL BÁSICO

Fundamento

F I L T R O

F I L T R O

Gestor/consultor deservicios de TI

Gestión y mejorade procesos

ITSM

Control deservicios de TI

Soporte deservicios de TI

Provisión deservicios de TI

Alineación entreel negocio y lasTecnologías dela Información

Gestor/consultorsénior de servicios

de TI

Auditor interno Auditor jefe

Figura 3�1 Programa de cualicación en ISO 20000 de EXIN/TÜV SÜD para personal






En noviembre de 2007, ISEB anunció que había iniciado conversaciones con itSMF UK conel n de participar en el programa de certicación, añadiendo un examen de nivel básico. Losdetalles de este acuerdo se añadirán a esta publicación cuando sean públicos.

La sección de Reerencias en el Apéndice contiene hipervínculos para acceder a las distintasorganizaciones que orecen certicación.

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

3.3.1 Historia y titularidad de ISO 20000La norma ISO 20000 ue 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 normainternacional.

CertifcaciónE X I N

/ T Ü V

S Ü D

-F un

d am

en

t o s

d eI S

O / I E C2

0 0 0 0

E X I N

/ T Ü V

S Ü D

-P r of e

si on

al

d e

I S O / I E C2

0 0 0 0

E X I N

/ T Ü V

S Ü D

- G e s t or /

c on

s ul t or

s é ni o

r d e s er vi ci o

s d e

T I

s e g ú nI S

O / I E

C2 0 0 0 0

E X I N

/ T Ü V

S Ü D

-A u d i t or i n

t er n

o

d eI S

O / I E C2

0 0 0 0

E X I N

/ T Ü V

S Ü D

-A u d i t or

j ef e

d e

I S O / I E C2

0 0 0 0

i t S MF -A

u d i t or

d eI S

O / I E C2

0 0 0 0

i t S MF -

C on

s ul t

or d eI S

O / I E C

2 0 0 0 0

I R CA -A

u d i t or

d e si s

t em

a sI T

S M

( v ar i o

sni v

el e

s )

I CA -A

u d i t or

j ef

e d e G e s t i ó n

d e

S er vi ci o

s d eT I

( I S O

/ I E C2

0 0 0 0 -1

)

Rol de Gestión de Servicios

de TI

Director de TI

Responsable de la Gestión del

Servicio/ Proesional de TI

Consultor de servicios de TI

Operador ITSM

Administrador de sistemas

Jee 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

Tabla 3�2 Roles de ITSM y gestión de la calidad relacionados con la certicación ISO 20000






BS 15000 tenía su origen en DISC PD 0005, el Código de Práctica para la Gestión de Serviciosde TI, que había sido denido para la Institución Británica de Normalización (BSI) por ungrupo de trabajo ormado por expertos británicos a nales de la década de 1990. Su objetivo erallenar el vacío que había dejado ITIL, cuyos primeros libros (versión 1) carecían de instruccionesconcretas sobre el diseño práctico de procesos para Gestión de Servicios de TI. DISC PD 0005

especicaba claramente requisitos y orecía recomendaciones.

Aunque el punto de partida era ITIL, su desarrollo dio pie a que se incluyeran también otrosprocesos. Esto contribuyó a aclarar las relaciones entre los distintos procesos. La Figura 3.2 muestrade una orma distinta los procesos de provisión y soporte de servicios de la versión 2 de ITIL. Seidenticaron nuevos grupos, incluyendo los procesos de relación y los inormes del servicio, queya se han incorporado a la versión 3 de ITIL3. Este modelo no varió cuando la norma pasó a BS15000 e ISO 20000, aunque se modicaron los nombres de los procesos. El modelo no incluyeprocesos para gestión de inraestructuras TIC ni para gestión de aplicaciones.

itSMF UK publicó BS 15000 en noviembre de 2000. Esta Norma Británica especicaba losrequisitos para un sistema de gestión de la calidad, así como los requisitos de calidad de losdistintos procesos. En sólo unos años, itSMF UK (que también actuaba como entidad decerticación responsable) recibió un gran número de peticiones de empresas que deseaban unacerticación. El interés internacional continuó aumentando hasta que se convirtió en una normainternacional.

PROCESOS DE PROVISIÓN DE SERVICIO

PROCESOS DE CONTROL

PROCESO DEENTREGA

Gestión de la ConfiguraciónGestión de Cambios

Gestión de la Entrega

Gestión de la Capacidad

Gestión de la Disponibilidady la Continuidad del

Servicio

PROCESOS DERESOLUCIÓN

Gestión de Incidencias

Gestión de Problemas

Gestión del Nivel de Servicio

Informes del Servicio

PROCESOSDE RELACIÓN

Gestión de Relacionescon el Negocio

Gestión de Proveedores

Gestión de la Seguridad dela Información

Presupuestos y Contabilidadde los Servicios de TI

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

3 Estos libros de ITIL no habían sido aún publicados y DISC PD005 se adelantó en algunos aspectos, como enel reconocimiento de la gestión de incidencias y la gestión de entregas como procesos independientes� Losnombres de los procesos gestión de la continuidad y gestión nanciera para servicios de TI en las actualizacionesde ITIL en 2000 y 2001 también se basaron en DISC PD005�






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

procesos de Gestión del Servicio.

ISO 9000 e ITIL ® en ISO 20000ITIL® no es el único precursor de ISO 20000. La norma para Gestión de Servicios de TI tambiéndebe 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 seexplicó 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ónde 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 la de la tabla son muy similares y se solapan. ISO 9000presenta una alta evidente de procesos para la realización del producto. Los procesos de Gestiónde Servicios de ITIL® y los requisitos de ISO 20000 vienen a paliar esta carencia.






I T I L ® v e r s

i ó n 3

I T I L ® v e r s i ó n 2

I S O 2 0 0 0 0

I S O

9 0 0 0

R e q u i s i t o s p a r a u n s i s t e m

a d e g e s t i ó n

P r o c e s o s p a r a g e s t i ó n o r g a n i z a t i v a

P r o c e s o s p a r a m e d i d a , a

n á l i s i s y m e j o r a

R e s p o n s a b i l i d a d d e l a d i r e c

c i ó n ,

r e q u i s i t o s d e d o c u m e n t a c i ó

n ,

c o m p e t e n c i a , c o n c i e n c i a c i ó

n y

o r m a c i ó n

P l a n i f c a c i ó n e s t r a t é g i c a ,

d e f n i c i ó n d e

p o l í t i c a s y o b j e t i v o s , c o m u n i c a c i ó n , g a r a n t í a

d e d i s p o n i b i l i d a d d e l o s r e c u r s o s n e c e s a r i o s y

r e v i s i o n e s d e g e s t i ó n ( a s e s P l a n i f c a r y H a c e r

d e l c i c l o P D C A )

P r o c e s o s n e c e s a r i o s p a r a

m e d i r y r e c o p i l a r

d a t o s p a r a a n á l i s i s d e r e n d

i m i e n t o y m e j o r a d e

l a e f c a c i a y l a e f c i e n c i a � I n c l u y e n l a m e d i d a ,

m o n i t o r i z a c i ó n y a u d i t o r í a

d e p r o c e s o s , a s í c o m o

a c c i o n e s c o r r e c t i v a s y p r e v e n t i v a s �

S o n p a r t e

i n t e g r a l d e l o s p r o c e s o s d e g e s t i ó n , g e s t i ó n d e

r e c u r s o s y r e a l i z a c i ó n ( a s e

s V e r i f c a r y A c t u a r d e l

c i c l o P D C A ) �

P r o c e s o s p a r a g e s t i ó n d e r e

c u r s o s

P r o v i s i ó n d e l o s r e c u r s o s n e c e s a r i o s p a r a

p r o c e s o s d e g e s t i ó n o r g a n i z a t i v a , r e a l i z a c i ó n

y m e d i d a

M e j o r a C

o n t i n u a d e l S e r v i c i o

P l a n i f c a c i ó n d e l a

i m p l a n t a c i ó n

d e l a G e s t i ó n d e l S

e r v i c i o

P l a n i f c a c i ó n e i m p l a n t a c i ó n d e l a

G e s t i ó n d e l S e r v i c i o

P l a n i f c a c i ó n d e l a G e s t i ó n d e S e r v i c i o s

( P l a n i f c a r )

I m p l a n t a c i ó n d e l a G e s t i ó n

d e S e r v i c i o s

y p r o v i s i ó n d e l s e r v i c i o ( H a c

e r )

P r o c e s o d

e m e j o r a C S I

M o n i t o r i z a c i ó n , m e d i d a y r e

v i s i ó n

( V e r i f c a r )

M e j o r a c o n t i n u a ( A c t u a r )

E s t r a t e g i a d e l S e r v i c i o

P l a n i f c a c i ó n e i m p l a n t a c i ó n d e

s e r v i c i o s n u e v o s o m o d i f c a d o s

P l a n i f c a c i ó n d e l a r e a l i z a c i ó

n d e l p r o d u c t o

G e s t i ó n d

e l a C a r t e r a d e

S e r v i c i o s

D i s e ñ o d e l S e r v i c i o ,

O p e r a c i ó

n d e l S e r v i c i o

P e r s p e c t i v a d e l n e

g o c i o

P r o c e s o s d e r e l a c i ó n

P r o c e s o s r e l a c i o n a d o s c o n e l c l i e n t e

( + v 1 E n l a c e c o n e l

c l i e n t e )

G e s t i ó n d e r e l a c i o n e s c o n e

l n e g o c i o

G e s t i ó n d

e p r o v e e d o r e s

( v 1 G e s t i ó n d e l a s i n

s t a l a c i o n e s +

r e l a c i o n e s c o n t e r c e

r o s )

G e s t i ó n d e p r o v e e d o r e s

C e n t r o d e

a t e n c i ó n a l u s u a r i o

( p r i m e r s o

l a p e )

G e s t i ó n d e l S e r v i c i o

P r o c e s o s d e r e a l i z a c i ó n

T o d o s l o s p r o c e s o s q u e o r e c e n l a s a l i d a

p r e v i s t a p o r l a o r g a n i z a c i ó n

E s t r a t e g i a d e l S e r v i c i o ,

D i s e ñ o d e l S e r v i c i o ,

M e j o r a C

o n t i n u a d e l S e r v i c i o

P r o v i s i ó n d e S e r v i c i o

P r o c e s o s d e p r o v i s i ó n d e

s e r v i c i o

G e s t i ó n d

e l n i v e l d e s e r v i c i o

G e s t i ó n d e l n i v e l d e

s e r v i c i o

G e s t i ó n d e l n i v e l d e s e r v i c i o

I n o r m e s d e l s e r v i c i o

I n o r m e s d e l s e r v i c i o ( n o u n

p r o c e s o a u t ó n o m o ,

s i n o p a r t e d e

l a g e s t i ó n d e l n i v e l d e s e r v i c i o )

I n o r m e s d e l s e r v i c i o






I T I L ® v e r s

i ó n 3

I T I L ® v e r s i ó n 2

I S O 2 0 0 0 0

I S O 9 0 0 0

G e s t i ó n d e l C a t á l o g o d e

S e r v i c i o s

G e s t i ó n f n a n c i e r a

G e s t i ó n f n a n c i e r a d

e l o s s e r v i c i o s

d e T I

P r e s u p u e s t o s y c o n t a b i l i d a d d e l o s

s e r v i c i o s d e T I

G e s t i ó n d e l a c o n t i n u i d a d d e l o s


G e s t i ó n d e l a c o n t i n

u i d a d d e l o s


G e s t i ó n d e l a d i s p o n i b i l i d a d

y l a

c o n t i n u i d a d d e l s e r v i c i o



G e s t i ó n d e l a

c a p a c i d a d

G e s t i ó n d e l a c a p a c

i d a d

G e s t i ó n d e l a c a p a c i d a d

G e s t i ó n d e l a d e m a n d a

G e s t i ó n d e l a d e m a n d a ( n o u n

p r o c e s o a u t ó n o m o ,

s i n o p a r t e d e

l a g e s t i ó n d e l a c a p a c i d a d )

G e s t i ó n d e l a s e g u r i d a d d e l a

i n o r m a c i ó

n

G e s t i ó n d e l a s e g u r i d a d

G e s t i ó n d e l a s e g u r i d a d d e

l a

i n o r m a c i ó n

S o p o r t e d e S e r v i c i o

O p e r a c i ó


P r o c e s o s d e r e s o l u c i ó n

G e s t i ó n d e i n c i d e n c i a s

G e s t i ó n d e i n c i d e n c

i a s

G e s t i ó n d e i n c i d e n c i a s

G e s t i ó n d e p e t i c i o n e s

C e n t r o d e


( s e g u n d o

s o l a p e )

C e n t r o d e a t e n c i ó n

a l u s u a r i o

G e s t i ó n d e p r o b l e m a s

G e s t i ó n d e p r o b l e m

a s

G e s t i ó n d e p r o b l e m a s

T r a n s i c i ó n d e l S e r v i c i o ,

O p e r a c i ó


P r o c e s o s d e c o n t r o l

G e s t i ó n d e l a c o n f g u r a c i ó n y

a c t i v o s d e

l s e r v i c i o

G e s t i ó n d e l a c o n f g

u r a c i ó n

G e s t i ó n d e l a c o n f g u r a c i ó n

G e s t i ó n d e c a m b i o s



P l a n i f c a c i ó n y s o p o r t e d e l a

T r a n s i c i ó n

( p r i m e r s o l a p e )

V a l i d a c i ó n

y p r u e b a s d e l s e r v i c i o

E v a l u a c i ó n

C e n t r o d e


( t e r c e r s o l a p e )

C e n t r o d e a t e n c i ó n

a l u s u a r i o

T r a n s i c i ó n d e l S e r v i c i o

P r o c e s o d e e n t r e g a

G e s t i ó n d e e n t r e g a s y

d e s p l i e g u e s

G e s t i ó n d e e n t r e g a s

G e s t i ó n d e e n t r e g a s

P l a n i f c a c i ó n y s o p o r t e d e l a

T r a n s i c i ó n

( s e g u n d o s o l a p e )

F u e r a d e

I S O 2 0 0 0 0 :

F u e r a d e I S O 2 0 0 0 0 :

G e s t i ó n d e a c c e s o s

G e s t i ó n d e e v e n t o s

O p e r a c i o n

e s d e T I

G e s t i ó n d e l c o n o c i m i e n t o

M o n i t o r i z a

c i ó n y c o n t r o l

G e s t i ó n d e i n r a e s t r

u c t u r a s T I C

G e s t i ó n d e a p l i c a c i o

n e s

T a b l a 3 � 3

P r o c e s o s d e l a s v e r s i o n e s 2 y 3 d e I T I L ® ,

I S O

2 0 0 0 0 e I S O

9 0 0 0






Pasado, presente y uturo de ITIL ®

La Biblioteca de la Inraestructura de Tecnología de Inormación (ITIL®) orece un marco detrabajo común para todas las actividades del departamento de TI con el n de aumentar la madurezde la provisión, el soporte y el control de los servicios de TI. Fue desarrollada en la década de1980 por la Agencia Central de Inormática y Telecomunicaciones (CCTA, actualmente Ocina

de Comercio del Gobierno, OGC) del Gobierno Británico. Ante la escalada en los costes de TI,el objetivo undamental ue utilizar los recursos de TI de orma más eciente y con un mayorcontrol de costes.

La Biblioteca de la Inraestructura de Tecnología de Inormación nació como una colección delibros, cada uno de los cuales cubría una práctica concreta de la Gestión de Servicios de TI. Trasla publicación inicial, el número de libros aumentó rápidamente hasta los 48 volúmenes con laversió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 ueron revisados a partir de 1999 para incorporar las prácticas másrecientes, la inormática distribuida e Internet. El resultado de esta actualización ue la versión2 de ITIL® (2000), cuyo objetivo ue hacer ITIL® más accesible (y asequible) para quienesdesearan adoptarlo. La versión 2 de ITIL® estructuró las publicaciones en “conjuntos” lógicosque agrupaban directrices de procesos relacionados en los distintos aspectos de la gestión, lasaplicaciones y los servicios de TI.

Los libros y disciplinas de la versión 2 de ITIL® ueron los siguientes:• Soporte de Servicio

• Provisión de Servicio• Gestión de Inraestructuras TIC• Planicació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 Sotware

En diciembre de 2005, la OGC promulgó una “Actualización de ITIL”, comúnmente conocidacomo ITIL® versión 3 (v3). El proyecto de actualización nalizó con la publicación de cinconuevos textos principales y un glosario Web, el 30 de mayo de 2007. La “nueva ITIL” presentala Gestión de Servicios de TI como un ciclo continuo de servicios de diseño, transerencia y operación de servicios. No obstante, antes de diseñar un servicio es necesario denir la estrategiade servicios de TI. Los procesos se deben mejorar de orma continua durante todo el ciclo de vidadel servicio. Todo ello da como resultado las cinco ases siguientes, que se muestran también enla 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.






3. Transición del Servicio - Se ocupa de gestionar cambios, los riesgos y el aseguramiento dela calidad, y de implantar diseños de servicios de modo que en las operaciones del servicio sepuedan controlar los servicios y la inraestructura.

4. Operación del Servicio - Explica cómo aumentar la ecacia y la eciencia mientras se ejecutanservicios en el entorno operativo.

5. Mejora Continua del Servicio - Comprueba la calidad de los servicios y la aumenta mediantemejoras en el diseño, la introducción y la operación de servicios.

Para simplicar, es posible trazar una correspondencia entre las ases del ciclo de vida del serviciode la versión 3 de ITIL® y las ases del ciclo PDCA. Las ases Estrategia del Servicio y Diseñodel Servicio podrían corresponder a la ase Planicar del ciclo de Deming, mientras que lasases Transición del Servicio y Operación del Servicio equivaldrían a la ase Hacer. La MejoraContinua del Servicio (CSI) representa las ases Vericar y Actuar del ciclo PDCA, junto con lamonitorización y los inormes sobre el rendimiento de los procesos. Por supuesto, cada una de lasases del ciclo de vida se debe mejorar de orma continua.

Aunque no hay ninguna relación ormal entre ISO 20000 e ITIL® (no existe ningún controldenido o implícito entre ambas), la norma está basada en los libros de la versión 2 de ITIL ®.Esto signica que los cambios en el contenido, el alcance y la terminología de la versión 3 deITIL® no aparecen todavía refejados en ISO 20000. No obstante, una de las muchas consignasque recibieron los autores de la versión 3 de ITIL® ue la de adaptar la nueva versión a ISO20000. Aunque sigue habiendo algunas dierencias entre la norma e ITIL®, la alineación entreambas no había sido nunca tan evidente.

Por ejemplo, ISO 20000 trata las peticiones de servicio como incidencias del mismo modo quela versión 2 de ITIL®, mientras que la versión 3 establece una separación ormal en gestión deincidencias, gestión de peticiones y gestión de eventos. Es de suponer que la próxima actualización

M e j o r a Con tinua d e l S e r v i c i o

T r a n s

i c i

ó n d e l

S e r v

i c i o

O p e r a c i ó n d e l S ervic i o

D i s

e ñ o

d e l S e r v

i c io

E s trat e g i a d e l S e

r v i

c i oITIL V3

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






de ISO 20000 refejará las mejores prácticas incluidas en la versión 3 de ITIL®. Para ello puede sernecesario algún tiempo, puesto que las normas ISO deben superar un riguroso proceso de controlde cambios para garantizar la calidad del producto nal. En cualquier caso, no se recomiendaesperar hasta que aparezca la siguiente versión de la norma, ya que se pueden obtener importantesventajas 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 cumplenlos requisitos de ISO 20000, ya que la norma admite que el proveedor de servicios puede utilizarcualquiera de los distintos marcos de trabajo existentes para la Gestión del Servicio.

ISO 9000La Organización Internacional de Normalización (ISO) ha existido desde 1947. Las primerasnormas ISO se reerí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. Especica requisitos para todas lasorganizaciones, independientemente del tipo de actividades realizadas, el tamaño del negocio ola complejidad de los procesos de negocio. La organización que implanta un sistema de gestióngenérico puede ser un parque de atracciones, un proveedor de servicios de TI, un departamentodel gobierno o una pequeña empresa de ontanerí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 ormaban una largalista de documentos, lo que obligaba a muchas organizaciones a generar muchos papeles para

demostrar el cumplimiento.

La situación es dierente con ISO 9001:2000, una norma que se centra en el rendimiento, enla mejora continua y en la satisacción de los clientes. La cantidad de documentación se puedereducir mucho en unción de la organización, la complejidad de sus procesos y los niveles decompetencia 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 lacalidad en lugar de un sistema de documentos (ISO, 2001).

La amilia de normas ISO 9000 incluye ISO 9000, ISO 9001:2000 e ISO 9004. ISO 9000contiene los undamentos y la terminología para sistemas de gestión de la calidad. ISO 9001especica los requisitos que debe cumplir un sistema de gestión de la calidad, mientras que ISO9004 contiene directrices para la mejora del rendimiento.

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

servicios, sus suministradores y sus clientes.






La norma omenta la adopción de un planteamiento de procesos integrados para la Gestión deServicios de TI (véase Sección 3.3.4). Tiene en cuenta todos los elementos que son obligatoriospara una buena Gestión del Servicio (es decir, aquellos que son comunes y exigidos por todoslos proveedores de servicios para la Gestión del Servicio), pero no se ocupa directamente derequisitos particulares.

En las especifcaciones ISO 20000-1 se declara:ISO 20000-1:2005 dene los requisitos que debe cumplir un proveedor de servicios paraorecer servicios gestionados con una calidad aceptable para sus clientes.

Puede ser utilizada:• Pornegociosquevayanaofertarsusservicios.

• Porempresasqueexijanunenfoquecoherente a todos los proveedores de servicios en unacadena de suministro.

• PorproveedoresdeserviciosquedeseenevaluarcomparativamentesuGestióndeServiciosde TI.• Comobaseparaunavaloraciónindependiente.

• Porunaorganizaciónquetengaquedemostrarquetienecapacidadparaofrecerserviciosque satisagan los requisitos de los clientes.

• Porunaorganizaciónquedeseemejorarsuserviciomediantelaaplicaciónecazdeprocesos para monitorizar y mejorar la calidad del servicio.

3.3.3 Dierencia entre ISO 20000-1 e ISO 20000-2La norma ISO 20000 consta de dos partes reunidas bajo el título general de Gestión del Servicio

de Tecnologías de la Inormación:• Parte 1: Especifcaciones - Publicada como ISO 20000-1: 2005, es la especicación ormal 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 orece instrucciones y recomendaciones para los procesos deGestión del Servicio dentro del alcance de la norma ormal.

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 certicación, mientras que laParte 2 incluye una lista de directrices y sugerencias (“recomendaciones”) para proveedores deservicios.

3.3.4 Grupos de procesosISO 20000 omenta la adopción de un planteamiento de procesos integrados. Una organizaciónque quiera desarrollar un sistema de gestión de la calidad tiene que identicar su propósito, denirlas políticas y objetivos y determinar los procesos y su secuencia. Para planicar un proceso, unaorganización tiene que denir las actividades que componen ese proceso.

ISO 20000-1 requiere diversas actividades. Concretamente dene 170 “obligaciones”, mientras

que ISO 9001 contiene 135. También hace reerencia a procesos e interaces de procesos, aunquees poco clara sobre las relaciones entre procesos. Uno de los motivos para ello es que dichas






relaciones dependen de la aplicación en una organización. Otra razón es que son demasiadocomplejas para incorporarlas a un modelo.

La subsección 1 de ISO 20000-1 contiene una imagen que muestra “varios procesos de Gestióndel 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ánincluidos en la Subsección 3.1 de ISO 20000, “Responsabilidad de la dirección”, en la Subsección4, “Planicación e implantación de la Gestión del Servicio”, y en la Subsección 5, “Planicación eimplantación de servicios nuevos o modicados”. Los procesos de mejora se encuentran tambiénen la Subsección 4 de ISO 20000-1.

Las especifcaciones 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 unaorganización puede considerar que son necesarios objetivos y controles adicionales para

Plan

Check

Act

Planificación e Implantación deServicios Nuevos o Modificados

Responsabilidad de la Dirección Requisitos de Documentación

Competencia, Concienciación y Formación

Sistema de Gestión

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

• Gestión de la Seguridad dela Información

• Presupuestos y Contabilidadde los Servicios de TI

• Gestión de la Capacidad• Gestión de la Disponibilidad

y la Continuidad del Servicio

Proceso de Entrega

• Gestión de Entregas Procesos de Resolución• Gestión de Incidencias

• Gestión de Problemas

Procesos de Control

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

Procesos de Relación

• Gestión de Relaciones conel Negocio

• Gestión de Proveedores

Planificación eImplantación dela Gestión del

Servicio

Planificar

Verificar

HacerActuar

Figura 3�4 Sistema de gestión de la calidad de Servicios de TI según ISO 20000






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 requisitosde 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 elCódigo de buenas prácticas, para hacer que dicho desarrollo siga las mejores prácticas de laGestió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ónde Servicios de TI. El objetivo de estos procesos es garantizar el mejor servicio posible que satisaga

las necesidades de negocio del cliente con los recursos acordados; es decir, un servicio proesional, coneciencia 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 uncionales (y puestos de trabajo), puede hacer que la Gestión del Servicio resulte un tema conuso para el nuevo gestor, hasta el punto de que la terminología se convierta en una barrera que impidala denición de procesos ecaces. La á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 enoque más coherente de la Gestión del Servicio. De esta ormadispondrá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 planicar 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 losprocesos de presupuestos y contabilidad de los servicios de TI, en la Subsección 6.4: “Debe haberpolíticas y procedimientos claros para: a) elaboración y control de presupuesto y contabilidadde todos los componentes, incluyendo activos de TI, recursos compartidos, gastos generales,servicios suministrados externamente, personal, seguros y licencias.” Así, mientras ISO 9000considera los procesos de gestión de recursos como uno de tres tipos posibles de procesos desoporte, ISO 20000 sólo los menciona como una subsección de los procesos de provisión deservicio.

3.3.5 Documentación, procesos, procedimientos y registros necesariosPor lo que respecta a documentación, procesos, procedimientos y registros, la Sección 3.2 de ISO20000-1 establece:

Los proveedores de servicios deben acilitar los documentos y registros necesarios para

garantizar la ecacia en la planicación, operación y control de la Gestión del Servicio,incluyendo:a) Políticas y planes documentados de Gestión del Serviciob) Acuerdos de nivel de servicio documentados






c) Procesos y procedimientos documentados requeridos por esta normad) Registros requeridos por esta norma

Se deberán denir 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 ormato o soporte.4

Como ocurre en cualquier norma ISO/IEC, todos los procesos descritos en la Parte 1 son deobligado cumplimiento para la organización que se somete a la auditoría. Todos ellos debenir acompañados de documentos y registros, incluyendo una descripción del proceso. Sin losdocumentos y registros de apoyo, no es posible vericar que todos los procesos obligatorioscumplen su descripción y presentan los niveles necesarios de ecacia y eciencia. Las organizacionestienen libertad para diseñar procesos y procedimientos adicionales para cumplir los requisitos de

ISO 20000-1.

Aunque ISO no dene el término “procedimiento”, requiere “procedimientos documentados y bien mantenidos para cada proceso o conjunto de procesos” (Sección 4.2, “Implantación de laGestión del Servicio y provisión de los servicios”). El glosario de la versión 3 de ITIL® dene unprocedimiento de la siguiente manera:

Un procedimiento es un documento que contiene los pasos que especican cómo llevar acabo una actividad. Los procedimientos están denidos como parte de procesos.

Por lo tanto, la descripción de los procesos debe incluir también la descripción de losprocedimientos. Hay también algunos procedimientos adicionales que están relacionados conel alcance de esta norma pero quedan uera de los procesos mencionados, como por ejemploun proceso o procedimiento de auditoría. La tabla 3.4 contiene procesos y procedimientos quese mencionan explícitamente, aunque hay que recordar que en ningún caso se trata de una listaexhaustiva.

4 Por ejemplo: discos ópticos o electrónicos, otograías, copia maestra de sotware o sitio Web de intranet�

(Sub)Sección de la Parte 1 Proceso o procedimiento exigido

3�2 Requisitos de la documentación Procedimientos de documentación

4�2 Implantación de la Gestión delServicio y

provisión de los servicios (Hacer)

Procedimientos documentados y bien mantenidospara cada proceso o conjunto de procesos

4�3 Monitorización, medición y revisión

(Verifcar)

Realización de auditorías

4�4 Mejora continua (Actuar) Mejora de la Gestión del Servicio

6�1 Gestión del nivel de servicio Soporte de procedimientos de SLA

6�4 Presupuestos y contabilidad de los

servicios de TI

Presupuesto y contabilidad de todos los componentesDistribución de costes indirectos y asignación decostes directos a los serviciosControl nanciero y de autorizaciones






Los proveedores de servicios deberán proporcionar documentación y registros para dar soportea 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 denir procedimientos y responsabilidades para la creación, revisión, aprobación,mantenimiento, eliminación y control de documentos y registros. El propietario responsablesénior debe garantizar que se cuenta con la evidencia necesaria para superar una auditoría depolíticas, planes y procedimientos de Gestión del Servicio. Tiene que haber un proceso operativopara la creación y gestión de documentos. Igualmente se debe proteger la documentación contraposibles daños.

Al igual que para procesos o procedimientos, ISO 20000 menciona pocos documentos quese exijan especícamente. Esto no signica que una organización que disponga sólo de losdocumentos exigidos explícitamente pueda recibir la certicación de manera automática. Será

preciso demostrar que se han denido e implantado todos los procesos exigidos por la norma,además de poder presentar la documentación correspondiente (no necesariamente en papel).

(Sub)Sección de la Parte 1 Proceso o procedimiento exigido

6�5 Gestión de la capacidad Monitorización de la capacidad del servicio Ajuste del rendimiento del servicioProvisión de la capacidad adecuada

6�6 Gestión de la seguridad de la

inormación

Investigación de todas las incidencias de seguridad Adopción de acciones de gestión

7�2 Gestión de relaciones con el negocio Proceso de quejasProceso de satisacción del cliente

7�3 Gestión de Proveedores Control del suministrador:• Revisión de contratos

• Disputas contractuales

• Fin de servicio

Procesos de suministradores y subcontratistas

8�2 Gestión de incidencias Gestión del impacto de incidenciasDenición de registro, priorización, impacto en elnegocio, clasicación, actualización, escalado,resolución y cierre ormal de todas las incidencias

8�3 Gestión de problemas Identicación, minimización y eliminación del impactode incidencias y problemas

9�1 Gestión de la confguración Comprobación de la integridad de sistemas, servicios ycomponentes de los serviciosRegistro de deciencias, inicio de acciones correctivasy preparación de inormes

9�2 Gestión de cambios Control de la autorización e implantación de cambiosde emergencia

10�1 Gestión de entregas Actualización y modicación de la inormación deconguración y los registros de cambios

Tabla 3�4 Procesos o procedimientos exigidos por ISO 20000-1






La tabla 3.5 muestra los planes, políticas y otros documentos que una organización necesita parala planicación, la operación y el control.

Los registros son un tipo especíco de evidencia. Los registros son documentos que indican losresultados obtenidos o que proporcionan evidencia sobre las actividades realizadas (la Sección3.3.8 sobre terminología contiene más inormación).

La tabla 3.6 muestra los registros exigidos explícitamente por ISO 20000-1; una vez más, esto nosignica que tener todos los registros indicados en la lista suponga la certicación automática.

Tabla 3�5 Documentos exigidos por ISO 20000-1

(Sub)Sección de la Parte 1 Documentos exigidos

4�1 Planifcación de la Gestión del Servicio(Planifcar)

Dirección de gestión y responsabilidadesdocumentadas

4�2 Implantación de la Gestión del Servicio y

provisión de los servicios (Hacer)

Políticas, planes, procedimientos y denicionespara cada proceso o conjunto de procesos


(Verifcar)

Objetivos de revisiones, valoraciones y auditorías

4�4 Mejora continua (Actuar) Política de mejora del servicio

6�1 Gestión del nivel de servicio Acuerdos de nivel de servicio, junto con acuerdosde servicio y contratos de suministradores

6�3 Gestión de la disponibilidad y la

continuidad del servicio

Planes de disponibilidad y continuidad de losservicios

6�5 Gestión de la capacidad Plan de capacidad6�6 Gestión de la seguridad de la inormación Política de seguridad de la inormación

Controles de seguridad

7�2 Gestión de relaciones con el negocio Grupos de interés y clientes del servicio Actas de reuniones

7�3 Gestión de Proveedores Proceso de gestión de proveedores Acuerdo de nivel de servicio con suministradoresInteraces de procesosRoles y relaciones entre suministradoresprincipales y subcontratados

9�1 Gestión de la confguración Política sobre denición de elementos de

conguración9�2 Gestión de cambios Alcance de cambios en servicio e inraestructura

10�1 Gestión de entregas Política de entregas

(Sub)Sección de la Parte 1 Registros exigidos


(Verifcar)

Registros de revisión, valoración y auditoría Acciones correctivas identicadas

4�4 Mejora continua (Actuar) Mejoras sugeridas del servicio

6�1 Gestión del nivel de servicio Servicios, objetivos especícos y característicasde carga de trabajo

Registros de acciones identicadas de mejora6�3 Gestión de la disponibilidad y la

continuidad del servicio

Registros de disponibilidadRegistros de pruebas de planes de continuidaddel servicio






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 integradoy con documentación interrelacionada.

3.3.6 Propósito de las distintas partes de la normaLa especicación de la norma dene un objetivo para cada una de sus partes. Dichos objetivosson 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 eectiva gestión e implantación detodos los servicios de TI.

• Sección 4.1: Planifcación de la Gestión del Servicio (Planifcar) - Planicar la implantacióny 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 (Verifcar) - Monitorizar, medir y revisarel cumplimiento de los objetivos y el plan de Gestión del Servicio.

• Sección 4.4: Mejora continua (Actuar) - Mejorar la ecacia y la eciencia de la provisión y de la Gestión del Servicio.

• Sección 5: Planifcación e implantación de servicios nuevos o modifcados - Asegurarque, tanto los servicios nuevos, como las modicaciones 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 - Denir, acordar, registrar y gestionar los niveles

de servicio.• Sección 6.2: Inormes del servicio - Generar en plazo los inormes acordados, ables y precisos, que sirvan de apoyo a la toma de decisiones y aciliten una comunicación ecaz.

(Sub)Sección de la Parte 1 Registros exigidos

6�4 Presupuestos y contabilidad de los

servicios de TI

Registros nancieros de presupuestos yprevisiones

6�6 Gestión de la seguridad de la inormación Registros de incidencias de seguridad Acciones de mejora

7�2 Gestión de relaciones con el negocio Registros de quejas del servicio Acciones de mejora

7�3 Gestión de proveedores Acciones de mejora

8�2 Gestión de incidencias Registros de incidencias

8�3 Gestión de problemas Registros de problemas Acciones de mejora

9�1 Gestión de la confguración Registros de conguraciónRelaciones y documentación necesaria para unaGestión del Servicio ecazDeciencias

9�2 Gestión de cambios Solicitudes de cambioRegistros de cambios (análisis)

Acciones de mejora

10�1 Gestión de entregas Fechas de entrega y entregables, con reerenciaa las correspondientes solicitudes de cambios,errores conocidos y problemas

Tabla 3�6 Registros exigidos por ISO 20000-1






• Sección 6.3: Gestión de la disponibilidad y la continuidad del servicio - Asegurar que loscompromisos adquiridos con los clientes sobre la disponibilidad y la continuidad del serviciose pueden cumplir bajo todas las circunstancias.

• Sección 6.4: Presupuestos y contabilidad de los servicios de TI - Elaborar y controlar lospresupuestos 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 todomomento, la capacidad suciente para cubrir la demanda acordada, presente y utura, de lasnecesidades del negocio del cliente.

• Sección 6.6: Gestión de la seguridad de la inormación - Gestionar ecazmente la seguridadde la inormación para todas las actividades del servicio.

• Sección 7.2: Gestión de relaciones con el negocio - Establecer y mantener una buena relaciónentre el proveedor de servicios y el cliente, basándose en el entendimiento del cliente y de losundamentos 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 prontocomo sea posible o responder a peticiones de servicio.

• Sección 8.3: Gestión de problemas - Minimizar los eectos negativos sobre el negocio deinterrupciones del servicio, mediante la identicación y el análisis proactivos de la causa de lasincidencias y la gestión de los problemas para su cierre.

• Sección 9.1: Gestión de la confguración - Denir y controlar los componentes del servicioy de la inraestructura, y mantener inormación precisa sobre la conguració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 omá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 TIComo se explicó en la Sección 3.3.1, la versión 3 de ITIL® consiste en un núcleo que es laEstrategia del Servicio, en torno al cual se desarrolla un ciclo de vida ormado por Diseño delServicio, Transición del Servicio, Operación del Servicio y Mejora Continua del Servicio (Figura3.3). Hasta cierto punto, es posible establecer una correspondencia entre los requisitos de ISO20000 y las ases 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 denido según la norma ISO20000 representa la estrategia de la Gestión del Servicio.

Los requisitos sobre planicación e implantación de la Gestión del Servicio se reeren al diseñode la gestión de los servicios prestados. El libro sobre Diseño del Servicio de la versión 3 deITIL® discute el diseño del servicio prestado y explica qué tiene que hacer la organización paragarantizar la calidad de los servicios.

Los requisitos sobre planicación e implantación de servicios nuevos o modicados tienen por objeto

hacer que la transición de nuevos servicios a operación se realice correctamente, de manera quese pueda garantizar la calidad de los servicios nuevos y los ya existentes. Este tema se discute en






el libro sobre Transición del Servicio de la versión 3 de ITIL®, que también contiene un grannúmero de mejores prácticas.

El texto de ISO 20000 sobre procesos (capítulos 6-10 de la norma) dene los requisitos que debencumplir 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 mejoresprácticas de Operación del Servicio en ITIL®, ya que los procesos mencionados en ISO 20000están repartidos entre los cinco libros esenciales de la versión 3 de ITIL®.

3.3.8 Términos y defniciones relativas a ISO 20000

Las especifcaciones ISO 20000-1 dicen:

Para los nes de ISO 20000 son de aplicación los siguientes términos y deniciones.

2.1Disponibilidad (availability):Capacidad de un componente o un servicio para realizar su unción requerida en un instantedeterminado 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 elservicio está disponible realmente para su uso por el negocio y las horas de servicio acordadas.

2.2

Línea de reerencia (baseline):Instantánea del estado de un servicio o un elemento de conguración individual en unmomento concreto (véase 2.4).

2.3Registro de cambio (change record):Registro que contiene los detalles de aquellos elementos de conguración (véase 2.4) a los queaecta un cambio autorizado y sobre cómo los aecta.

2.4Elemento de conguración (Conguration Item, CI):Un componente de una inraestructura o un elemento que está o estará bajo el control de lagestión de la conguración.

NOTA: Los elementos de conguración pueden variar mucho en complejidad, tipo y tamaño, comprendiendo desde un sistema completo (incluyendo todo el hardware, elsotware y la documentación) hasta un módulo aislado o un componente hardware menor.

2.5

Base de datos de gestión de la conguración (Conguration Management Database, CMDB):Base de datos que contiene todos los detalles relevantes de cada elemento de conguración y los detalles de las relaciones importantes entre ellos.






2.6Documento (document):Inormació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 laevidencia de intenciones.

NOTA 2: Ejemplos de documentos son las declaraciones de políticas, los planes, losprocedimientos, los acuerdos de nivel de servicio o los contratos.

2.7Incidencia (incident):Cualquier suceso que no sea parte del uncionamiento normal de un servicio y que cause, o

pueda causar, una interrupción de dicho servicio o una disminución de su calidad.

2.8Problema (problem):Causa subyacente desconocida de una o más incidencias.

2.9Registro (record):Documento que indica los resultados obtenidos o que proporciona la evidencia de lasactividades realizadas.

NOTA 1: En esta norma, los registros se distinguen de los documentos por el hecho de quelos registros sirven para proporcionar la evidencia de actividades, en lugar de la evidencia deintenciones.

NOTA 2: Ejemplos de registros son los inormes de auditorías, las solicitudes de cambio,los inormes de incidencias, los registros de ormación individual o las acturas enviadas aclientes.

2.10Entrega (release):Colección de elementos de conguración, nuevos y/o modicados, que se prueban eintroducen de orma conjunta en el entorno de producción.

2.11Solicitud de cambio (request or change):Formulario, en orma impresa o en pantalla, que se utiliza para registrar los detalles de unasolicitud de un cambio en cualquier elemento de conguración perteneciente a un servicio ouna inraestructura.






2.12Centro 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 deltrabajo 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 losservicios y los niveles de servicio acordados.

2.14Gestión del Servicio (Service Management)Gestión de los servicios para cumplir con los requisitos de negocio.

2.15Proveedor de servicios (service provider)La organización que quiere cumplir con la Norma ISO/IEC 20000.





Esta parte del libro explica los requisitos de ISO 20000 y orece una guía para la evaluación,mantenimiento y mejora del sistema de gestión de la calidad de servicios de TI. Contieneliteralmente las especicaciones para la provisión de servicios de TI de calidad según ISO 20000-1y el código de buenas prácticas de ISO 20000-2. Al nal del título de cada sección se indica entreparé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 lacalidad en ISO 9000 es el planteamiento de procesos, que especica que es posible alcanzar conmás eciencia un determinado resultado si las actividades y recursos relacionados se gestionancomo un proceso. Otro principio de la gestión de la calidad es el planteamiento de sistema parala gestión, según el cual la organización puede alcanzar sus objetivos de una orma más ecaz y eciente si identica, comprende y gestiona procesos interrelacionados como un sistema.

Las ilustraciones se muestran en notación BPM (Modelo de Procesos de Negocio) para que lanorma sea más sencilla de comprender. Estas ilustraciones contienen en muchos casos actividadesseparadas, sin mostrar la conexión con las otras actividades en un modelo de procesos. Comose dice en la Sección 1.1 de la Parte 1 de ISO 20000, la relación entre los procesos depende desu aplicación dentro de una organización. Lo mismo ocurre con la relación entre las actividades.

La norma habla undamentalmente de actividades, más que de procesos. Algunos de los procesoso los pasos de los procesos se pueden solapar. Estrictamente hablando, cada verbo que aparece enla norma se podría reducir a una sola actividad. Para acilitar la comprensión, se han combinadovarias actividades en un paso de proceso.

El Código de buenas prácticas (Parte 2 de la norma) orece una explicación de los requisitos; en

algunos casos esto implica más detalles y, por tanto, más actividades y documentos de los queserían necesarios según la Parte 1 de la norma.

Capítulo 4

Especifcaciones y Códigode buenas prácticas para

ISO 20000






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

Para simplicar las cosas, cada sección incluye también una guía de mejores prácticas cuyoobjetivo 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 trabajopara garantizar la ecacia de la gestión e implantación de todos los servicios de TI.

Guía de ISO 20000-1 Guía de ISO 20000-2

Actividad implícitade ISO 20000-2

Actividad explícitade ISO 20000-1

Actividad implícitade ISO 20000-1

Disparador deISO 20000-1

Actividad explícitade ISO 20000-2

Documento implícitode ISO 20000-2

Documento explícitode ISO 20000-1

Documento implícitode ISO 20000-1

Disparador deISO 20000-2

Documento explícitode ISO 20000-2

ISO 20000-1 ISO 20000-2

Figura 4�1 Leyendas de las ilustraciones en notación BPM (Modelo de Procesos de Negocio)





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

Responsabilidad de la dirección (3.1)


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 Serviciodentro del contexto de los requisitos de negocio de la organización y de los requisitos de losclientes.

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 satisacción del cliente.d) Designar un miembro de la dirección como responsable para la coordinación y gestión detodos los servicios.

e) Determinar y proveer recursos para planicar, implementar, monitorizar, revisar y mejorarla provisión y la gestión de los servicios, por ejemplo, contratando el personal apropiado ogestionando la rotación personal.

) 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 planicados, para asegurar

la continuidad de su idoneidad, su adecuación y su eectividad.


El papel de la dirección para asegurar que las mejores prácticas son adoptadas y mantenidas en los procesos es undamental 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 identicar un responsable a nivel de altadirección como responsable de los planes de Gestión del Servicio. Este responsable senior deberíaresponsabilizarse de la entrega a todos los niveles del plan de Gestión del Servicio.

El rol de responsable sénior debería estar al rente de los recursos designados para la actividades de mejora del servicio, bien sean actividades continuas o con un enoque de proyecto.

El responsable sénior debería estar apoyado por un grupo encargado de la toma de decisiones que tengala suciente autoridad para denir 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 fujo deprocesos.

Las actividades de la dirección no orman parte de los procesos en la Figura 3.2, aunque son unaparte importante de los procesos de negocio.






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 sobreresponsabilidad de la dirección se puede demostrar mediante liderazgo y acciones documentadaspara 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.

Definir la política,los objetivos y losplanes de Gestión

del Servicio

Política, objetivosy planes de

Gestión del Servicio

Transmitir laimportancia

Registros decomunicaciones

Garantizar laidentificación de

los requisitosdel cliente

Requisitos

del clienteRequisitosdel cliente

Garantizar elcumplimiento de

los requisitosdel cliente

Medidas delogros de servicios

Medidas desatisfaccióndel cliente

Determinar yproporcionar

recursos

Recursosdeterminados

Gestionar riesgos

Efectuar revisionesRegistros

de revisiones

Designar a ungestor responsable

Incluye la gestión derecursos para actividadesde mejora del servicio

Apoyado por ungrupo autorizado detoma de decisiones

Gestor responsabledesignado

Intervaloplanificado

Interfaces:

Mejora continua (Actuar):- Sugerir mejoras para SIP

Figura 4�1�1 Responsabilidad de la dirección






• 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 satisacció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, planesde acción y seguimientos.

4.1.2 Requisitos de documentación (3.2)


Los proveedores del servicio deben acilitar documentos y registros necesarios para aseguraruna planicación, operación y control de la Gestión del Servicio eectivas. 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 dierentes tipos de documentos y registros.

NOTA: La documentación puede estar en cualquier orma o tipo de soporte.


El responsable senior debería asegurar que las evidencias necesarias están disponibles para una auditoriade las políticas, planicaciones 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 orma de documentos, los cuales pueden ser de cualquier tipo y estar en cualquier ormato o soporte que sea adecuado para su n.

Los siguientes documentos son considerados normalmente como válidos para servir de evidencias de la planicación de la Gestión del Servicio:a) Políticas y planes b) Documentación del servicioc) 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 satisacen las características descritas.






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 inormáticos.


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 laspocas “obligaciones” sobre procesos y procedimientos en ISO 20000-1.

Políticas yplanes de Gestión

del Servicio

SLAs

Procesos yprocedimientos

Registros (controlde procesos)

Definirprocedimientos

y responsabilidadesde documentación

Responsabilidadesde documentación

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

Procedimientosde documentación

Glosariode términos

La documentación puede ser decualquier tipo, formato o soporte

Proporcionardocumentos/

evidenciade auditoría

Interfaces:


Figura 4�1�2 Requisitos de documentación






La documentación se utiliza como medio para comunicar inormación y para compartirconocimientos. También hace que sea más sencillo mejorar el rendimiento de la organización. Sindocumentación, una organización no puede tener una idea común de su propio rendimiento.

La serie ISO 9000 orma 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ño2000 de la serie ISO 9000 incluye una metodología de procesos, lo mismo que ISO 20000. Estono excluye ningún tipo de trabajo de ocina o documentación, pero desplaza la atención haciala gestión de procesos. La documentación es necesaria para demostrar el cumplimiento de lanorma. Tal como se dice en la norma, la documentación puede ser de cualquier tipo, ormato osoporte.

4.1.3 Competencia, concienciación y ormación (3.3)


Se deben denir y mantener todos los roles y responsabilidades de la Gestión del Servicio, junto con las competencias que sean requeridas para su ejecución eectiva.

Las competencias y necesidades de ormación del personal deben revisarse y gestionarse parapermitir al personal llevar a cabo sus roles de orma eectiva.

La alta dirección debe asegurar que sus empleados son conscientes de la relevancia eimportancia de sus actividades y de cómo deben contribuir a la consecución de los objetivos

de la Gestión del Servicio.


Generalidades El personal que realiza el trabajo relativo a la Gestión del Servicio debería ser competente para esta unción gracias a la educación recibida, a la ormació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, ormación, habilidades y experiencia.d) Proveer ormación o llevar a cabo otras acciones para satisacer estas necesidades.e) Evaluar la eectividad de las acciones realizadas.

Desarrollo proesional El proveedor del servicio debería desarrollar y mejorar las competencias proesionales de su equipo de

trabajo. Entre las medidas tomadas para conseguir esto, el proveedor del servicio debería incluir losiguiente :






a) Contratación - con el objetivo de comprobar la validez de los detalles de los candidatos al puestode trabajo (incluyendo su cualicación proesional) y de identicar la ortalezas, debilidades y habilidades potenciales de los candidatos rente a una descripción/perl del puesto de trabajo, rente a los objetivos de la Gestión del Servicio y rente al conjunto de objetivos de la calidad del servicio.

b) Planicació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, planicando 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 identicar los requisitos de ormación y desarrollodentro de un plan de ormación y desarrollo y proveer su impartición en el momento oportuno y de orma eectiva.

Se debería inormar al personal en los aspectos relevantes de la Gestión del Servicio (por ejemplo, a

través de cursos de ormación, auto estudio, tutorías y ormació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 ormación para cada persona, junto con las descripciones de la ormación proporcionada.

Enoques 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 orma indenida. El proveedor del servicio debería decidir también la proporción a alcanzar entre lacontratació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 orma indenida es particularmente importante cuando el proveedor del servicio está planicando como proveer un serviciodurante y después de cambios a gran escala en el número y habilidades del personal de apoyo.

Los actores que se deberían considerar para establecer la combinación más adecuada de estos enoques incluyen:a) El carácter de las competencias nuevas o modicadas : 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 planicación de las mejoras del servici.d) Disponibilidad de personal competent.e) Tasas de rotación del persona. ) Planes de ormació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 dene las entradas y salidas de un proceso,pero también las actividades que orman los pasos del proceso. La organización dene además los






roles y responsabilidades que corresponden a cada paso del proceso. El empleado al que se hayaasignado un determinado rol debe encajar en el perl del puesto de trabajo asociado al rol y lasresponsabilidades (Figura 4.1.3).

Roles yresponsabilidades

de Gestión del Servicio

Registros decompetencias y

necesidades de formación

Junto con lascompetencias necesarias

Registrosde formación,conocimientosy experiencia

Proporcióncuantificada

Plan de formacióny desarrollo

Al menosuna vez al año

Validez decompetencias

nuevas/modificadas

Índice de cambioen conocimientosy competencias

Carga de trabajoprevista y cualificaciones

necesarias

Disponibilidad depersonal competente

Índices de rotacióndel personal

Planes de formación

Definir y

mantener roles yresponsabilidadesde Gestión del Servicio

Revisar y gestionarlas competencias y

necesidades deformación del personal

Hacer que el personalsea consciente de la

relevancia e importanciade sus actividades

Buscar un equilibrioóptimo entre

contratacionespermanentes

y de corta duración yentre la contratación

de nuevos empleados yla formación de

personal existente

Revisar elrendimientode todos losmiembros

del personal

Emprender lasacciones oportunas

Planificar y ofrecerformación o adoptar las

medidas adecuadaspara satisfacer

estas necesidades

Evaluar laeficacia de las

acciones emprendidas

Interfaces:


Figura 4�1�3 Competencia, concienciación y ormación






Una parte importante del modelo de procesos de la organización consiste en garantizar que lospasos del proceso son ejecutados en todo momento por empleados competentes, cualicados y con la concienciación necesaria.

La competencia, la concienciación y la ormación se basan en tres principios de la gestión de la

calidad:• Liderazgo - Capacidad de una persona para infuir, motivar y habilitar a otras personas para

que contribuyan a la ecacia y éxito de la organización a la que pertenecen.• Implicación de las personas - Se deben identicar los talentos especiales de cada uno y

aprovecharlos en benecio 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 equilibrioentre las competencias necesarias y disponibles, sino también aprovechar las oportunidades dedesarrollar competencias, transmitir experiencias y adquirir conocimientos. Los tutores oproesores pueden dar apoyo a los empleados. La ormación de grupos también puede avorecerel intercambio de experiencias y el desarrollo de nuevas competencias.

Los grupos de interés, incluyendo clientes y empleados, deben ser conscientes de las ventajas queaporta una gestión de TI más madura y de los motivos que llevan a planicar ciertos cambios y medidas. Esta concienciación ayuda a vencer la resistencia a cambios en la orma 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 cubririncorporando el conocimiento a los procesos en todo el ciclo de vida de TI, que es a su vez elque marca las prioridades para el desarrollo de conocimientos y el proceso para compartirlos.También impulsa la identicación y el desarrollo de la base de conocimientos necesaria antes deque llegue el momento de usar esos conocimientos. Muchas organizaciones no son conscientes deesta necesidad y no orecen la ormación precisa a sus empleados, lo que lleva a una interrupcióndel proceso por alta de personal cualicado. La ausencia de intercambio de conocimientos esalgo que hay que vigilar antes, durante y después de la aplicación del conocimiento a una tarea.

4.1.4 Planifcación e implementación de la Gestión del Servicio (4)


NOTA: La metodología conocida como Planicar-Hacer-Vericar-Actuar (PDCA, del inglésPlan-Do-Check-Act ) puede aplicarse a todos los procesos. La metodología PDCA puededescribirse del modo siguiente:a) Planifcar - 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) Verifcar - Monitorizar y medir los procesos y los servicios contrastándolos con laspolíticas, los objetivos y los requisitos, e inormar sobre los resultados.






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ítulos4 a 10 de ISO 20000.

La Figura 4.1.4 muestra el modelo de procesos completo para un proveedor de servicios almáximo nivel.

Las entradas para los procesos de Gestión del Servicio son:• Requisitos de negocio• Requisitos del cliente• Solicitud de servicio nuevo/modicado• Otros procesos (negocio, suministrador, cliente)• Registros del centro de atención al usuario• Otros equipos (como Operaciones de TI, Seguridad)

Requisitosde negocio

Requisitosdel cliente

Solicitud deservicio nuevo/

modificado

Otros procesos(negocio,

suministrador, cliente)

Centro deatenciónal usuario

Otros equipos(como Operacionesde TI, Seguridad)

Resultadosde negocio

Satisfaccióndel cliente

Servicio nuevoo modificado

Otros procesos(negocio,

suministrador, cliente)

Satisfacciónde equiposy personas

ACTUAR

Mejoracontinua

PLANIFICAR

Planificar laGestión del Servicio

Responsabilidad de la dirección

Gestión de servicios

VERIFICAR

Monitorizar,medir y revisar

HACER

Implantar laGestión del Servicio

Figura 4�1�4 La metodología Planicar-Hacer-Vericar-Actuar para los procesos de Gestión delServicio (círculo de calidad de Deming)






Las salidas para los procesos de Gestión del Servicio son:• Resultados de negocio• Satisacción del cliente• Servicio nuevo o modicado• Otros procesos (negocio, suministrador, cliente)

• Satisacción de equipos y personas

La responsabilidad de la dirección va más allá del ciclo Planicar-Hacer-Vericar-Actuar quese muestra en la Figura 4.1.4, ya que todos los procesos de Gestión del Servicio se ejecutanbajo la responsabilidad de la alta dirección. La metodología Planicar-Hacer-Vericar-Actuar esnecesaria 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 ases iterativas que ormandicho plan.

Es posible establecer las siguientes correspondencias entre estas ases y el ciclo PDCA:• Planifcar - ¿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)• Verifcar - ¿Cómo comprobar que se han alcanzado los hitos? (medidas y métricas)

• Actuar - ¿Cómo mantener el impulso?

Visión, misión,metas y objetivos

de negocio

Valoracionesde referencia

Objetivosmedibles

Mejora deservicios y procesos

Medidasy métricas

¿Cómo mantenerel impulso?

¿Cuál es la visión?

¿Cuál es lasituación actual?

¿Cuál es lasituación deseada?

¿Cómo conseguirla?

¿Se ha conseguido?

Figura 4�1�5 Las seis ases de un Plan de Mejora Continua del Servicio (Fuente: OGC)






4.1.5 Planifcación de la Gestión del Servicio (Planifcar) (4.1)

Objetivo: Planicar la implementación y la provisión de la Gestión del Servicio.

Las especifcaciones ISO 20000-1 dice:

Se debe planicar la Gestión del Servicio. Como mínimo, el plan debe denir 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 delos suministradores;

e) Las interaces entre los procesos de Gestión del Servicio y el modo en que tienen que

coordinarse las actividades; ) El enoque que hay que dar a la identicación, la evaluación y la gestión de actividades y de los riesgos para la consecución de los objetivos denidos;

g) El enoque para la relación con proyectos que estén creando o modicando los servicios;h) Los recursos, el equipamiento y los presupuestos necesarios para alcanzar los objetivos

denidos;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 denidas tanto la orientación de la gestión como las responsabilidades

documentadas para revisar, autorizar, comunicar, implementar y mantener los planes.Cualquier plan especíco de un proceso que se elabore debe ser compatible con este plan deGestión del Servicio.


El alcance de la Gestión del Servicio se debería denir como parte del plan de Gestión del Servicio.

Por ejemplo, puede denirse según:a) La organizaciónb) La ubicaciónc) El servicio

La dirección debería denir 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 laNorma ISO/IEC 20000-1.

NOTA: La planicació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 granmagnitud. En este caso, los procesos subyacentes a la Gestión del Servicio deberían ser coherentes entre






ellos. También se debería poder demostrar cómo se gestiona cada requisito de planicación vinculándoloa sus correspondientes unciones, responsabilidades y procedimientos.

La planicación de la Gestión del Servicio debería ormar 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 aecten a los procesos incluidos en el alcance acordado de la

Gestión del Servicio).

El plan de Gestión del Servicio debería estar enocado 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 inraestructuras.d) Los cambios de la legislación.e) Las modicaciones en normativas como, por ejemplo, modicaciones de las tasas impositivas

locales. ) La liberalización o la regulación de los sectores industriales.

g) Las usiones y las adquisiciones.

Un plan de Gestión del Servicio debería denir :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 denidos.d) La estructura de las unciones 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 interaces entre los procesos de la Gestión del Servicio y el modo en que se deberían los coordinar

los procesos y/o actividades.; ) El enoque que se debería aplicar para la identicación, la evaluación y la gestión de riesgos para la

consecución de los objetivos denidos. g) Una planicación de los recursos expresada en términos de las echas en las que deberían estar

disponibles las uentes de nanciación, las habilidades y los recursos.h) El enoque para la modicación del plan y de los servicios denidos 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.







ISO 20000-1 exige que la organización dena 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 denir susprocesos de Gestión del Servicio con los correspondientes roles y responsabilidades, las interacesentre procesos y las interaces con proyectos. También se tiene que denir la orma en que van acoordinar las actividades.

Los planes que se desarrollen para procesos especícos tienen que ser compatibles con el plan deGestión del Servicio.

Para ello, la Subsección “Métodos de planicación” de ISO 20000-2 especica que es posible

utilizar múltiples métodos de planicación de Gestión del Servicio en lugar de un único plan oprograma, en cuyo caso los procesos subyacentes de la Gestión del Servicio deben mantener unacoherencia interna.

Planes paraprocesos específicos

(deben sercompatibles con losplanes de Gestión

del Servicio)

Planesde Gestióndel Servicio

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

Deben facilitar la vinculación de los requisitos deplanificación a roles, responsabilidades y procedimientos

Dirección degestión y

responsabilidades

documentadas

Definir unadirección clarade gestión y

responsabilidadesdocumentadas

Planificarla Gestión

del Servicio

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

Interfaces:


Tienen en cuenta procesos y cambios debidosa 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

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

Figura 4�1�6 Planicación de la Gestión del Servicio (Planicar)






La suma de todos los elementos aquí mencionados para la planicación de la Gestión del Servicioorma 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 avorable si comienza a actuar como un negocio y dene una visión (ase 1) conobjetivos, presupuestos y métricas. Una visión de Gestión del Servicio de TI es una declaraciónsobre “ ¿Cuál es la situación deseada? ” acordada por el negocio y la organización de TI. Describe elobjetivo 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 objetivostécnicos y de negocio, describir el compromiso y las opiniones de la dirección superior y motivaral 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 participanen un SIP o se ven aectados 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 enoque coherente y continuo de laGestión del Servicio de TI. La gestión de TI y la arquitectura de herramientas también deben darsoporte a los requisitos de negocio.

Entre las actividades clave para denir la dirección guran:

• Analizar las necesidades de negocio y lo que puede hacer la organización de TI para garantizarsu satisacción.

• Denir una política de gestión de riesgos y hacer que se incluya en los procesos de planicacióny toma de decisiones.

• Denir una estrategia de TI y hacer que se integre en la estrategia de negocio.• Diseñar políticas en unción de los resultados de negocio y garantizar que se obtiene el máximo

rendimiento de las inversiones en TI.

Los actores 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 ormas 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.• Inormación y comunicación a disposición de todo el que lo necesite.• Conocimiento de los avances tecnológicos para identicar oportunidades para el negocio.

• Búsqueda de éxitos rápidos sin olvidar los benecios a largo plazo.• Institucionalización de los cambios organizativos.






Antes de empezar a aplicar un SIP, la organización de TI tiene que saber cuál es la visión (ase 1)y cuál es la situación actual (ase 2) desde distintos puntos de vista:• Directrices de negocio: La estrategia y dirección del negocio, los problemas a los que se enrenta

y su eecto sobre TI.• Directrices tecnológicas: Los avances tecnológicos y la orma en que se deben aplicar para que

contribuyan al negocio.• La orma 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 esuerzo necesario para hacerla realidad. Los modelos de madurez , las evaluaciones comparativas y los inormes de análisis de “Gaps” permiten identicar carencias en la capacidad delas personas, el proceso y la tecnología. También revelan el valor potencial de los resultados parael negocio en caso de eliminarse esa carencia. Un análisis de “Gaps” bien documentado acilita lapriorización de las carencias y la identicació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ísticasde la organización de TI. Para ello deben dar respuesta a la pregunta “ ¿Cuál es la situación deseada? ”(ase 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 justicar un SIP hay que comparar los costes y benecios del proyecto en un caso de negocio. Aunque los costes son relativamente áciles de medir (personal, herramientas, etc.), resulta máscomplicado determinar los benecios como resultado directo de un SIP. Los resultados nosiempre se pueden cuanticar económicamente, ya que los proyectos orientados a procesos suelenorecer más calidad de provisión de servicios, niveles de servicio más elevados y más fexibilidadde organización.

Para que un caso de negocio tenga éxito es necesario que un alto directivo apoye el SIP y se sientacomprometido en su ejecución. Sin este tipo de patrocinio, existe un riesgo elevado de que nose pueda disponer de los ondos y los recursos necesarios y no sea posible alcanzar las mejorasprevistas. El patrocinador debe denir 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 unalto grado de compromiso, por lo que tienen que ser evidentes para todos y estar incorporados enel SIP. Estos éxitos rápidos también se deben comunicar con recuencia para que sean conocidospor todos los grupos de interés.






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.


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 ondos.b) La asignación de roles y responsabilidades.c) La documentación y el mantenimiento de políticas, planes, procedimientos y deniciones

para cada proceso o conjunto de procesos.d) La identicació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 delpersonal adecuado y la gestión de continuidad del personal.) 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) Inormar del progreso en comparación con los planes.i) La coordinación de los procesos de Gestión del Servicio.


La consecución de los procesos de mejores prácticas de Gestión del Servicio capaces de satisacer 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íanmantener.

Se deberían realizar revisiones de acuerdo con el aparatado 4.3, Monitorización, medición y revisión(Vericar).

NOTA: Es posible que la persona que sea adecuada para realizar la planicación y la implementacióninicial no sea la apropiada para la operación continua.


En la ase Hacer del ciclo PDCA se implantan el modelo de procesos y los roles y responsabilidadesdel proceso. En esta ase, la organización empieza a uncionar de acuerdo con el modelo deprocesos. 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 vuelvaa “congelar”.Copyright protected. Use is for Single Users only via a VHP Approved License.





Fondos ypresupuestos

asignados


asignados

Políticas, planes,procedimientos ydefiniciones de

procesos actualizados

Registrosde revisiones

Informesde progreso

Plan de Gestióndel Servicio

Riesgosidentificados y

medidas adoptadas

Planes deGestión del Servicio

Asignar fondos

y presupuestos

Asignar roles yresponsabilidades

Documentar ymantener políticas,

planes, procedimientosy definicionesde procesos

Gestionar equipos,incluyendo los del

centro de atención alusuario y operaciones

Gestionarinstalaciones

y presupuestos

Comunicar elprogreso con

respecto a los planes

Revisar políticas,planes,

procedimientos ydefiniciones de

procesos

Implantar elplan de


Coordinarprocesos de


Identificar ygestionar riesgos

Políticas, planes,procedimientos y

definicionesde procesos

Políticas, planes,procedimientos ydefiniciones de

procesos

Interfaces:


Gestión de cambios:- Presentar solicitudes de cambio

Informes del servicio:- Recibir información

Presupuestos y contabilidad:- Presupuesto y contabilidad detodos los componentes

Figura 4�1�7 Implantación de la Gestión del Servicio y provisión del servicio (Hacer)






Guía Al responder a la pregunta “ ¿Cómo conseguir la situación deseada? ” (ase 4) hay que tener encuenta:• 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 uturo).• La madurez de cada uno de los procesos de Gestión del Servicio de TI (objetivo actual y

uturo).• 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 denido procesos individuales de Gestión del Servicio de TI. Los procesos dependientes sedeben implantar con un nivel de madurez similar.

Se tiene que preparar un resumen de las carencias identicadas para presentarlo a un grupomultidisciplinar de los principales grupos de interés. Es preciso que este grupo comprenda lasmejoras necesarias y se comprometa con ellas para eliminar las carencias identicadas antes deque se pueda iniciar la planicación de acciones. Para contar con más apoyo de la direcciónes muy importante garantizar la credibilidad de los análisis o evaluaciones comparativas y susresultados.

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 noalcanzan los resultados deseados debido a las dicultades que surgen cuando las personas tienenque cambiar su orientación y la orma en que trabajan. Las personas en general se muestranreacia a los cambios, por lo que es preciso explicar las ventajas a todos los aectados con el nde conseguir su apoyo y hacer que abandonen sus anteriores métodos de trabajo. Para ello esundamental un liderazgo uerte.

La cultura empresarial es otro aspecto básico que se debe tener en cuenta, ya que puede acilitarla implantación o, por el contrario, ser una uente de resistencia. Cuando se inicia un SIP, se sueleprestar mucha atención a la nueva estructura organizativa y a la nueva tecnología y muy poca ala cultura de la organización. La cultura organizativa aecta al liderazgo, el cual a su vez infuyeen las probabilidades de éxito de un cambio organizativo. La cultura es un actor intangible, perose debe gestionar para:• Determinar la cultura existente.• Denir actitudes de colaboración.• Cambiar los aspectos indeseaqbles de dicha cultura.

Los cambios organizativos propuestos aectan a las personas y a su orma de ver las cosas. En

momentos de cambio radical es importante canalizar correctamente estas emociones paraavorecer los cambios, ya que son un actor muy importante para el éxito. Se deben planicaréxitos rápidos que generen optimismo y animen a los miembros aectados del personal a






explorar las posibilidades que orece la nueva situación. El siguiente paso consiste en consolidare institucionalizar las mejoras. La comunicación no es una actividad aislada, sino un requisitocontinuo 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, loque a su vez puede acelerar el cambio organizativo y hacer que resulte más ecaz a largo plazo.

La organización se tiene que comprometer a tener en cuenta todas las opiniones. No se puedeignorar la resistencia a los cambios, ya que eso sólo serviría para mantenerla oculta. Hacer quela resistencia sea abierta para poder discutirla y analizarla permitirá identicar nuevas áreas departicipació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 conllevarla introducción de nuevos roles que tal vez superen los límites tradicionales de la organización, loque puede ser causa de dicultades. Es undamental contar con una denición clara de todas lasresponsabilidades. Sin estos roles y responsabilidades, el nuevo proceso será conuso y es posibleque las personas vuelvan a sus viejos métodos de trabajo.

Una vez denidos los procesos, lo primero que hay que hacer es ponerlos bajo control, tras locual se pueden desarrollar hasta un nivel reproducible para que posteriormente maduren a unnivel que sea gestionable. Se deben denir grados de control sobre procesos, usando métricas paragestionar 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 essu relación con las estructuras organizativas existentes y de las ormas de trabajar. Para que losdepartamentos uncionen como equipos multidisciplinares y no como ‘guetos tecnológicos’ espreciso introducir cambios undamentales, como:• Implantación de procesos bien denidos y reproducibles en todos los departamentos.• Inclusión de nuevas áreas de responsabilidad en las descripciones de los puestos de trabajo.• Modicación de valores, comportamientos y culturas para omentar el enoque a cliente.• Aumento del nivel de conocimientos entre el personal que utiliza procesos complejos.• Herramientas integradas, que permitan el intercambio de datos y aciliten el fujo de trabajo.• Compromiso de la dirección con servicios de TI enocados 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 unción delnegocio; 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 undamental,pero sin olvidar que una herramienta tiene que acilitar un proceso (“la estructura sigue a laestrategia”). 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 objetivosde la organización. En este caso se debe preparar una nueva declaración de requisitos e iniciar elproceso de evaluación y selección de herramientas nuevas o modicadas. Si la organización carecede experiencia en herramientas, lo más aconsejable es empezar con una herramienta sencilla y






usarla como prototipo para documentar los requisitos, tras lo cual se podrá iniciar una selecciónmás seria de herramientas.

Para todas estas iniciativas es imprescindible un buen patrocinio.

4.1.7 Monitorización, medición y revisión (Verifcar) (4.3)

Objetivo: Monitorizar, medir y revisar que los objetivos y el plan de Gestión del Servicio seestán cumpliendo.


El proveedor del servicio debe aplicar métodos adecuados para la monitorizar y, cuandosea 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 planicados.

La dirección debe realizar revisiones a intervalos planicados para determinar si los requisitosde Gestión del Servicio:a) Son conormes con el plan de Gestión del Servicio y los requisitos de esta norma.b) se implementan y se mantienen de manera ecaz.

Se debe planicar un programa de auditorías, teniendo en cuenta el estado y la importanciade los procesos y las áreas que auditar, así como, los resultados de las auditorías anteriores.Se deben denir en un procedimiento los criterios, el alcance, la recuencia y los métodos

de auditoría. La selección de auditores y la realización de las auditorías deben garantizar laobjetividad y la imparcialidad del proceso de auditoría. Los auditores no deben auditar supropio trabajo.

El objetivo de las revisiones, evaluaciones y auditorías de la Gestión del Servicio se deberegistrar junto con las conclusiones de dichas auditorías, sus revisiones y las accionescorrectivas que se hayan identicado. Se debe comunicar a las partes correspondientes laexistencia de cualquier área signicativa con alguna no conormidad u otra discrepancia.


El proveedor del servicio debería planicar 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 denidob) La satisacción del cliente c) La utilización de los recursos d) Las tendencias e) Las no conormidades de mayor consideració







Medidas cuando corresponda

¿Cumplen el plan de Gestióndel Servicio?¿Está eficazmente implantadoy mantenido?

Proceso y selección deauditores para garantizar laobjetividad e imparcialidad

Intervalosplanificados

Planificar unprograma

de auditoría

Informara las partes

correspondientesde las áreas con

posibles problemas

Realizar auditorías

Definir elprocedimientode auditoría

Monitorizar ydemostrar la

capacidad de losprocesos de Gestión

del Servicio

Revisarrequisitos de


Registrar elobjetivo, los

resultados y lasacciones correctivas

Programade auditoría

Registros decomunicaciones

Objetivosde revisiones,valoracionesy auditorías

Datos sobre lacapacidad de los

procesos de Gestióndel Servicio para

alcanzar resultados

Registrosde revisión,valoracióny auditoría

Registrosde accionescorrectivas

identificadas

Registrosde revisiones

Resultados deautorías anteriores

Interfaces:



Para determinar la frecuencia deauditorí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

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

Figura 4�1�8 Monitorización, medición y revisión (Vericar)






La monitorización, la medida y la revisión son actividades clave para la mejora continua, unode los principios de la Gestión de la Calidad en ISO 9000. Es imposible conseguir una mejoracontinua sin determinar lo que se ha conseguido realmente. Una organización sólo puede vericarsi 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 Serviciocomprende:• Grado de cumplimiento de los objetivos denidos de servicio• Satisacción del cliente• Utilización de recursos• Tendencias• Principales altas de conormidad

Esta subsección de la Parte 1 de la norma especica uno de los pocos procedimientos documentados

que se exigen explícitamente: un procedimiento de auditoría. La subsección también exige deorma explícita registros del objetivo de revisiones, valoraciones y auditorías de la Gestión delServicio, de los resultados de dichas auditorías y de las acciones correctivas identicadas.

Guía Para comprobar si se han alcanzado los hitos (ase 5) es necesario denir objetivos claros y medibles. Estos objetivos pueden denir 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 resultadosde un proceso o actividad. Las métricas esenciales son el tiempo, el coste, la calidad y la ecacia. Esimportante determinar cuál es el método más ecaz para medir el rendimiento en cada caso. Losresultados 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 esteproblema. Las medidas se tienen que realizar con recuencia para poder introducir ajustes siempreque sea preciso, pero no tan a menudo que se generen cargas de trabajo innecesarias. Tambiénes importante incluir resultados y métricas de proyectos en las revisiones de rendimiento de losempleados.

Las mejores métricas son aquéllas que resultan creíbles, son objetivas y necesitan pocos recursos deprocesamiento o cortos tiempos de parada. Siempre que sea posible hay que utilizar herramientasautomatizadas para recopilar, comunicar y controlar las medidas. Las medidas y las métricas sedeben revisar periódicamente con el negocio para comprobar que son adecuadas y corregirlas sies necesario.

Los actores críticos de éxito (CSFs) son elementos undamentales para cumplir la misión delnegocio. Los indicadores clave del rendimiento (KPIs) se derivan de estos CSFs y determinan lacalidad, el rendimiento, el valor y la conormidad 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 denir y medirperiódicamente para cada proceso con el n de vericar que se cumplen los CSFs.






Los CSFs y los KPIs se van transmitiendo sucesivamente desde los departamentos hasta nivelesindividuales, proporcionando una línea de reerencia y mecanismos que permiten eectuar unseguimiento del rendimiento. Se recomienda concentrarse en un número mínimo de KPIs (cincopor proceso, por ejemplo). Una vez vericado un KPI, se puede pasar a nuevos KPIs. Cadaorganización tiene que determinar los correspondientes CSFs y KPIs. También es posible que

se necesiten distintas métricas en unción del grupo de interés o la disciplina de la Gestión delServicio.

Un método que se emplea habitualmente para el seguimiento de métricas es la realización deauditorías empleando KPIs. También se pueden hacer análisis de tendencias con un “Cuadro deMando Integral” que acilita la gestión del rendimiento en la organización. Los objetivos de lagestió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, ormación e inversiones ensotware.

• Perspectiva fnanciera - La gestión nanciera de TI cubre la asignación de costes y gastos a laorganización del cliente.

Los CSFs y KPIs también se pueden utilizar como objetivos para un SIP. Al terminar cada unade las ases importantes del SIP se puede realizar una Revisión Post-Implantación (PIR) paracomprobar que se han cumplido los objetivos. Los resultados se deben comparar con las metasoriginales para denir nuevos objetivos de mejora.

4.1.8 Mejora continua (Actuar) (4.4)

Objetivo: Mejorar la ecacia y la eciencia de la entrega y de la Gestión del Servicio.


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

Gestión de las mejoras del servicioSe deben evaluar, registrar, priorizar y autorizar todas las propuestas de mejora del servicio. Sedebe utilizar un plan para controlar la actividad.El proveedor del servicio debe disponer de un proceso para identicar, medir y gestionar lasactividades de mejora e inormar de dichas actividades de manera continua. Este proceso debeincluir: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.






ActividadesEl 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) Identicar, planicar 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, reerentes a mejoras, que se realicen desde

todos los procesos de Gestión del Servicio. ) Medir, inormar 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.


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 ecaz y más eciente. 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íatener un conocimiento detallado de las repercusiones de estos actores sobre los procesos de Gestión del Servicio.

Debería existir una coordinación ecaz 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 aecten ala calidad del servicio y a los requisitos del cliente.

Planicación de mejoras del servicioLos proveedores del servicio deberían adoptar un enoque 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 lacalidad del mismo como línea de reerencia sobre la que se puedan comparar las mejoras reales. Paraevaluar la ecacia 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 paramejorar los servicios.






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 progresotomando como reerencia los objetivos ormalmente acordados.


Como se indicó anteriormente, la metodología Planicar-Hacer-Vericar-Actuar es aplicable atodos los procesos. La ase nal de esta metodología consiste en aprovechar las oportunidades de

mejora y tiene que ser objeto de una cuidadosa planicación.

La mejora continua es uno de los ocho principios de la gestión de la calidad. El proceso de mejoracontinua es uno de los pocos procedimientos documentados que se exigen explícitamente en ISO20000. La subsección sobre mejora continua también exige de orma explícita registros de todaslas mejoras sugeridas del servicio.

Guía La parte más diícil de cualquier SIP consiste en mantener las mejoras (ase 6) que se hanconseguido. Es necesario documentar las mejoras de procesos para conseguir que los procesos

sean reproducibles y para acilitar la denición de algún tipo de norma de calidad. Todos losconocimientos adquiridos durante el SIP se deben recopilar y divulgar mediante la aplicación detécnicas de gestión del conocimiento.

Mantener las mejoras puede resultar más complejo debido a la continua aceleración de loscambios en las Tecnologías de la Inormación. Esta mayor demanda de cambio responde a unamayor necesidad del negocio para innovar y seguir siendo competitivo. Para conservar las mejorasde 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 paramantener el impulso y avorecer la adopción de nuevos cambios.

Los procesos se tienen que monitorizar y revisar continuamente. Suponiendo que el negocioestá realizando inversiones importantes en iniciativas de mejora de la Gestión de Servicios deTI y en los SIPs, se deben utilizar medidas y métricas relacionadas con el negocio y su uso deTI para demostrar que se obtiene un retorno de la inversión. Las métricas también ayudarán alos empleados a comprender en qué punto se encuentran, qué es lo que han conseguido, haciadónde deben avanzar, cuándo se alcanzan hitos signicativos y cuándo se deben superar barrerasde importancia. La inormación de las medidas permitirá al equipo revisar y comprender losresultados e introducir ajustes a medida que progresen.

Es necesario reorzar continuamente la alineación entre el negocio y las Tecnologías de la Inormación a todos los niveles. Las prioridades del negocio ayudan a identicar los eectos de las operacionessobre el negocio, las partes que se ven aectadas y de qué manera. Como resultado, la productividad






del negocio en general será de más calidad y las actividades de negocio se eectuarán en el ordencorrecto de importancia.

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

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

Línea de referencia para monitorizar ycomparar las mejoras reales

Política de mejoradel servicio

Política de Gestión

del Servicio yplan de mejora delservicio revisados

Informe de mejoras

SIP

Registros de lacalidad actual del

servicio y los nivelesde servicio

SIP autorizado

Definir roles yresponsabilidades

Roles yresponsabilidadesdefinidos

El personal debería conocer la políticade calidad del servicio

Plan de mejora del servicio, incluyendomejoras sugeridas

Recopilar y analizardatos sobre lacapacidad del

proveedor de servicios

Identificar yplanificar mejoras

Consultar a todaslas partes implicadas

Medir y comunicarlas mejorasdel servicio

Revisar las

políticas, procesos,procedimientos

y planes de Gestióndel Servicio

Valorar y registraroportunidades

de mejora

Establecer y publicaruna política sobremejora del servicio

Implantarmejoras

Comparar lamejora real con

la mejora prevista

Corregir faltas deconformidad con los

planes de Gestióndel Servicio

Tener en cuentaentradas relevantes

sobre mejoras

Animar a empleadosy clientes a que

sugieran mejoras

Comprobar que lasacciones aprobadas se

llevan a cabo y cumplenlos objetivos previstos

SIP

Cuando sea necesario

De otros procesos deGestión del Servicio

SIP

SIP

Interfaces:

Todos los procesos:- Recibir oportunidades demejora para SIP

Gestión de cambios:- Presentar solicitudes de cambio


Gestión de la seguridad dela información:- Recibir información de gestiónsobre tendencias en incidenciasde seguridad de la información

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)






4.2 Control de servicios de TI

4.2.1 Planifcación e implementación de nuevos servicios o de servicios modifcados(5)

Objetivo: Asegurar que, tanto los servicios nuevos, como las modicaciones a los existentes,se pueden gestionar y proveer con los costes y la calidad acordados.


En las propuestas de nuevos servicios o modicaciones en los existentes, se deben considerarlos costes y el impacto a nivel organizativo, técnico y comercial que pudiera derivar de suentrega y gestión.

La implementación de nuevos servicios o modicaciones en los existentes, incluyendo laeliminación de un servicio, debe ser planicada y aprobada a través de un proceso ormal degestión de cambios.

La planicación e implementación deben incluir los ondos y recursos adecuados para llevar acabo 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

modicaciones 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 aectadas.d) Los nuevos contratos y acuerdos, o modicaciones a los contratos y acuerdos existentes,

para estar alineados con las necesidades del negocio.e) Los requisitos de mano de obra y contratación. ) Los requisitos de perles y ormació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 modicaciones en los existentes, por ejemplo gestión de la capacidad, gestiónnanciera.

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 modicaciones en los existentes, deben ser aceptados por elproveedor del servicio antes de ser implementados en el entorno de producción real.Tras la implementación, el proveedor del servicio debe inormar de los resultados alcanzadospor el servicio nuevo, o por el servicio modicado, comparándolos con los resultados

previstos. Se debe realizar una revisión posterior a la implementación, que compare losresultados reales con los planicados a través del proceso de gestión de cambios.







Temas a considerar La planicación de los servicios nuevos o modicados 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 servicioe) Los procesos de Gestión del Servicio, procedimientos y documentación existentes ) El enoque de la Gestión del Servicio, incluyendo la implementación de los procesos de Gestión del

Servicio que hubieran sido previamente excluidos del enoque

Propuesta deservicios nuevos o

modificados

Debe tener en cuenta:- Coste- Impacto organizativo- Impacto técnico- Impacto comercial

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

Planificar serviciosnuevos o

modificados

Aprobar el plan através de gestión

de cambios

Aceptar los

serviciosmodificados

Implantar losservicios nuevos o

modificados a tr avésde gestión de

cambios

RevisiónPost-Implantación

(PIR)

Comunicar losresultados obtenidosen relación con los

planificados

Interfaces:


Gestión de cambios:- Planificar y aprobar la implantación de servicios nuevos omodificados, 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 Planicación e implantación de servicios nuevos o modicados






Registros de los cambios Todas las modicaciones al servicio se deberían refejar en los registros de gestión de cambios :Esto incluye a los planes para:a) La contratación y ormación del personab) La reubicación

c) La ormació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 ) El cierre ormal de los servicios


Cuando el negocio de un proveedor de servicios esté en marcha, siempre existirá la necesidad de

introducir servicios nuevos o modicados. Estos nuevos servicios o los cambios en el catálogode servicios se tienen que tramitar a través del proceso de gestión de cambios. La sección deISO 20000-1 sobre planicación e implantación de servicios nuevos o modicados estipulalos requisitos que tienen que cumplir las propuestas de servicios nuevos o modicados, queconstituyen una entrada para el proceso de gestión de cambios.

La planicación e implantación de servicios nuevos o modicados tiene que colaborar con elproceso de gestión de cambios. La interaz entre ambos debe estar documentada.

4.2.2 Procesos de control: gestión de la confguración (9.1)

Objetivo: Denir y controlar los componentes del servicio y de la inraestructura, y mantenerinormación precisa sobre la conguración.

Las especifcaciones ISO 20000-1 dice:

Debe existir una visión integrada para la planicación de la gestión de cambios y de laconguración.

El proveedor del servicio debe denir la interaz con los procesos de contabilidad nancierade activos.

NOTA: La contabilidad nanciera de los activos queda uera del ámbito de esta sección.

Debe existir una política que dena qué se considera como elemento de conguración y quécomponentes lo constituyen.

Se debe denir la inormación que se debe registrar para cada elemento, y se deben incluir lasrelaciones y la documentación necesaria para la Gestión eectiva del Servicio.

La gestión de la conguración debe proporcionar los mecanismos para identicar, controlary hacer el seguimiento de las versiones de los componentes identicables del servicio y de






la inraestructura. Se debe asegurar que el grado de control es suciente para cubrir lasnecesidades del negocio, los riesgos de allo y la criticidad del servicio.

La gestión de la conguración debe proporcionar inormación al proceso de gestión decambios sobre el impacto de un cambio solicitado sobre la conguración del servicio y de la

inraestructura. Los cambios en los elementos de conguración deben ser áciles de identicary auditables cuando sea apropiado, por ejemplo para cambios y movimientos en el sotware y el hardware.

Los procedimientos de control de conguración deben asegurar que se mantiene la integridadde los sistemas, servicios y componentes de servicio.

Antes de un paso al entorno real, debe establecerse una línea de reerencia de los elementos deconguración correspondientes.

Deben estar controladas, en una biblioteca ísica o electrónica segura, las copias maestrasde los elementos de conguración digitales, con reerencias a los registros de conguración,por ejemplo sotware, productos de prueba, documentos de soporte. Todos los elementosde conguración deben ser identicables de manera única y registrados en la base dedatos de gestión de la conguración, cuyo acceso para actualizaciones se debe controlarde manera estricta. La base de datos de la gestión de la conguración se debe gestionar y vericar activamente para asegurar su abilidad y precisión. El estado de los elementos deconguración, sus versiones, ubicación, cambios y problemas relacionados, así como ladocumentación asociada deben estar visibles para quienes lo requieran.

Los procedimientos de auditoría de la conguración deben incluir el registro de deciencias,el lanzamiento de acciones correctivas y la comunicación de su resultado.


La gestión de la conguración se debería planicar 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 conguraciones de TI de orma eectiva.

Debería estar disponible una inormación precisa sobre la conguración para dar soporte a la planicación y al control de los cambios a medida que los sistemas y los servicios nuevos y modicados sonliberados y distribuidos. El resultado debería ser un sistema eciente que integre los procesos de gestiónde la inormación de conguración del proveedor del servicio con los de los clientes y suministradores,cuando proceda.

Todos los activos y conguraciones 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 sonautorizados 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 inormación necesaria para delegar






esta responsabilidad, por ejemplo, la persona que autoriza un cambio podría requerirle inormacióndel coste, riesgos, impacto del cambio y recursos para la implementación.La inraestructura y/o los servicios deberían tener un plan(es) actualizado(s) de gestión de laconguración, que puede ser independiente o ormar parte de otros documentos de la planicación.Éstos deberían incluir o describir :

a) Ámbito, objetivos, políticas, roles y responsabilidades normalizados.b) Los procesos de gestión de la conguración para denir los elementos de conguración de los servicios

e inraestructuras, controlar cambios en las conguraciones, resgistrar e inormar del estado de los ítems de conguración y vericar la integridad y la exactitud de los elementos de conguració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 conguración (acceso, protección, versionado, construcción, control de entrega).e) El proceso de control de los elementos de contacto que identiquen, registren y gestionen los elementos

y la inormación de la conguración en los límites comunes a dos o más organizaciones, por ejemplo:

interaces de sistemas, versiones. ) La planicación y el establecimiento de los recursos para mantener los activos y las conguraciones bajo control y mantener el sistema de gestión de la conguración, por ejemplo, ormación.

g) La gestión de los suministradores y subcontratistas que estén llevando a cabo labores de gestión de laconguración.

NOTA: Se debería implantar un nivel apropiado de automatización para asegurar que los procesos nose convierten en inecaces en proclives al error o que no pudieran ejecutarse.

Identicación de conguración

Todos los elementos de conguración deberían estar identicados de manera unívoca y estar denidos por atributos que describan sus características uncionales y ísicas. La inormación debería ser relevante y auditable.

En la base de datos de la conguración deberían utilizar y registrar los marcas apropiados u otros métodos de identicación.

Los elementos a ser gestionados se deberían identicar usando los criterios de selección establecidos y deberían incluir :a) Todas las distribuciones y entregas de los sistemas de inormación y del sotware (incluyendo sotware

de terceras partes) y la documentación relativa de los sistemas, por ejemplo, las especicaciones de requisitos, diseños, inormes de prueba, documentación de la entrega.

b) Las líneas de reerencia de la conguración o las premisas de construcción para cada entorno,módulo hardware normalizado y versión.

c) Copia ísica maestra y bibliotecas electrónicas, por ejemplo: la biblioteca denitiva de sotware.d) Las herramientas o paquetes usados para la gestión de la conguración.e) Licencias. ) Componentes de seguridad, por ejemplo: cortauegos. g) Activos ísicos que sean necesarios para la gestión nanciera 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.






j) Relaciones y dependencias entre los elementos de la conguración.

NOTA: Otros elementos que podrían ser considerados como elementos de conguración son:a) Otra documentaciónb) Otros activos

c) Otras instalaciones, por ejemplo: emplazamientos d) Unidades de negocioe) Personas

Se deberían identicar las relaciones y dependencias adecuadas entre los elementos de conguració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 conguració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 conguraciónEl proceso debería garantizar que sólo los elementos de la conguración autorizados e identicables sonaceptados y registrados desde su recepción hasta su baja.

Ningún elemento de la conguración se debería añadir, modicar, reemplazar o eliminar/retirar sin ladocumentación de control apropiada, por ejemplo: aprobación de la solicitud de cambio, inormaciónactualizada de la versión.

Para proteger la integridad de los sistemas, servicios e inraestructura, los elementos de la conguraciónse 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: sotware.

Seguimiento del estado de conguración y elaboración de inormes Los registros de la conguración se deberían mantener actualizados y con la precisión adecuada pararefejar los cambios en el estado, localización y versión de los elementos de la conguración.

El seguimiento del estado debería proporcionar inormación sobre los datos actuales e históricos de cadaelemento de conguración a lo largo de su ciclo de vida. Esto debería permitir el seguimiento de los cambios en los elementos de la conguración a través de sus dierentes estados, por ejemplo: solicitado,recibido, en pruebas de aceptación, activo, bajo cambio, retirado y eliminado.

La inormación de la conguración se debería mantener actualizada y disponible para: los planes, latoma de decisiones y la realización de cambios a las conguraciones denidas.

Cuando sea requerida, la inormación de la conguració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 inormación de la conguració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.






Los inormes de gestión de la conguración deberían estar disponibles para todas las partes correspondientes. Los inormes deberían cubrir : la identicación y el estado de los elementos de laconguración, sus versiones y la documentación asociada.

Los inormes deberían cubrir :

a) Las últimas versiones de los elementos de la conguración.b) La localización del elemento de conguración y, para el sotware, la localización de las versiones

maestra.c) Interdependencias.d) Historia de la versión.e) Estado de los elementos de la conguración que conjuntamente constituyan:

1) La conguración del servicio o del sistema. 2) Un cambio, una línea de reerencia, un paquete de instalación o una entrega.

3) Una versión o variante.

Vericación y auditoría de la conguraciónLos procesos de vericación y auditoría, en sus aspectos ísicos y uncionales, se deberían planicar y se debería realizar una comprobación para asegurar que los procesos y recursos adecuados estánestablecidos para:a) Proteger las conguraciones ísicas y el capital intelectual de la organización.b) Asegurar que el proveedor del servicio tiene el control de sus conguraciones, las copias maestras y

las licencias.c) Garantizar que la inormación de la conguración está actualizada, controlada y es visible.d) Asegurar que un cambio, una entrega, un sistema o un entorno es conorme a los requisitos

contratados o especicados y que los registros de la conguración son exactos.

Periódicamente se deberían realizar auditorías de la conguración, antes y después de un cambioimportante, después de un desastre y a intervalos aleatorios.

Las deciencias y las no conormidades 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 plande mejora del servicio.

NOTA: Normalmente hay dos tipos de auditoría de la conguración:a) Auditoría uncional de la conguración - Un examen ormal para vericar que un elemento

de conguración ha alcanzado el rendimiento y características uncionales especicadas en sus documentos de conguración.

b) Auditoría ísica de la conguración - Un examen ormal de la conguración “según sale de ábrica” de un elemento de conguración para vericar su conormidad con sus documentos de conguración del producto.

Las actividades básicas de la gestión de la conguración son: planicación e implantación;identicación; control; seguimiento de estado e inormes; y vericación y auditoría.

Los documentos que se exigen explícitamente en el proceso de gestión de la conguración son losregistros de conguración y los registros de deciencias.






La gestión de la conguración tiene interaces con el proceso de gestión de cambios, con elproceso de gestión de entregas y con los procesos de contabilidad de activos nancieros. Estasinteraces deben estar documentadas (Figuras 4.2.2, 4.2.3 y 4.2.4).

Guía La gestión de la conguración incluye las siguientes actividades:• Planicación• Identicación• Control• Seguimiento del estado• Vericación• Inormes

La meta, los objetivos, el alcance y las prioridades de la gestión de la conguración deben estaralineados con los objetivos del negocio. El alcance de la gestión de la conguración se detalla enel paso de identicación.

La identicación está relacionada con la denición y mantenimiento de convenciones denomenclatura y números de versión de componentes ísicos de la inraestructura de TI, junto

con documentación, las relaciones entre ellos y los atributos correspondientes. Las líneas base deconguración del hardware existente y uturo se describen mediante clústeres de CIs.

Plan de gestión dela configuración

Incluidas relaciones ydocumentación

Política en la que sedefina qué se entiende

por elemento deconfiguración (CI) y sus

componentesconstituyentes

El plan debe incluir:-Alcance, objetivos, políticas,normas, roles yresponsabilidades-Procedimientos de control decambios y configuración-Requisitos de seguimiento,trazabilidad y realización deauditorías-Definición de la interfaz conla gestión de entregas-Proceso de control de interfaz-Gestión de proveedores

Definir la interfazcon los procesos de

contabilidad deactivos financieros

Proporcionarmecanismos deidentificación,

control y

seguimiento deversiones de CIs

Designar a ungestor responsable

para todos los activosy configuraciones

principales

Planificar la gestiónde la configuración

en línea con lagestión de cambios ydefinir la informaciónque se debe registrar

Figura 4�2�2 Gestión de la conguración






La pregunta básica para la identicación de componentes de TI es:

“¿Qué servicios y componentes asociados de la inraestructura de TI tienen que estar controlados por disciplinas de Gestión del Servicio y qué inormación se necesita para ello?”

Para desarrollar un sistema de identicación es necesario tomar decisiones acerca del alcance y el nivel de detalle de la inormación que se va a registrar. Para cada propiedad (característica)

Todos los activos se debenclasificar según suimportancia para el servicioy el nivel de protección querequieran

Registros deconfiguración (CMDB)

Control read andupdate access

to CMDB

Identificar CIs

Mantener laintegridadde los

CIs

CMDB actualizada

Marcar CIs

Incluidas relaciones ydependencias entre CIs

Restringido a los CIsautorizados

Mantener los CIsen un entorno

seguro

Evitar cualquiermodificaciónde CIs sin la

documentación decontrol

correspondiente

Registrar CIs

Copias maestras deelementos electrónicos

de configuración

CMDB

Controlar copiasmaestras deelementos

electrónicos deconfiguración en

bibliotecas seguras

Referenciar las

copias maestras aregistros de

configuración

Figura 4�2�3 Gestión de la conguración (cont�)






se debe identicar a un propietario o grupo de interés. Cuantas más propiedades se registren,

mayor esuerzo habrá que hacer para actualizar la inormación. La pregunta básica enunciadaanteriormente se puede descomponer en otras más detalladas para determinar la inormación quese va a registrar. Por ejemplo:

Informe con:- Registros dedeficiencias

- Acciones correctivasemprendidas

- Resultado de las accionescorrectivas

Informes para todas

las partes afectadas

Línea base de CIs

Proporcionarinformación sobre

impacto a gestiónde cambios

Programa deauditorías

Informes degestión de laconfiguración

Incluyen:- Información de versiones- Ubicación de CIs y

versiones maestras- Interdependencias- Estado de CIs

Medir una líneabase de los CIs

apropiados antesde una entrega

Programarauditorías

Proporcionarinformación sobre

datos deconfiguración

Programa deauditorías

Verificar y auditaractivamente la

CMDB para emprenderacciones correctivas

Interfaces:

Procesos de contabilidad de activos financieros


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


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 dela 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 conguración (cont�)






• ¿De qué recursos se dispone para recopilar y actualizar la inormació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 aectarán a los servicios en caso de surir una avería y qué inormación senecesita 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 inormación presentes y uturas de los otros procesos?• ¿Qué requisitos están asociados con lo estipulado en el SLA?• ¿Qué inormación se necesita para los cobros?• ¿Son realistas los objetivos o es preerible dejar algunas cosas para más adelante?

Las respuestas a estas preguntas orecen inormació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(proundidad).

Por lo que se reere al alcance , la Figura 4.2.5 muestra las relaciones entre un servicio y loscomponentes de la CMDB. Por debajo de este alcance quedan los otros CIs necesarios parael servicio. Controlar estas relaciones hace que resulte más sencillo determinar el impacto deincidencias sobre los servicios. También es posible generar un inorme de todos los componentesque se utilizan en un servicio. Toda esta inormación puede ser útil para planicar la introducciónde mejoras en el servicio. El CI “servicio” también puede tener relaciones con otros CIs, comoacuerdos con el cliente en orma de acuerdo de nivel de servicio. En el ejemplo de la gura,

el Servicio B queda completamente uera del alcance de la CMDB; como consecuencia, notodos los CIs que contribuyen al “Servicio A” están incluidos en el alcance de la CMDB, lo quesignica que no se puede dar un soporte completo al Servicio A.

Infraestructura de TI

CI 1

Aplicación A

CI 2

Módulo A

CI 4

Módulo B

CI 5

LAN 2

CI 3

Sistema 21

CI 6

NIC 12

CI 7

PABX

Línea 1 (digital)

Línea 2 (digital)

Módem 5

CI 8

Línea 3 (analógica)

Servicio B

Alcance

Servicio A

Figura 4�2�5 Alcance de la CMDB






Una vez determinado el número de áreas en el alcance, se puede pasar a identicar los elementosdel ciclo de vida de CIs que van a estar incluidos en el alcance. Para ello hay que resolver cuestionescomo: ¿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 inraestructura? La ventaja deincluir productos en desarrollo es que sus especicaciones no se pueden modicar sin realizar

consultas y que su transerencia al entorno de gestión resulta más sencilla. Esta decisión aectaráa la actividad de monitorización de estado, pero también puede ampliar el alcance de la gestiónde la conguración en términos de ciclo de vida del producto, lo que supone un aumento derecursos.

Determinar el nivel de detalle de atributos para cada tipo de CI es muy importante para denirla gestión de la conguración, ya que de ello depende la inormación disponible sobre CIsindividuales y los nombres y atributos incluidos.

Para determinar el nivel de detalle es necesario buscar un equilibrio entre los requisitos degestió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 laconguración.

Las relaciones entre CIs son útiles para diagnosticar errores, predecir la disponibilidad de serviciosy valorar cambios. Es posible registrar muchas relaciones dierentes, tanto ísicas como lógicas:• Relaciones ísicas

− Forma parte de : Es la relación padre-hijo del CI; por ejemplo, un disco duro orma partede un ordenador personal y un módulo de sotware orma 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 sotware utilizado por diversos programas.

Para denir la proundidad 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 CIspadres y deniendo el número de niveles de desglose de CIs. El nivel más alto está ormado porla propia inraestructura de TI, mientras que el más bajo es el más detallado sobre el que se puedeejercer control. Incluir un CI en la CMDB sólo es útil si el control de ese CI y la inormaciónrelacionada redundan en benecio de otros procesos de ISO 20000. Las implantaciones suelenempezar a un nivel elevado, tras lo cual se van introduciendo niveles más bajos de orma selectiva,especialmente cuando se implanta la gestión de entregas.






En la denición de la CMDB hay que tener en cuenta las siguientes reglas generales:• Cuantos más niveles haya, más inormació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 inormación sobre la

inraestructura de TI.

También se utilizan variantes cuando coexisten distintas ormas de un CI, lo que implica unarelación paralela. Existen versiones , por ejemplo, si se utilizan al mismo tiempo una versión nuevay otra antigua de un mismo CI, lo que implica una relación en serie. El uso ecaz de estos dosconceptos acilita la planicación de cambios.

Cada CI debe tener un nombre único y sistemático que permita distinguirlo de otros CIs. Laopción más sencilla consiste en un simple sistema de numeración, tal vez dividido en distintosintervalos para cada área. Se pueden generar nuevos números cada vez que se cree un nuevo CI.

Relacionespadre-hijo

Sistema A

A1

A1

A3

A 4

A 3.1

A 3.2

A 3.3

Figura 4�2�6 Relaciones padre-hijo entre CIs (Fuente: OGC)

Infraestructura de TI

Hardware Software Red Documentación

Suite 1 Suite 2

Programa 1-1 Programa 1-2 Programa 1-3

Módulo 1-2-1 Módulo 1-2-2

Figura 4�2�7 Desglose de la CMDB (Fuente: OGC)






Si es posible, los nombres deben tener sentido para acilitar la comunicación con los usuarios.Estas convenciones de nomenclatura también se pueden usar para poner etiquetas ísicas a losCIs de orma que sean ácilmente identicables durante auditorías, labores de mantenimiento y registros de incidencias.

Para cada tipo de CI se debe denir el desarrollo detallado de la CMDB, sus atributos y relaciones.Los atributos se utilizan para almacenar inormación sobre el tipo de CI. Los atributos indicadosen la Tabla 4.2.1 pueden ser útiles para congurar CIs de inraestructura en una CMDB.

Atributo Descripción

Número/etiqueta o número de código de

barras de CI

Identicación exclusiva del CI� Suele ser unnúmero de registro asignado automáticamente porla base de datos� Aunque no todos los CIs puedenllevar una etiqueta ísica, todos ellos tienen unnúmero exclusivo�

Copia o número de serie Número de identicación del suministrador en

orma de número de serie o de licencia�Número de identifcación de herramienta de

auditoría

Las herramientas de auditoría suelen tener suspropios identicadores, que pueden ser distintospara cada área�Este atributo proporciona un vínculo para esteentorno�

Número de modelo/reerencia de catálogo Identicación exclusiva empleada en el catálogopor el suministrador�Cada versión de un modelo tiene un númerodistinto (por ejemplo, PAT-NL-C366-4000-T)�

Nombre de modelo Nombre completo del modelo, que suele incluir

un identicador de versión (por ejemplo, PII MMX400 MHz)�

Fabricante Fabricante del CI�

Categoría Clasicación del CI (por ejemplo, hardware,sotware o documentación)�

Tipo Descripción del tipo de CI con detalles sobrela categoría (por ejemplo, conguración dehardware, paquete de sotware o módulo deprograma)�

Fecha de caducidad de la garantía Fecha en que caduca la garantía�

Número de versión Número de la versión del CI�

Ubicación Ubicación del CI (por ejemplo, la biblioteca omedio donde residen los CIs sotware o el centro/ sala donde están los CIs hardware)�

Responsable propietario Nombre y/o designación del propietario o personaresponsable del CI�

Fecha de responsabilidad Fecha en que la persona anterior se hizoresponsable del CI�

Origen/suministrador El origen del CI (por ejemplo, desarrollado en laorganización o adquirido por el suministrador X)�

Licencia Número de licencia o reerencia al acuerdo delicencia�

Fecha de suministro Fecha en que el CI ue suministrado a laorganización�






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 indicanlos números de los CIs correspondientes en los registros de incidencias, problemas y cambios. Seacual sea el método seleccionado, se deben mantener las relaciones entre el CI y los registros comose indica en la Tabla 4.2.2.

El mantenimiento de las relaciones entre CIs es una parte importante de la gestión de laconguración. Dependiendo del tipo de base de datos, estas relaciones se pueden incluir comoatributos de CIs o en una tabla aparte (Tabla 4.2.3).

Algunas bases de datos disponen de un método que permite ver un registro histórico de atributosy relaciones. Esto puede ser útil para obtener inormación sobre tiempo de parada, reparacionesy mantenimiento en los campos de “Estado actual”, así como para llevar un seguimiento de lospropietarios anteriores.

Puede ser necesario mantener listas de atributos con inormación técnica sobre cada tipo de CI.También se deben crear vínculos con otras uentes de inormación able sobre: ubicaciones,

Tabla 4�2�1 Ejemplos de atributos


Número de Solicitud de Cambio (RFC) Números de RFCs activas o abiertas previamentepara el CI�

Número de problema Números de problemas activos o abiertospreviamente para el CI�

Número de incidencia Números de incidencias relacionadas con el CI�

Tabla 4�2�2 Otros registros relacionados con CIs


Relaciones de CIs padres Clave o número de CI de los CIs padres�

Relaciones de CIs hijos Clave o número de CI de los CIs hijos�

Otras relaciones Relaciones entre el CI y otros CIs, aparte delas relaciones padre-hijo ya mencionadas (porejemplo, un CI “utiliza” o “está conectado a”)�

Tabla 4�2�3 Atributos de relaciones


Fecha de aceptación Fecha en que el CI ue aceptado y aprobado porla organización�

Estado (actual) Estado actual del CI (por ejemplo, “en pruebas”,“activo” o “retirado”)�

Estado (previsto) El siguiente estado previsto del CI, con echa eindicación de la acción a realizar�

Coste Coste de adquisición del CI�

Valor residual después de depreciación Valor actual del CI después de su depreciación�

Comentarios Campo de texto para comentarios (por ejemplo,para describir las dierencias entre variantes)�






usuarios, departamentos, números de teléono, titulares de presupuestos y números depresupuestos. 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 conguració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 inraestructura de TI (estas

líneas base están incluidas en el catálogo de productos).• CIs estándar para registrar inormación de costes (elementos de coste).• Puntos de partida para el desarrollo y las pruebas de nuevas conguraciones.• Puntos de marcha atrás en caso de problemas con nuevas conguraciones después de

cambios.• Un estándar para la entrega de conguraciones a usuarios (por ejemplo, una “estación de

trabajo estándar”).

• Un punto de partida para el suministro de nuevo sotware.

Una estación de trabajo estándar es un ejemplo habitual de línea base de producto. Al limitarel número de estaciones de trabajo estándar dierentes, resulta más ácil estimar el impacto y losrecursos necesarios para el despliegue y las pruebas de nuevas unciones y mejoras. Las líneas basetambién se pueden usar para establecer una política de combinación y planicación de cambios(por ejemplo, para Paquetes de Entrega). Las líneas base ayudan a reducir los costes de gestión y acilitan la planicación de proyectos.

Otra aplicación útil de las líneas base es el catálogo de productos, que contiene una lista de las

conguraciones certicadas que se pueden usar en la inraestructura de TI y que los usuariospueden solicitar. En este caso, un CI nuevo es una copia del catálogo con un número exclusivoy una etiqueta. Antes de añadir un producto al catálogo siempre hay que analizar su caso denegocio.

El ciclo de vida de un componente se puede dividir en varias ases, cada una de ellas con uncódigo de estado asignado. Esta división depende de las características de la inraestructura de TIque la organización quiera registrar. Mantener un registro de la echa de cada cambio de estadopuede proporcionar inormación útil sobre el ciclo de vida de un producto: echa de pedido,echa de instalación y mantenimiento y soporte necesarios. El estado de un componente tambiénpuede determinar su posible uso. Por ejemplo, si se eectúa un seguimiento del estado de losrepuestos no operativos, es posible que este hardware no se pueda desplegar en otros lugares sinuna consulta previa (por ejemplo, como parte de un plan de recuperación ante desastres).

El siguiente es un ejemplo de una posible clasicació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)






– 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 modicada disponible– En pruebas– Entregado para instalación– Activo (CI en uso)– Repuesto

La inormación se tiene que gestionar de una manera ecaz para mantener actualizada la CMDB.Siempre que una actividad cambie las características registradas de un CI o las relaciones entreCIs, el cambio debe quedar registrado en la CMDB. Nota: Las características de los CIs sólose pueden modicar 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 refejar larealidad de una situación (por ejemplo, una parada del sistema).

La gestión de la conguración controla todos los componentes de TI recibidos por la organizacióny garantiza que están registrados en el sistema. El hardware se puede registrar en el momento delpedido o la entrega, mientras que el sotware se puede registrar cuando se incluye en la Bibliotecade Sotware Denitivo (DSL) o en la Biblioteca de Medios Denitivos (DML).

Una de las tareas de control consiste en garantizar que los CIs sólo se registran si han sido autorizadosy están incluidos en el catálogo de productos. Por este motivo, la gestión de la conguraciónmantiene una relación muy estrecha con la gestión de proveedores, la gestión de incidencias, lagestión de problemas y la gestión de cambios. Si en la inraestructura de TI se introducen cambioscoordinados por la gestión de cambios, la gestión de la conguración tendrá que incorporar estainormación a la CMDB. La gestión de la conguración impone requisitos sobre la madurezde 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 refeja la CMDB autorizada, la gestión de la conguraciónmonitoriza 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 ladisponibilidad).






• 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 modica la licencia de un CI.

• Se modican los detalles de un CI después de una auditoría.

La gestión de la conguración también tiene la responsabilidad de hacer que se resuelva cualquierproblema que pueda surgir en un proceso.

Las auditorías se utilizan para vericar que la situación actual continúa refejando los datos dela CMDB. Por ejemplo, las herramientas de auditoría pueden realizar análisis automáticos deestaciones de trabajo y generar inormes sobre la situación actual y el estado de la inraestructurade TI. Esta inormació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 conguración considere que la inormación puede ser

incorrecta

Las herramientas de auditoría no deben tener capacidad para modicar automáticamente laCMDB 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 lagestión de cambios.

El actor crítico de éxito para la gestión de la conguración consiste en mantener actualizada lainormación de la base de datos. Esto signica que se tienen que cumplir todos los requisitos dela gestión de cambios y la gestión de entregas y que para que se registre inormación debe existirsiempre un grupo de interés.

Es muy importante que la implantación de la gestión de la conguración se divida en variasases. Los intentos de orzar en exceso el alcance de la gestión de la conguración en un solo pasoestán generalmente condenados al racaso. Los registros mantenidos antes de la implantacióndel proceso tienen que ser retirados para evitar duplicaciones. El éxito de la introducción delproceso se verá avorecido si se consiguen algunos éxitos rápidos y si los elementos de registrodel proceso se asignan a personal que no sólo tiene los conocimientos precisos, sino también laactitud adecuada.

Los inormes de gestión de la conguración pueden incluir los siguientes elementos:• Inormación sobre la calidad del proceso.• Número de dierencias 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 conguración no estaba autorizada.• Número de ocasiones en que no se pudo localizar una conguración registrada.






• Dierencias de nivel de atributos descubiertas por auditorías.• Tiempo necesario para procesar una solicitud de registro de inormación.• Lista de CIs para los que se registraron cambios o incidencias por encima de un número

determinado.• Inormación estadística sobre la estructura y composición de la inraestructura 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.


Los cambios en los servicios y la inraestructura deben tener un ámbito claramente denido y

documentado.

Todas las peticiones de cambio se deben registrar y clasicar, por ejemplo en urgentes, deemergencia, importantes, menores. Se debe evaluar el riesgo, el impacto y los benecios parael negocio de las peticiones de cambio.

El proceso de gestión de cambios debe incluir la orma en que puede darse marcha atrás ocorregir 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 orma controlada.

Se debe revisar el éxito de todos los cambios y, en caso contrario, se deben decidir y llevarse acabo acciones correctivas tras la implementación.Deben existir políticas y procedimientos para controlar la autorización e implementación decambios de emergencia.

La echas planicadas para la implementación de los cambios se deben utilizar como basepara la planicación de cambios y entregas. Se debe mantener y comunicar a las partescorrespondientes la planicación que contenga los detalles de todos los cambios aprobadospara su implementación y las echas propuestas.

Los registros de cambios se deben analizar regularmente para detectar incrementos en elvolumen de cambios, tipos recurrentes recuentemente, tendencias emergentes y cualquierotra inormación relevante. Los resultados y conclusiones obtenidos a partir del análisis de loscambios se deben registrar.

Las acciones de mejora identicadas para la gestión de cambios se deben registrar y debeproporcionar inormación de entrada al plan de mejora del servicio.







Planicación e implantaciónLos procesos y procedimientos de gestión de cambios deberían garantizar que :a) Los cambios tienen claramente denido y documentado su alcance.

b) Sólo son aprobados los cambios que proporcionan benecios al negocio, por ejemplo: comerciales,legales, regulatorios y estatuarios.

c) Los cambios son planicados en base a la prioridad y al riesgo.d) Los cambios a las conguraciones pueden ser vericados durante la implementación del cambio.e) Cuando sea requerido, el plazo para la implementación de los cambios es supervisado y para

identicar propuestas de mejora. ) Puede demostrarse cómo un cambio es : 1) Generado, registrado y clasicado (con las reerencias a los documentos que dieron origen al

cambio).

2) Evaluado en relación al impacto, la urgencia, el coste, los benecios 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 conguración

aectados, 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, vericado y entregado.

8) Cerrado y revisado.9) Planicado, supervisado e incluido en un inorme.10) Asociado a incidencias, problemas, otro cambio y a los registros de elementos de conguración,

cuando sea apropiado.

El estado de los cambios y las echas de implementación planicadas se deberían usar como base parala planicación del cambio y del despliegue. La inormación de planicación debería estar disponible para las personas aectadas por el cambio.

Cuando se pueda ocasionar una perdida del servicio durante el horario normal del servicio, las personas aectadas deberían acordar el cambio antes de su implementación.

Cierre y revisión de una solicitud de cambioTodos los cambios se deberían revisar en relación a su éxito o allo 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ónen los cambios principales para comprobar que :a) El cambio cumple sus objetivos.b) Los clientes están satisechos con los resultados.c) No ha habido eectos colaterales inesperados.

Toda no conormidad se debería registrar y tomarse las acciones pertinentes.Cualquier debilidad o deciencia identicada en la revisión del proceso de gestión de cambios, deberíaalimentar los planes de mejora del servicio.






Cambios de emergencia En ocasiones se requiere la realización de cambios de emergencia, y cuando sea posible, se deberíaseguir el proceso de cambio, aunque algunos detalles se documenten a posteriori. Cuando el procesode 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 justicar por quien

los implementa y deberían ser revisados después del cambio para vericar que era una verdaderaemergencia.

Inormes, análisis y acciones de la gestión de cambios Los registros de los cambios se deberían analizar de orma periódica, para detectar incrementos en el nivel de cambios, recuencia de los tipos recurrentes, tendencias emergentes y cualquier otra inormaciónrelevante. Los resultados y las conclusiones derivados del análisis de los cambios se deberían registrar y actuar sobre ellos.


Las actividades básicas del proceso de gestión de cambios consisten en registrar, aceptar y clasicarsolicitudes 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 decambio y los registros para acciones de mejora. Una solicitud de cambio puede proceder de otrosprocesos, de un usuario o de un empleado. Estas interaces con el proceso de gestión de cambiostienen que estar debidamente documentadas, al igual que la interaz de la gestión de cambios conel 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ássignicativos se adoptan en el Comité de Cambios (CAB). El CAB incluye miembros de muchaspartes de la organización, así como clientes y suministradores. La gestión de la conguración seencarga de proporcionar inormació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.• Inormación de la CMDB (especícamente, el análisis de impacto de los cambios).• Inormación procedente de otros procesos, como gestión de problemas y gestión de la

capacidad.• Planicación de cambios (Lista de Cambios Planicados, FSC).

Las salidas del proceso son:• Lista actualizada de cambios (FSC)• Disparadores para gestión de la conguración y gestión de entregas• Orden del día, actas y decisiones del CAB

• Inormes de gestión de cambios






Planificar lagestión decambios

Todos los cambiosde emergenciatienen que acabar

siguiendo elproceso de cambioestándar

Utilizar comoentrada para SIP

Con un alcance

bien definido ydocumentado paracambios en servicioe infraestructura

Comunicar laprogramación a laspartes afectadas

Registros deacciones de mejora

Registros deanálisis de cambios

Incluye el impactosobre:- Planes dedisponibilidad ycontinuidad ydocumentosrelacionados

- Controles deseguridad

- Evaluaciones deriesgos para laseguridad

Solicitud decambio (RFC)

Controlar loscambios

introducidos enSLAs y otros

contratos

Controlar laimplantación y elretiro de servicios

Incluida revisiónpost-implantación

Definir políticas yprocedimientos

para controlar los

cambios deemergencia

Registrar RFC

Clasificar RFC:evaluar riesgo,

impacto, beneficiopara el negocio

y coste

Aprobar ycomprobar el

cambio

Programación decambios

Programar elcambio

Implantar elcambio

Revertir o corregirlos cambios

fallidos

Registrosde cambios


Analizar registrosde cambios y

revisar el cambio

Política yprocedimiento

para cambios de

emergencia

Registros decambios

Programación decambios

actualizada

Registros de RFC

Interfaces:

Todos los procesos relevantes:- Presentar solicitudes de cambio


Planificación e implantación de

servicios nuevos o modificados:- Planificar y aprobar laimplantación de serviciosnuevos o modificados,incluyendo la financiación y losrecursos adecuados; conaceptación formal

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

Gestión de entregas:- Controlar la implantación deservicios

- Valorar el impacto de lassolicitudes de cambios sobrelos planes de entrega

- Actualizar registros de cambios- Gestionar entregas deemergencia según el procesode gestión de cambios deemergencia

Gestión del nivel de servicio:- Controlar los cambiosintroducidos en SLAs y otroscontratos


Presupuestos y contabilidad:- Presupuesto y contabilidad detodos los componentes

- Estimar el coste y aprobarcambios en servicios

Gestión de relaciones con el

negocio:- Gestionar los cambiosintroducidos en contratos(en su caso) y SLAs

Gestión de proveedores:- Gestionar los cambiosintroducidos en contratos ySLAs

Gestión de la disponibilidad y lacontinuidad del servicio:- Evaluar el impacto de cualquiercambio sobre el plan dedisponibilidad y continuidaddel servicio

- Controlar todos los cambiosintroducidos en ladocumentación dedisponibilidad y continuidaddel servicio

- Vincular la documentación conla gestión de cambios

Gestión de la seguridad de lainformación:- Valorar el impacto de loscambios sobre los controles deseguridad antes de implantarlos cambios

- Realizar evaluaciones deriesgos para la seguridad

- Evitar que los cambiosreduzcan la eficacia de loscontroles

Figura 4�2�8 Gestión de cambios






La gestión de cambios utiliza las siguientes actividades para el procesamiento de cambios (Figura4.2.9):• Registro• Aceptación• Clasicación

• Planicación y aprobación• Coordinación• Evaluación

Coordinación

Aceptación;

Filtrado de RFCs

Clasificación;categoría y prioridad

Planificación;impacto y recursos

Evaluación y cierre

No

Sí

Procedimientos

deu

rgencia

Iniciarplande

marchaatrás

No

Presentación de RFC;Registro

Construcción

Pruebas

Implantación

Sí

Rechazo; posibleRFC nueva

Puede ser iterativo

¿Funciona?

¿Es urgente?

Figura 4�2�9 Actividades de la gestión de cambios según ITIL V2






En primer lugar hay que registrar todas las RFCs. Si se presenta una RFC para resolver unproblema, también se debe registrar el número del error conocido.

No todas las solicitudes de modicación se tratan como cambios; algunas tareas de gestiónrutinarias, que están claramente denidas y cubiertas por procedimientos (cambios estándar)

pero que no implican la modicación de la inraestructura, se pueden tratar como si ueranpeticiones de servicio. El resultado es la siguiente clasicación de cambios:• Cambios estándar (como peticiones de servicio) - Cuando existen modelos de cambios

aprobados y perectamente denidos que se registran individualmente, pero que no sonevaluados individualmente por la gestión de cambios; estos cambios son rutinarios. (Nota: Notodas las peticiones de servicio son cambios.)

• Cambios no estándar - Todas las demás modicaciones de la inraestructura gestionada queno son cambios estándar.

Entre la inormación que puede contener una RFC gura la siguiente:• Número de identicación de la RFC.• Número del error conocido/problema asociado (en su caso).• Descripción e identicación de los correspondientes CIs.• Motivo del cambio, incluidos justicación y benecio para el negocio.• Versión actual y nueva de los CIs que se vayan a cambiar.• Nombre, ubicación y número de teléono 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 paracomprobar si alguna de las RFCs está poco clara o si es ilógica, impracticable o innecesaria. Estassolicitudes son rechazadas especicando el motivo para ello. La persona que haya presentado lasolicitud debe tener siempre la oportunidad de deender su posición.

Un cambio conduce a la modicació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 inormación necesaria para seguir adelante con el procesamiento delcambio 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 decambio para el negocio.

• La categoría se determina en unción del impacto del cambio sobre el riesgo para los servicios

y la disponibilidad de recursos. El impacto puede oscilar entre leve y grave.






Posteriormente se añade al registro la siguiente inormació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• Inormació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)• Inormación sobre la evaluación y el escenario

La gestión de cambios planica los cambios mediante un calendario o Lista de Cambios Planicados (FSC). La FSC contiene detalles de todos los cambios aprobados y las echas previstas para suimplantación. Los miembros del CAB asesoran sobre la planicación de cambios importantes, ladisponibilidad de personal, los costes y los aspectos aectados del servicio, además de garantizar laparticipación de los clientes. El CAB unciona así como un comité asesor. La gestión de cambiosgoza de una autoridad delegada, ya que actúa en representación de la dirección de TI. Es posibleque los cambios más importantes tengan que ser aprobados por la dirección de TI antes de llegaral CAB. Esta aprobación puede incluir aspectos nancieros, técnicos y de negocio.

Para que la planicación resulte ecaz es necesario que la gestión de cambios se mantenga en

contacto con las ocinas del proyecto y con todos los demás miembros de la organizaciónencargados de construir e implantar los cambios. También la comunicación del plan de cambiosse tiene que realizar con la máxima ecacia.

Previa consulta con los departamentos de TI aectados, el CAB puede especicar ventanas detiempo periódicas para la implantación de cambios aprovechando los momentos que minimicenel impacto sobre el servicio. Los mejores momentos podrían ser los nes de semana o uera delhorario habitual de ocina. Del mismo modo se pueden establecer períodos durante los cuales noesté permitido realizar cambios (o sólo unos pocos), como durante las horas de ocina o al naldel año scal, cuando todos los departamentos de usuarios están cerrando sus cuentas.

La inormación sobre la planicación de un cambio se debe distribuir antes de la reunión delCAB, 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 jos, 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, elgestor de cambios y todas las demás partes involucradas (identicadas por el CAB) deben tener






en cuenta los siguientes aspectos:• Capacidad y rendimiento de los servicios aectados• 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 confictos 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 paraque puedan construir e integrar los cambios. La construcción puede incluir la creación de unanueva versión de sotware 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 lacoordinación. Para ello cuenta con el apoyo de la gestión de entregas y la dirección de línea, quetienen 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 parainvertir el cambio si no orece el resultado necesario. La gestión de cambios no debería aprobarel cambio si no existe un procedimiento de marcha atrás. También es necesario redactar un plande comunicación en caso de que el cambio tenga algún impacto sobre el entorno del usuario.Durante la ase 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 setienen que someter a pruebas completas, teniendo en cuenta los criterios denidos anteriormentepor el CAB. En la mayor parte de los casos, las pruebas requieren un laboratorio o un entorno depruebas independiente. Las primeras ases de las pruebas pueden ser realizadas por los encargadosde la construcción, pero no se debe implantar ningún cambio sin someterlo a algunas pruebasindependientes. 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 uncionalidad del cambio.• Pruebas de aceptación de operaciones - Pruebas independientes realizadas por los encargados

del soporte y mantenimiento de la inraestructura modicada, como el centro de atención alusuario.

Si no se puede probar un cambio de orma 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 unaescala mayor.






Cualquier miembro del departamento aectado que sea responsable de gestionar la inraestructurade TI puede recibir el encargo de implantar un cambio en esa inraestructura. La gestiónde cambios tiene que hacer que se cumpla el programa del cambio. Debe existir un plan decomunicación que indique claramente a quién se tiene que inormar 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 queevaluar . El CAB decide si es necesario eectuar algún seguimiento. Para ello se deben tener encuenta las siguientes cuestiones:• ¿Ha conducido el cambio al objetivo deseado?• ¿Están los usuarios satisechos con el resultado?• ¿Ha habido algún eecto secundario?• ¿Se han superado los esuerzos 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 Post-Implantació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 alló utilizando un método distinto. Normalmentees 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 rustrado suele empeorar más las cosas.

El uso de procedimientos de evaluación con un límite de tiempo concreto puede ayudar aimpedir 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 planicación, siempre puede haber cambios que tengan una prioridadabsoluta. Los cambios urgentes son muy importantes y se deben llevar a cabo lo antes posible. Enla mayor parte de los casos es necesario desviar para estos cambios los recursos dedicados a otrasactividades. Los cambios urgentes pueden tener un gran impacto sobre el trabajo planicado. Porlo 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 Conanza; posteriormente se tiene quepreparar con todo cuidado una implantación mejorada del cambio.

A pesar de estas medidas, existe la posibilidad de que surjan cambios urgentes que requieranprocedimientos para tratarlos con rapidez y sin que la gestión de cambios pierda el controldel proceso. Si hay tiempo suciente, el gestor de cambios puede organizar una reunión deemergencia 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 presentauera del horario de ocina, 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énpuede tratarse de una llamada teleónica.






Es posible que no haya tiempo suciente para realizar las pruebas normales, por lo que despuésde la implantación se deben ejecutar todas las ases necesarias de los procedimientos normalesde prueba. De esta orma se garantiza la realización de las pruebas omitidas anteriormente, laactualización de los archivos (registros de cambios y CMDB) y la posibilidad de eectuar unseguimiento del cambio (“¿qué es lo que ha cambiado?”).

El objetivo de la gestión de cambios es conseguir un equilibrio entre fexibilidad y estabilidad.Para refejar la situación de la organización en cada momento se pueden preparar inormes 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ácos 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ásserá suciente 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 siguientesecció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 enel entorno de producción.


NOTA: El proceso de gestión de entregas se debería integrar con los procesos de gestión de laconguración y de gestión de cambios.

Se debe documentar y acordar la política de entrega que establezca la recuencia y el tipo de laentregas.

El proveedor del servicio debe planicar con el negocio la entrega de los servicios, sistemas,sotware y hardware.






Los planes sobre cómo desplegar una entrega se deben acordar y autorizar por todas las partespertinentes, por ejemplo clientes, usuarios, personal de operaciones y de soporte.

El proceso debe incluir la orma en que se dé marcha atrás o se corrige la entrega si no serealiza con éxito.

Los planes deben registrar los entregables y las echas de la entrega, y hacer reerencia a laspeticiones de cambio, errores conocidos y problemas relacionados. El proceso de gestión deentregas debe proporcionar la inormació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 lainormación de conguración y los registros de cambio. Las entregas de emergencia se debengestionar de acuerdo a un proceso denido que realice la interaz con el proceso de gestión de

cambios de emergencia.

Se debe establecer un entorno controlado de pruebas de aceptación para construir y probartodas las entregas previamente a su distribución.Las entregas y su distribución se deben diseñar e implementar de orma que la integridaddel hardware y del sotware se mantenga a lo largo de la instalación, la manipulación, elempaquetado y la provisión.

Se debe medir el éxito y el allo de las entregas. Las mediciones deben incluir las incidenciasrelacionados 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 debenproporcionar inormación de entrada al plan para la mejora del servicio.


Generalidades La gestión de entregas debería coordinar las actividades del proveedor del servicio, los dierentes proveedores y el negocio para planicar y desplegar una entrega a lo largo de un entorno distribuido.

Son esenciales una buena planicació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 planicar con el negocio la entrega de los sistemas de inormación, las inraestructuras, los servicios y la documentaciónaectados.

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 conguración, nuevos o cambiados, requeridos para eectuar los cambios autorizados.

El proveedor del servicio se debería asegurar que los aspectos técnicos y no técnicos de la entrega sonconsiderados de orma conjunta.






Los elementos de la entrega deberían poder ser trazables y no ser modicables. 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 recuencia 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 identicació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. ) 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 eciencia. g) La vericación y la aceptación de una entrega.

Planicación de la entrega y del despliegue El proveedor del servicio debería trabajar conjuntamente con el negocio para asegurar que los elementos de conguración que se van a desplegar en una entrega son compatibles entre sí y con los elementos de conguración del entorno de destino.

La planicación de la entrega debería asegurar que los cambios de los sistemas de inormación,inraestructuras, servicios y documentación aectados son acordados, autorizados, programados,coordinados y que se realiza un seguimiento de los mismos.

La entrega y el despliegue se deberían planicar en etapas ya que los detalles del despliegue podrían no

ser conocidos inicialmente.

La planicación de una entrega y del despliegue normalmente debería incluir :a) Las echas 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 identicados 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

dierentes unidades geográcas.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 vericación y aceptación. ) La comunicación, preparación, documentación y ormació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 identicació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, paraactualizaciones de gran tamaño, que el entorno de producción está en el estado esperado en el momento de instalar la entrega.






Desarrollo o compra de sotware Se deberían vericar en el momento de la recepción, las entregas de sistemas de inormación y de sotware 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 conguración.

Diseñar, construir y congurar una entrega Los procesos de gestión de entregas y distribución se deberían diseñar e implementar para:a) Asegurar que existe conormidad con la arquitectura de sistemas, la Gestión del Servicio y las

normas de inraestructura del proveedor del servicio.b) Mantener la integridad durante la construcción, instalación, manipulación, empaquetado y

entrega.c) Usar bibliotecas de sotware 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 identicados y que se pueden llevar a cabo acciones de

recuperación si se requieren.e) Habilitar vericaciones antes de la instalación para comprobar que la plataorma de destinosatisace los requisitos previos.

) Habilitar vericaciones que se comprueben que una entrega está completa cuando llega a sudestino.

Las salidas de este proceso deberían incluir las notas de la entrega, las instrucciones de instalación y el sotware instalado y hardware ya instalados, en relación a la línea de reerencia de la conguració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.

Vericación y aceptación de la entrega El resultado nal debería ser una aprobación basada en el grado en el que el paquete completo de laentrega recoge la totalidad de los requisitos.

Los procesos de vericación y aceptación deberían:a) Vericar 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 conguración

y que se han instalado en el entorno de pruebas de aceptación usando el proceso de producción planicado.

c) Vericar que se ha completado el nivel adecuado de pruebas, por ejemplo, pruebas uncionales y no uncionales, 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 satisacce 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.






) Vericar antes de la instalación que la plataorma de destino satisace los requisitos previos de sotware y hardware.

g) Vericar 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ónde la conguración en reerencia al elemento de conguración desplegado. Esta documentación deberíaincluir :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 planicación de la ormación para los responsables del servicio, el personal de apoyo y los

clientes. ) Una línea de reerencia de la conguración para la entrega, incluyendo elementos de conguraciónasociados 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 vericación y la

aceptación.

Si un sistema o servicio no cumple completamente con los requisitos especicados, antes de pasar a producción se debería identicar y registrar mediante la gestión de la conguración y la gestión de

problemas. La inormació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 inormar a la gestión de cambios.

Despliegue, distribución e instalaciónSe 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 sotware son seguras.b) Existen procedimientos adecuados para el almacenamiento, expedición, recepción y eliminación de

bienes.c) Se planican y completan las comprobaciones sobre las instalaciones ísicas, el entorno, las

instalaciones eléctricas y otros servicios.d) Se notican 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 sotware 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 conguración se deberían actualizar con la ubicación y el propietario del sotware y el hardware tras una instalación llevada a cabo con éxito.






Se debería usar un cuestionario de satisacción y aceptación por parte del cliente de la instalación pararegistrar el éxito o el racaso de dicha instalación.

Todos los resultados de las encuestas de satisacció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 periodoinmediatamente 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.


Los pasos principales del proceso de gestión de entregas son: desarrollo de una política deentregas; diseño, construcción y conguración; pruebas y aceptación; despliegue, distribucióne instalación; y comprobación de la entrega. Las salidas de la comprobación de la entrega sonregistros del éxito o el racaso de la entrega, que a su vez pasan a ser entradas para un plan demejora del servicio. El único documento exigido explícitamente para la gestión de entregas es lapolítica de entregas, mientras que los únicos registros que se exigen son los de echas de entrega y

entregables, con reerencia a solicitudes de cambio, errores conocidos y problemas relacionados.

ISO 20000 dene tres interaces 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 interaces denidas son la interaz con el proceso de gestión de incidencias para transmitirla inormación adecuada y la interaz con el proceso de gestión de la conguración para actualizarlos registros de inormación sobre activos y conguraciones.

Guía Como ya se ha dicho, es posible combinar varias RFCs en una sola entrega. Las entregas puedenestar planicadas con un objetivo uncional para el negocio, generalmente como entregas demantenimiento de aplicaciones concretas. Pueden incluir hardware y sotware y su implantaciónes responsabilidad de la gestión de entregas . Es aconsejable denir 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 lasinterrupciones innecesarias para el usuario (“rehacer el camino todas las semanas”).






Especifica lafrecuencia y el tipode las entregas

Política de entregas


Plan de entregay despliegue

Especifica la maneraen que se va a revertiro corregir la entregaen caso de no teneréxito

Registra fechas deentrega y entregables,con referencia a lascorrespondientessolicitudes decambios, erroresconocidos yproblemas

En un entornocontrolado depruebas de aceptación

Incluyen:-- Medidas deincidenciasrelacionadas con la

entrega- Evaluación delimpacto sobre losrecursos del personalde soporte,operaciones de TI ynegocio

Registros de

éxitos y fracasosde la entrega y

oportunidades demejora

Incluye planes paracomunicación,preparación yformación

Incluyendo elsoftware adquirido

Notas de la entrega

Instrucciones deinstalación

Línea base de

configuración

Documentación:- Documentación de

soporte, como SLAs,listas de sistemas,procedimientos deinstalación y soporte,herramientas dediagnóstico oinstrucciones deoperación yadministración

- Procesos deconstrucción,entrega, instalacióny distribución

- Planes decontingencia ymarcha atrás

- Programas deformación

- Línea base deconfiguración

- Cambios, problemasy errores conocidosrelacionados

- Evidencia deautorización,verificación yaceptación

Incluyeactualizaciones detoda ladocumentaciónasociada

Visado

Informe de faltasde conformidadpara gestión de

problemas ygestión deincidencias

Visado por laautoridad deentregas

Interfaz definida conel proceso de gestiónde cambios deemergencia

Evaluar el impactode RFCs sobre elplan de entrega

Documentar ydefinir la política

de entregas

Planificar eldespliegue de la

entrega e informara gestión deincidencias

Diseñar, construiry configurar la

entregaNotas de la entrega

Instrucciones deinstalación

Línea base deconfiguración

Plan de despliegue

Probar y aceptarla entrega

Identificar yregistrar faltas de

conformidad(errores conocidos)con los requisitos

Desplegar,distribuir e instalar

la entrega(emergencia)

Encuesta declientes

Medir y analizarel éxito de la

entrega

Corregir/revertirla entrega si no

tiene éxito

Requisitos

Registros deéxitos y fracasosde la entrega y

oportunidades demejora

Actualizar losregistros decambios y la

configuración

Certificar lacompletitud

y el cumplimientode requisitos

Interfaces:


Gestión de la configuración:- Actualizar registros deinformación sobre activosy configuraciones

Gestión de cambios:- Evaluar el impacto de RFCssobre los planes de entrega

- Actualizar registros decambios

- Gestionar entregas deemergencia según elproceso de gestión decambios de emergencia


Presupuestos y contabilidad:- Presupuesto y contabilidadde todos los componentes

Gestión de incidencias:- Intercambiar lainformación relevante

Crear el entornode pruebas de

aceptación

Figura 4�2�10 Gestión de entregas






El proceso de gestión de entregas incluye las siguientes actividades:• Política y planicación de entregas• Diseño, construcción y conguración de entregas• Pruebas y aceptación de entregas• Planicación de despliegue

• Comunicación, preparación y ormación• Distribución e instalación de entregas

Estas actividades no siempre se ejecutan en el orden indicado. La política y planicación deentregas se puede denir cada seis meses o un año, mientras que otras actividades suelen serdiarias. La Figura 4.2.11 muestra las actividades de la gestión de entregas.

Para cada sistema, el gestor de entregas debe desarrollar una política de entregas en la que se denacómo y cuándo se conguran las entregas. Las entregas más importantes se pueden planicarpor anticipado junto con el número de versión o la identicación de la entrega, de orma que loscambios se puedan incorporar en los momentos más adecuados.

El gestor de entregas también especica a qué nivel es posible distribuir CIs de orma 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 esuerzo que conlleva compilarlos e implantarlos de orma simultánea.• La dicultad de la instalación en los centros de los usuarios.• La complejidad de las dependencias entre el nuevo sotware y hardware y el resto de la

inraestructura de TI; cuanto más ácil resulte aislar el sotware o hardware, más sencillo seráprobarlo.

Antes de planicar una entrega es necesario reunir inormació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 deservicio, junto con la autorización de las correspondientes RFCs.

Planificaciónde

entregas

Entornode desarrollo

Entorno controladode pruebas

Entorno deproducción

Políticade

entregas

Diseño ydesarrollo(o pedido yadquisición)de software

Construccióny configuración de laentrega

Pruebasde ajuste

alpropósito

Comunicación,preparacióny formación

Distribucióne instalación

Base de Datos de Gestión de la Configuración (CMDB)y

Biblioteca de Software Definitivo (DSL)

Gestión de entregas

Aceptaciónde la

entrega

Planificaciónde

despliegue

Figura 4�2�11 Actividades de la gestión de entregas según ITIL V2 (Fuente: OGC)






La planicació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.• Coneccionar el calendario de entrega.• Preparar un plan de comunicación.

• Realizar visitas para determinar el hardware y sotware que se está utilizando.• Denir roles y responsabilidades.• Obtener presupuestos detallados y negociar con los suministradores sobre nuevo hardware,

sotware y servicios de instalación.• Preparar planes de marcha atrás.• Preparar un plan de calidad para la entrega.• Planicar la aceptación de la entrega por la organización de gestión y los usuarios.

Los resultados de esta actividad orman 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 congurar entregas.Una entrega puede estar basada en conjuntos de componentes (CIs) desarrollados por lapropia organización o adquiridos a terceros y congurados. Las instrucciones de instalación y conguración de entregas también se deben considerar parte de la entrega y se pondrán, comoCIs, bajo el control de la gestión de cambios y la gestión de la conguración.

Es recomendable congurar y probar todo el hardware y sotware en un entorno de pruebas antesde su instalación denitiva. La conguración y el registro de los componentes sotware 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 deelementos de conguración. Es recuente que se reserve hardware normalizado para utilizarloexclusivamente en la compilación o creación de imágenes. Es aconsejable automatizar esta partedel proceso para que sea más able. En entornos de desarrollo de sotware, esta actividad seconoce 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 dene las actividades necesarias para recuperar elservicio en caso de que haya algún problema con la entrega. La creación de planes de marcha atráses responsabilidad de la gestión de cambios, aunque la gestión de entregas tiene que colaborarpara garantizar la viabilidad de dichos planes. Lo mejor es satisacer por adelantado los requisitosdel 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 habersido aceptado por los usuarios.

El proceso de construcción de la entrega puede incluir la compilación y vinculación de módulossotware o el llenado de bases de datos con datos de pruebas o de otro tipo, como tablas decódigos postales, tasas de impuestos, zonas horarias o tablas de divisas, además de inormación deusuarios. Para ello es recuente 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 identicadas en laCMDB como conguraciones estándares para acilitar su uso ante uturos requisitos. Los planes






de pruebas cubren la prueba y aceptación de la calidad del sotware, hardware, procedimientos,instrucciones de operación y guiones de despliegue antes de la entrega, y posiblemente tambiénsu evaluación después de la entrega. Igualmente se deben probar los guiones de instalación. Lainormación necesaria para esta actividad incluye:• Denición de la entrega

• Calendario de entrega• Instrucciones para congurar 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 sotware 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 uncional por representantes

de los usuarios y a una prueba operativa por personal de gestión de TI, quienes tendrán en cuentala operación técnica, las unciones, los aspectos operativos, el rendimiento y la integración conel resto de la inraestructura. Las pruebas deben incluir también los guiones de instalación, losprocedimientos de marcha atrás y cualquier cambio que se introduzca en los procedimientos degestión. Cada uno de los pasos tendrá que ser aceptado ormalmente 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 cambiosdebe organizar la aceptación ormal por parte de los usuarios y el visado de la entrega por losdesarrolladores 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 conguración. Este estado de reerencia para la entregatiene que estar especicado en la denició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 allidos. Losresultados de esta actividad incluyen:• Procedimientos de instalación probados• Componentes de la entrega probados• Errores conocidos y deectos en la entrega• Resultados de pruebas• Documentación de soporte y gestión• Lista de sistemas aectados• Instrucciones de operación y herramientas de diagnóstico• Planes de contingencia y marcha atrás probados• Programa de ormación para personal, gestores y usuarios• Documentos rmados de aceptación• Autorización rmada de la entrega

Al plan de entrega redactado en las ases anteriores se añade ahora inormación sobre las actividadesy el calendario exacto de implantación, es decir, una planicación de despliegue :• Calendario, lista de tareas y recursos humanos necesarios.

• Lista de los CIs que se deben instalar y retirar, junto con la orma en que se van a retirar.• Plan de actividades para cada centro de implantación, teniendo en cuenta las posibles echas deentrega y, en el caso de una organización internacional, las zonas horarias.






• Envío de notas de la entrega y otras comunicaciones a las partes aectadas.• Planes para la adquisición de hardware y sotware.• Adquisición, almacenamiento seguro, identicació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 ormas:• Despliegue completo de la entrega (método “Big Bang”).• Despliegue de la entrega por ases, con varias opciones:

– Incrementos uncionales (todos los usuarios reciben nuevas unciones al mismo tiempo)– Incrementos de localización (por grupos de usuarios)– Evolutivo (las unciones se van ampliando por ases)

El personal que mantiene contacto con los clientes (centro de atención al usuario y gestión derelaciones con el cliente), el personal operativo y los representantes de la organización de usuariostienen que conocer los planes y su posible impacto sobre las actividades rutinarias. Esto se puedeconseguir mediante sesiones de ormación conjunta, cooperación y participación conjunta en laaceptación de la entrega. Es necesario comunicar las responsabilidades y comprobar que todo elmundo las conoce. Si el despliegue de la entrega se realiza por ases, se debe inormar de ello a losusuarios, comunicándoles también los planes previstos y cuándo recibirán las nuevas unciones.

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

aectado.

La gestión de entregas monitoriza los procesos de logística para la adquisición, almacenamiento,transporte, entrega y cesión de sotware y hardware. El proceso incluye procedimientos, registrosy documentos de soporte (como hojas de embalaje), por lo que puede proporcionar inormaciónable a la gestión de la conguración. La instalación donde se almacene el hardware y el sotwaretiene 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óne instalación de sotware. De esta orma se reducirá el tiempo y los recursos necesarios para ladistribución, además de aumentar la calidad. Por lo general, estas herramientas también permitencomprobar más ácilmente el éxito de la instalación.

Antes de iniciar una instalación, es conveniente comprobar que el entorno donde se va a instalarla entrega cumple todas las condiciones (espacio suciente en disco, seguridad, controles olimitaciones ambientales como aire acondicionado, espacio en piso y alimentación eléctrica/SAI).

Una vez realizada la instalación, hay que actualizar la inormación en la CMDB para acilitar la

vericación de los acuerdos de licencia.






La planicación e implantación de la gestión de entregas depende en gran medida de laimplantación de la gestión de la conguración y la gestión de cambios. Debe incluir la planicacióne implantación inicial de las capacidades de gestión de entregas, seguida de una revisión y mejoracontinuas de:• Políticas de entregas que incluyan niveles, tipos, unidades, identicación, recuencia y ases 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 conguración sotware.

4.3 Alineación entre el negocio y las Tecnologías de laInormación

4.3.1 Proceso de la provisión del servicio: Gestión del nivel de servicio (6.1)

Objetivo: Denir, acordar, registrar y gestionar los niveles de servicio.


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 detrabajo que deben soportar.Cada servicio orecido se debe denir, acordar y documentar en uno o más acuerdos de nivelde servicio.

Se deben acordar y registrar por todas las partes relevantes los SLAs, junto con los acuerdos deservicio 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 encuentranactualizados y continúan siendo ecaces con el transcurso del tiempo.

Los niveles de servicio se deben monitorizar y se deben generar inormes de dichos nivelescon relación a los objetivos, mostrando tanto la inormación actual como las tendencias.Las razones para las no conormidades se deben comunicar y revisar. Las acciones de mejoradenidas durante este proceso se deben registrar y constituyen una entrada al plan de mejoradel servicio.


Catálogo de servicios Todos los servicios deberían estar denidos en un catálogo de servicios. Este catálogo puede ser reerenciado desde el SLA y debería utilizarse para recoger aquellos aspectos considerados como






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 inormació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 parareiniciar un servicio tras un allo importante)

c) Datos de contactod) 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 á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 ormalmente documentado en un acuerdo de nivel de servicio (SLA). El SLA debería ser autorizado ormalmente 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 denir desde la perspectiva del cliente. Los SLAs deberían incluir únicamente unconjunto adecuado de objetivos para centrar la atención en los aspectos más importantes del servicio.

NOTA 1: Demasiados objetivos pueden generar conusión y conllevar un exceso de gastos.

El contenido mínimo que debería tener un SLA, o que se debería reerenciar 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 inormes.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.

) Horario de servicio, por ejemplo de 09 :00 h a 17 :00 h, excepciones al mismo (por ejemplo nes de semana o periodos vacacionales), periodos críticos para el negocio y cobertura uera del horario.

g) Interrupciones planicadas 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 noticación.l) Procedimientos de reclamación.

m) Objetivos del servicio.n) Límites de la carga de trabajo (superior e inerior), 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.






o) Detalles de alto nivel de la gestión nanciera, 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 inormación volátil o común a varios SLAs (como datos de contacto) se puede reerenciar desde el SLA sin que esto suponga un impacto en la calidad de los procesos de SLM siempre que los documentos de reerencia estén también bajo el control del proceso de gestión de cambios.

NOTA 3: En el SLA se suele hacer reerencia 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, usiones y reorganizaciones del negocio, y los cambios en los requisitos del cliente, pueden implicar el ajuste de los niveles de servicio, su redenición o incluso su suspensión temporal.

El proceso SLM debería ser fexible para adecuarse a estos cambios. El proceso SLM debería asegurar que el proveedor del servicio continúa ocalizado en el cliente durante la planicación, implantación

y la gestión continua del servicio prestado.Se debería dar al proveedor del servicio la inormació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 inorme 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 satisacción del cliente es una parte importante de la gestión del nivel de servicio pero deberíareconocerse 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.






Acuerdos de servicios de soporte Los servicios de soporte de los cuales depende el servicio prestado se deberían documentar y acordar concada suministrador de servicios. Esto incluye los grupos internos que proveen parte del servicio orecido por el proveedor del servicio.


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 orecer• Monitorizar los niveles de servicio• Inormar 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 tieneque conducir a la denición de un plan de mejora del servicio.

Los cambios que se introduzcan en los acuerdos de nivel de servicio tienen que estar controladospor la gestión de cambios. Se debe documentar la interaz entre la gestión del nivel de servicioy el proceso de gestión de cambios, así como la interaz con el proceso de mejora continua queevalúa, registra, prioriza y autoriza todas las mejoras propuestas.

Guía

La gestión del nivel de servicio incluye las siguientes actividades:• Identicación de necesidades• Denición de requisitos• Contratación de niveles de servicio• Monitorización de rendimiento• Inorme de rendimiento• Revisión de rendimiento

ISO 20000 contempla un proceso independiente para inormes del servicio, por lo que los pasosde comunicación y revisión se discutirán en la Sección 4.3.2, inormes del servicio.

La calidad percibida de un servicio depende de las expectativas del cliente, de la gestión continuade las percepciones del cliente, de la estabilidad del servicio y de la aceptabilidad de los costes. Porlo tanto, la mejor orma de orecer una calidad adecuada es empezar discutiendo los requisitos oposibles 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 noexistan acuerdos claros. Estos aspectos supuestos (implícitos) de los servicios de TI suelen causar

mucha conusión, lo que una vez más pone de maniesto la necesidad de que los gestores delnivel de servicio conozcan lo mejor posible a sus clientes para poder ayudarles a tener una opiniónclara sobre los servicios y niveles de servicio que necesitan y el coste correspondiente.






SLA

Contratos desuministradores

Acordar y registrarservicios, objetivos

específicos ycaracterísticas decarga de trabajo

Definir, acordar ydocumentar cada

uno de los serviciossuministrados

Monitorizar nivelesde servicio con

referencia aobjetivos específicos

Comunicar nivelesde servicio con

referencia aobjetivos específicos

Informe denivel de servicio

Con motivos de faltasde conformidad

Revisar el informede nivel de servicioy registrar acciones

de mejora

Acuerdos deservicios de soporte

Procedimientoscorrespondientes


Acciones demejora

Acciones demejora

Registros deservicios, objetivos

específicos ycaracterísticas decarga de trabajo

Catálogode servicios

Mantener elcatálogo de servicios



Presupuesto ynecesidades del

negocio del cliente

Para cada grupo de clientes y servicio,definen:- Máximo período continuo permitidocon pérdida de servicio

- Máximos períodos permitidos conservicio degradado

- Niveles permitidos de degradación deservicio durante períodos derecuperación de servicio

- Participación conjunta en planes dedisponibilidad y continuidad

Interfaces:

Mejora continua (Actuar):- Gestionar actividades de mejora- Sugerir mejoras para SIP

Gestión de cambios:

- Controlar el SLA- Presentar una solicitud de cambio



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 continuidaddel servicio antes de acordar los requisitos del cliente

Figura 4�3�1 Gestión del nivel de servicio






Los requisitos del cliente tienen que estar expresados en valores medibles para que puedancontribuir al diseño y monitorización de los servicios de TI. Si no se ha llegado a un acuerdocon el cliente acerca de las métricas a utilizar, resulta diícil vericar si el servicio ha satisechoo no alguno de los acuerdos. La gestión del nivel de servicio desempeña un papel clave en lacomprensión y denición de las necesidades del cliente.

El primer paso para cerrar SLAs sobre servicios de TI presentes o uturos debe ser la identicacióny denición de las necesidades del cliente en los requisitos de nivel de servicio. Además de hacerlouna vez durante el proceso, esta actividad también se debe realizar periódicamente a partir deinormes y revisiones, a petición del cliente o cuando convenga a la organización de TI. Estaactividad puede cubrir servicios nuevos o ya existentes.

Denir el alcance y la proundidad de los requisitos del cliente se considera un proceso de diseñodentro 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 nal delproceso corresponden a los requisitos del cliente. Durante el proceso de diseño, el término“externo” hace reerencia a la comunicación con clientes, mientras que “interno” se reere al

soporte técnico dentro de la organización de TI. El proceso de diseño consta de varios pasos, desdela identicación de los requisitos de cliente y su denición en normas claras hasta el desarrollo delos requisitos técnicos para la provisión del servicio.

El primer paso para cuanticar servicios de TI nuevos o existentes consiste en denir o redenir entérminos generales las expectativas del cliente acerca del servicio. Estas expectativas se ormalizanen requisitos documentados de nivel de servicio, que deben incluir a toda la organizacióndel cliente. Este paso se considera normalmente la parte más diícil de la gestión del nivel deservicio.

El gestor del nivel de servicio tiene que estar preparado para reunirse con la organización delcliente al principio de esta ase. Lo primero que hay que preguntarse, es qué es lo que se exige alservicio de TI y de qué elementos debe constar el servicio. Un servicio técnico puede conllevar eluso de una inraestructura limitada, como una Red de Área Ancha (WAN). Dicho servicio puedeser una parte de un servicio compuesto, como el acceso a un completo sistema de inormación queincluya toda la inraestructura subyacente (WAN, LAN, estaciones de trabajo y aplicaciones).

Los usuarios tienen que estar divididos en grupos durante estas reuniones. El gestor del nivel deservicio prepara una lista de grupos de usuarios y de sus requisitos y autoridad. Para denir los

requisitos de nivel de servicio se necesita la siguiente inormación:• Una descripción (desde la perspectiva del cliente) de las unciones que debe orecer elservicio.






• Las horas y días en que el servicio debe estar disponible.• Los requisitos de continuidad del servicio.• Las unciones de TI necesarias para la provisión del servicio.• Reerencias a los métodos operativos o normas de calidad en vigor que haya que tener en

cuenta en la denición del servicio.

• Una reerencia al SLA que se deba modicar o sustituir, en su caso.

La ase de diseño dará como resultado un documento de requisitos de nivel de servicio, queestará rmado por el gestor del nivel de servicio y el cliente. Los requisitos de nivel de serviciotambién se pueden modicar mientras el departamento trabaja en el diseño, la adquisición y laimplantación. Dichos cambios pueden estar relacionados con la viabilidad de las unciones o loscostes previstos y tienen que ser aprobados por ambas partes.

Durante la ase de especicación se desarrollan en detalle los requisitos de nivel de servicio

para convertirlos en normas internas. El objetivo de esta ase es proporcionar la siguienteinormación:• Una descripción inequívoca y detallada de los servicios de TI y de sus componentes.• Las especicaciones de la orma de implantación y provisión del servicio.• Las especicaciones del procedimiento necesario de control de la calidad.

Se recomienda distinguir los elementos de la documentación para uso interno de los que sonpara uso externo (Figura 4.3.2). Las especicaciones para uso externo están relacionadas con losobjetivos acordados con los clientes y son las que controlan el proceso de diseño. Se denen encolaboración con la organización del cliente y orman la entrada para las especicaciones para

uso interno.

Documentos externos:

- Requisitos de nivel de servicio

- Acuerdo de nivel de servicio

- Catálogo de servicios

Documentos internos:

- Hojas de especificaciones

- Acuerdos de nivel operativo

- Contratos de soporte

Dirección del negocio

Usuarios

finales

Departamento de TI

Sumi

nistradores

Control dedocumentos

Revisióninterna

Figura 4�3�2 Fase de especicación






Las especicaciones para uso interno se reeren a los objetivos internos de la organización de TI,que se deben cumplir para satisacer las demandas del cliente. La separación entre especicacionesinternas y externas resulta especialmente útil una vez iniciado el proceso de gestión del nivel deservicio, 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

especicaciones internas y externas. A esto contribuyen el control de documentos y las revisionesinternas, que permiten mantener registros de documentos relacionados, gestionar versiones y organizar auditorías periódicas

Las hojas de especicaciones (especicaciones del servicio) describen en detalle lo que el clientedesea (elemento externo) y el impacto que eso tiene sobre la organización de TI (elementointerno). no es necesario que estén rmadas por las dos partes, aunque tienen que estar sujetas alcontrol de documentos. El catálogo de servicios se puede preparar a partir de las especicacionesde servicios. Esto permite incluir inmediatamente en las hojas de especicaciones y en el catálogo

de servicios cualquier cambio en los niveles de servicio. Finalmente, se revisa o se crea el SLA deacuerdo con las hojas de especicaciones revisadas.

Toda la inormación de gestión (indicadores clave del rendimiento) y las especicaciones paraproveedores internos y externos se deben incluir en un único plan de calidad del servicio quecontenga amplia inormación sobre las contribuciones realizadas a los servicios de TI por cadaproceso de Gestión del Servicio.

Al terminar la ase de especicación, la organización de TI habrá convertido las necesidades denegocio en conguraciones y recursos de TI. Esta inormación se utiliza para redactar o modicar

los siguientes documentos:• Acuerdo de nivel de servicio - Al desarrollar la estructura del SLA, se recomienda empezar

deniendo los aspectos generales (como los servicios de red para toda la empresa) y desarrollarun modelo general de SLA basado en servicios antes de iniciar las negociaciones. Los SLAspueden tener una estructura jerárquica (como la organización del cliente) refejada en unacuerdo marco con diversos niveles, cada uno de ellos con su propio nivel de detalle. Losniveles superiores incluyen acuerdos sobre servicios generales para la organización, mientrasque los ineriores contienen inormación relevante para clientes y servicios especícos.La estructura de un SLA depende de distintas variables como:– Aspectos í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 queconocer los OLAs o UCs que aecten a la provisión de un servicio concreto. La gestión de laconguración puede ayudar a aclarar los vínculos con las hojas de especicaciones.

• Catálogo de Servicios - Los siguientes consejos pueden resultar útiles para elaborar unCatálogo de Servicios:

– Utilizar el idioma del cliente, evitando términos técnicos y usando la terminología delnegocio correspondiente.– Tratar de ver las cosas desde el punto de vista del cliente y utilizar ese enoque para identicar

la inormación relevante.






– Presentar la inormación de orma atractiva, ya que la organización de TI usará tal documentopara presentarse a sus clientes.

– Poner el documento a disposición del mayor número posible de grupos de interés (porejemplo, publicándolo en una página de intranet o en CD-ROM).

Sólo es posible monitorizar los niveles de servicio si están denidos con claridad desde el principioy corresponden a los objetivos acordados. Los niveles de servicio se tienen que medir desde laperspectiva del cliente. La monitorización no se puede limitar a los aspectos técnicos, sino quedebe incluir también aspectos de procedimientos. Por ejemplo, los usuarios pensarán que unservicio no está disponible mientras no se les inorme de que ha sido restablecido.

La gestión de la disponibilidad y la gestión de la capacidad proporcionan inormación sobre laimplantación de los objetivos técnicos asociados con los niveles de servicio. En algunos casostambién se recibirá inormación de los procesos de soporte del servicio, y especialmente de la

gestión de incidencias. Sin embargo, medir parámetros internos no es suciente, puesto queno guardan relación con la percepción del usuario. También tiene que ser posible medir otrosparámetros como el tiempo de respuesta, el tiempo de escalado y el tiempo de soporte. Sólo seobtendrá una imagen completa si se combina inormación de gestión de sistemas y de la Gestióndel Servicio.

En muchas organizaciones donde se está introduciendo la gestión del nivel de servicio, se discutela conveniencia de asociar sanciones al incumplimiento de las condiciones del SLA. Se trata deuna cuestión compleja, ya que la gestión del nivel de servicio está basada en la interacción deldepartamento 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 usuariospersiguen los mismos objetivos corporativos, resulta dudoso que las sanciones (y especialmentelas de tipo nanciero) contribuyan al interés común. Puede ser mucho más conveniente alcanzaracuerdos 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 unservicio de un proveedor de TI externo, en cuyo caso es mucho más probable que se utilice uncontrato de soporte (UC) legalmente vinculante en lugar de un SLA.

Los niveles de servicio se deben revisar periódicamente teniendo en cuenta los siguientesaspectos:• Acuerdos de nivel de servicio desde la revisión anterior.• Problemas relacionados con los servicios.• Identicació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 accionesde mejora como:

• Desarrollo de un Programa de Mejora del Servicio.• Asignación de personal adicional y otros recursos.• Modicación de los niveles de servicio denidos en el SLA.






• Modicación de los procesos y procedimientos.• Modicació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 denidos para el proceso.• Campaña de concienciación para inormar sobre el proceso, omentar su conocimiento y

recabar apoyos.• Tareas, autoridades y responsabilidades bien denidas para el proceso, distinguiendo entre

control del proceso y tareas operativas (contactos con el cliente).

Los siguientes KPIs pueden servir para determinar la ecacia y la eciencia del proceso de gestióndel 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 deectos.• Elementos de los SLAs que se revisen periódicamente.• Elementos de los SLAs que cumplan los niveles de servicio acordados.• Deectos identicados y cubiertos por un plan de mejora.• Acciones emprendidas para eliminar los deectos identicados.• Tendencias identicadas con respecto a los niveles reales de servicio.

4.3.2 Proceso de la provisión del servicio: Generación de inormes del servicio (6.2)

Objetivo: Generar en plazo los inormes acordados, ables y precisos, para inormar de latoma de decisiones y para una comunicación ecaz.


Se debe describir claramente cada inorme de servicio, incluyendo su identicador, elpropósito, la audiencia y los detalles del origen de los datos.

Los inormes de servicio se deben generar para vericar si se cumplen los requisitos y necesidades de los usuarios. Los inormes de servicio deben incluir:a) El rendimiento y comportamiento rente a los objetivos de nivel de servicio.b) Las no conormidades 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 inormes de los resultados de los principales eventos, por ejemplo las principales

incidencias y cambios.e) La inormación sobre tendencias. ) El análisis de satisacción.

Las decisiones de gestión y las acciones correctivas deben tener en cuenta los aspectosdestacados en los inormes de servicio y deben comunicarse a las partes aectadas.







NOTA: El éxito de todos los procesos de Gestión del Servicio depende del uso de la inormación proporcionada en los inormes de servicio.

Política Los requisitos para la generación de inormes para clientes y para gestión interna se deberían acordar y ser registrados. La supervisión del servicio y la generación de inormes 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 inormes deberían refejar las relaciones entre ellos. Por ejemplo, un suministrador principal debería inormar sobre la totalidad del servicio que presta, incluyendo cualquier servicio realizado por un tercero y que orme parte del que el suministrador principal gestiona como parte del servicio al cliente.

Propósito de los inormes del servicio y vericación de su calidad Los inormes de servicio se deberían generar a tiempo, y ser claros, ables y concisos. Se deberíanadecuar a las necesidades de quien lo recibe y ser sucientemente precisos para poder ser utilizados como herramienta de apoyo en la toma de decisiones.La presentación debería ayudar a comprender los inormes de orma que sean ácilmente asimilables, por ejemplo usando grácos.

Se deberían generar distintos tipos de inormes :a) Inormes reactivos, que muestran lo que ha ocurrido.b) Inormes proactivos, que avisen por adelantado de eventos signicativos con objeto de permitir que

se puedan realizar acciones preventivas (por ejemplo, inormes sobre inminentes rupturas de los

SLAs).c) Distribución previa de inormes que muestren las actividades planicadas.

Inormes de servicioEl proveedor del servicio debería generar inormes para los clientes y para la dirección, que cubran los siguientes aspectos :a) Comportamiento rente a objetivos de nivel de servicio, por ejemplo inormes de caídas del servicio,

logros.b) No conormidades rente a normas.c) Características de la carga de trabajo y volumen de la inormación, por ejemplo incidencias,

problemas, cambios y tareas, clasicación, ubicación, clientes, tendencias estacionales, combinaciónde prioridades, número de solicitudes de ayuda.

d) Inormes de resultados después de eventos de alto nivel, por ejemplo cambios y entregas.e) Inormación de tendencias por periodos (por ejemplo diaria, semanal, mensual). ) Inormes que incluyan inormación de cada proceso, por ejemplo número de incidencias y de

preguntas más recuentes, componentes de la inraestructura poco ables, tareas que consumen grannúmero de recursos económicos, técnicos o humanos.

g) Inormes para destacar cargas de trabajo uturas o planicadas.







El enoque a cliente es uno de los principios de la gestión de la calidad, por lo que la elaboraciónde inormes del servicio es una actividad importante que orma parte de la gestión del nivel deservicio. Las actividades de inormes del servicio descritas en esta subsección de la norma estánencaminadas a satisacer las necesidades y los requisitos de gestión interna y del cliente. Estasactividades tienen una interaz con todos los procesos que se usan para adquirir inormación.

La elaboración de inormes del servicio no es una actividad que ejecute exclusivamente elproveedor de servicios, puesto que también los suministradores tienen que inormar de su servicioal proveedor de servicios. Los inormes de servicio de un suministrador deberían refejar posibles

relaciones entre suministradores.

Acordar y registrarrequisitos parainformes del

servicio

Describirinformes

del servicio

Elaborar informes

del servicio

Comunicar lasdecisiones de ladirección y las

acciones correctivasa las partesafectadas

Requisitos

de informes

del servicio

Descripciones

de informes

del servicio

Incluyen:

- Identidad- Propósito- Destinatarios- Detalles de la fuente de datos

Incluye:- Grado de cumplimiento delos objetivos específicos denivel de servicio

- Faltas de conformidad yposibles problemas

- Características de carga detrabajo

- Informes de rendimientodespués de eventos deimportancia

- Información de tendencias yanálisis de satisfacción

Tipos de informes:- Informes reactivos: Qué

ha ocurrido- Informes proactivos:

Anticipación de eventosimportantes

- Informes de planificación:Actividades planificadas

Informe

del servicio

Informe

del servicio

Incluyen:- Información de cada uno de

los procesos- Datos que destaquen cargas

de trabajo previstas parael futuro

Reflejan las relaciones entre

suministradores.

Interfaces:

Todos los procesos relevantes:- Proporcionar información

Mejora continua (Actuar):

- Sugerir mejoras para SIP

Gestión del nivel de servicio:

- Comunicar niveles de servicio con

referencia a objetivos específicos

Figura 4�3�3 Inormes del servicio






Guía Se deben presentar inormes de cliente (inormes del servicio) en los intervalos especicados enel SLA. Estos inormes comparan los niveles de servicio acordados con los niveles de serviciomedidos en la práctica. Por ejemplo, se pueden presentar inormes sobre:• Disponibilidad y tiempo de parada durante un período especicado.

• 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 uncionales 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 allidos.• Proporción de la capacidad del servicio empleada.• Número de cambios completados y abiertos.• Coste del servicio suministrado.

A dierencia de los inormes de nivel de servicio, los inormes de gestión no se elaboran para elcliente, sino para controlar o gestionar el proceso interno. Pueden contener métricas sobre losniveles 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.• Satisacció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 contabilidadde los servicios de TI (6.4)

Objetivo: Presupuestar y contabilizar los costes de la provisión del servicio.


NOTA: Esta sección cubre la elaboración de presupuestos y de la contabilidad de los serviciosde TI. En la práctica, muchos proveedores del servicio estarán involucrados en acturarpor tales servicios. Sin embargo, dado que la acturación es una actividad opcional, no estácubierta por la norma. Se recomienda a los proveedores que si hacen uso de la acturación,el mecanismo para hacerlo esté plenamente denido y entendido por las partes. Todas lasprácticas contables en uso se deberían alinear con las prácticas contables más amplias de laorganizació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 inormació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 eectivo y la autorización.






Los costes se deben presupuestar con suciente detalle para permitir el control económicoeectivo y la toma de decisiones. El proveedor del servicio debe monitorizar e inormar delos costes contra el presupuesto, revisar las previsiones económicas y gestionar los costes enconsonancia. Los costes de los cambios en el servicio se deben valorar y aprobar a través delproceso de gestión de cambios.


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 acturación del servicio. Sin embargo, dado que la acturación es una actividad opcional, no está cubierta por esta norma. Se recomienda a los proveedores del servicio que cuando lleven a cabo la acturación, el mecanismo empleado para ello esté denido endetalle y sea atendido por todas las partes implicadas.

La responsabilidad sobre muchas de las decisiones nancieras va a estar uera del ámbito de laGestión del Servicio y también podrían dictarse externamente los requisitos acerca de qué inormación nanciera se debe acilitar, de qué manera y con qué recuencia. Las disposiciones de esta secciónestán enocadas en las prácticas que se deberían seguir para satisacer los requisitos de la norma. Sinembargo, se pueden tener en cuenta requisitos más amplios en el caso de que impacten en alguna de las políticas y procedimientos denidos. Todas las prácticas contables utilizadas deben estar alineadas conlas prácticas contables generales en la organización del proveedor del servicio.

Política

Debería existir una política para la gestión nanciera de los servicios. La política debería denir los objetivos a ser cumplidos por la realización de los presupuestos y la contabilidad.

La política debería denir 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 dierentes ubicaciones.d) Las reglas para manejar las variaciones rente 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 nancieros que tengan los clientes, el proveedor del servicio y los proveedores, según esté denido en la política.

NOTA: Los proveedores del servicio que operen en un entorno comercial podrían necesitar invertir

mucho más esuerzo y tiempo en la gestión nanciera. Contrariamente, para aquellos proveedores del servicio que sólo necesiten la simple identicación de los costes, esta gestión puede ser mucho más simple.






La realización de los presupuestos y la contabilidad se deberían realizar por todos los proveedores del servicio, cualesquiera que ueran sus otras políticas en cuanto a gestión nanciera.

Elaboración del presupuestoLa elaboración del presupuesto debería tener en cuenta los cambios planicados de los servicios

durante el periodo presupuestario y, en el caso de que las necesidades presupuestarias excedan los ondos disponibles, planicar la gestión que se va a hacer del décit.

La elaboración de los presupuestos puede tener en cuenta actores tales como variaciones estacionales y cambios planicados a corto plazo en los costes y acturación de los servicios.

El seguimiento de los costes rente al presupuesto debería acilitar lo antes posible la inormación de las variaciones rente al presupuesto. Se debería establecer un proceso para gestionar las implicaciones de las variaciones rente al presupuesto.

La elaboración de los presupuestos y el seguimiento de los costes deberían dar soporte a la planicaciónde 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 eciencia

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


En la gestión nanciera de la organización de un proveedor de servicios se pueden distinguiractividades de elaboración y control de presupuestos, contabilidad y cobros.

Guía Un sistema ecaz de control de costes tiene que cumplir los siguientes criterios:• Facilitar el desarrollo de una estrategia de inversión que permita aprovechar la fexibilidad

orecida por la moderna tecnología.• Identicar 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 inormación relevante.• Facilitar las decisiones cotidianas de la dirección, de manera que se puedan adoptar decisionesa largo plazo con el mínimo riesgo nanciero posible.

• Ser fexible y capaz de responder rápidamente a cambios en las actividades de negocio.






La Figura 4.3.5 muestra el ciclo nanciero de elaboración y control de presupuestos, contabilidady cobros.

El objetivo de la elaboración y control de presupuestos es planicar y controlar las actividades de unaorganización. La planicación corporativa y estratégica determina los objetivos a largo plazo de

Presupuesto ycontabilidad de

todos loscomponentes

Política ygestión financierade servicios de TI

Crearprevisiónfinanciera

Distribuir costesindirectos y

asignar costesdirectos a servicios

Monitorizar ycomunicar costes

en relaciónal presupuesto

Revisar lasprevisionesfinancieras

Revisión deprevisionesfinancieras

Informesde costes

Previsiónfinanciera

Previsiónfinanciera

Incluye modelosde costes

Controlar finanzas

y autorizaciones

Definir políticas yprocesos sobre

gestión financierade servicios de TI

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

Interfaces:

Todos los procesos relevantes:- Presupuesto y contabilidad de

todos los componentes


Proceso de gestión de cambios:

- Estimar el coste y aprobar cambios en servicios- Presentar solicitudes de cambio


Figura 4�3�4 Presupuestos y contabilidad de los servicios de TI






un negocio. Los presupuestos denen los planes nancieros para los objetivos durante el períodocubierto por el presupuesto, que normalmente oscila entre uno y cinco años.

Dependiendo de la política nanciera del negocio, se pueden seguir dos métodos de elaboraciónde presupuestos :• Presupuesto incremental - En el caso de presupuestos incrementales, las ciras del año anterior

sirven de base para el nuevo presupuesto, que se ajusta para refejar 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 justicar todas sus peticiones derecursos en términos de coste presupuestario. Esto signica que se evalúan todos y cada uno delos gastos antes de decidir si se aprueban y cuál debe ser su coste. Es evidente que este métodorequiere mucho más tiempo, por lo que normalmente sólo se utiliza cada pocos años y sepreere el método incremental para los años restantes.

El proceso de elaboración y control de presupuesto comienza con la identicación de los actoresclave que limitan el crecimiento de la empresa. En muchos casos se trata del volumen de ventas,aunque también puede ser la alta de espacio o materiales. Es recuente que el presupuesto vengadeterminado por restricciones nancieras. Este proceso incluye la denición de los siguientespresupuestos secundarios (en lo que sigue se ignoran los procesos de aprobación seguidos en cadanegocio):• 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. Laelaboració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 inormación detalladasobre los servicios que se deben suministrar (cantidades, tiempos de entrega, personas-hora y

materiales).• Presupuestos administrativos - En unció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.

Necesidades de TIen las actividades

de negocio

Planes de TI(incluyendo

presupuestos)Contabilidad Cobros

Información sobretarifas planificadas

Identificarobjetivos

financieros

Métodos de

control decostes

Gestión delNivel de Servicio

GestiónFinanciera

Métodosde cobro

Figura 4�3�5 El ciclo nanciero






• Presupuestos de costes e inversiones - El presupuesto de costes es resultado de los planescontemplados en los presupuestos anteriores, mientras que el presupuesto de inversionesidentica el gasto asociado a la sustitución y adquisición de los medios de producción. Losproyectos de inversión que se hayan iniciado el año anterior también pueden infuir en elpresupuesto de inversiones.

El año nanciero (scal) 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, conel n de realizar comparaciones entre las ciras presupuestadas y reales.

Algunos negocios no sólo elaboran presupuestos anuales detallados, sino también una previsióngeneral para un período de tres o cinco años. De esta orma, la dirección sénior puede conocerlas expectativas a más largo plazo.

Para que una organización de TI uncione como un negocio es undamental identicar y comprender todos los costes imputables a TI. Para ello se emplea la contabilidad . Se debendeterminar todos los costes, aunque no se vayan a cobrar a los clientes.

Una de las actividades contables más importantes consiste en denir elementos de coste. Estaestructura se mantiene ja durante un año, tras lo cual se puede modicar. En la mayor partede los casos se elige un método de contabilidad de costes cuando se introduce una estructura deelementos de coste en el negocio, lo que signica que la estructura de elementos de coste tieneque ser compatible con los métodos adoptados por el negocio. Lo normal es que se registrencostes para cada departamento, cliente o producto.

Sin embargo, lo ideal es que la estructura refeje los servicios suministrados. Aunque el procesono se utilice para imputar costes, suele resultar útil basar la estructura de tipos de coste en unaestructura 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 creadospor la organización de TI para la prestación de servicios. En esta estructura, los elementos deservicio de nivel más bajo soportan a los elementos de servicio de nivel superior. Cuanto más altasea la posición de un elemento en esta estructura, más relevante es su unción para el negocio. A partir de los elementos de servicio se denen los elementos de coste, que a su vez se dividen enunidades de coste para personal, hardware, sotware y gastos generales.

La ventaja de estructurar los elementos de coste a partir de los elementos de servicio reside en quepermite ver con claridad el gasto en hardware, sotware y soporte del servicio. Además de unaestructura basada en costes directos, también se puede decidir cómo asignar costes indirectos alos servicios. Cuanto más detallada sea la estructura de servicios, más ácil será comprender loscostes.

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 elementosde coste. Resultaría más claro, pero también orecería inormación menos detallada.






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 identicar nuevas tendencias (uncrecimiento imprevisto, por ejemplo) y, en su caso, responder de acuerdo con la política denegocio.

La imputación de costes interna es una herramienta muy ecaz para conseguir que los usuariosempleen con más cuidado los recursos de TI. No obstante, cobrar por los servicios de TI noresulta tan útil si los titulares de presupuestos en las organizaciones de los clientes no tienenque pagar por otros servicios como el teléono, el alojamiento, la sala de correo, la comida o laadministración de personal. En otras palabras: la imputación de costes tiene que ser compatiblecon las políticas nancieras de la organización. Si se considera que el cobro es adecuado, lostitulares de presupuestos pueden hacer rente a los costes operativos, que repercuten en el preciode sus productos y servicios.

Los cobros se emplean normalmente para recuperar todos los costes en que se ha incurrido, encuyo caso la organización de TI unciona como una unidad de negocio. Esto sólo es posiblecuando se conocen los costes operativos reales de los servicios de TI.

Servicios de red (LAN y WAN)

Estación de trabajoLínea base A

Ordenador de sobremesa potente

Estación de trabajoLínea base BThin Client

Estación de trabajoLínea base C

Ordenador portátil

Sistema operativoWindows Vista

Sistema operativoWindows XP

Aplicaciones generales de negocio

Aplicaciones colaborativaServicios de correo y directorio

Intranet, Extranet e InternetServicios de información

Emulador de terminalEntorno IBM

Emulador de terminalotro entorno

Aplicación de negocioCuentas

Aplicación de negocioGestión de Relaciones

Aplicación de negocioDatos de marketing

Servicios de archivos e impresión

Aplicaciones de oficina

Figura 4�3�6 Ejemplo de una estructura de servicios






Es conveniente denir políticas de imputación de costes antes de jar un precio. Existen dierentespolíticas que se pueden elegir en unción de los objetivos de la gestión nanciera. También esposible introducir el cobro por ases y usar una política distinta para cada ase. Las políticas deimputación de costes son:• Comunicación de inormación - Se inorma 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 ellose puede elegir entre dos opciones:– Calcular los costes correspondientes a cada unidad de negocio e inormar a los gestores

interesados.– Como la anterior, pero incluyendo los costes que se van a cobrar siguiendo un método de

cobro especíco.• Flexibilidad de precios - Los precios se jan y se cobran con periodicidad anual. Si el

proveedor de servicios decide invertir en un servicio porque se utiliza con más recuencia, elcontrato puede incluir una cláusula para cobrar los costes adicionales. La alternativa es orecer

más capacidad a otros clientes potenciales.• Cobro por noción - Los costes se acturan, pero no es necesario pagarlos. Esto permite a laorganización de TI adquirir experiencia en el uso del proceso y corregir posibles errores enel sistema de cobro. También orece al cliente la oportunidad de acostumbrarse al cobro. Noobstante, este método de imputación de costes sólo es útil si nalmente se recuperan los costes,ya que de lo contrario no se llegará a tener conciencia de ellos.

Con recuencia resulta diícil jar el precio de un servicio. El establecimiento de precios incluyelas 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 elobjetivo y el benecio 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). Elprecio no sólo es importante para recuperar los costes en que se ha incurrido, sino que tambiéninfuye en la demanda del producto. Una estrategia de precios fexibles puede ser útil parapromocionar productos, para retirarlos o para distribuir la demanda de sistemas. Los ingresosobtenidos con otros servicios pueden ayudar a costear un servicio nuevo que tiene pocos clientes.Los costes de un servicio tienen que estar claramente identicados antes de que se pueda elegiruna estrategia de establecimiento de precios.

Dependiendo de la política de imputación de costes, el cliente recibe una actura o unacomunicación del uso real de servicios de TI. Los costes se tratan en las reuniones periódicascon el cliente previstas en el proceso de gestión del nivel de servicio, que recibe la siguiente

inormación:• Gasto en servicios de TI por cliente• Dierencia entre los cobros reales y estimados






• Métodos de imputación de costes y contabilidad empleados• Disputas sobre cobros, con sus causas y soluciones

El proceso de gestión nanciera tiene que presentar a la dirección de TI inormes periódicos sobreaspectos como:• Costes y benecios generales de los servicios de TI• Análisis de costes para cada departamento de TI, plataorma y otras unidades relevantes• Costes correspondientes al sistema de gestión nanciera• Planicación de uturas inversiones• Comparación entre los resultados planicados y reales• Oportunidades de reducción de costes

Antes de introducir la gestión nanciera hay que inormar a los usuarios, al personal y a ladirección de TI del objetivo que se persigue, así como de los costes, benecios y posibles problemas

asociados con la introducción.

Los CSFs para la introducción de un sistema ecaz 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 inormes en términos de unidades de rendimientocuanticables).

• El sistema de monitorización de costes debe proporcionar detalles y justicación de gastos.• La Gestión de Servicios de TI debe contar con sistemas bien equilibrados que orezcan servicios

de TI ecaces a un precio razonable.

• La dirección de TI debe ser consciente del impacto y los costes que conlleva la introducción dela gestión nanciera y estar plenamente comprometida.

• La gestión de la conguración debe proporcionar inormación relevante sobre la estructura delos servicios para poder denir un sistema de contabilidad apropiado.

Los siguientes indicadores de rendimiento pueden ayudar a controlar el proceso:• Análisis coste-benecio 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 nancieros.• Cambia el uso de los servicios por parte del cliente.• Se presentan inormes puntuales a la gestión del nivel de servicio.

4.3.4 Procesos de relaciones: Generalidades (7.1)

Las especifcaciones ISO 20000-1 dicen:Los procesos de relación describen los dos aspectos relacionados con la gestión de proveedoresy con la gestión de las relaciones con el negocio.


Los procesos de relación describen los dos aspectos relacionados de la gestión de proveedores y la gestiónde relaciones con el negocio. Esta norma se dirige hacia el rol de un proveedor del servicio, el cual






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 ormalizarán mediante contratos. Las relaciones internas se

ormalizarán mediante acuerdos de servicio o de soporte interno que son a menudo designados comoacuerdos de nivel operacional.

La Figura 4.3.7 muestra una representación simplicada de las 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 orma 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 paradescribir la organización a la que se dirige este documento, independientemente del papel, o sentido enla 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 orma directa o bien mediante el proveedor del servicio.

Los procesos de relación deberían asegurar que todas las partes :a) Entienden y satisacen 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 satisacción del cliente son apropiados y que se comunican y entienden las necesidades uturas del negocio.

El alcance, los roles y las responsabilidades de las relaciones con el negocio y las relaciones con los suministradores deberían denirse y acordarse. Esto debería incluir la identicación de todos los grupos de interés, los contactos y los medios y recuencia de la comunicación.

Suministrador Proveedorde servicios

Gestión deProveedores

Cliente

Gestión deRelaciones con

el Negocio

Figura 4�3�7 Procesos de relaciones






La Figura 4.3.8 muestra cómo se pueden visualizar los procesos generales de relación en lenguajeBPM.

Cambios de alcance del servicio, SLA,contrato o necesidades de negocio

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

Grupos de interésy clientes del servicio

Identificar ydocumentar a los

grupos de interés ylos clientes del servicio

Asistir a la revisióndel servicio paradiscutir cambios

Mantener reunionesintermedias yemitir nuevos

registros para SIP

Responder a cambiosimportantes y

nuevas necesidadesde negocio

Planificarreuniones formales

Definir y acordar elalcance, los roles y

las responsabilidadesde las relaciones con

el negocio y lossuministradores

Identificar contactos

con grupos de interésy las líneas y frecuencia

de comunicación

Al menos unavez al año

Antes y después decambios importantes

Designar a personasresponsables del

proceso de relacionescon el negocioy satisfacción

del cliente

Emitir registros derevisión del servicio

A intervalosacordados

RFC si es necesario

Actas

Actas

Registros derevisión del servicio

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


Figura 4�3�8 Gestión de relaciones con el negocio






El enoque a cliente es uno de los ocho principios de la gestión de la calidad, por lo que lagestión de relaciones con el negocio es un proceso importante. Un proveedor de servicios tieneque controlar los procesos de su propia organización para poder orecer al cliente servicios de TIde calidad, pero también debe controlar los servicios de los suministradores que contribuyen alnegocio 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 elcliente, basándose en el entendimiento del cliente y de los undamentos de su negocio.


El proveedor del servicio debe identicar 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 larevisión del servicio y para discutir cualquier cambio en el alcance del mismo, en el SLA, en elcontrato (si existe) o en las necesidades del negocio. Se deben mantener reuniones a intervalosacordados para discutir el comportamiento y las prestaciones, los cumplimientos, asuntosvarios 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ónde cambios.

El proveedor del servicio debe permanecer al tanto de las necesidades del negocio y de losprincipales cambios en el mismo para preparar una respuesta a dichas necesidades.

Debe existir un proceso de reclamaciones. La denición de la reclamación ormal sobre elservicio debe estar acordada con el cliente.Todas las reclamaciones ormales sobre el servicioson registradas por el proveedor del servicio, investigadas, controladas emprendiendo accionessobre ellas, inormadas y ormalmente cerradas. Cuando una reclamación no sea resueltamediante 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 satisacción del cliente y todo el proceso de gestión de relaciones con elnegocio. Debe existir un proceso de medición periódica de la satisacción del cliente paraobtener inormación y comentarios, y actuar en consecuencia. Las acciones de mejora que seidentiquen durante este proceso se deben registrar y utilizar como inormación de entradapara un plan de mejora del servicio.







Revisiones del servicioEl 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 planicarse y ser noticadas a los grupos de interés para los que sean relevantes.

El proveedor del servicio debería planicar y registrar todas las reuniones ormales, 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 puedanestar al tanto de las necesidades del negocio y de los cambios principales para poder prepararse para dar una respuesta a los mismos.

Reclamaciones del servicioEl proveedor del servicio y los clientes deberían acordar un procedimiento ormal 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 identicar a la persona de contacto en el proveedor del servicio al que dirigir las reclamaciones ormales.

El proveedor del servicio debería registrar, investigar, tomar acciones, elaborar inormes y cerrar ormalmente todas las reclamaciones de servicio.

Las reclamaciones más relevantes se deberían revisar periódicamente y ser escaladas a la alta direcciónsi no se resuelven dentro de los plazos acordados con los clientes.

Los proveedores del servicio deberían analizar periódicamente las reclamaciones registradas paraidenticar tendencias y elaborar inormes 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 plande mejora del servicio.

Medición de la satisacción del cliente Se debería medir la satisacción del cliente para permitir al proveedor del servicio comparar el desempeño

con los objetivos de satisacción de clientes y con encuestas previas. El alcance y la complejidad de laencuesta se deberían concebir de orma que los clientes puedan responder ácilmente y sin que se requiera un excesivo tiempo para cumplimentar de una manera adecuada dicha encuesta.






Se deberían investigar las variaciones signicativas en los niveles de satisacció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 satisacció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 serviciosobre cuyo progreso se inorme al cliente.Las elicitaciones sobre el servicio se deberían documentar y dar a conocer al equipo que esté prestandoel servicio.

Según el principio de enoque a cliente de la gestión de la calidad, las organizaciones dependende sus clientes y, por tanto, tienen que comprender sus necesidades presentes y uturas, cumplirsus 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 satisacción del cliente (Figura 4.3.10)

Los documentos necesarios para la gestión de relaciones con el negocio incluyen un documentosobre las partes interesadas y los clientes del servicio, las actas de las reuniones de relaciones conel negocio, registros de quejas ormales sobre el servicio y registros de acciones de mejora.

El proceso de gestión de relaciones con el negocio tiene una interaz con el proceso de gestión decambios, 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 deTI para soporte y coordinación. Las comunicaciones en vertical aectan a políticas, control einormes.

El principal reto de la gestión de relaciones con el negocio consiste en garantizar una relación buenay ecaz a todos los niveles entre la organización de TI y la organización del cliente. Es importanteque desde el principio se dena 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 acturas”, la persona autorizada a alcanzar un acuerdo con laorganizació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 acturas” también puede ser el usuario que “está al teclado”.






Posibilidad de escalado

Registros dequejas del servicio

Tendencias

Tendencias

Registrar todas lasquejas sobre el servicio

Investigar las quejassobre el servicio

Resolver las quejassobre el servicio

Informar de lasquejas sobre el servicio

Cerrar formalmentelas quejas sobre

el servicio

Acordar elprocedimiento de

gestión dequejas formales

Revisar periódicamentelas quejas pendientes

de resolución y procedera su escaladosi es necesario

Analizar periódicamentelos registros de quejas

para identificartendencias

Informar del

análisis a los clientes

Acordar ladefinición de queja

formal sobre el servicio

Identificar el puntode contacto parala presentación

de quejas formales


Tendencias

Registros dequejas del servicio

Figura 4�3�9 Gestión de relaciones con el negocio: Gestión de quejas






La gestión de relaciones con el negocio desempeña un importante rol en el desarrollo delalineamiento estratégico entre la organización de TI y la organización que adquiere los servicios deTI. En la práctica, se trata undamentalmente 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 unenoque a cliente y propone soluciones de TI que ayudan al cliente a cumplir sus objetivos de

Medidas desatisfacción del cliente

Medidas desatisfacción del cliente



Plan de mejoradel servicio

Comentarios positivos

Obtener medidasde satisfacción

Registrar las accionesde mejora identificadas


Comparar los resultados

con los objetivos desatisfacción y losresultados de

encuestas anteriores

Investigar ycomprender las variaciones

significativas en losniveles de satisfacción

Discutir con el clientelos resultados de las

encuestas de satisfacción

y acordar unplan de acción

Informar al clientesobre el progreso dela mejora del servicio

Documentarcomentarios positivos

Comunicar los comentariospositivos al equiporesponsable de la

provisión del servicio

Figura 4�3�10 Gestión de las relaciones con el negocio: Gestión de satisacción del cliente






negocio. La naturaleza dinámica de las dos organizaciones obliga también a coordinar la velocidadde los cambios.

Los acuerdos con el cliente sobre los servicios que se van a suministrar se desarrollan en propuestasde nivel de servicios a través de la gestión del nivel de servicio. Si el cliente desea introducir unaintranet, por ejemplo, es necesario llegar a un acuerdo sobre la disponibilidad, el soporte alusuario, la implantación de solicitudes de cambio y el coste. Estos acuerdos se jan en un acuerdode nivel de servicio (SLA).

Si la organización del cliente quiere introducir cambios (ampliación o modicación) en losservicios de TI contemplados en los acuerdos que orman parte del SLA, tendrá que presentaruna solicitud de cambio (RFC). Una vez realizada la instalación, hay que actualizar la inormacióny el estado del CI en la CMDB para acilitar la vericación de los acuerdos de licencia.

La Figura 4.3.11 no sólo orece inormación sobre las comunicaciones en horizontal y en vertical,sino también sobre el horizonte de planicación de los procesos. La coordinación a nivel estratégicotiene un horizonte de planicación de varios años. La gestión del nivel de servicio aecta a losacuerdos de nivel táctico y su horizonte de panicación es de aproximadamente un año. Lagestión de cambios, el centro de atención al usuario y la gestión de incidencias aectan al niveloperativo y tienen un horizonte de planicación de meses, semanas, días o incluso horas.

Las encuestas de satisacción del cliente (CSS) pueden ser encuestas periódicas de tipo ormal obien estudios realizados por el centro de atención al usuario. En ambos casos se selecciona avarios interlocutores al azar y se les hacen algunas preguntas sobre su percepción de la calidad delservicio de TI. La inormación recopilada con las encuestas del centro de atención al usuario sedebe considerar como un complemento a la CSS completa. Tanto el texto de las preguntas comosu contenido se tienen que elegir con mucho cuidado. Las preguntas tienen que aectar 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 lasacciones propuestas para las áreas de mejora.

SuministroDemanda

Directores de departamento

Jefes de proyecto

Usuarios

Gestoresde negocio

Titulares depresupuestos

Organización del cliente Organización de TI

Alineamientoestratégico

Nivelesde servicio

Solicitudesde cambio

Soporte

Estratégica

Táctica

Operativa

Informes

Política

Gestión de Relacionescon el Cliente de TI

Gestiónde TI

Gestión delnivel de servicio

Gestión de cambios

Gestión de incidencias

Centro de atención al usuario

Producción

Figura 4�3�11 Gestión de las relaciones con el negocio






Los resultados de la CSS deben servir para realizar un análisis de tendencias con el n deconseguir 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 delcliente.

4.3.6 Procesos de relaciones: Gestión de proveedores (7.3)

Objetivo: Gestionar los suministradores para garantizar la provisión sin interrupciones deservicios de calidad.


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 elsuministro de alguna parte del servicio. Es el proveedor del servicio quien debe demostrarel cumplimiento de estos procesos de gestión de proveedores. Pueden existir relacionescomplejas, 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 porel suministrador(es) se deben acordar por todas las partes y documentar en los SLAs u otrosdocumentos.

Los SLAs con los suministradores se deben alinear con los SLAs del negocio.Las interaces entre los procesos utilizados por cada parte deben ser acordadas y documentadas.

Todos los roles y relaciones entre suministradores principales y subcontratados deben estarclaramente documentados. Los suministradores principales deben ser capaces de demostrarque tienen procesos para garantizar que los subcontratistas cumplen con los requisitoscontractuales.

Se debe disponer de un proceso para la revisión detallada del contrato o del acuerdoormal, con periodicidad mínima anual, que garantice que las necesidades y obligacionescontractuales del negocio se siguen cumpliendo.

Los cambios al contrato(s), si existen, y los SLAs deben ser el resultado de estas revisiones o deaquellas requeridas en cualquier momento. Cualquier cambio debe estar sujeto al proceso degestión de cambios.

Debe existir un proceso para tratar los desacuerdos contractuales.

Debe existir un proceso para gestionar la nalización normal o anticipada de un servicio, o latraserencia del mismo a un tercero.






Se debe monitorizar y revisar el comportamiento y las prestaciones rente a los objetivos denivel de servicio. Las acciones de mejora identicadas durante este proceso se deben registrary utilizar como inormación de entrada al plan de mejora del servicio.


IntroducciónLos procedimientos de gestión de proveedores deberían garantizar que :a) El suministrador entiende sus obligaciones rente 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 inormació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 procesocomún para asegurar que la inormación sobre el desempeño de los suministradores está controlada y se actúa consecuentemente.

Debería existir una persona de contacto denida dentro de la organización del proveedor del servicioque sea el responsable de la relación con cada suministrador.

Todos los contratos con suministradores deberían contener una planicación de las revisiones paraevaluar si los objetivos de negocio para el suministro de un servicio siguen siendo válidos.

Debería existir un proceso claramente denido para la gestión de cada contrato. El proceso para

la modicación de contratos debería estar también claramente denido. Cualquier cambio a este procedimiento se debería noticar ormalmente a todos los suministradores aectados.

Negocio

Proveedor deservicios (puede

ser interno o externo)

Suministrador 1

Suministrador 2

Suministradorprincipal 3

Suministradorsubcontratado 4

Figura 4�3�12 Ejemplo de relación entre proveedores de servicios y suministradores






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 bonicaciones,se deberían establecer claramente sus undamentos y elaborar un inorme del cumplimiento de los requisitos.

Denición del servicioPara cada servicio y suministrador el proveedor del servicio debería mantener :a) Una denició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 inorme 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 ormadirecta 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 ormalmente a los suministradores subcontratados; guiándose, cuando sea apropiado, por los requisitos incluidos en la Norma ISO/IEC 20000-1.

Gestión de los confictos contractuales Tanto el proveedor del servicio como el suministrador deberían uncionar conorme a un proceso para gestionar los confictos, el cual se debería denir o reerenciar dentro del contrato.

Debería existir un procedimiento o itinerario para poder escalar los confictos que no puedan ser resueltos mediante el procedimiento ordinario.

El proceso debería asegurar que los confictos son registrados, investigados, que se toman acciones necesarias sobre ellos y que se cierran ormalmente.

Finalización del contratoEl proceso de gestión de contratos debería contemplar la extinción del contrato (tanto planicada,como prematura). También debería proporcionar un mecanismo de transerencia del servicio a otraorganización.


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. Porlo tanto, la gestión de la relación con el suministrador y el control del contrato son procesos muy importantes.






Con vía de escalado

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 distintasorganizaciones

- Definición de servicios, roles yresponsabilidades

- Alcance del servicio- Proceso de gestión de contratos, nivelesde autorización y un plan de abandonode contrato

- Condiciones de pago, en su caso- Parámetros de elaboración de informes yregistros de rendimiento

Incluye nombres y responsabilidades

-Finalización prevista-Finalización anticipada-Transferencia a otra organización

Al menos una vez al año

Roles responsables:

****

****

*

***

***

*

**

*

*

*

*

**********

Proveedor de serviciosProveedor de servicios y suministrador principalSuministrador principalTodas las partes afectadas

Designar a un gestorde contratos para

cada suministrador

Acordar ydocumentar las

interfaces del proceso

Documentar todoslos roles y relaciones

entre suministradoresprincipales y

subcontratados

Resolver disputascontractuales

Demostrar que lossubcontratistaspueden cumplir

los requisitos

Efectuar unarevisión del contrato

o acuerdo formal

Cambiarel contrato

Documentar elproceso de gestión

de proveedores

Acordar y

documentar losrequisitos, elalcance, el nivelde servicio y los

procesos decomunicación que

se vayan aadquirir con lossuministradores

Gestionar lafinalizacióndel servicio


Monitorizar y revisarel rendimiento de lossuministradores enrelación a objetivos

específicos

Identificar yregistrar acciones

de mejora

Obtener evidenciade que los

suministradoresprincipales gestionana los subcontratistas

SLAs desuministradores

u otros documentos

Interfacesdel proceso

Roles yrelaciones

RfCs

Registrode disputas

Proceso de gestiónde proveedores



Informede conformidad

Informede conformidad

Interfaces:

Procesos de suministradores- Documentar interfaces


Proceso de gestión de cambios:- Gestionar los cambios introducidosen contratos y SLAs

Gestión del nivel de servicio


- Recibir informaciónPresupuestos y contabilidad:- Presupuesto y contabilidad de todoslos componentes

Figura 4�3�13 Gestión de proveedores






La norma exige explícitamente la existencia de procesos documentados de gestión de proveedores.En estos procesos se deben denir las actividades necesarias para eectuar una revisión delcontrato, para resolver disputas contractuales y para gestionar la nalización de los servicios. Sihay múltiples suministradores, el suministrador principal debe contar con procesos para controlarlos servicios de todos los suministradores.

Los documentos exigidos explícitamente para la gestión de proveedores son los acuerdos de nivelde servicio de los suministradores y los registros de acciones de mejora.

El proceso de gestión de proveedores tiene interaces con procesos de suministradores, con elproceso de gestión de cambios y con el proceso de mejora continua. Estas interaces deben estardocumentadas.

Guía

Una organización tiene por lo general muchos suministradores, la mayor parte de los cualesproporcionan servicios o productos que el negocio utiliza como activos que dan soporte a lacadena de valor del negocio, aunque estén controlados por el cliente. Los tipos de suministradoresy sus contratos pueden tener una infuencia decisiva sobre la estructura organizativa y sobre todoel marco de trabajo de SLAs.

En el caso de los suministradores clave, la relación resulta especialmente importante y la calidaddel servicio puede ser determinante para la cadena de valor. Esto aecta a la relación con laorganizació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 omentan la actividad comercial y la interacción de negocios.• Operativo - Productos y servicios, especialmente si se puede encontrar con acilidad una

alternativa.

Para suministrar los servicios es preciso que se desarrollen y mantengan relaciones adecuadas. Lostipos 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 delidad a un único suministrador se

puede traducir en precios más avorables 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 avorece la competencia en precios.

• Asociación - Las relaciones de asociación se establecen a nivel ejecutivo, requieren alianzasestratégicas y se basan en riesgos compartidos.

• Externalización -Es cada vez más común y, por lo general, consiste en transerir la responsabilidadde la entrega del servicio de suministradores internos a suministradores externos.

Existen diversos actores que pueden infuir en la relación o combinación de relaciones elegidas.

Una herramienta de posicionamiento estratégico, como los perles mostrados en la Figura 4.3.14,puede ayudar a una organización a elegir el enoque más adecuado.






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 haceesta ormalización es documentar elementos de la relación, pero su éxito dependerá también deactores humanos y de negocio. La relación ormalizada 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 benecios• 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

Suministrador importante

Activo dealto valor y

bajo riesgo

Suministrador importante

Servicio debajo valor yalto riesgo

Conexión con suministradores

Valor parael negocio

Suministrador estratégico

Servicio dealto valor y

alto riesgo

Suministrador útil

Activo debajo valor ybajo riesgo

Riesgo creciente

Figura 4�3�14 Perles de relaciones con suministradores






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.


Se deben identicar los requisitos de disponibilidad y de continuidad del servicio sobre labase de los planes de negocio, los SLAs y las evaluaciones del riesgo. Los requisitos debenincluir los derechos de acceso y los tiempos de repuesta, así como la disponibilidad extremo aextremo de los componentes del sistema.

Los planes de disponibilidad y continuidad del servicio se deben desarrollar y revisar almenos una vez al año, para asegurar que los requisitos cumplen lo acordado bajo todas lascircunstancias, desde la normalidad hasta la pérdida grave del servicio. Estos planes se debenmantener para asegurar que refejan los cambios acordados, requeridos por el negocio.

Los planes de disponibilidad y de continuidad del servicio se deben probar de nuevo cuandose produzca un cambio importante en el entorno del negocio.

El proceso de gestión de cambios debe evaluar el impacto de cualquier cambio sobre losplanes de disponibilidad y continuidad del servicio.

La disponibilidad se debe medir y registrar. Se debe investigar la indisponibilidad noplanicada y se deben llevar a cabo las acciones necesarias.

NOTA: Cuando sea posible, se deben predecir problemas potenciales y tomar medidaspreventivas.

Los planes de continuidad del servicio, la lista de contactos y la base de datos de gestión dela conguración deben estar disponibles incluso en el caso de que no sea posible el accesonormal a las ocinas. El plan de continuidad del servicio debe incluir la actividad de vuelta ala 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 allidas se debenelaborar planes de acción.


NOTA: Los desastres o allos 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.






Generalidades Los requisitos de continuidad y disponibilidad se deberían identicar sobre la base de las prioridades del negocio del cliente, los acuerdos de nivel de servicio y los riesgos evaluados. El proveedor del serviciodebería mantener una capacidad suciente para el servicio junto con planes ácilmente realizables,diseñados para asegurar que los requisitos acordados pueden ser alcanzados en todas las circunstancias,

desde el uncionamiento habitual hasta los casos de caídas graves del servicio. El proveedor del serviciodebería planicarse para satisacer los datos conocidos de incrementos y decrementos de volumende usuarios, picos o caídas previstos de la demanda y cualquier otro cambio uturo 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 infuencia capital en las acciones, esuerzos y recursos destinados para satisacer 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 denidos en los SLAs para identicar no conormidades con los objetivos de disponibilidad acordados.

d) Documentar y revisar las no conormidades.e) Predecir la disponibilidad a uturo. ) 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 acabo las acciones correctivas.

Estrategia de continuidad del servicioEl proveedor del servicio debería desarrollar y mantener una estrategia que dena el enoque general a seguir para satisacer 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 ormalmente.






Planicación y prueba de la continuidad del servicioEl 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 rente a cadaobjetivo.

d) Las copias de seguridad de los datos, los documentos, el sotware y cualquier equipo y personal necesario para la restauración del servicio están disponibles de orma rápida ante un desastre o un allo 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. ) El personal conoce y asume su rol para activar y/o ejecutar los planes y tiene acceso a la documentaciónrelativa 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 signicativos.

Se deberían llevar a cabo pruebas con una recuencia suciente, para asegurar que los planes de continuidad son eectivos 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 allos en las pruebas se deberían documentar y revisar para proveer de inormació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 actividadesque garantizan la disponibilidad de los sistemas en todo momento. ISO 20000 contempla unsistema combinado de gestión de la disponibilidad y la continuidad del servicio, pero en lapráctica se trata de dos procesos dierentes, aunque estrechamente relacionados.

La planicación y las pruebas de la disponibilidad y de la continuidad del servicio se puedenrealizar como un solo conjunto de actividades, mientras que las actividades de monitorizacióny gestión de la disponibilidad y de gestión de la continuidad del servicio se deben ejecutar porseparado.






Incluyendo:- Derechos de acceso- Tiempos de respuesta- Disponibilidad de extremo aextremo de componentes de

sistemas

Con:- Datos conocidos de aumentos

o descensos del volumen deusuarios

- Picos y valles de carga detrabajo

- Cualquier otro cambio que sepueda producir en el futuro

Deberían tener en cuenta:- Dependencias entre

componentes de sistemas yservicios

- Asignación de laresponsabilidad de invocar

planes de continuidad- Asignación de responsabilidades

sobre objetivos

Disponibles cuando no seaposible el acceso normal deoficina, junto con listas decontactos y la CMDB

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

Al menos una revisión al año

Los cambios se deben acordar

formalmente

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 todoslos documentos, junto conlos equipos necesarios parasu uso

Planes de negocio

SLAs

Evaluacionesde riesgos

Planes dedisponibilidad ycontinuidad del

servicio

Requisitos dedisponibilidad ycontinuidad del

servicio

Requisitos dedisponibilidad ycontinuidad del

servicio

Mantener lasuficiente capacidad

del servicio paracumplir los requisitos

Conservar y mantenertodos los documentos

y equipos decontinuidad delservicio en unlugar seguro

Garantizar que elpersonal comprende

su rol y tieneacceso a documentosde continuidad del

servicio

Desarrollar, mantenery revisar unaestrategia de

continuidad delservicio

Identificar requisitosde disponibilidad

y continuidaddel servicio

Desarrollar ymantener planes

de disponibilidad ycontinuidad del

servicio

Interfaces:


Gestión de cambios:- Presentar solicitudes de cambio- Evaluar el impacto de cualquier

cambio sobre el plan dedisponibilidad y continuidad del servicio

- Controlar todos los cambios

introducidos en la documentación dedisponibilidad y continuidad del servicio- Vincular la documentación con la

gestión de cambios

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

gestión de contratos

Proceso de gestión de la configuración:- Permitir el acceso a la CMDB cuando

no sea posible el acceso normal deoficina

- Programar auditorías deconfiguració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 delservicio antes de acordar losrequisitos del cliente


Presupuestos y contabilidad:- Presupuesto y contabilidad de todos

los componentes

Incluyen el regreso a lascondiciones normales de

operación

Figura 4�4�1 Procesos de gestión de la continuidad y disponibilidad del servicio






Los procesos de gestión de la disponibilidad y la continuidad del servicio tienen interaces conlos procesos de gestión de cambios y gestión de la conguración. Para garantizar la continuidaddel servicio es preciso que sea posible acceder a la CMDB cuando no sea posible el acceso normalde ocina. El proceso de gestión de cambios evalúa el impacto de cualquier cambio sobre elplan 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 interaces 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 conguración deberían estar documentadas(Figura 4.4.2).

Guía La gestión de la continuidad de los servicios de TI (ITSCM) orma parte de la gestión de lacontinuidad del negocio (BCM) y depende de la inormació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 ables 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:• Defnir 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 todala organización para que todos los aectados sean conscientes de la necesidad de ITSCM. Ladirección tiene que demostrar su compromiso.

• Defnir 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 deaseguramiento, normas de calidad como la serie ISO 9000, normas de gestión de la seguridadcomo BS 7799 y principios generales de política de negocio. También se identica la estructurade gestión apropiada, como responsabilidades asignadas y una estructura de procesos quepermita hacer rente a posibles desastres.

• Asignar recursos - La creación de un entorno de ITSCM puede exigir una inversión considerableen recursos y personal. También es necesario orecer ormación para que el personal pueda darsoporte a los requisitos y la estrategia.

• Establecer la organización del proyecto - Se recomienda emplear un método ormal degestión de proyectos, como PRINCE2TM, con el apoyo de sotware de planicación.

Antes de analizar los servicios de TI, es aconsejable identicar los motivos por los que la empresatiene que incluir la gestión de la continuidad de los servicios de TI en su gestión de la continuidaddel negocio, así como el impacto potencial de una interrupción grave de los servicios. En algunoscasos el negocio puede sobrevivir durante algún tiempo, por lo que lo más importante es restaurarlos servicios; en otros, el negocio no puede uncionar sin servicios de TI y debe hacer hincapiéen la prevención. La mayor parte de los negocios intentan encontrar un equilibrio entre ambosextremos.

Se realiza un análisis de los servicios de TI que son esenciales para el negocio (como sistemas deinormación, aplicaciones omáticas, aplicaciones de contabilidad y correo electrónico) y quedeben estar disponibles según los acuerdos de nivel de servicio. En el caso de algunos servicios






Plan de acción

Registros de pruebasde continuidad

Registros dedisponibilidad

Registros de faltasde conformidad

Registros deacciones correctivas

Al menos unavez al año

De acuerdo con lasnecesidades delnegocio

Incorporar losfallos de las pruebasen un plan de acción

Monitorizar yregistrar

la disponibilidad

Investigar faltas dedisponibilidad no

planificadas

Adoptar las acciones(correctivas)apropiadas

Identificar,documentar y revisarfaltas de conformidadcon los requisitos de

disponibilidad

Predecir ladisponibilidad futura

y posiblesproblemas

Adoptar accionespreventivas

Revisar los planes dedisponibilidad ycontinuidad del

servicio

Probar o volver aprobar los planes de

disponibilidad ycontinuidad del servicio

Registros de pruebasde continuidad

En caso de cambioimportante

Planes dedisponibilidad ycontinuidad delservicio

Registros dedisponibilidad

Requisitos deSLAs

Planes probados dedisponibilidad ycontinuidad delservicio

Realizar pruebasde continuidad y

registrar losresultados

Figura 4�4�2 Procesos de gestión de la continuidad y disponibilidad del servicio: Proceso dedisponibilidad






que no son esenciales, se puede llegar al acuerdo de proporcionar un servicio de emergencia concapacidad y disponibilidad limitadas. No obstante, los niveles de servicio durante la recuperaciónante desastres sólo se pueden modicar de común acuerdo con el cliente. Para servicios críticos sedebe 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. Lainormación de la gestión de la disponibilidad se utiliza para analizar hasta qué punto losrecursos de TI desempeñan una unción crítica para el soporte de los servicios de TI discutidos

Iniciar BCM

Análisis de impacto en el negocio

Estrategia de continuidad delos servicios de TI

Evaluación de riesgos

Implantar acuerdosde respaldo

Desarrollar planesde recuperación

Aseguramiento

Educación yconcienciación

Gestión decambios

Revisión yauditoría

Pruebas

Formación

Inicio

Requisitos yestrategia

Implantación

Gestión operativa

Fase 1

Fase 2

Fase 3

Fase 4

Implantar medidasde reducción de riesgos

Organización y

planificación de laimplantación

Desarrollar procedimientos

Pruebas iniciales

Figura 4�4�3 Modelo del proceso de ITSCM (según el modelo BCM de la OGC, actualmente centradoen ITSCM)






anteriormente. La gestión de la capacidad proporciona inormación sobre la capacidad necesaria.Es preciso determinar la interrupción máxima que pueden surir estos servicios, desde la pérdidainicial de servicio hasta su completa restauración. Esta inormación se usará posteriormente paraidenticar las opciones de recuperación para cada servicio.

Un análisis de riesgos puede ayudar a identicar los riesgos a los que está expuesto un negocio y orece a la dirección inormación muy importante sobre medidas de prevención. Mantener unplan de recuperación ante desastres puede resultar relativamente costoso, por lo que convieneempezar considerando la posibilidad de usar medidas de prevención. Una vez agotadas dichasmedidas, 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; esteejemplo está basado en el Método de Análisis y Gestión de Riesgos de la antigua Agencia Centralde Inormática y Telecomunicaciones (CCTA), la actual OGC.

El modelo consta de cuatro pasos:• En primer lugar hay que identicar los componentes de TI relevantes (activos), como edicios,

sistemas, datos, etc. Para que esta identicación sea ecaz es preciso documentar el propietarioy el propósito de cada componente.

• El siguiente paso consiste en analizar las amenazas a que están expuestos los activos y susdependencias, y estimar la probabilidad (alta, media o baja) de que se produzca un desastre. Porejemplo, un sistema de alimentación eléctrica poco able en una zona con muchas tormentasse puede considerar una amenaza.

• A continuación hay que identicar y clasicar la vulnerabilidad (alta, media o baja) de losactivos. Un pararrayos puede orecer cierto grado de protección contra las tormentas eléctricas,pero sigue existiendo la posibilidad de que la red y los sistemas inormáticos suran dañosgraves.

• Finalmente, se evalúan las amenazas y las vulnerabilidades en el contexto de los componentesde 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 laactividad del negocio y opciones de recuperación de TI. Se pueden adoptar medidas de prevención

Análisis deriesgos

Gestión deariesgos

Activos Amenazas Vulnerabilidades

Contramedidas(prevención y recuperación)

Riesgos

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






en unción de los resultados del análisis de riesgos, teniendo siempre en cuenta los costes delas medidas y los niveles de los riesgos que se intenta prevenir. Si existen riesgos que no sepueden evitar con medidas de prevención, es necesario eliminarlos mediante una planicaciónde la recuperación. Para garantizar la continuidad del negocio hay que contar con las siguientesopciones 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éono, correo y servicios de mensajería.• Archivos - Ficheros, documentos, sistemas basados en papel y materiales de reerencia.• 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 uncionar ecazmente 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 paraservicios que sean críticos para el negocio, ya que no habrá suciente personal con experienciaen el uso de sistemas tradicionales. Sin embargo, los sistemas basados en papel pueden ser unaopción viable para servicios de menor importancia.

• Acuerdos recíprocos - Esta opción se puede usar si dos organizaciones tienen hardware similary acuerdan orecerse una a otra sus instalaciones en caso de desastre. Para ello es necesarioque 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 lacapacidad reservada para este n no se utilice para otras cosas o se pueda liberar rápidamente.Esta opción no resulta tan atractiva en los actuales entornos inormáticos distribuidos, dondehay una mayor demanda de sistemas con alta disponibilidad y potencia de procesamientoindividual, como cajeros automáticos y banca on-line.

• Recuperación gradual (respaldo en río) - Esta opción puede ser adecuada para negociosque pueden operar durante algún tiempo (72 horas, por ejemplo) sin servicios de TI. Permitedisponer de una sala de ordenadores vacía en una instalación ja previamente acordada, o biende 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 dered y conexiones teleónicas. Esta opción de recuperación se puede contratar a un suministradorexterno. Es necesario establecer acuerdos independientes con suministradores para garantizarla rápida entrega de componentes de TI. La ventaja de este método es que las instalacionesestán siempre disponibles. Los benecios y los costes son distintos para instalaciones jas y portátiles.

• Recuperación intermedia (respaldo en templado) - Esta opción permite acceder a unentorno operativo similar, en el que los servicios pueden continuar con normalidad tras unbreve 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 optarpor esta variante del planteamiento, que consiste en que parte de la capacidad necesariaestá reservada en cada sistema. La gestión de la capacidad se encarga de monitorizar esta






capacidad de reserva (de modo similar a lo que ocurre en la opción de recuperación poracuerdos recíprocos).

– Externa: Un servicio comercial orecido a distintos clientes por organizaciones externas derecuperación. Los costes se dividen entre los clientes y dependen del hardware y el sotwarenecesarios 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 enrío. Este método resulta relativamente caro y es probable que las instalaciones se encuentrena cierta distancia.

– Móvil : Esta opción proporciona una caravana con toda la inraestructura necesarialista para su uso. La caravana unciona como sala de ordenadores y dispone de sistemasde control de ambiente, como aire acondicionado. Las conexiones de electricidad, datosy telecomunicaciones tienen que estar situadas en puntos especiales a cierta distancia deledicio. Entre las ventajas que orece esta opción guran los rápidos tiempos de respuesta y laproximidad a la sede del negocio. Esta opción sólo se puede utilizar con un número limitado

de plataormas hardware. Algunos de los principales suministradores de hardware oreceneste servicio con varias caravanas equipadas con conguraciones de hardware estándar. Lacaravana visita el negocio en los momentos acordados (una vez al año, por ejemplo) paraprobar los acuerdos de recuperación.

• Recuperación inmediata (arranque en caliente, respaldo en caliente) - Esta opción oreceuna 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 oincluso de los procesos de producción, todo ello en estrecha colaboración con la gestión de ladisponibilidad.

En la mayor parte de los casos es posible combinar distintas opciones. Por ejemplo, unacaravana con un centro inormático de operaciones (arranque en caliente móvil) puede oreceruna solución temporal hasta que se preparen instalaciones portátiles y se reciban los nuevosordenadores centrales (arranque en río móvil). La operación normal quedará restaurada cuandose haya vuelto a equipar el edicio 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 queimplantar la ITSCM y desarrollar en detalle los planes para las instalaciones de TI. Es necesariocrear una organización para implantar los procesos de ITSCM. Dicha organización puede incluirequipos 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 esposible 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 inormáticos






• Plan de telecomunicaciones (accesibilidad y enlaces)• Plan de seguridad (integridad de datos y redes)• Plan de personal• Planes administrativos y nancieros

Junto con la gestión de la disponibilidad, se adoptan medidas de prevención para reducir el impactode una incidencia. Estas medidas pueden incluir:• Uso de alimentación eléctrica de respaldo y SAIs• Sistemas tolerantes a allos• Almacenamiento en el exterior y sistemas RAID

El arranque también puede incluir acuerdos de respaldo que cubran personal, edicios y telecomunicaciones. Incluso durante el período de contingencia, es posible eectuar un arranquerestaurando 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 rmadospara el suministro de componentes en el momento especicado y al precio acordado. Cuandose produce el desastre, el suministrador puede procesar el pedido sin necesidad de tener quepreparar un presupuesto. Estos contratos latentes se tienen que actualizar todos los años para querefejen los nuevos precios y modelos. En la actualización hay que tener en cuenta las líneas basede gestión de la conguració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 ormal de cambios,identicando todos los procedimientos necesarios para su soporte. Se tienen que comunicar atodos aquéllos que participen en los planes o se vean aectados por ellos. En general, un plan derecuperación contempla cambios en la inraestructura y en los niveles de servicio acordados. Porejemplo, la migración a una nueva plataorma de gama media puede implicar que, en caso de sernecesaria la recuperación, no exista una unidad equivalente en las instalaciones de respaldo paraarranque externo en caliente. Por este motivo, la gestión de la conguración desempeña un rolmuy importante en la monitorización de las líneas base de conguración especicadas en el plande recuperación.

El plan de recuperación debe incluir todos los elementos relevantes para la restauración de lasactividades 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

eectúa un seguimiento de cambios en la inraestructura.• Lista de rutas - Si el plan está dividido en secciones, cada una de las cuales especica las

acciones que debe realizar un grupo especíco, la lista de rutas indica qué secciones se debenenviar a qué miembros del personal.• Inicio de recuperación - Describe cuándo y en qué condiciones se activa el plan.






• Clasifcació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 oalta), 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 gruposo á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 personalparticipan, y dónde se encuentra el centro de control.

– Inraestructura de TI : Elementos de hardware, de sotware y de telecomunicaciones que debeorecer el sistema de recuperación, procedimientos de recuperación y contratos latentes parala adquisición de nuevos componentes de TI.

– Personal : Personal necesario en las instalaciones de recuperación y, si las instalaciones estánlejos del negocio, servicios de transporte y alojamiento.

– Seguridad : Instrucciones de protección contra robos, incendios y explosiones en las sedescentral y remota, junto con inormación sobre instalaciones externas de almacenamiento

como cámaras y almacenes.– Centros de recuperación: Inormación sobre contratos, personal con unciones especícas,seguridad y transporte.

– Restauración: Procedimientos para restaurar la situación normal (en el edicio, 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 undamental que se desarrollen procedimientos ecaces que todo el mundopueda 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 aectados son unaspecto crítico de ITSCM. Las pruebas se deberían realizar en casos bien denidos y con objetivosy criterios de éxito claros. Se tienen que eectuar nuevas pruebas después de cambios importantesy al menos una vez al año. El departamento de TI es responsable de probar la ecacia de loselementos 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 omentaráel entendimiento mutuo y hará que resulte más ácil conseguir el soporte y el compromiso delnegocio.

Una ormación ecaz del personal de TI y otros departamentos, junto con la concienciación detodo el personal y la organización, son esenciales para cualquier proceso de continuidad de losservicios de TI. Es posible que el personal de TI tenga que ormar a otros miembros de los equiposde recuperación del negocio para que estén amiliarizados con el proceso y puedan proporcionarsoporte durante las operaciones de recuperación. La ormación y las pruebas deben incluir lasinstalaciones de contingencia, tanto internas como externas.

Los planes se deberían revisar y vericar periódicamente para comprobar que están actualizados.Esto aecta a todos los aspectos de ITSCM. En el área de TI, esta auditoría se debe realizar siempre






que se produzca un cambio signicativo en la inraestructura de TI, como la introducción denuevos 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 laestrategia de TI. Las organizaciones con cambios rápidos y recuentes pueden implantar un

programa periódico para vericar 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 unrol muy importante para mantener actualizados todos los planes de ITSCM y para analizar elimpacto de cualquier cambio sobre el plan de recuperación.

El aseguramiento consiste en la vericación de que el proceso (procedimientos y documentos) y susentregables tienen la calidad adecuada para satisacer las necesidades de negocio de la empresa.

Los actores críticos de éxito (CSFs) para la gestión de la continuidad de los servicios de TI son:

• Un proceso ecaz de gestión de la conguración• El soporte y compromiso de toda la organización• Herramientas ecaces y actualizadas• Formación especíca 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 deectos 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 inormes de gestión sobre su causa y eecto, así como sobre el resultado de la gestión. Cualquier punto débil que se detecte tendrá queser corregido con planes de mejora.

Los inormes de gestión del proceso ITSCM incluyen también inormes de evaluación de pruebasde planes de recuperación, que se utilizan para aseguramiento. El proceso inorma igualmentesobre el número de cambios introducidos en los planes de recuperación como resultado decambios signicativos en otros procesos. Es posible que se elaboren también inormes sobrenuevas amenazas.

Por lo que se reere a la gestión de la disponibilidad , se deben duplicar los elementos esencialessiempre que sea posible y usar sistemas de detección y corrección de allos para conseguir altosniveles de disponibilidad. Es recuente que, en caso de avería, se activen sistemas automáticos dereserva. Pese a ello, también se deben adoptar medidas organizativas que puede proporcionar lagestión de la disponibilidad.

La gestión de la disponibilidad puede comenzar tan pronto como el negocio haya denidoclaramente sus requisitos de disponibilidad para el servicio. Se trata de un proceso continuo que

sólo termina cuando se retira un servicio.






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, abilidad y capacidad de mantenimiento para los componentes

de TI en la inraestructura.

• Datos sobre allos que aecten a servicios o componentes, generalmente en orma de inormesy registros de incidencias y problemas.

• Datos de monitorización y conguració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

modicados.

• Tecnología necesaria para obtener la capacidad de recuperación necesaria en la inraestructura,con el n de reducir o eliminar el impacto de componentes deectuosos de la inraestructura.• Garantías de disponibilidad, abilidad y capacidad de mantenimiento de los componentes de

la inraestructura necesarios para el servicio de TI.• Inormes sobre los niveles alcanzados de disponibilidad, abilidad y capacidad de

mantenimiento.• Requisitos de monitorización de disponibilidad, abilidad y capacidad de mantenimiento.• Un plan de disponibilidad para la mejora proactiva de la inraestructura de TI.• Planes de acción y medidas adoptadas como actividades reactivas después de incumplimientos

del SLA.

Criterios de diseño de disponibilidad

y recuperación

Planes de acción

Medidas adoptadas después de

incumplimientos del SLA

Gestión de la

disponibilidad

Requisitos de disponibilidad

del negocio

Logros de nivel de servicio

Datos de monitorización

y configuración

Datos de incidencias

y problemas

Requisitos de disponibilidad,

fiabilidad y capacidad de

mantenimiento

Evaluación de impacto

en el negocio

Planes de mejora de la disponibilidad

Monitorización de la disponibilidad

Informes sobre niveles alcanzados dedisponibilidad, fiabilidad y capacidad

de mantenimiento

Objetivos específicos acordados de

disponibilidad, fiabilidad y capacidad

de mantenimiento

Evaluación de riesgos y capacidad de

recuperación de la infraestructura de TI

Figura 4�4�5 Entradas y salidas de la gestión de la disponibilidad (Fuente: OGC)






La gestión de la disponibilidad incluye una serie de actividades clave de planicación y monitorización:• Planifcació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 inormes

Antes de cerrar un SLA hay que determinar los requisitos de disponibilidad, incluyendo tantonuevos 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 identicar:• Funciones clave de negocio• Denición acordada de parada de los servicios de TI• Requisitos cuanticables de disponibilidad• Impacto cuanticable de paradas imprevistas en los servicios de TI sobre las unciones de

negocio• Horario comercial• Acuerdos sobre ventanas de mantenimiento

Denir lo antes posible y con claridad los requisitos de disponibilidad es undamental para evitarque surjan conusiones y dierencias de interpretación. Los requisitos del cliente se tienen quecomparar con lo que se puede orecer en la realidad. Si existen dierencias, hay que determinar elcorrespondiente impacto sobre el coste.

Las vulnerabilidades que aecten a los niveles de disponibilidad se deben identicar lo antesposible. De esta orma se evitarán costes excesivos de desarrollo, gastos imprevistos en asesposteriores, Puntos Únicos de Fallo (SPOF), cobros de costes adicionales por los suministradoresy retrasos en las entregas.

Un buen diseño, basado en niveles de disponibilidad apropiados, permitirá cerrar contratos demantenimiento ecaces con los suministradores. El proceso de diseño utiliza diversas técnicas,como Análisis de Impacto de Fallos de Componente (CFIA) para identicar SPOFs, Métodode Análisis y Gestión de Riesgos de la CCTA (CRAMM) o cualquier otra técnica de gestión deriesgos, así como técnicas de simulación.

Si no es posible alcanzar los niveles de disponibilidad acordados, la mejor opción consiste endeterminar 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 dierente y herramientas de desarrollo puedeacilitar el cumplimiento de los objetivos.






Si los requisitos son especialmente exigentes, se puede considerar la posibilidad de usar otratecnología de tolerancia a allos, otros procesos (gestión de incidencias, gestión de problemasy gestión de cambios) o recursos adicionales de Gestión del Servicio. Los recursos nancierosdisponibles determinan en gran medida las posibles opciones.

Es muy complicado conseguir una total disponibilidad sin interrupciones, por lo que hay queconsiderar períodos planicados de alta de disponibilidad. Dichos períodos se pueden usarpara iniciar acciones preventivas, como actualizaciones de hardware y sotware. Estas ventanaspermiten también la implantación de cambios.

Si se interrumpe un servicio de TI, es importante que la incidencia se resuelva de orma rápiday ecaz para recuperar los niveles acordados de disponibilidad. El diseño para recuperaciónincluye, por ejemplo, un proceso ecaz de gestión de incidencias con procedimientos apropiadosde escalado, comunicación, respaldo y recuperación.

La seguridad y la abilidad mantienen una relación muy estrecha. Un mal diseño de seguridadde la inormación puede aectar a la disponibilidad del servicio, mientras que un diseño ecaz deseguridad de la inormación hace que sea más ácil conseguir una alta disponibilidad. En la asede planicación hay que tener en cuenta las cuestiones de seguridad y analizar su impacto sobrela 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 inormes son dos actividades importantes de la gestión de la disponibilidad,puesto que orman la base para vericar acuerdos de servicio, resolver problemas y denirpropuestas de mejora. La alta de disponibilidad de los servicios se puede reducir tratando delimitar cada una de las ases del ciclo de vida extendido de la incidencia, como se ve en la Figura4.4.6:• Detección/registro - El tiempo desde que se produce una incidencia hasta que se detecta.• Diagnóstico - La ase siguiente, que dura hasta que se realiza un diagnóstico.• Reparación - La ase siguiente, necesaria para realizar reparaciones í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. ElTiempo Medio de Restauración del Servicio (MTRS) es el tiempo necesario para que unaunción (servicio, sistema o componente) vuelva a estar operativa después de un allo. Los análisisde la respuesta MTRS a distintos actores son útiles para mejorar el rendimiento y el diseño deservicios. Es posible reducir el tiempo MTRS gestionando cada uno de sus componentes.

Es importante que los inormes de disponibilidad estén redactados desde la perspectiva delcliente. Estos inormes orecen undamentalmente inormación sobre la disponibilidad delservicio para unciones esenciales de negocio, servicios de aplicaciones, y la disponibilidad de los






datos (perspectiva de negocio), en lugar de inormación sobre la disponibilidad de componentestécnicos de TI.

El plan de disponibilidad es uno de los productos más importantes de la gestión de ladisponibilidad. No se trata del plan de implantación de la gestión de la disponibilidad, sino deun plan a largo plazo que aecta a la disponibilidad durante un período de varios años. Debedescribir la situación actual y posteriormente se puede ampliar para que incluya actividades demejora de los servicios existentes y directrices, así como planes para nuevos servicios y directricespara 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ónde la capacidad, la gestión nanciera y el desarrollo de aplicaciones (directamente o a través dela gestión de cambios).

Para que sea eciente, la gestión de la disponibilidad tiene que usar diversas herramientas para lassiguientes actividades:• Determinar el tiempo de parada• Registrar inormación histórica• Generar inormes• Realizar análisis estadísticos• Realizar análisis de impactos

La gestión de la disponibilidad utiliza inormación procedente de los registros de gestión deincidencias, la CMDB y la base de datos de gestión de la capacidad. La inormación puede estaralmacenada 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 queacilitan la planicación, la mejora y la elaboración de inormes. 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 ecaz, que dena lasrelaciones entre servicios y recursos de producción, puede resultar muy útil para desarrollar estamatriz. La Figura 4.4.7 muestra un ejemplo de matriz CFIA. Los elementos de conguración

INCIDENCIA INCIDENCIA

Detectada

Tiempo de

detección

Tiempo de disponibilidad, tiempo entre fallos

Factor de fiabilidad

Tiempo entre incidencias del sistema

Tiempo de parada, tiempo de restauración del servicio

Factor de capacidad de mantenimiento

Tiempo de

registro

Tiempo de

diagnóstico

Tiempo de

reparación

Tiempo de

recuperación

Tiempo de

restauración

Registrada Diagnosticada Reparada Recuperada Restaurada

Figura 4�4�6 El ciclo de vida extendido de la incidencia






marcados con una “X” son elementos importantes de la inraestructura de TI (análisishorizontal). Los servicios que están recuentemente marcados con una “X” son complejos y muy sensibles a allos (análisis vertical). Este método también se puede aplicar a dependenciasde suministradores externos (CFIA avanzado).

• Análisis del Árbol de Fallos (FTA) - Es una técnica que permite identicar la cadena de

sucesos que conducen al allo de un servicio de TI. Para cada servicio se genera un árbolempleando 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 allo

del aire acondicionado.–

Sucesos disparadores : Sucesos que causan otros sucesos, como un apagado automático iniciadopor 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 orma

de identicar contramedidas justicables para proteger la condencialidad, la integridad y ladisponibilidad de la inraestructura de TI.

• Cálculos de disponibilidad - Las métricas descritas anteriormente se pueden usar paraalcanzar con el cliente acuerdos sobre disponibilidad de servicios. Estos acuerdos se incluyenen el acuerdo de nivel de servicio. El porcentaje de disponibilidad se calcula restando el tiempode parada real al tiempo de servicio acordado, dividiendo el resultado por el tiempo de servicioacordado y multiplicando por 100.

• Análisis de Interrupción de Servicios (SOA) - Es una técnica que permite identicar lascausas de allos para investigar la ecacia de la organización de TI y sus procesos, así como parapresentar e implantar propuestas de mejora. Tiene las siguientes características:– Amplio alcance: No se limita a la inraestructura, 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 guran un planteamiento más eciente, 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 sucientesoporte. TOP también permite combinar los conocimientos y experiencias de diseñadores y administradores de sistemas.






El aspecto más importante de este método es que se trata de un planteamiento ecaz, ecientee inormal que da resultados rápidamente.

Los actores críticos de éxito (CSFs) para la gestión de la disponibilidad son:• El negocio debe tener objetivos y requisitos de disponibilidad claramente denidos.• La gestión del nivel de servicio debe estar preparada para ormalizar acuerdos.• Ambas partes deben tener las mismas deniciones de disponibilidad y parada.

• Tanto el negocio como la organización de TI deben ser conscientes de los benecios que aportala gestión de la disponibilidad.

Elemento de Configuración:

Ordenador 1Ordenador 2Cable 1Cable 2Enchufe 1Enchufe 2Segmento de EthernetRouterEnlace WANRouterSegmentoNICServidorSoftware de sistema

AplicaciónBase de datos

Servicio A

B

B

X

XXXXXABB

BX

Servicio B

BBBBXXXXXXXABB

BX

X = Servicio no disponible en caso de falloA = Configuración a prueba de fallos

B = A prueba de fallos, con tiempo de transición" " = Ningún impacto

Figura 4�4�7 Matriz CFIA

Servicio interrumpido

OR

Inhibición ¿Fuera de las horas

de servicio?

Sistema interrumpido

Red interrumpida

AND

Ordenador

interrumpido

Aplicación

interrumpida

Línea normalinterrumpida

Línea de respaldointerrumpida

Figura 4�4�8 Análisis del Árbol de Fallos (Fuente: OGC)






Los siguientes indicadores clave del proceso (KPIs) muestran la ecacia y la eciencia de la gestiónde la disponibilidad:• Porcentaje de disponibilidad (tiempo de disponibilidad) de cada servicio o grupo de usuarios• Duración de paradas• Frecuencia de paradas

Los inormes de disponibilidad para el cliente ya han sido discutidos anteriormente. Las siguientesmé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 inraestructura(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 capacidadsuciente para cubrir la demanda acordada, actual y utura, de las necesidades del negocio delcliente.


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 identicación de pía/os, umbrales y costes para las actualizaciones del servicio.c) La evaluación de los eectos 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 identicar métodos, procedimientos y técnicas para la monitorización de lacapacidad del servicio, el ajuste del comportamiento y de las prestaciones del servicio y laprovisión de la adecuada capacidad.


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ícos y quedar documentadas.






El resultado de las variaciones en la carga de trabajo o en el entorno debería ser predecible; se deberíanrecoger y analizar datos actuales e históricos de utilización de componentes y recursos, al nivel adecuado,con el n de dar soporte al proceso. La gestión de la capacidad debería ser el punto ocal de todas las cuestiones de rendimiento y capacidad.

El proceso debería orecer soporte directo al desarrollo de servicios nuevos y a la modicació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 inraestructura y los requisitos esperados, con la recuencia suciente para tener en cuenta el ritmo de cambios de los servicios y de los volúmenes de servicio, la inormación de los inormes de gestión de cambios y del negocio del cliente.

Dicho inorme 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 denidos en el SLA.

Debería existir una buena comprensión de la inraestructura 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, ajustary orecer 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). ElCó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 aectará a las operaciones de copia derespaldo en cinta y hará que se tarde más tiempo en encontrar archivos guardados en la red. Unabuena gestión de la capacidad permitiría al proveedor de servicios, por ejemplo, detectar quelas 18 iniciativas estratégicas de TI para el año en curso harán que se quede obsoleta la actualsolución de copias de respaldo. Con esta inormación, el gestor de la capacidad puede distribuirel coste de la nueva solución de copias de respaldo entre las 18 iniciativas para que se conozca conexactitud el coste de cada una de ellas. Esta orma de actuar es proactiva. Si, por el contrario, noexiste gestión de la capacidad, la organización de TI no reaccionará hasta que se haya superadola ventana para copias de respaldo. En este caso el cliente verá a la organización de TI como unauente de gasto que “no hace más que pedir dinero”, y todo se deberá a que la organización no hatenido una actitud proactiva al denir 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 uturas del negocio, para lo cual obtiene inormación del cliente (por ejemplo, de planesestraté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






Producir y

mantener un plan

de capacidad

Tiene en cuenta las necesidades del negocioe incluye:– Requisitos de rendimiento y capacidad

presentes y previstos– Escalas de tiempos, umbrales y costes

identificados para actualizaciones deservicios

– Evaluación de los efectos de actualizacionesprevistas de servicios, solicitudes de cambios,nuevas tecnologías y técnicas sobre lacapacidad

– Impacto previsto de cambios externos– Datos y procesos que permitan realizar

análisis predictivos

Analizar datosde utilización

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

Dimensionar y

modelar servicios

Identificar

métodos,

procedimientos

y técnicas

Para monitorizar la capacidad del servicio,

ajustar el rendimiento del servicio y ofrecer

una capacidad adecuada

Traducir

prediccionesy estimaciones

en requisitos

Capturar datos

de utilización

Plan de

capacidad

Requisitos decapacidad

Datos sobre

utilización presente

y pasada

Datos sobre

utilización

presentey pasada

Interfaces:

Presupuestos y contabilidad:

- Presupuesto y contabilidad de todos los

componentes


- Recibir información

Mejora continua (Actuar):

- Sugerir mejoras para SIP

Figura 4�4�9 Gestión de la capacidad






servicio apropiados es necesario conocer el rendimiento y los picos de carga. Este subprocesotiene uertes vínculos con la gestión del nivel de servicio en lo que se reere a la denición y negociación de acuerdos de servicio.

• Gestión de la capacidad de los recursos - Su objetivo es determinar y comprender eluso de los componentes y la inraestructura de TI. Los recursos incluyen, por ejemplo, el

ancho de banda de red, la capacidad de procesamiento o la capacidad de disco. Es necesariodetectar problemas potenciales lo antes posible para poder gestionar estos recursos de maneraecaz. La organización también se tiene que mantener inormada de los avances técnicos. Lamonitorización activa de tendencias es otra actividad de este subproceso.

La Figura 4.4.10 ilustra algunas de las actividades esenciales en esta área.

El plan de capacidad describe los requisitos de capacidad presentes y uturos de la inraestructura deTI, así como los cambios previstos en la demanda de servicios de TI, sustitución de componentesobsoletos y avances técnicos. El plan de capacidad dene también los cambios necesarios parapoder orecer los niveles de servicio acordados en los SLAs a un coste razonable, junto con losrequisitos uturos de nivel de servicio. Debe incluir:• Expectativas de rendimiento• Puntos de actualización• Coste previsto de las actualizaciones de inraestructura (coste de capital, recurrente, operativo

y de personal)

Estas ciras se deben actualizar periódicamente en entornos dinámicos.

Figura 4�4�10 Actividades iterativas de la gestión de la capacidad (Fuente: OGC)

C D B

Monitorización

Análisis

Ajuste

Implantación(mediante gestión

de cambios)

Umbrales deutilización de

recursos

Informes deexcepciones

de SLM

Informes deexcepciones deutilización de

recursos

Umbrales de SLM






Hasta cierto punto, el plan de capacidad es la salida más importante de la gestión de la capacidad.Las salidas incluyen con recuencia un plan anual que está sincronizado con el presupuesto olos planes nancieros, así como planes trimestrales con detalles de los cambios previstos decapacidad. Todo ello da como resultado un conjunto coherente de planes en el que el nivel dedetalle aumenta a medida que se aproxima el horizonte de planicación.

El modelado es una potente herramienta de gestión de la capacidad que se emplea para prever elcomportamiento de la inraestructura. Las herramientas existentes para gestión de la capacidadvan 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 ambosextremos se encuentran diversas técnicas que son más precisas que una estimación y más baratasque un modelo piloto completo. Entre estas herramientas guran, 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 reerencia (evaluación comparativa) (la más precisa)• Sistema real

El dimensionamiento de aplicaciones se centra en los recursos necesarios para la operación deservicios nuevos o modicados (como servicios en desarrollo o en ase de mantenimiento), obien en los servicios que puede ser necesario adquirir si lo solicita el cliente. Estas predicciones

incluyen inormación sobre los niveles de rendimiento previstos, los recursos necesarios y sucoste.

Esta disciplina es especialmente importante durante las primeras ases de desarrollo del productoy en puntos clave de proyectos de desarrollo. Para la dirección es muy importante disponer deinormación clara sobre el hardware necesario, así como sobre otros recursos de TI y los costesprevistos en esta ase. También acilita la redacción de SLAs o requisitos de nivel de servicionuevos o modicados.

El dimensionamiento de aplicaciones puede exigir un esuerzo considerable en entornos grandeso complejos. En primer lugar, la gestión de la capacidad acuerda con los desarrolladores losrequisitos de nivel de servicio que deberá satisacer el servicio. Una vez el servicio ha llegado a laase de entrega y aceptación, se compara su rendimiento con los objetivos especícos de nivel deservicio para garantizar que se pueden cumplir sin problemas.

Una de las salidas del dimensionamiento de aplicaciones es el eecto de variaciones de la cargade trabajo. Esta inormación se puede usar para predecir cuál será la capacidad necesaria si, porejemplo, el número de usuarios aumenta un 25%. Otra característica de la carga de trabajo es laevolución de los requisitos de capacidad con el tiempo (picos por día/semana/año y crecimiento

uturo).






El objetivo de la monitorizaciónde componentes de la inraestructura es garantizar el cumplimientode los niveles de servicio acordados. Entre los recursos que hay que monitorizar guran, porejemplo, 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 uturo y detectar posibles “cuellos de botella”, lo que puede llevar a iniciar proyectosde aumento de la eciencia o a la adquisición de nuevos componentes de TI. Para analizaractividades es preciso tener un conocimiento completo de la inraestructura en su conjunto,de los procesos de negocio y de las relaciones entre los elementos de gestión de la capacidad delnegocio, el servicio y los recursos.

Elajuste optimiza sistemas para la carga de trabajo real o prevista, a partir de datos de monitorizacióndebidamente interpretados y analizados.

El objetivo de la implantación es introducir capacidad nueva o modicada. Si para ello se necesitaun cambio, la implantación incluye también el proceso de gestión de cambios.

El objetivo de la gestión de la demanda es infuir en la demanda de capacidad. Por ejemplo, siun usuario ejecuta durante el día un inorme de SQL mal escrito (bloqueando la base de datosy generando una cantidad desmesurada de tráco en la red), el gestor de la capacidad puederecomendar la creación de un trabajo para ejecutar el inorme durante la noche, de manera que elusuario lo tenga sobre su mesa por la mañana. La gestión de la demanda proporciona inormaciónimportante para la elaboración, monitorización y posible ajuste del plan de capacidad y losSLAs.

La gestión de la demanda también puede incluir el uso de cobro dierencial para infuir en elcomportamiento 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 recopilary actualizar inormación técnica, inormación de negocio y cualquier otra inormación quepueda ser relevante para la gestión de la capacidad. Es posible que no se pueda almacenar todala inormación de capacidad en una sola base de datos ísica. Cada administrador de redes osistemas inormáticos puede elegir el planteamiento que considere más conveniente. En muchoscasos, la CDB es en realidad un conjunto de bases de datos que contienen toda la inormaciónnecesaria sobre capacidad (Figura 4.4.11).

La calidad del proceso de gestión de la capacidad depende de los siguientes actores críticos de éxito:• Previsiones y expectativas de negocio precisas• Comprensión de la estrategia de TI y precisión de su planicación• Conocimiento de tecnologías presentes y uturas• Cooperación con otros procesos• Capacidad para demostrar un buen control de costes






El éxito de la gestión de la capacidad viene determinado por los siguientes indicadores clave delrendimiento:• Predictibilidad de la demanda del cliente - Identicació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

jados 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 satisacer en todo momento la demanda del cliente, y grado deimportancia que se concede al proceso de gestión de la capacidad.

Los inormes de gestión proporcionados por el proceso de gestión de la capacidad incluyen, poruna parte, inormació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 inormes de excepciones sobre aspectos tales como:Discrepancias entre la capacidad real y planicada• 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 inormes de gestión de la planicación y el rendimiento de la capacidad tienen que estar adisposición de todas las partes interesadas (negocio, aplicación y organización de TI).

Previsiones denegocio

Datos deservicios

Datostécnicos

Datosfinancieros

Datos deutilización

CDB

Informes degestión

Planes decapacidad

Informesatécnicos

Figura 4�4�11 Fuentes de inormación para la CDB






4.4.3 Gestión de la seguridad de la inormación (6.6)

Objetivo: Gestionar la seguridad de la inormación de manera ecaz para todas las actividadesdel servicio.


NOTA: ISO/IEC 17799 Tecnologías de la Inormación. Código de prácticas para la gestiónde la seguridad de la inormación, proporciona una guía para la gestión de la seguridad de lainormación.

La dirección, con la autoridad apropiada, debe aprobar una política de seguridad de lainormación, que debe comunicarse a todo el personal implicado y, cuando sea adecuado, alos clientes.

Unos controles adecuados de seguridad deben ayudar a:a) Implantar los requisitos de la política de seguridad de la inormació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 losriesgos a los que están asociados los controles, la manera de utilizarlos y el mantenimiento delos 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 inormacióny a los servicios, deben estar basados en un acuerdo ormal que dena todos los requisitos deseguridad necesarios.

Las incidencias de seguridad se deben comunicar y registrar tan pronto como sea posiblede acuerdo a los procedimientos de gestión de incidencias.Se deben poner en marchaprocedimientos para asegurar que todas las incidencias de seguridad son investigadas, y que setoman medidas al respecto.

Se deben poner en marcha mecanismos para poder cuanticar y monitorizar los tipos,volúmenes e impacto de las incidencias y el mal uncionamiento de la seguridad. Las accionesde mejora identicadas durante este proceso se deben registrar y servir como inormación deentrada al plan de mejora del servicio.


Generalidades

La seguridad de la inormación es el resultado de un sistema de políticas y procedimientos diseñados para identicar, controlar y proteger la inormación y cualquier equipamiento empleado junto con el almacenamiento, transmisión y procesamiento de dicha inormación.






El personal del proveedor del servicio con roles de especialista en seguridad de la inormación deberíaestar amiliarizado con la Norma ISO/IEC 17799. Tecnologías de la inormación. Técnicas de seguridad. Código de prácticas para la gestión de la seguridad de la inormación.

Identicación y clasicación de los activos de inormación

El proveedor del servicio debería:a) Mantener un inventario de los activos de inormación (por ejemplo, ordenadores, sistemas de

comunicación, documentos y otra inormación) que son necesarios para la provisión del servicio.b) Clasicar 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

conguraciones).d) Ayudar a entender en qué podría impactar uno de los servicios gestionados.e) Proveer de inormación para las decisiones reerentes a los tipos de controles a establecer.

Riesgos para los activos de inormación

Los riesgos para los activos de inormación se deberían evaluar en unción de :a) Su naturaleza (por ejemplo: uncionamiento deectuoso del sotware, errores de operación, allos de

comunicación).b) Probabilidad.c) Impacto potencial para el negocio.d) Experiencias pasadas.

Seguridad y disponibilidad de la inormación Al evaluar los riesgos, se debería prestar atención a los siguientes puntos :a) Revelación de inormación sensible a partes no autorizadas.b) Inormación inexacta, incompleta o inválida (por ejemplo: inormación raudulenta).c) Inormación que quede inservible para su uso (por ejemplo: debido a un corte de energía

eléctrica).d) Daño í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 inormación, las necesidades para satisacer los requisitos especícos de los clientes respecto a la seguridad (por ejemplo: niveles de disponibilidad) y los requisitos legales o regulatorios que apliquen.






Controles Además de otros controles que puedan ser justicables 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 inormación:a) La alta dirección debería denir la política de seguridad de la inormación, comunicarla a su

personal y a sus clientes y asegurarse de que se implanta ecazmente.b) Los roles y las responsabilidades para la gestión de la seguridad de la inormación se deberían denir

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 ecacia de la Política de Seguridad de laInormación.

d) El personal que ejerza un rol signicativo en seguridad debería recibir ormación en seguridad de la inormación.

e) Todo el personal debe ser concienciado acerca de la política de seguridad de la inormación.

) 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 eectiva de los controles.h) Se debería hacer un inorme de las incidencias de seguridad de la inormació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 inormación a la dirección encuanto a:a) Ecacia de la política de seguridad de la inormación.

b) Las tendencias que aparezcan en las incidencias de seguridad de la inormación.c) Dar entrada de inormación a un plan de mejora del servicio.d) Tener bajo control el acceso a la inormación, los activos y los sistemas.

La gestión de la seguridad de la inormación debería estar documentada de una manera able.

El Código de buenas prácticas para la gestión de la seguridad de la inormación ISO/IEC 17799orece una guía sobre el proceso en la Subsección 6.6 de la norma para la provisión de serviciosde TI de calidad. Como consecuencia, la Parte 2 de ISO 20000 especica que el personal delproveedor de servicios con roles especializados en la seguridad de la inormación debe estaramiliarizado con ISO/IEC 17799.

ISO 20000 requiere explícitamente una política de seguridad de la inormación, así comocontroles de seguridad documentados, registros de incidencias de seguridad y registros de accionesde mejora. Los procedimientos que se exigen explícitamente para la gestión de la seguridad dela inormación son procedimientos para investigar incidencias de seguridad y emprender lasacciones pertinentes (Figuras 4.4.12 y 4.4.13).

La gestión de la seguridad de la inormación tiene interaces con los procesos de gestión de

cambios, gestión de incidencias, gestión de la conguración y mejora continua.






Incluyen:– Implantación de los requisitos

de la política de seguridadde la información

– Gestión de los riesgosasociados con el acceso alservicio o a los sistemas

Describen:

– Los riesgos asociados a loscontroles

– La forma de operación ymantenimiento de loscontroles

Política de seguridadde la información

Requisitos deseguridad en SLA

Llegar a un acuerdosobre el acceso de

organizacionesexternas

Definir la políticade seguridad de

la información

Documentar el ISMS

Definir y asignar rolesy responsabilidades

Designar al propietarioresponsable de

proteger los activosde información

Aprobar la políticade seguridad de la

información

Comunicar la políticaal personal afectado

y a los clientes

Documentar controlesde seguridad

Controles de seguridad

Acuerdos sobreacceso externo

ISMS



asignados


Interfaces:

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

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

Presupuestos y contabilidad:– Presupuesto y contabilidad de todos los componentes

Informes del servicio:– Recibir 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

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

Mejora continua (Actuar):– Sugerir mejoras para SIP– Proporcionar información de gestión sobre tendencias en incidencias de

seguridad de la información

Figura 4�4�12 Gestión de la seguridad de la inormación






Registros deevaluación de

riesgos de seguridad

Maintain riskassessment

(during changes)

Incluyen el impacto sobre serviciosgestionados

Los riesgos para activos de informaciónse 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 expertaAnalizar registrospara informara la direcció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

Monitorizar ymantener la eficacia

de la política deseguridad de la

información

A intervalosacordados

Concienciar alpersonal e implantar

eficazmentela política de seguridad

de la información

Adquirir conocimientosde ISO/IEC 17799

El personal de seguridad debeestar familiarizado conISO/IEC 17799

Formar al personalcon roles deseguridad

significativos

Mantener uninventario de activos

de información

Clasificar activos porsu importancia y

nivel de protección

Efectuar unaevaluación

de riesgos deseguridad


Figura 4�4�13 Gestión de la seguridad de la inormación (cont�)






Guía Las organizaciones y sus sistemas de inormación no dejan de cambiar, lo que obliga a revisarcontinuamente las actividades de gestión de la seguridad para garantizar su ecacia. La gestión dela seguridad es un ciclo innito con ases sucesivas de Planicar, Hacer, Vericar y Actuar, comomuestra la Figura 4.4.14.

Los requisitos del cliente aparecen en la parte superior derecha como entradas del proceso. Lasección sobre seguridad del acuerdo de nivel de servicio (SLA) dene estos requisitos en términosde los servicios de seguridad y del nivel de seguridad exigido. El proveedor de servicios comunicaestos acuerdos a la organización mediante un plan de seguridad que dene normas de seguridado acuerdos de nivel operativo. Posteriormente se implanta este plan, se evalúa la implantación y seprocede a actualizar el plan y su implantación. La gestión del nivel de servicio inorma al clientesobre estas actividades. De esta orma, el cliente y el proveedor de servicios orman un procesocíclico completo: el cliente puede modicar los requisitos en unción de los inormes, mientrasque el proveedor de servicios puede ajustar el plan o su implementación según estas observaciones

o bien tratar de modicar los acuerdos denidos en el SLA.

El proveedor de servicios de TI implantalos requisitos de seguridad del SLA

PLANIFICAR:

Acuerdos de Nivel de Servicio

Contratos de Soporte

Acuerdos de Nivel Operativo

Políticas internas

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

CONTROLAR:

¡Organizar!

Creación del marco de gestión

Asignación de responsabilidades

EVALUAR:

Auditorías internas

Auditorías externas

Autoevaluaciones

Incidencias de seguridad

MANTENER:

Aprendizaje

Mejora

Planificación

Implantación

El cliente define los requisitos de negocio

Informes

Según SLA

Capítulo de seguridad/Acuerdo de Nivel de Servicio

Acuerdo entre cliente y proveedor

Figura 4�4�14 El proceso de gestión de la seguridad (Fuente: OGC)






La actividad de control que aparece en el centro de la Figura 4.4.14 es el primer subproceso dela gestión de la seguridad y está relacionada con la organización y la gestión del proceso. Estoincluye el marco de gestión de la seguridad de la inormación, que describe los subprocesos:• Denició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 inormes proporcionados al cliente a través de la gestión delnivel de servicio.

Esta actividad dene los subprocesos, las unciones de seguridad y los roles y responsabilidades.También describe la estructura organizativa, los acuerdos de presentación de inormes y la líneade control (quién enseña a quién, quién hace qué, cómo se inorma de la implantación). Las

siguientes medidas descritas en el Código de buenas prácticas de ISO/IEC 17799 se implantancon esta actividad:• Política

– Desarrollo e implantación de políticas, conexiones con otras políticas– Objetivos, principios generales y signicación– Descripción de los subprocesos– Asignación de unciones 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 inormació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 inormación– Coordinación de la seguridad de la inormació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 inormación– Principios de seguridad para acceso de terceros– Seguridad de la inormación en contratos con terceros

El subproceso de planicación incluye la denición de la sección sobre seguridad en el SLA encolaboración con la gestión del nivel de servicio, así como las actividades relacionadas con laseguridad en los contratos de soporte. Los objetivos denidos en términos generales en el SLA sedetallan ahora para especicarlos en orma de un acuerdo de nivel operativo. Este OLA se puedeconsiderar como el plan de seguridad para una unidad organizativa del proveedor de servicios

o como un plan de seguridad especíco (por ejemplo, para cada plataorma de TI, aplicación y red). El subproceso de planicación también recibe inormación procedente de los principios dela política del proveedor de servicios (del subproceso de control), como “cada usuario debe tener






una identicación exclusiva” o “todos los usuarios recibirán en todo momento un nivel básicode seguridad”.

Los acuerdos de nivel operativo para seguridad de la inormación (planes de seguridad especícos)se elaboran e implantan siguiendo los procedimientos normales. Esto signica que las actividades

que se deban ejecutar en otros procesos se tendrán que coordinar con esos procesos. La gestión decambios utiliza inormación procedente de la gestión de la seguridad para introducir los cambiosnecesarios en la inraestructura de TI. El subproceso de planicación se discute con la gestióndel nivel de servicio para denir, actualizar y cumplir la sección sobre seguridad en el SLA. ElSLA tiene que denir los requisitos de seguridad, utilizando términos medibles siempre quesea posible. La sección sobre seguridad en el acuerdo debe garantizar que se puede vericar elcumplimiento de todas las normas y los requisitos del cliente sobre seguridad.

El objetivo del subproceso de implantación es implantar todas las medidas especicadas en los

planes. Para acilitar este subproceso se puede utilizar la siguiente lista de comprobación.• Clasifcación y gestión de recursos de TI– Inormación para el mantenimiento de los CIs en la CMDB– Clasicació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 condencialidad 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– Inormació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 (rewalls, servicios de conexión teleónica,puentes y routers)






– Implantación de medidas para la identicación y autenticación de sistemas inormá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 denir y presentar una RFC para el proceso de gestión de cambios.

Existen tres ormas de evaluación:• Autoevaluaciones - Implantadas undamentalmente 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 dierencia de lo que ocurre en las autoevaluaciones, las auditorías no pueden ser realizadas porel mismo personal que participa en los otros subprocesos. De esta orma se garantiza la separaciónde responsabilidades. Un departamento interno de auditoría se puede encargar de realizar lasauditorías.

Las evaluaciones también pueden tener lugar en respuesta a incidencias de seguridad. Lasactividades principales son:• Vericar la conormidad con la política de seguridad y la implantación de los planes de

seguridad.• Realizar auditorías de seguridad en sistemas de TI.

• Identicar 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 lainraestructura de TI, la organización y los procesos de negocio. El mantenimiento de seguridadincluye el mantenimiento de la sección sobre seguridad en el SLA, así como el mantenimiento delos planes detallados de seguridad (acuerdos de nivel operativo).

El mantenimiento se eectúa en unción de los resultados del subproceso de evaluación y de unavaloración de los cambios en los riesgos. Estas propuestas se pueden introducir en el subprocesode planicación o bien en el mantenimiento del SLA en su conjunto. El resultado en amboscasos puede ser la inclusión de actividades en el plan anual de seguridad. Todos los cambios estánsometidos al proceso normal de gestión de cambios.

Los inormes no son un subproceso, sino una salida de los otros subprocesos. Se elaboran paraproporcionar inormación acerca del rendimiento conseguido en materia de seguridad y parainormar a los clientes sobre asuntos de seguridad. La presentación de estos inormes suele seruno de los requisitos del acuerdo con el cliente.






Los siguientes son algunos ejemplos de inormes programados y de los sucesos que puedenincluir:• El subproceso de planifcación

– Inorma sobre el grado de conormidad con el SLA y los KPIs acordados para seguridad.– Inorma sobre los contratos de soporte y cualquier problema asociado con ellos.

– Inorma sobre acuerdos de nivel operativo (planes de seguridad internos) y los principios deseguridad del propio proveedor (en la línea base, por ejemplo).

– Inorma sobre planes anuales de seguridad y planes de acción.• El subproceso de implantación

– Inorma sobre el estado de implantación del proceso de seguridad de la inormación.– Presenta una lista de incidencias de seguridad y de respuestas a esas incidencias, incluyendo

opcionalmente una comparación con el período del inorme anterior.– Identica tendencias en incidencias.– Inorma sobre el estado del programa de concienciación.

•

El subproceso de evaluación– Inorma sobre el rendimiento de los subprocesos.– Inorma sobre el resultado de auditorías, revisiones y evaluaciones internas.– Inorma sobre avisos e identicación de nuevas amenazas.

Para inormar sobre incidencias de seguridad denidas en el SLA, el proveedor de servicios debetener un canal directo de comunicación con un representante del cliente (el responsable deseguridad de la inormación corporativa, por ejemplo) a través del gestor de nivel de servicio, elgestor de incidencias o el gestor de seguridad. También se tiene que denir un procedimiento decomunicación en circunstancias especiales.

Salvo en circunstancias especiales, los inormes se transmiten a través de la gestión del nivel deservicio.

Los actores 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 sediscutieron en la Sección 4.3.1 para la gestión del nivel de servicio, ya que se reeren a los asuntosde seguridad cubiertos por el SLA.

4.5 Soporte de servicios de TI

Las especifcaciones ISO 20000-1 dicen:La gestión de incidencias y la gestión de problemas son procesos separados, aunque ambosestán uertemente relacionados.







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 urgenciase 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 planicació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 esuerzo/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 undamental 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 satisactoriamente un cambiocorrectivo 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 inormación sobre las áreas de negocio aectadas por los problemas.

Se debería almacenar y mantener en la base de datos de conocimiento, la inormación sobre las soluciones provisionales, su aplicabilidad y su eectividad.

Las prioridades de la gestión de incidencias y problemas dependen del impacto y la urgenciade un problema o una incidencia. El impacto depende de la escala del daño. La urgencia porresolver el problema o la incidencia depende del tiempo que transcurre desde la detección hastael 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 enunción de la prioridad y de otros actores objetivos de negocio que se mencionan en el Código

de buenas prácticas.






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 oresponder a peticiones de servicio.


Se deben registrar todas las incidencias.

Se deben adoptar procedimientos para gestionar el impacto de las incidencias.

Los procedimientos deben denir el registro, la priorización, el impacto en el negocio,la clasicación, la actualización, el escalado, la resolución y el cierre ormal de todas lasincidencias.

Se debe mantener inormado al cliente del progreso de la incidencia sobre la que hayainormado o de su petición de servicio, y se le debe advertir por adelantado sobre si sus nivelesde 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 inormaciónrelevante como, por ejemplo errores conocidos, resoluciones de problemas y la base de datosde gestión de la conguración.Los incidentes graves se deben clasicar y gestionar de acuerdo con un proceso.


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 aecten, o que

eventualmente pudieran, aectar 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 clasicació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 vericación y el cierre de las incidencias. ) El contacto de primera nivel con los clientes.

g) El escalado.

Se puede inormar sobre incidentes mediante llamadas teleónicas, buzón de voz, visitas, cartas, axes omensajes de correo electrónico, o bien los avisos pueden ser registrados directamente por los clientes que






tengan acceso al sistema de registro de incidencias, o se pueden registrar automáticamente mediante unsotware de supervisión automática.

Todas las incidencias se deberían registrar de modo que la inormació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 aectadas. 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 actualizadaque contenga inormación sobre técnicos especialistas, incidencias anteriores, problemas relacionados y errores conocidos, soluciones provisionales y listas de comprobación, que ayuden a restablecer el servicioen la empresa.

Siempre que sea posible, se debería proporcionar al cliente los medios necesarios para continuar consus actividades empresariales, aunque sea con un servicio degradado (por ejemplo inhabilitando una unción deectuosa).

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 cuandose produzcan incidencias similares.

Una incidencia sólo debería cerrarse denitivamente cuando el usuario que haya noticado dichaincidencia haya podido conrmar que la incidencia se ha resuello y el servicio ha sido restablecido.

Incidencias graves Se debería denir claramente qué constituye un incidente grave y quién está capacitado para llevar acabo cambios en el uncionamiento habitual del proceso de incidencias/problemas.

Todas las incidencias graves deberían tener en todo momento un gestor responsable claramente denido.

La designación como responsable de una incidencia grave debería proporcionar los niveles de autoridad individual adecuados para la unción de coordinar y controlar todos los aspectos de la resolución.Esto debería incluir la responsabilidad del escalado y una comunicación ecaz entre todas las áreas implicadas en la resolución y con los clientes que se vean aectados 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á inormación al plan de mejora del servicio.






Incluyen peticiones de servicio(que se consideran un tipo deincidencia) e incidencias graves

La prioridad establece los objetivosespecíficos de resolución.La prioridad debe estar basada enel impacto y la urgencia.El impacto indica el daño en elnegocio del cliente.La urgencia indica la necesidad deuna resolución rápida en elnegocio del cliente.

La programación se basa enprioridades, recursos disponibles,tiempo y coste

Bien en el primer nivel, bien

por derivación.

Cuando la persona que comunicóla incidencia haya confirmado laresolución de la incidencia y elrestablecimiento del servicio

En caso de incidencia grave:incluir una revisión que sirvade entrada a un SIP

Incluye:- Definición de incidencia grave- Asignación de autoridad paradesviar el proceso normal

- Designar a un gestor responsablede la incidencia grave

Como errores conocidos,

resoluciones de problemasy CMDB

Como especialistas técnicos,incidencias anteriores, erroresconocidos y problemas relacionados,soluciones provisionales y listas decomprobación

Registrosde incidencias



Registros deincidencias

actualizados


actualizados

Registrarincidencias

Cerrar incidencias

Resolverincidencias

Clasificarincidencias

Definir el impacto

de las incidenciasen el negocio

Priorizarincidencias

Recibir llamadas

Verificarla resolución

Preparar eltratamiento de

incidencias graves

Dar acceso a

informaciónrelevante

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óny gestión de problemas:

- Intercambiar la información relevante


Gestión de la seguridad de la información:

- El proceso de gestión de incidencias cubre incidenciasde seguridad

Figura 4�5�1 Gestión de incidencias






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, clasicación, actualización, escalado, resolución y cierreormal. Los registros de incidencias son la salida que debe producir el registro de incidencias(Figuras 4.5.1 y 4.5.2).

La gestión de incidencias tiene interaces con la gestión de problemas y con la gestión de laconguración, en ambos casos para proporcionar inormación sobre errores conocidos, resolucionesde problemas, contenidos de la CMDB, especialistas técnicos, soluciones provisionales y listas decomprobación. Las dos interaces deben estar documentadas.

Guía La Figura 4.5.3 muestra los pasos que componen el proceso:• Aceptación y registro de la incidencia• Clasicació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

Actualizarregistros deincidencias


actualizadosCon detalles de solucionesprovisionales

Efectuar unseguimiento de

las incidencias entodo su ciclo de vida

Revisarincidencias graves


Escalarincidencias

Informar al clienteacerca del progresode las incidencias

comunicadas

Si no es posible mantener losniveles de servicio y se haacordado una acción:- Advertir al cliente por anticipado


Figura 4�5�2 Gestión de incidencias (cont�)






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 detectadaspor:• Un usuario que comunica la incidencia al centro de atención al usuario.• Un sistema que detecta un evento en una aplicación o inraestructura 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.

no

sí

sí

no

no

sí

¿Resuelta?

Aceptación y registrode la incidencia

Clasificación y

soporte inicial

ComparaciónProcedimiento de

petición de servicio

¿Coinciden?

Petición de servicio

Investigacióny diagnóstico

Resolución yrecuperación

Cierre dela incidencia

Segui

mientoymonitorizacióndeprogreso;

escaladosiesnecesario

Figura 4�5�3 Proceso de gestión de incidencias






El registro consta de los siguientes pasos:• Asignar a la incidencia un número de reerencia - En la mayor parte de los casos, el sistema

asigna automáticamente un número de reerencia exclusivo a la incidencia; este número sesuele comunicar al usuario para que le sirva de reerencia en comunicaciones posteriores.

• Registrar inormación básica de diagnóstico - Fecha y hora, síntomas, usuario, persona

encargada del problema, ubicación e inormación del servicio o hardware aectado.• Añadir inormación sobre la incidencia - Más inormación sobre la incidencia (procedente

de un guión o entrevista, por ejemplo) o de la CMDB (generalmente basada en la relacióndenida en la base de datos).

• Emitir alertas - Si una incidencia tiene un impacto elevado (como la avería de un servidorimportante), 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 inormación de la incidencia,

o bien registrarla por separado, y vincularla al registro principal de dicha incidencia.

Es conveniente que las opciones de clasicació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 unasola lista diversos aspectos de clasicación, como el tipo, el grupo de soporte y el origen. Estopuede generar conusió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, porejemplo, 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 uncionalidad - 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, inormación, consejo o documentación. Se puede incluir en unprocedimiento independiente o tratarla de la misma orma que otras incidencias.

A continuación se asigna la prioridad para que los grupos de soporte puedan prestar a la incidenciala 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 sesoluciona?).

Prioridad = Urgencia * Impacto

Para identicar los servicios relacionados con la incidencia se puede utilizar una lista que hagareerencia al SLA correspondiente. Esta lista incluirá también los tiempos de escalado para cadaservicio de acuerdo con el SLA.

Teniendo en cuenta la prioridad y el SLA, se inormará a los usuarios aectados sobre el tiempomáximo estimado para resolver la incidencia (duración del ciclo) y sobre cuándo aparecerá nuevainormación sobre el progreso. Estas cronologías quedan registradas en el sistema.






El estado de la incidencia indica su posición en el fujo de trabajo. Algunos de los estados posiblesson:• Nueva• Aceptada• Planicada

• Asignada• Activa• Suspendida• Resuelta• Cerrada

Una vez terminada la clasicación, se comprueba si anteriormente ha habido una incidenciasimilar y, en caso armativo, si existe alguna solución provisional o permanente. Esta actividadse 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 competenciatécnica todas las incidencias para las que no exista una solución inmediata o que queden uerade su ámbito de competencia. Este grupo de soporte investiga y resuelve la incidencia, o bienla traslada a otro grupo de soporte. Esta actividad de traslado, que recibe también el nombre deescalado uncional, suele estar basada en la categoría asignada a la incidencia. En la deniciónde categorías también se puede tener en cuenta la estructura de los grupos de soporte. Un buentraslado de incidencias es undamental para que la gestión de incidencias sea ecaz, por lo que “elnú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ónen 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 seencuentra ninguna solución.

Una vez implantada la solución, el grupo de soporte devuelve la incidencia al centro de atención alusuario, que a su vez se pone en contacto con la persona que comunicó la incidencia para vericarla resolución. La incidencia se puede cerrar si se conrma que ha sido resuelta correctamente;de lo contrario, se tiene que reiniciar el proceso en el punto apropiado. A continuación hay queactualizar el registro con la categoría y prioridad nal de la incidencia, los servicios/usuarios/clientes aectados y los componentes (CIs) identicados como causa de la incidencia.

Como propietario de todas las incidencias, el centro de atención al usuario es responsable demonitorizar el progreso y de inormar al usuario acerca del estado de la incidencia. Los comentariosdel usuario pueden resultar útiles después de un cambio de estado, como cuando se vuelve a dartraslado a la incidencia o se produce un cambio en la duración prevista del ciclo.

El control del proceso se basa en los inormes dirigidos a los distintos grupos. El gestor deincidencias se encarga de elaborar estos inormes, así como de preparar una lista de distribucióny un calendario de inormes. Los inormes pueden ser muy detallados y estar personalizados paralas siguientes unciones:






• Gestor de incidencias - Inorme para:– Identicar eslabones perdidos en el proceso– Identicar confictos con SLAs– Eectuar un seguimiento del proceso– Identicar tendencias

• Gestión de líneas de TI - Inorme dirigido a la dirección del grupo de soporte para acilitar elcontrol en cada una de las áreas del grupo de soporte. Requiere inormació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 - Inorme sobre la calidad de los servicios prestados; tambiénpuede ir dirigido a clientes.

• Gestores de otros procesos de Gestión del Servicio - Los inormes dirigidos a los gestoresde otros procesos tendrán un carácter eminentemente inormativo; la gestión de incidenciaspuede proporcionar la siguiente inormació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 guran los siguientes:• Número total de incidencias• Tiempo medio de resolución (por prioridad)• Porcentaje de incidencias resueltas según los objetivos especícos 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 clasicació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 eectos negativos sobre el negocio de las interrupciones del servicio,mediante la identicación y el análisis proactivo de la causa de los incidentes, y la gestión delos problemas para su cierre.







Se deben registrar todos los problemas identicados.

Se deben adoptar procedimientos para identicar, minimizar y evitar el impacto de las

incidencias y de los problemas. Estos procedimientos deben denir el registro, la clasicació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, porejemplo 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 lacausa subyacente de problemas. Para que resulte ecaz la resolución de problemas, se debesupervisar, revisar y elaborar inormes sobre ella.

El equipo de gestión de problemas debe ser responsable de garantizar que esté disponible,para la gestión de incidencias, la inormación actualizada sobre errores conocidos y problemascorregidos.

Las acciones de mejora identicadas durante este proceso se deben registrar e incluir en elplan de mejora del servicio.


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 clasicar las incidencias para ayudar a determinar las causas de los problemas. Laclasicación puede hacer reerencia a los problemas y cambios existentes.

NOTA: Cuando se registren incidencias por primera vez, su categorización se verá infuenciada por otros actores que incluyen el servicio, el área de negocio aectada y los síntomas que se presenten.

Errores conocidos Cuando la investigación de la gestión de problemas haya identicado la causa del origen de un incidente y un método para resolver las incidencias, el problema se debería clasicar como un error conocido.

Se deberían registrar todos los errores conocidos tomando como reerencia los servicios real o potencialmente aectados además del elemento de conguración que se sospeche que causa el error encuestión.

La inormació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.






Un error conocido no se debería cerrar hasta que se haya resuelto satisactoriamente.

NOTA: El cliente o el proveedor del servicio pueden decidir que la resolución resulta demasiado carao que no aporta benecio al negocio. En este caso, esto debería quedar claramente documentado. Noobstante, 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 identicado y se haya tomado una decisión para resolver el error, laresolución se debería conducir a través del proceso de gestión de cambios.

ComunicaciónLa inormación sobre soluciones provisionales, arreglos permanentes o el progreso de los problemas se

debería comunicar a las partes aectadas o puede requerirse para dar soporte a los servicios aectados.Seguimiento y escaladoSe 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 identicación de incidencias que incumplan los objetivos del nivel de servicio.c) La distribución de inormació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 denició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 acilitar 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 inormado 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 justique. La nalidad 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.






c) Revisiones de la dirección para determinar y analizar tendencias y para proporcionar inormacióna otros procesos como, por ejemplo, el de educación y ormación del cliente.

Temas a tratar en las revisiones Las revisiones deberían incluir inormación de :

a) Tendencias, por ejemplo, problemas e incidencias recurrentes, errores conocidos, etc.b) Problemas recurrentes de una determinada clasicación de componente o de ubicación.c) Deciencias causadas por la subcontratación, la ormación o la documentación.d) Falta de comormidad con la legislación, por ejemplo, conorme a normas, políticas y leyes.e) Errores conocidos en las entregas planicadas. ) 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 inormació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 ladocumentació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 reerencias a la inormación que resulte de ayuda para el análisis como,

por ejemplo:a) Activos y conguraciónb) Gestión de cambios c) Un error conocido y divulgado, inormación sobre las soluciones provisionales de los proveedores d) Inormación histórica sobre problemas similares

La prevención de problemas debería abarcar desde la prevención de incidencias individuales, tales comolas dicultades reiteradas para utilizar una determinada unció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 unde con la gestión de la disponibilidad.

La prevención de problemas también incluye el suministro de inormación a los clientes para evitar que tengan que pedir ayuda en el uturo, por ejemplo, para prevenir incidencias causadas por la altade conocimiento o la alta de ormación del usuario.

Al igual que en el caso de la gestión de incidencias, ISO 20000 exige explícitamente procedimientosdetallados para la gestión de problemas. Estos procedimientos incluyen en parte las mismasactividades que el proceso de gestión de incidencias: registro, clasicación, actualización,

escalado, resolución y cierre. La gestión de incidencias incluye además los pasos de priorización y denición del impacto en el negocio.






Registrar los recursos empleados,las acciones emprendidas, loscambios de personas responsablesy los resultados de revisiones

También puede incluir una mejoraen la formación de clientes

Monitorizar, revisar y comunicarla eficacia de la resolución

La prioridad establece losobjetivos específicos de resolución.La prioridad debe estar basada enel impacto y la urgencia.El impacto indica el daño en el

negocio del cliente.La urgencia indica la necesidad deuna resolución rápida en el negociodel cliente.

La programación se basa enprioridades, recursos disponibles,tiempo y coste..

Incluye:- Servicios que están o puedenestar afectados

- CI cuyo fallo puede habercausado el error

Incluyen:- Campo de aplicación- Eficacia

Junto con soluciones provisionales

Con definición de puntosde escalado

Por ejemplo, con análisis detendencias en el volumen y tipo

de incidencias

A partir de la identificación deincidencias que incumplen losobjetivos específicos de nivel deservicio

Debe comprobar que:- Los detalles de la resoluciónestán registrados

- Se ha asignado a la causa unacategoría- El cliente y el personal desoporte conocen la resolución

- El cliente está conforme conla resolución

- Se informa al cliente si no seencuentra una resolucón


Otras fuentes deinformación, como

activos yconfiguraciones,errores conocidos

y solucionesprovisionales

Registrarproblemas

Identificarproblemas (demodo reactivo

y proactivo)

Clasificarproblemas

Actualizarregistros deproblemas

Escalar problemas

Cerrar problemas

Resolverproblemas

Priorizarproblemas

Investigar eidentificar

la causa y clasificarel problema como

error conocido

Determinarla solución

Desarrollar ymantenersoluciones

provisionales

Adoptarprocedimientos

Registrosde problemas




RFC

Registros deproblemas

actualizados

Registros deproblemasactualizados

Registros deproblemas

actualizados

Error conocido

Solucionesprovisionales

Interfaces:

Cliente:- Información sobre las áreas de

negocio afectadas


Gestión de cambios:- Presentar peticiones de cambio


Presupuestos y contabilidad:- Presupuesto y contabilidad

de todos los componentes

Gestión de la seguridad de lainformación:

- Intercambiar información degestión sobre tendencias enincidencias de seguridad de lainformación

- Gestión de problemas deberíainvestigar las incidencias deseguridad

Gestión de incidencias:

- Intercambiar la informaciónrelevante

Figura 4�5�4 Gestión de problemas para identicar, minimizar o evitar el impacto de incidencias yproblemas






Los documentos que se requieren explícitamente en el proceso de gestión de problemas sonregistros de problemas y registros de acciones identicadas de mejora (Figuras 4.5.4 y 4.5.5).

La gestión de problemas tiene interaces con el proceso de gestión de cambios para gestionar loscambios necesarios. El proceso de gestión de incidencias y todos los demás procesos de Gestióndel Servicio obtienen inormación actualizada del proceso de gestión de problemas. La otrainteraz de la gestión de problemas es con la mejora continua. Todas estas interaces deben estardocumentadas.

Guía Las entradas de la gestión de problemas son:• Detalles de incidencias, incluyendo soluciones provisionales.• Detalles de conguración procedentes de la base de datos de gestión de la conguración

(CMDB).• Detalles acilitados por los suministradores acerca de los productos usados en la inraestructura,incluyendo detalles técnicos y los errores conocidos en dichos productos.

Registros dela base de

conocimientoJunto con solucionesprovisionales

A los clientes y elpersonal afectado

Incluyendo:

- Tendencias- Deficiencias- No conformidades- Errores conocidos enentregas planificadas

- Compromiso del personal- Reaparición de problemasresueltos


Informar sobre

errores conocidos atodos los procesosITSM cuando se

introduce un servicioen el entorno de

producción y registraren la base deconocimiento

Comunicarinformación sobre

solucionesprovisionales,

solucionespermanentes o

progresode problemas

Efectuar unseguimiento del

progreso deproblemas

Revisar el problemasi es necesario

Figura 4�5�5 Gestión de problemas (cont�)






• El catálogo de servicios y acuerdos de nivel de servicio.• Detalles sobre la inraestructura y su comportamiento, como registros de capacidad, medidas

de rendimiento e inormes 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 deproblemas

• Solicitudes de cambio (RFCs)• Registros actualizados de problemas• Registros de problemas cerrados una vez eliminada la causa raíz• Inormació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 inormación

El objetivo básico del control de problemas es identicar la causa subyacente de los problemasy encontrar soluciones provisionales, convirtiendo así los problemas en errores conocidos. LaFigura 4.5.6 ilustra el control de problemas.

En principio, cualquier incidencia de causa desconocida se debe considerar un problema. Sinembargo, en la práctica sólo vale la pena hacerlo si la incidencia se repite o se puede repetir, o biensi se trata de una sola incidencia importante.

(Control de errores)

S e g u i m

i e n t o y m o n i t o r i z a c i ó n d e p r o b l e m

a s

Identificación yregistro deproblemas

Investigación ydiagnóstico de

problemas

RFC, resoluciónde problemas

y cierre

Clasificaciónde problemas

Figura 4�5�6 Control de problemas según ITIL V2 (Fuente: OGC)






La actividad de “identicar problemas” se suele encargar a analistas de problemas, aunque tambiénpueden 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 esnecesario incluir inormación sobre el usuario. No obstante, las incidencias asociadas con el

problema se tienen que identicar y relacionar con el problema.

Los siguientes son ejemplos de situaciones en las que se identican 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 inraestructura identica 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 lacapacidad).

• 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 esuerzoadicional se puede expresar en términos de coste y benecios para la organización (por ejemplo,identicando las áreas que necesitan más soporte y determinando su grado de importancia paralos servicios suministrados).

Esta evaluación se puede basar en la severidad (el “actor 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 aectados• El tiempo y coste necesarios para resolver las incidencias

Los problemas se pueden clasicar por área (categoría). La identicación señala los CIs de nivelmás bajo que aectan al problema. La clasicación va acompañada de un análisis de impacto,que determina la gravedad del problema y su eecto 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 unción de la clasicación del problema y se reservatiempo para su resolución. La clasicación incluye:• Categoría - Identica el dominio relevante; por ejemplo, hardware o sotware.• Impacto - Eecto 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 clasicació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 urgenciay el impacto de un problema, mientras que la aparición de nuevas incidencias puede aumentarla urgencia y el impacto.






La actividad de investigación y diagnóstico se repite varias veces, acercándose cada vez más a laresolució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 especialistasde un grupo de soporte pueden colaborar en el análisis y diagnóstico del problema.

Los problemas no se deben exclusivamente a hardware y sotware, sino que también puedentener su causa en un error de documentación, humano o de procedimiento, como la entregade una versión incorrecta de sotware. 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 componentesde la inraestructura.

Una vez se conoce la causa y se ha identicado el CI (o combinación de CIs) responsable delproblema, es posible establecer un vínculo entre el CI y la incidencia. A continuación se asigna alproblema 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 suresolución, siempre que sea posible y apropiado. Para ello se presenta una RFC a la gestión decambios y se evalúan los cambios en una Revisión Post-Implantación (PIR). El control de errorespuede exigir la participación de muchos departamentos y cubre los entornos de producción y desarrollo (Figura 4.5.7).

La gestión de problemas tiene que determinar la solución de negocio más apropiada a cadaproblema, teniendo en cuenta los acuerdos de nivel de servicio, los costes y benecios, y los

(Control de problemas)

S e g u i m i e n t o y m o n i t o r i z a c i ó n d e e r r o r e s

Identificación yregistro de errores

Registrar laresoluciónde errores

RFC

Evaluaciónde errores

Cerrar elerror y losproblemasasociados

Cambio implantadocon éxito

Figura 4�5�7 Control de errores según ITIL V2 (Fuente: OGC)






niveles de impacto y urgencia del error conocido. Para ello hay que determinar si se necesitauna solución temporal, una solución permanente, o ambos tipos de solución. También se puedetomar la decisión de no resolver un problema; por ejemplo, cuando no existe justicación denegocio para hacerlo. Sea cual sea la decisión adoptada, la inormación correspondiente al errorconocido tiene que estar registrada y a disposición de la gestión de incidencias.

Una vez identicada una solución apropiada, se dispondrá de suciente inormación parapresentar una RFC. La gestión de cambios se encarga de implantar la resolución a través de laRFC.

Después de la implantación, los cambios necesarios para resolver problemas, errores conocidosy 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 puedeproceder 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” enla base de datos de problemas. De ello se inorma a la gestión de incidencias para que se puedancerrar también las incidencias asociadas con el problema. En el caso de problemas graves, se debeeectuar 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 allo

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 laresolución haya sido vericada por el cliente); si no se han cerrado las incidencias asociadas, esnecesario volver a abrir el problema.

La actividad de seguimiento y monitorización monitoriza el progreso de problemas y erroresconocidos durante todas las ases de su ciclo de vida. Estas acciones orman parte tanto delcontrol 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 inorma periódicamente a la gestión de problemassobre el progreso de las RFCs presentadas.

En general, la gestión proactiva de problemas se ocupa de la calidad de los servicios y la inraestructura.Para evitar problemas, se tiene que concentrar en el análisis de tendencias y en la identicaciónde posibles incidencias antes de que se produzcan, para lo cual examina componentes que sondébiles o están sobrecargados. Si hay varios dominios, se intenta evitar que los allos que seproducen en un dominio aparezcan también en los demás. También se identican e investigan lospuntos débiles en los componentes de la inraestructura. Una CMDB bien diseñada e implantada

puede ayudar a realizar un análisis de escenarios (“Qué ocurre si …”) para detectar posiblespuntos de allo y actuar de orma proactiva para mitigar los riesgos.






Durante el proceso se transmite inormación sobre soluciones provisionales y temporales a lagestión de incidencias para que el centro de atención al usuario pueda inormar lo antes posiblea los usuarios aectados. La CMDB y el SLA pueden dar inormación sobre qué es lo que se debecomunicar y a quién.

Los actores críticos de éxito para la gestión de problemas son:• Una buena denición del marco del proceso y del conjunto de objetivos, interaces y recursos

del proceso.• Un conjunto de procedimientos completo y bien documentado.• Buena inormación de gestión de incidencias y una cooperación ecaz 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 allos.

Los parámetros del proceso también se deben comunicar para operaciones de gestión interna, conel n de evaluar y controlar la eciencia de la gestión de problemas. Los inormes de gestión deproblemas pueden ser muy completos y cubren las siguientes cuestiones:• Inormes 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 identicar componentes aectados por allos recuentes y para determinar si

los suministradores cumplen sus obligaciones contractuales.• Efcacia 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 deRFCs presentadas e implantadas con éxito.

• Relación entre gestión de problemas reactiva y proactiva - Un aumento de las accionesproactivas, en lugar de reaccionar a las incidencias, indica un aumento en la madurez delproceso.

• Calidad de los servicios en desarrollo - Inorma de nuevos servicios y componentes y de suserrores conocidos.

• Estado y planes de acción para problemas abiertos - Resumen de lo que se ha hecho hastael momento y de lo que se va a hacer a continuación para reducir el impacto de problemas,incluyendo las RFCs planicadas y el tiempo y los recursos necesarios.

• Propuestas de mejora de la gestión de problemas - Si la inormación de los actores anterioresindica que el proceso de gestión de problemas no satisace los objetivos estipulados en el plande calidad del servicio, se pueden presentar propuestas para mejorar el proceso e identicarrecursos adicionales.





Entre los aspirantes a obtener un certicado de gestión de la calidad del servicio guranproveedores de servicios internos y externos, que desempeñan un rol o tienen interés en lagestión de la calidad del servicio aunque la organización no esté (aún) certicada. El certicadode Fundamentos de ISO/IEC 20000 para Gestión del Servicio está orientado undamentalmentea esta amplia audiencia. Por otra parte, los clientes que tengan previsto exigir a sus proveedoresde servicios que obtengan un certicado ISO/IEC 20000 podrán tener un mejor conocimientode lo que pueden esperar de sus proveedores de servicios.

Los requisitos para el examen son:1. Comprender las defniciones 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 certicación.c. El candidato comprende el concepto de ISO 20000.

3. Especifcaciones de calidad para Gestión de Servicios de TI:a. El candidato comprende las especicaciones de calidad para la gestión y mejora de procesos

ITSM.b. El candidato comprende las especicaciones de calidad para el control de servicios de TI.c. El candidato comprende las especicaciones de calidad para la alineación entre el negocio

y las Tecnologías de la Inormación.d. El candidato comprende las especicaciones de calidad para la provisión de servicios de

TI.e. El candidato comprende las especicaciones de calidad para el soporte de servicios de TI.

Capítulo 5

El examen de Fundamentosde ISO/IEC 20000






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 Inormació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 PrerrequisitosNo hay ningún criterio ormal o prerrequisito que deban cumplir los candidatos que se deseenpresentar al examen de Fundamentos de ISO 20000. No obstante, es conveniente que loscandidatos asistan a un curso de ormación acreditado (que puede ser un curso de autoestudio en

Web). Se recomienda a los candidatos que deseen asistir a un curso de ormación que elijan unode los proveedores de cursos acreditados.

Tampoco hay ningún criterio estricto para quienes deseen asistir a un curso de ormaciónacreditado, aunque es necesario tener algún conocimiento de la Gestión de Servicios de TI y serecomienda haber obtenido el Certicado de Fundamentos de Gestión de Servicios de TI antesde asistir a un curso de ormació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 sinutilizar ningún libro. Para cada pregunta se orecen cuatro posibles respuestas, entre las que elcandidato tendrá que elegir la correcta. Se concede un punto por cada respuesta correcta. Laspreguntas de examen se eligen entre un banco de preguntas que se actualiza periódicamente. Laspreguntas 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 cursosacreditados reciben un examen de ejemplo y una plantilla de calicación. Los exámenes que serealicen en ordenador o a través de la Web se calican automáticamente y el candidato conoce elresultado de orma inmediata. En el caso de exámenes en papel, se envían a la entidad examinadorao a un agente examinador para su calicación.

Para aprobar es preciso obtener 26 puntos o más. Los candidatos que suspendan pueden repetir elexamen. 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 deormació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 entidadexaminadora o a un agente examinador.





El examen de Fundamentos de ISO/IEC 20000 221

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

5.3 ReclamacionesLos estudiantes que deseen presentar una reclamación deberán hacerlo ante el correspondienteproveedor de cursos, entidad examinadora o agente examinador. Las entidades y agentesexaminadores disponen de un procedimiento de resolución de reclamaciones (DRP) que cubresu 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 20000Hay un par de cosas que se puede hacer para aumentar sus posibilidades de éxito en el examen delCerticado de Fundamentos de ISO/IEC 20000. La primera de ellas, por supuesto, es tomárseloen serio.

5.4.1 Preparación para el examen• Asista a un curso de ormación acreditado. Aprender los conceptos básicos de la gestión de

la calidad del servicio es más divertido y ecaz si se hace entre un grupo de proesionales conexperiencias 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 ormación. Como norma general, serecomienda dedicar unas 20 horas al estudio en solitario.

• Discuta con sus amigos y compañeros de trabajo lo que aprenda en el curso de ormación y en los libros. Compartir experiencias sobre mejores prácticas le ayudará a entender mejor losprincipios de la gestión de la calidad del servicio.

• Utilice el examen de ejemplo más actualizado que le proporcione su entidad examinadora paraprepararse 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 caé 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 identicación (pasaporte o DNI).

5.4.3 Consejos prácticos durante el examen

• Lea atentamente todas las preguntas.• Responda primero las preguntas sencillas.






• 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ásprecisión a la pregunta planteada, aunque no refeje todo lo que haya aprendido sobre el temaen cuestión.

• No complique la pregunta tratando de encontrar contraejemplos a la respuesta que le parecemá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 diícil. ¡Usted puede!

5.5 Preguntas de ejemplo

Las siguientes preguntas de ejemplo son una buena muestra del tipo de preguntas que encontrará enlos 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 entidadesexaminadoras o a un proveedor de ormación acreditado. Los exámenes más recientes de lasentidades examinadoras refejan los últimos cambios y mejoras que se han introducido en losexámenes, o bien contienen una versión con respuestas incluidas, con comentarios y explicacionesde cada una de las opciones.

Pregunta 1

Un planteamiento para desarrollar e implantar un sistema de gestión de la calidad consta devarios 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. Denir métodos para medir la ecacia y la eciencia 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.






Pregunta 2Los 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 lasobligaciones.

B. Que se inorma 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 recuente entre los suministradores y el negocio para resolver

cuestiones que no resultan satisactorias.

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 aectados. No obstante, orma parte del procesode gestión de incidencias y es responsabilidad de un gestor designado para la incidencia grave, por lo que queda uera 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 20000-1: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 modicación de la inormación de conguración y los registros de

cambios.

A. Incorrecto. Esto orma parte de los procedimientos de gestión de cambios.B. Incorrecto. Esto orma parte de los procedimientos de gestión de la seguridad de la inormación.C. Incorrecto. Esto orma 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 modicación de inormación sobre conguraciones y registros de

cambios.






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 20000D. 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 Microsot para la Gestión del Servicio.

Pregunta 5

El planteamiento Planicar-Hacer-Vericar-Actuar (PDCA) se puede aplicar a todos los procesosde ISO/IEC 20000.

¿Qué es lo que cubre la ase Actuar de esta metodología?

A. La denición de los objetivos y procesos necesarios para obtener resultados que respondan alos 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 orma continua el rendimiento de los

procesos.

A. Incorrecto. Esta acción se realiza durante la ase Planicar de la metodología.B. Incorrecto. Esta acción se realiza durante la ase Hacer de la metodología.C. Incorrecto. Estas acciones se realizan durante la ase Vericar.D. Correcto. Esta acción se realiza durante la ase 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 ase 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á enocado a la mejora continua, y no a la orientación de clientes

especícamente.C. Incorrecto. El modelo se puede usar durante la ase de diseño, pero está enocado a la mejora

continua durante todas las ases.D. Incorrecto. De esto se encargan los modelos de costes que orman parte del presupuesto y lacontabilidad.






Pregunta 7¿Cuál es la denición de disponibilidad?

A. Un registro que contiene los detalles de aquellos elementos de conguración (CIs) a los queaecta un cambio autorizado y sobre cómo les aecta.

B. Una instantánea del estado de un servicio o de un elemento de conguración (CI) individualen un momento concreto.

C. Cualquier suceso que no sea parte del uncionamiento normal de un servicio y que cause, opueda 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 unción requerida en uninstante determinado o a lo largo de un período de tiempo denido.

A. Incorrecto. Esta denición corresponde a un registro de cambio.B. Incorrecto. Esta denición corresponde a una línea base.

C. Incorrecto. Esta denición corresponde a una incidencia.D. Correcto. Esta denición corresponde a la disponibilidad.

Pregunta 8Los servicios nuevos o modicados tienen que ser aceptados antes de su implantación en elentorno de producción.

¿Qué es lo que hay que hacer después de la implantación de un servicio nuevo o modicado?

A. Se lleva a cabo una Revisión Post-Implantación (PIR) para comparar los resultados reales con

los planicados.B. Se tiene que denir el método de conexión entre proyectos que crean o modican servicios.C. No hay que hacer nada más; el servicio nuevo o modicado “sigue su curso” y se gestiona

como un servicio normal.D. Se tiene que denir la manera en la que se va a revertir o corregir el cambio en caso de no tener

éxito.

A. Correcto. Esta cláusula orma parte de la norma.B. Incorrecto. Esto orma parte de la planicación de la Gestión del Servicio (Planicar) y no es

relevante después de la implantación de servicios nuevos o modicados.C. Incorrecto. La norma especica que se debe realizar una PIR. No se contempla la opción de no hacer

nada.D. Incorrecto. Esta cláusula orma parte de la gestión de cambios y tiene que estar cumplida o denida

antes de la implantación.

Pregunta 9¿Qué es Six Sigma®?

A. Un instrumento de calidad para medir deectos 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.






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 ecaz 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 ecaz no es el objetivo de los procesos de gestión de la disponibilidad y la continuidad del servicio; está más relacionado con los inormes 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 unsuministrador y un cliente, no entre un suministrador y un proveedor.

Pregunta 11El personal debe contar con la ormación y la experiencia necesarias para alcanzar un nivel decompetencia apropiado.

¿Cuál de las siguientes es una de las mejores prácticas sobre competencia?

A. Se deben mantener registros apropiados de educación, ormación, conocimientos y experiencia.

B. Debe haber al menos dos empleados que hayan recibido la ormación adecuada para cadarol.

C. Los empleados deben tener al menos una licenciatura relevante.D. Todo el personal debe haber recibido ormació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 aecta 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 ormación adecuada para el rol.D. Incorrecto. Esta ormación es especíca para seguridad, pero no es una de las mejores prácticas sobre

competencia en general.






Pregunta 12¿A qué tipo de organizaciones benecia ISO/IEC 20000?

A. Organizaciones que deseen conrmar 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 certicar sus servicios.D. Distribuidores de herramientas que necesiten especicar los procesos del proveedor de

servicios.

A. Incorrecto. ITIL® va mucho más allá que ISO/IEC 20000, por lo que no será posible conrmar 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 certica es el sistema de gestión, no los servicios.D. Incorrecto. Los proveedores de servicios especican sus procesos basándose en ISO/IEC 20000 y en

ITIL

®

.

Pregunta 13¿Qué inormación se debe registrar como línea base antes de implantar un plan de mejora delservicio?

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, perotambién puede haber otra inormación.

B. Incorrecto. Esta medida puede ser necesaria para aumentar el número de empleados, pero también puede haber otra inormación.

C. Correcto. La norma recomienda que la calidad y los niveles de servicio se recojan como una líneabase 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 inormación.

Pregunta 14¿Dónde se dene 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 inorme del servicio.

A. Incorrecto. El marco de trabajo de TI proporciona una estructura para la Gestión del Servicio, pero

no dene el servicio propiamente dicho.B. Incorrecto. El OLA dene un acuerdo de soporte subordinado al servicio principal para el cliente.C. Correcto. El servicio para el cliente se dene en el catálogo de servicios o en el SLA.






D. Incorrecto. El inorme del servicio contiene datos sobre el rendimiento del servicio, pero no dene el servicio.

Pregunta 15¿Por qué es importante que los proveedores de servicios aciliten documentos y registros?

A. Porque es uno de los requisitos (evidencia) para cumplir ISO/IEC 20000.B. Para poder registrar e identicar de orma única todos los elementos de conguración (CIs) en

la base de datos de gestión de la conguración (CMDB).C. Para garantizar la ecacia de la planicació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 orma parte de la gestión de la conguració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 orma parte de la competencia, la concienciación y la ormació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 orma parte del proceso y no existe ningunarecomendació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 acilitar la gestión de problemas inormación actualizada sobre erroresconocidos y problemas corregidos?

A. A todos los procesos de ISO/IEC.B. A la gestión de la disponibilidad.






C. A la gestión de la conguración.D. A la gestión de incidencias.

A. Incorrecto. Según la norma, la gestión de problemas tiene que acilitar esta inormación al procesode 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 acilitar esta inormación al procesode gestión de incidencias.

C. Incorrecto. Según la norma, la gestión de problemas tiene que acilitar esta inormación al procesode gestión de incidencias.

D. Correcto. La gestión de problemas tiene que acilitar esta inormació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 dene las condiciones de la certicación del sistema de gestión.B. Porque detalla todas las empresas que han sido certicadas.C. Porque detalla todos los servicios que han sido certicados.D. Porque identica los procesos que han quedado uera del alcance.

A. Correcto. La declaración de alcance demuestra que el sistema de gestión ha superado las pruebas necesarias para obtener la certicación.

B. Incorrecto. El certicado sólo se puede conceder a una empresa (entidad legal única).C. Incorrecto. Lo que se certica 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 19Los objetivos especícos 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 nose debe tener en cuenta?

A. Los conocimientos disponibles.B. Los confictos entre requisitos de recursos.C. El esuerzo o coste requerido por el método de resolución.D. El número de incidencias detectadas previamente para un elemento de conguració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 identicar

problemas.






Pregunta 20¿Cuál es la orma correcta de introducir un cambio en un contrato debido a una revisión generalde 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 denir un proceso para realizar revisiones generales de un contrato. Todos los cambios introducidos en el contrato estarán sometidos al procesode gestión de cambios.





ACP Accredited Course Provider ANSI American National Standards Institute AS Australian StandardBPM Business Process ModelingBS British StandardBSC Balanced ScorecardBSI British Standard Institution

CAB Change Advisory BoardCAP Corrective Action PlanCCTA Central Computer and Telecommunications Agency CEO Chie Executive OcerCFIA Component Failure Impact AnalysisCIO Chie Inormation OcerCI Conguration ItemCISM Certied Inormation Security ManagerCMDB Conguration Management DatabaseCMM Capability Maturity ModelCMMI Capability Maturity Model IntegrationCobiT® Control Objectives or ITCPD Continual Proessional DevelopmentCRAMM CCTA Risk Analysis and Management MethodCSI Continual Service ImprovementCSF Critical Success FactorCSS Customer Satisaction SurveysDML Denitive Media Library DSL Denitive Sotware Library

EA European co-operation or AccreditationEFQM European Foundation or Quality ManagementENAC Entidad Nacional de Acreditación (España)

Lista de abreviaturas






ESP External Service ProviderFISM Fellow o the Institute o Service ManagementFSC Forward Schedule o ChangeFTA Fault Tree AnalysisIAF International Accreditation Forum, Inc.

IRCA International Register o Certicated AuditorsIS Inormation SystemIEC International Electrotechnical CommissionISACA Inormation Systems Audit and Control AssociationISO International Organization or StandardizationISM Institute o Service ManagementISMS Inormation Security Management SystemIT Inormation Technology ITIL Inormation Technology Inrastructure Library

ITOCO Input-Throughput-Output-Control-OutcomeITSM IT Service ManagementITSCM IT service continuity managementitSMF IT Service Management ForumITT Invitation to Tender JAB The Japan Accreditation Board For Conormity Assessment JQA Japanese Quality AssociationKPI Key Perormance IndicatorMI Management InormationMISM Member o the Institute o Service Management

MLA Multilateral Recognition ArrangementMOF Microsot Operations Framework MTRS Mean Time to Restore ServiceNAB National Accreditation Body OGC Oce o Government CommerceOLA Operational Level AgreementOSS Operational Support SystemPDCA Plan-Do-Check-ActPIR Post Implementation Review PRINCE2TM Projects In Controlled EnvironmentsQMS Quality Management SystemRAID Risks, Assumptions, Issues, DependenciesRCB Registered Certication Body RC Request or ChangeRP Request or ProposalROI Return on InvestmentRvA Raad voor Accreditatie (Comité de Acreditación, Holanda)SANSInstitute SysAdmin, Audit, Network, Security Institute

SEI Sotware Engineering InstituteSIP Service Improvement ProgramSLA Service Level Agreement





Lista de abreviaturas 233

SLM Service Level ManagementSOA Service Outage AnalysisSOX Sarbanes-Oxley ActSPOF Single Points O FailureSQM Service Quality Management

TGA Asociación Alemana de AcreditaciónTOP Technical Observation PostTQM Total Quality ManagementUC Underpinning ContractUKAS The United Kingdom Accreditation Service










Reerencias 235

Reerencias

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

shing.• 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-to-end service. London: BSI.• Dugmore, J., & S. Lacy (2006). BIP 0034 : 2006. Achieving ISO/IEC 20000. Finance or 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 SourcingManagement. 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 - Inormation technology - Service management -Part 2: Code o practice. ISO.

• ISO JTC 1/SC 7 (2005). ISO/IEC 20000-1 - Inormation technology - Service management- Part 1: Specication. ISO.

• ISO TC 176/SC 1 (2000). ISO 9000:2000 - Quality management systems - Fundamentalsand 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 o 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 Certication web site. www.isoiec20000certication.com/index.asp.

• McFarlane, I., & J. Dugmore (2006). BIP 0015 : 2006. IT service management. Sel assessment workbook. 2nd edition. London: BSI.






• 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. Pitalls o ISO/IEC 20000 certication programmes. White

paper or 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 urther. 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). Inormation Security based on ISO 27001/ISO 17799; A Management Guide.

Zaltbommel: Van Haren Publishing.• ISO 17799 : 2005, Inormation technology - Security techniques - Code o practice or inormation

security management. (2005). Geneva: International Organization or Standardization.• ISO 27001: 2005, Inormation technology - Security techniques - Inormation Security management

Systems - Requirements. (2005). Geneva: International Organization or Standardization

Sobre TQM• Bent, B.J. van der (2006). TQM - Total Quality Management. In J. van Bon (ed.) Frameworks

or 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 or continual improvement). Salem, NH: GOAL/

QPC.• Conti, T. (1993). Building Total Quality. A guide or management. London: Chapman and

Hall.• Crosby, P.B. (1979). Quality is Free. New York: McGraw-Hill.• Deming, W.E. (1986). Out o the Crisis. Cambridge, MA: MIT Center or Advanced

Engineering Study.• Deming, W.E. (1994, 2nd edition). The New Economics or Industry, Government, Education.

Cambridge, MA: MIT Center or 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 HouseBusiness Division.• Juran, J. (1988). Juran on Planning or Quality. New York: The Free Press.





Reerencias 237

• MacLeod, A., & L. Baxter (2001). The Contribution o Business Excellence Models inRestoring Failed Improvement Initiatives. European Management Journal , Vol. 19, No. 4, 392-403.

• Mulè, G. (2007). EFQM - European Foundation or Quality Management Excellence Model. in J. van Bon (ed.) Frameworks or IT Management (second edition). Zaltbommel: Van Haren

Publishing.• March, A. (1996). A Note on Quality: The Views o 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 or the implementation o the EFQM-Excellence model. Leuven:Comatech.

• Peach, R.W., Peach, B., & Ritter, D.S. (2000). Memory jogger 9000/2000 (implementing ISO9001). 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 International Organization or

Standardization• www.bsi-global.com British Standard Institution• www.deming.org Deming Institute

• www.eqm.org European Foundation or Quality Management

• www.ink.nl Instuto de Calidad de Holanda• www.juran.com Instituto Juran• www.kaizen-institute.com Instituto Kaizen• www.olkk.nl On line kwaliteitskring, Círculo de calidad holandés• www.vck.be Centro Belga de Gestión de la Calidad

Oportunidades de cualifcación• www.isoiec20000certifcation.com - Inormación sobre cualicaciones en ISO/IEC 20000

de itSMF UK • www.exin-exams.com - Inormación sobre cualicaciones en ISO/IEC 20000 de EXIN• www.tuev-sued.de/it-zert - Inormación sobre cualicaciones en ISO/IEC 20000 de TÜV

SÜD• www.irca.org/certifcation/certifcation_12.html - Inormación sobre cualicaciones en

ISO/IEC 20000 de IRCA • www.aaq.org - Inormación sobre cualicaciones en ISO/IEC 20000 de AFAQ (ICA)










239

Índice alabé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 certicació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

BBase de Datos de Gestión de la Conguración

(CMDB) 60, 94Biblioteca de la Inraestructura de Tecnología

de Inormación (ITIL¨) 7, 34, 45, 49,227

Biblioteca de Sotware Denitivo (DSL) 107Biblioteca electrónica 94BS 15000 35, 45

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

Cambio de emergencia 111, 119, 228

Cambio externo 183Campo de aplicación 35Capacidad 18Características de carga de trabajo 129, 187Categoría 114, 215Catálogo de Servicios 129, 136, 227Código de buenas prácticas 63Código de Práctica 2, 52Centro de Atención al Usuario 62, 205,

207Certicación de empresas 2, 35Certicación individual 3, 38Ciclo de vida de la incidencia 179Ciclo PDCA 6, 50, 224Cierre ormal 201, 204Clasicación 201, 204, 209, 211, 215Cálculo de disponibilidad 181Cliente 9, 154CMMI 33

CobiT® 33Componente 8, 16, 21, 30Compromiso de la dirección 66Concienciación 72Conjunto de actividades 10, 25Consensor del sector 54Consultor de gestión de la Calidad del

Servicio 39Consultor de Servicios de TI 39Contabilidad de activos nancieros 93Contrato 61, 150, 159Contrato de Soporte (UC) 136Contrato de suministrador 129, 159Control 27Control de entregas 125Control de la conguración 94, 95, 96Control de la gestión 35Control de seguridad 190, 192Copias maestras 94

Criterios de auditoría 84Cuadro de Mando Integral 87Cuestionario 37






DDeclaración de alcance 36, 229Declaración de política 61Deciencia 97, 110Denición del servicio 160

Denición de queja 152Deming 6, 50, 224Descripción de proceso 16, 55Director de TI 39Directrices de documentación 51Directrices de negocio 79DISC PD 0005 45Disponibilidad 18, 60, 164, 176, 225, 226Distribución 119, 122

Documentación 38, 54, 56Documento 55, 57, 61, 67, 228

EEcacia 27Eciencia 27Elemento de Conguración (CI) 60, 93Elementos de conguración digitales 94Eliminación de un servicio 91Empaquetado 119

Encuesta de satisacción del cliente (CSS)157

Enoque a cliente 5, 8, 152Enoque coherente 5, 52, 54Entidad de Certicación Registrada (RCB)

2, 35Entidad Nacional de Acreditación (NAB) 35Entorno de pruebas de aceptación 119, 121Entrada 10, 27Entrega 61, 118, 123Entrega de emergencia 119Error conocido 209, 214, 216Escalabilidad 18Escalado 160, 202, 207, 210Especicación 2, 52Estado 215Estrategia de continuidad del servicio 165Evaluación 30, 31, 37Evaluación comparativa 32, 79

Evaluación de capacidad 30Evaluación de madurez 30Evaluación de riesgos 164, 165, 168

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

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

G

Gestión de contratos 159, 160Gestión de disputas contractuales 158, 160Gestión de la Calidad 5Gestión de la Calidad del Servicio 1, 7Gestión de la Calidad Total (TQM) 6Gestión de quejas 154Gestión de Servicios 62Gestión de Servicios de TI (ITSM) 21Gestor de la Calidad 39Gestor del proceso 28

Gobierno 33, 224Grupo de interés 34

HHerramientas 23

IIdenticación proactiva 59, 208Impacto 114, 200, 206, 215Imparcialidad 41, 84Incidencia 61, 201, 225Incumplimiento 38Independiente del marco de trabajo 1Indicador Clave del Rendimiento (KPI) 86,

136Inorme de auditoría 32, 38, 61Inorme del servicio 138, 139, 227Inorme proactivo 139Inorme reactivo 139

Instalación 119, 122Institución Británica de Normalización (BSI)35, 45





Índice alabético 241

Instrucción de Trabajo 16ISO 9000:2005 14ISO 9001:2000 7, 51ISO 9004 51ISO/IEC 9000 5, 8, 33, 46, 51

ISO/IEC 15504 33ISO/IEC 17799 190, 196ISO/IEC 20000 33, 44, 46, 51ISO/IEC 27001 34itSMF UK 42, 45

J Jee de proyecto 39

LLista de Cambios Planicados (FSC) 115Límites de carga de trabajo 130Línea base 225, 227Línea base de conguración 94, 106, 121,

174Línea de reerencia 1, 31, 60

MMarcha atrás 116, 118, 126

Marco de trabajo 33Matriz de disponibilidad 180Mejora continua 7, 11, 28, 51, 86, 224Mejora Continua del Servicio (CSI) 50,

59Método de Análisis y Gestión de Riesgos de la

CCTA (CRAMM) 171, 181Metodología de procesos integrados 10, 52Métrica 86Modelado 187Modelo de madurez 29, 79Modelo ERSCR 27Monitor 50Monitorización 10, 217, 224Monitorizar 72, 84

NNecesidades del cliente 9, 14, 222Nivel de Madurez 29

Norma de calidad 54

OObjetividad 84Objetivo especíco de nivel de servicio 129Objetivos de calidad 14, 32, 222Objetivos de Mejora del Servicio 89

Obligaciones 2, 52Observación 38Operador ITSM 39Operativo del proceso 28Organización Internacional de Normalización

(ISO) 51

PPartes interesadas 7, 9, 10

Percepción de la calidad 19Personal competente 39Petición de Servicio 114, 206Plan de Acciones Correctivas (CAP) 38Plan de Calidad del Servicio 136Plan de capacidad 183, 186Plan de continuidad del servicio 164, 166Plan de disponibilidad 164, 180Plan 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, 74Plan de pruebas 127Planicación de los recursos 76Política 14, 32Política de calidad 14, 32, 88, 222Política de entregas 118, 120, 123, 125Política de Gestión de Servicios 65, 67Política de Mejora del Servicio 87Política de seguridad de la inormación 190,

192Portabilidad 18Presupuesto 54, 143, 144Prioridad 114, 200, 206, 215Problema 61, 208Procedimiento 55, 56, 61, 67Procedimiento de reclamaciones 153Proceso 10, 25

Proceso de certicación 37Proceso de gestión de quejas 152






Proesional/Gestor de Servicios de TI 39Programa de auditoría 84Programa de Reconocimiento Multilateral

(MLA) 35Propietario del proceso 28

Propietario responsable sénior 56, 65Proveedor de servicios 62Puesto de Observación Técnica (TOP) 181

RRecomendaciones 2, 52Recuperación 168, 171Recursos 54, 63Reducción de riesgos 168

Registro 55, 56, 57, 61, 67, 228Registro de cambio 60, 225Registro de conguración 96, 97Registro Internacional de Auditores

Certicados (IRCA) 42Relaciones de mutuo benecio con los

suministradores 13Rendimiento 18, 51Requisitos de la Gestión del Servicio 84Requisitos del cliente 8, 14, 19, 65, 154,

227Requisitos del negocio 62, 183Resolución de incidencias 200, 229Resolución de problemas 200, 210, 229Responsabilidad 28, 56, 66, 67, 74, 77Respuesta 27Resultado 27Resultados deseados 13, 14, 82Revisión de Gestión de Servicios 67, 84Revisión del servicio 152, 153Revisión Post-Implantación (PIR) 87, 91,

117, 225Revision de problemas 210Rol 28, 39, 42, 77

SSalida 10, 27Satisacción del cliente 51, 67, 131, 153, 154

Seguimiento 210, 217Seguridad 18Servicio 16Servicio degradado 202Servicio de TI 16

Sistema de Gestión 7, 13Sistema de Gestión de la Calidad 10, 13, 31Sistema de Gestión de la Calidad basado en

procesos 10Sistema de Gestión de Servicios de TI 2, 21Sistema de Gestión genérico 51Six Sigma 34Solicitud de Cambio (RFC) 61, 114, 123Suministrador 158, 223

Suministrador principal 139, 158, 160Suministrador subcontratado 158Supervisión de la Disponibilidad 165

TTiempo Medio de Restauración del Servicio

(MTRS) 179Toma de decisiones con undamento real 12Trazabilidad 96TÜV SÜD 42

UUrgencia 200, 206, 215Usuario 9, 154

VValoración de certicación 38Valoración inicial 38, 114Valoración interna 37Vericación y aceptación de entregas 121Vericación y auditoría de la conguración

97Vinculaciones entre procesos 73





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

ITIL Books

IT Service Management

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

ISBN 978 90 8753 102 7 (english edition)

Foundations of IT Service ManagementBased 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.


Foundations of IT Service ManagementBased on ITIL® V3Now 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, andcovering the ITIL Service Lifecycle, processes and functionsfor Service Strategy, Service Design, Service Operation,Service Transition and Continual Service Improvement.


English€39.95excl tax

English

€39.95excl tax

English

€15.95excl tax





www.vanharen.net

ISO/IEC 20000

ISO/IEC 20000: A Pocket GuideA quick and accessible guide to the fundamentalrequirements for corporate certifi cation.


Implementing ISO/IEC 20000Certifi cation: The RoadmapPractical advice, to assist readers through therequirements of the standard, the scoping, theproject approach, the certifi cation procedure andmanagement of the certifi cation.


ISO/IEC 20000: An IntroductionPromoting awareness of the certifi cation fororganizations within the IT Service Management

environment.


English

€49.95excl tax

English

€39.95excl tax

English

€15.95excl tax





www.vanharen.net

Other leading

ITSM Books

Frameworks for IT ManagementAn unparalleled guide to the myriad of IT management instruments currently available to IT and business managers.Frameworks for IT Management: A Pocket Guide is alsoavailable.


IT Governance based on CobiT 4.1: A Management GuideDetailed information on the overall process model as well as the theory behind it.


Six Sigma for IT ManagementThe fi rst book to provide a coherent view and guidance forusing the Six Sigma approach successfully in IT ServiceManagement, whilst aiming to merge both Six Sigma and ITIL® into a single unifi ed approach to continuous improvement. SixSigma for IT Management: A Pocket Guide is also available.


Metrics for IT Service ManagementA general guide to the use of metrics as a mechanism tocontrol and steer IT service organizations, with considerationof the design and implementation of metrics in serviceorganizations using industry standard frameworks.

ISBN 978 90 77212 69 1€39.95

excl tax

English

€39.95excl tax

English

€39.95excl tax

English

€22.50excl tax











Date post:	09-Jul-2015
Category:	Documents
Upload:	victorvargas69
View:	445 times
Download:	2 times

9789087532932PROT_unlocked

Documents