Une iso(iec 20000-2=2007

40
UNE-ISO/IEC 20000-2 norma espaæola Junio 2007 T˝TULO Tecnologa de la informacin Gestin del servicio Parte 2: Cdigo de buenas prÆcticas (ISO/IEC 20000-2:2005) Information technology. Service management. Part 2: Code of practice. (ISO/IEC 20000-2:2005). Technologies de l’information. Gestion de services. Partie 2: Code de bonne pratique. (ISO/IEC 20000-2:2005). CORRESPONDENCIA Esta norma es idØntica a la Norma Internacional ISO/IEC 20000-2:2005. OBSERVACIONES ANTECEDENTES Esta norma ha sido elaborada por el comitØ tØcnico AEN/CTN 71 Tecnologa de la Informacin cuya Secretara desempeæa AETIC. Editada e impresa por AENOR Depsito legal: M 28166:2007 LAS OBSERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A: 39 PÆginas © AENOR 2007 Reproduccin prohibida C GØnova, 6 28004 MADRID-Espaæa TelØfono 91 432 60 00 Fax 91 310 40 32 Grupo 24 AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Transcript of Une iso(iec 20000-2=2007

Page 1: Une iso(iec 20000-2=2007

UNE-ISO/IEC 20000-2 norma española

Junio 2007 TÍTULO

Tecnología de la información Gestión del servicio Parte 2: Código de buenas prácticas (ISO/IEC 20000-2:2005) Information technology. Service management. Part 2: Code of practice. (ISO/IEC 20000-2:2005). Technologies de l'information. Gestion de services. Partie 2: Code de bonne pratique. (ISO/IEC 20000-2:2005).

CORRESPONDENCIA

Esta norma es idéntica a la Norma Internacional ISO/IEC 20000-2:2005.

OBSERVACIONES

ANTECEDENTES

Esta norma ha sido elaborada por el comité técnico AEN/CTN 71 Tecnología de la Información cuya Secretaría desempeña AETIC.

Editada e impresa por AENOR Depósito legal: M 28166:2007

LAS OBSERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:

39 Páginas

© AENOR 2007 Reproducción prohibida

C Génova, 6 28004 MADRID-España

Teléfono 91 432 60 00 Fax 91 310 40 32

Grupo 24

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 2: Une iso(iec 20000-2=2007

S

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 3: Une iso(iec 20000-2=2007

- 3 - ISO/IEC 20000-2:2005

ÍNDICE Página

PRÓLOGO ........................................................................................................................................ 6 INTRODUCCIÓN ............................................................................................................................ 7 1 OBJETO Y CAMPO DE APLICACIÓN ...................................................................... 7 2 TÉRMINOS Y DEFINICIONES.................................................................................... 8 3 EL SISTEMA DE GESTIÓN.......................................................................................... 8 3.1 Responsabilidad de la dirección...................................................................................... 8 3.2 Requisitos de la documentación ...................................................................................... 9 3.3 Competencia, concienciación y formación ..................................................................... 9 3.3.1 Generalidades ................................................................................................................... 9 3.3.2 Desarrollo profesional...................................................................................................... 9 3.3.3 Enfoques a considerar...................................................................................................... 10 4 PLANIFICACIÓN E IMPLEMENTACIÓN DE LA GESTIÓN DEL SERVICIO .. 10 4.1 Planificación de la gestión del servicio (Planificar) ....................................................... 10 4.1.1 Alcance de la gestión del servicio .................................................................................... 10 4.1.2 Enfoques de la planificación............................................................................................ 11 4.1.3 Eventos a considerar ........................................................................................................ 11 4.1.4 Alcance y contenidos de la planificación ........................................................................ 11 4.2 Implementación de la gestión del servicio y la provisión del servicio (Hacer) ............ 12 4.3 Monitorización, medición y revisión (Verificar)............................................................ 12 4.4 Mejora continua (Actuar)................................................................................................ 13 4.4.1 Política............................................................................................................................... 13 4.4.2 Planificación de las mejoras del servicio ........................................................................ 13 5 PLANIFICACIÓN E IMPLEMENTACIÓN DE NUEVOS SERVICIOS, O DE SERVICIOS MODIFICADOS............................................................................. 13 5.1 Aspectos a considerar ...................................................................................................... 13 5.2 Registros de los cambios .................................................................................................. 14 6 PROCESOS DE LA PROVISIÓN DEL SERVICIO.................................................... 14 6.1 Gestión de nivel de servicio ............................................................................................. 14 6.1.1 Catálogo de servicios........................................................................................................ 14 6.1.2 Acuerdos de nivel de servicio (SLA) ............................................................................... 15 6.1.3 Proceso de gestión de nivel de servicio ........................................................................... 16 6.1.4 Acuerdos de servicios de soporte .................................................................................... 16 6.2 Generación de informes del servicio............................................................................... 16 6.2.1 Política............................................................................................................................... 16 6.2.2 Propósito de los informes del servicio y verificación de su calidad.............................. 16 6.2.3 Informes de servicio ......................................................................................................... 17 6.3 Gestión de la continuidad y disponibilidad del servicio ................................................ 17 6.3.1 Generalidades ................................................................................................................... 17 6.3.2 Actividades y supervisión de la disponibilidad .............................................................. 18 6.3.3 Estrategia de continuidad del servicio............................................................................ 18 6.3.4 Planificación y prueba de la continuidad del servicio ................................................... 18 6.4 Elaboración del presupuesto y contabilidad de los servicios de TI.............................. 19 6.4.1 Generalidades ................................................................................................................... 19 6.4.2 Política............................................................................................................................... 19 6.4.3 Elaboración de los presupuestos ..................................................................................... 20 6.4.4 Contabilidad ..................................................................................................................... 20

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 4: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 4 -

6.5 Gestión de la capacidad ................................................................................................... 20 6.6 Gestión de la seguridad de la información..................................................................... 21 6.6.1 Generalidades ................................................................................................................... 21 6.6.2 Identificación y clasificación de los activos de información.......................................... 21 6.6.3 Prácticas para la evaluación de los riesgos de seguridad.............................................. 21 6.6.4 Riesgos para los activos de información......................................................................... 21 6.6.5 Seguridad y disponibilidad de la información ............................................................... 21 6.6.6 Controles ........................................................................................................................... 21 6.6.7 Documentos y registros.................................................................................................... 22 7 PROCESOS DE RELACIONES .................................................................................... 22 7.1 Generalidades ................................................................................................................... 22 7.2 Gestión de las relaciones con el negocio ......................................................................... 23 7.2.1 Revisiones del servicio...................................................................................................... 24 7.2.2 Reclamaciones del servicio .............................................................................................. 24 7.2.3 Medición de la satisfacción del cliente............................................................................ 24 7.3 Gestión de suministradores ............................................................................................. 24 7.3.1 Introducción ..................................................................................................................... 25 7.3.2 Gestión de contratos......................................................................................................... 25 7.3.3 Definición del servicio ...................................................................................................... 25 7.3.4 Gestión de múltiples suministradores............................................................................. 25 7.3.5 Gestión de los conflictos contractuales ........................................................................... 26 7.3.6 Finalización del contrato ................................................................................................. 26 8 PROCESOS DE RESOLUCIÓN.................................................................................... 26 8.1 Antecedentes ..................................................................................................................... 26 8.1.1 Establecimiento de prioridades....................................................................................... 26 8.1.2 Soluciones provisionales .................................................................................................. 26 8.2 Gestión del incidente ........................................................................................................ 27 8.2.1 Generalidades ................................................................................................................... 27 8.2.2 Incidentes graves .............................................................................................................. 27 8.3 Gestión del problema ....................................................................................................... 28 8.3.1 Alcance de la gestión de problemas ................................................................................ 28 8.3.2 Inicio de la gestión de problemas .................................................................................... 28 8.3.3 Errores conocidos............................................................................................................. 28 8.3.4 Resolución de problemas ................................................................................................. 28 8.3.5 Comunicación ................................................................................................................... 28 8.3.6 Seguimiento y escalado .................................................................................................... 29 8.3.7 Cierre de registros de incidentes y problemas ............................................................... 29 8.3.8 Revisiones de problemas.................................................................................................. 29 8.3.9 Aspectos a tratar en las revisiones .................................................................................. 29 8.3.10 Prevención de problemas................................................................................................. 30 9 PROCESOS DE CONTROL........................................................................................... 30 9.1 Gestión de la configuración ............................................................................................. 30 9.1.1 Planificación e implementación de la gestión de la configuración ............................... 30 9.1.2 Identificación de la configuración................................................................................... 31 9.1.3 Control de la configuración............................................................................................. 32 9.1.4 Seguimiento del estado de configuración e informes..................................................... 32 9.1.5 Verificación y auditoria de la configuración.................................................................. 33 9.2 Gestión del cambio ........................................................................................................... 33 9.2.1 Planificación e implementación....................................................................................... 33 9.2.2 Cierre y revisión de una solicitud de cambio ................................................................. 34 9.2.3 Cambios de emergencia ................................................................................................... 34 9.2.4 Informe, análisis y acciones de la gestión del cambio.................................................... 35

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 5: Une iso(iec 20000-2=2007

- 5 - ISO/IEC 20000-2:2005

10 PROCESOS DE ENTREGA........................................................................................... 35 10.1 Proceso de gestión de la entrega...................................................................................... 35 10.1.1 Generalidades ................................................................................................................... 35 10.1.2 Política de entrega............................................................................................................ 35 10.1.3 Planificación de la entrega y el despliegue ..................................................................... 35 10.1.4 Desarrollo o compra de software .................................................................................... 36 10.1.5 Diseño, construcción y configuración de una entrega ................................................... 36 10.1.6 Verificación y aceptación de la entrega.......................................................................... 37 10.1.7 Documentación ................................................................................................................. 37 10.1.8 Despliegue, distribución e instalación............................................................................. 38 10.1.9 Post-implantación y despliegue de la entrega ................................................................ 38 BIBLIOGRAFÍA............................................................................................................................... 39

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 6: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 6 -

PRÓLOGO ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica Internacional) constituyen el sistema especializado para la normalización a nivel mundial. Los organismos nacionales que son miembros de ISO o IEC participan en el desarrollo de normas internacionales a través de comités técnicos establecidos por las organizaciones respectivas para realizar acuerdos en los campos específicos de la actividad técnica. Los comités técnicos de ISO e IEC colaboran en campos de interés mutuo. Otras organizaciones internacionales, públicas y privadas, en coordinación con ISO e IEC, también participan en el trabajo. En el campo de tecnologías de la información, ISO e IEC han establecido un comité técnico conjunto, el denominado ISO/IEC JTC 1 Las normas internacionales se redactan de acuerdo con las reglas establecidas en la Parte 2 de las Directivas ISO/IEC. La tarea principal de los comités técnicos es preparar normas internacionales. Los proyectos de normas internacionales adoptados por los comités técnicos se envían a los organismos miembros para su votación. La publicación como norma internacional requiere la aprobación por al menos el 75% de los organismos miembros con derecho a voto. Se llama la atención sobre la posibilidad de que algunos de los elementos de esta norma internacional puedan estar sujetos a derechos de patente. ISO e IEC no asumen la responsabilidad por la identificación de cualquiera o todos los derechos de patente. La Norma Internacional ISO/IEC 20000-2 fue elaborada por el British Standards Institution (como BS 15000-2) y fue adoptada por el procedimiento especial de "fast-track", por el Comité Técnico conjunto ISO/IEC JTC 1, Tecnologías de la Información, en paralelo con la aprobación de los organismos nacionales miembros de ISO e IEC. A nivel nacional el comité espejo de éste es el AEN/CTN 71 Tecnología de la Información y que ha sido el encargado de elaborar esta Norma UNE-ISO/IEC 20000-1 que es idéntica a la Norma Internacional ISO/IEC 20000-1:2005. ISO/IEC 20000 está formada de dos partes bajo el mismo título de Tecnología de la Información. Gestión del servicio: − Parte 1: Especificaciones − Parte 2: Código de buenas prácticas

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 7: Une iso(iec 20000-2=2007

- 7 - ISO/IEC 20000-2:2005

INTRODUCCIÓN

Esta parte de la Norma ISO/IEC 20000, al tratarse de un código de buenas prácticas, tiene la forma de guía y recomendaciones. No se debería citar como si fuera una especificación y se debería tener especial cuidado para asegurar que las afirmaciones sobre su cumplimiento no son engañosas. Esta parte de la Norma ISO/IEC 20000 se debería usar junto con la Norma ISO/IEC 20000-1 dado que esta última contiene las especificaciones asociadas a este código de buenas prácticas. Se asume que la ejecución de las disposiciones de esta parte de la Norma ISO/IEC 20000 se confía a personal compe-tente y adecuadamente cualificado. Una norma internacional no pretende incluir todas las disposiciones de un contrato. Los usuarios de las normas internacionales son los responsables de su correcta aplicación. La conformidad con una norma internacional no confiere por si misma inmunidad frente a las obligaciones legales. Esta parte de la Norma ISO/IEC 20000 describe las mejores prácticas para los procesos de gestión del servicio dentro del alcance de la Norma ISO/IEC 20000-1. La provisión del servicio adquiere mayor importancia a medida que los clientes requieren servicios cada vez más avanza-dos (al mínimo coste) para satisfacer las necesidades de sus negocios. Este hecho reconoce a su vez que los servicios y la gestión de estos servicios son esenciales para ayudar a las organizaciones a generar ingresos y ser rentables. La Norma ISO/IEC 20000-1 contiene especificaciones para la gestión de los servicios y se debería leer conjuntamente con esta parte de la Norma ISO/IEC 20000. La serie de Normas ISO/IEC 20000 posibilita a los proveedores del servicio entender cómo mejorar la calidad del servicio que proporcionen a sus clientes ya sean clientes internos o externos. Los proveedores del servicio pueden tener dificultades para mantener niveles altos de servicio al cliente debido a las crecientes dependencias existentes entre el soporte de los servicios y el amplio rango de tecnologías disponibles. Al trabajar de forma reactiva, los proveedores emplean muy poco tiempo en la planificación, formación, revisión, investigación y el trabajo junto con los clientes. El resultado de todo esto es el fracaso en la adopción de prácticas de trabajo estructuradas y proactivas. Se está demandando a estos mismos proveedores del servicio mejorar la calidad, reducir los costes, dar mayor flexibili-dad y una respuesta más rápida a los clientes. La gestión efectiva del servicio proporcione a los clientes altos niveles de servicio y de satisfacción. La serie de Normas ISO/IEC 20000 hace una distinción entre las mejores prácticas de los procesos, que son indepen-dientes del tamaño, forma, estructuras y nombres que adopten las organizaciones. La serie de Normas ISO/IEC 20000 se aplica igualmente a proveedores del servicio grandes y pequeños, y los requisitos asociados a estas mejores prácticas de los procesos de gestión del servicio no cambian en función de la forma de la organización que proporciona el marco de gestión en que dichos procesos son realizados. 1 OBJETO Y CAMPO DE APLICACIÓN

Esta parte de la Norma ISO/IEC 20000 representa un consenso de la industria respecto a las normas de calidad para los procesos de gestión del servicio TI. Estos procesos de gestión del servicio proporcionan el mejor servicio posible para cubrir las necesidades de negocio del cliente, con los niveles acordados de recursos, esto es, un servicio profesional, rentable y con riesgos asociados que son conocidos y gestionados. La variedad de términos que se usan para el mismo proceso, y entre procesos y grupos funcionales (y cargos organizativos), puede hacer que el tema de la gestión del servicio sea confuso para un directivo nuevo. No entender la terminología puede ser una barrera para crear procesos eficaces. Entender la terminología es un beneficio tangible y significativo que proporcionan las Normas ISO/IEC 20000. Esta parte de la Norma ISO/IEC 20000 recomienda que los proveedores del servicio adopten una ter-minología común y un enfoque más consistente de la gestión del servicio; establece unas bases comunes para la mejora de los servicios. También proporciona un marco de referencia para ser usado por proveedores de herramientas de gestión del servicio.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 8: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 8 -

Al tratarse de una norma basada en procesos, este código de prácticas no pretende ser usado para una evaluación de producto. Sin embargo, las organizaciones que desarrollen herramientas, productos y sistemas de gestión de servicios pueden usar las dos partes de la serie ISO/IEC 20000, las especificaciones y el código de buenas prácticas para ayudar al desarrollo de herramientas, productos y sistemas que soporten las mejores prácticas de la gestión del servicio. Esta parte de la Norma ISO/IEC 20000 proporciona una guía para los auditores y ofrece asesoría a los proveedores del servicio para la planificación de las mejoras del servicio o para ser auditados conforme a la Norma ISO/IEC 20000-1. La Norma ISO/IEC 20000-1 especifica una serie de procesos de gestión del servicio relacionados como se muestra en la figura 1.

Figura 1 − Procesos de la gestión del servicio 2 TÉRMINOS Y DEFINICIONES

Para los fines de este documento son aplicables los términos y definiciones dados en la Norma ISO/IEC 20000-1. 3 EL SISTEMA DE GESTIÓN

Objetivo: Proveer un sistema de gestión, incluyendo las políticas y un marco de trabajo para posibilitar la efectiva gestión e implementación de todos los servicios TI.

3.1 Responsabilidad de la dirección

El papel de la dirección para asegurar que las mejores prácticas son adoptadas y mantenidas en los procesos es fundamental para cualquier proveedor del servicio que quiera cumplir con los requisitos de la Norma ISO/IEC 20000-1. Para asegurar el compromiso de la dirección se debería identificar un responsable a nivel de alta dirección como responsable de los planes de gestión del servicio. Este responsable senior debería responsabilizarse de la entrega a todos los niveles del plan de gestión del servicio. El rol de responsable senior debería ser estar al frente de los recursos designados para las actividades de mejora del servicio, bien sean actividades continuas o con un enfoque de proyecto. El responsable senior debería estar apoyado por un grupo encargado de la toma de decisiones que tenga la suficiente autoridad para definir la política y para hacer cumplir sus decisiones.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 9: Une iso(iec 20000-2=2007

- 9 - ISO/IEC 20000-2:2005

3.2 Requisitos de la documentación

El responsable senior debería asegurar que las evidencias necesarias están disponibles para una auditoria de las políti-cas, planificaciones y procedimientos de la gestión del servicio y de cualquier actividad relacionada con ellos. Gran parte de las evidencias de los planes y operaciones de la gestión del servicio se deberían encontrar en forma de documentos, los cuales pueden ser de cualquier tipo y estar en cualquier formato o soporte que sea adecuado para su fin. Los siguientes documentos son considerados normalmente como válidos para servir de evidencias de la planificación de la gestión del servicio: a) políticas y planes; b) documentación del servicio; c) procedimientos; d) procesos; e) registros de control de procesos. Debería existir un proceso para la creación y gestión de los documentos para ayudar a asegurar que se satisfacen las características descritas. La documentación se debería proteger de daños, debidos, por ejemplo, a escasas condiciones del entorno donde se encuentran y a desastres en los sistemas informáticos.

3.3 Competencia, concienciación y formación 3.3.1 Generalidades

El personal que realiza el trabajo relativo a la gestión del servicio debería ser competente para esta función gracias a la educación recibida, a la formación, las habilidades y la experiencia adecuadas. 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 es consciente de la relevancia e importancia de sus actividades dentro del más amplio

contexto de negocio y de cómo contribuyen a la consecución de los objetivos de calidad; c) mantener registros apropiados de la educación, formación, habilidades y experiencia; d) proveer formación o llevar a cabo otras acciones para satisfacer estas necesidades; e) evaluar la efectividad de las acciones realizadas. 3.3.2 Desarrollo profesional

El proveedor del servicio debería desarrollar y mejorar las competencias profesionales de su fuerza de trabajo. Entre las medidas tomadas para conseguir esto, el proveedor del servicio debería incluir lo siguiente: a) contratación: con el objetivo de comprobar la validez de los detalles de los candidatos al puesto de trabajo (inclu-

yendo su cualificación profesional) y de identificar la fortalezas, debilidades y habilidades potenciales de los candidatos frente a una descripción/perfil del puesto de trabajo, frente a los objetivos de la gestión del servicio y frente al conjunto de objetivos de la calidad del servicio;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 10: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 10 -

b) planificación: con el objetivo de dotar de personal a los servicios nuevos o a aquellos que se hayan ampliado (también contratando servicios), usando tecnología nueva, asignando personal de gestión del servicio a los equipos de desarrollo de proyecto, planificando la sucesión y rellenando los vacíos que se generen debido a rotación anticipada del personal;

c) formación y desarrollo: con el objetivo de identificar los requisitos de formación y desarrollo dentro de un plan de

formación y desarrollo y proveer su impartición en el momento oportuno y de forma efectiva. Se debería formar al personal en los aspectos relevantes de la gestión del servicio (por ejemplo, a través de cursos de formación, auto estudio, tutorías y formación en el trabajo) y se debería desarrollar el trabajo en equipo y las habilida-des de liderazgo. Se debería mantener un registro cronológico de la formación para cada persona, junto con las descripciones de la formación proporcionada. 3.3.3 Enfoques a considerar

Para que los equipos de personal alcancen unos niveles apropiados de competencia, el proveedor del servicio debería decidir cual es la proporción óptima entre las contrataciones a corto plazo y de forma indefinida. El proveedor del servi-cio debería decidir también la proporción a alcanzar entre la contratación de nuevo personal con las habilidades requeridas y el reciclaje de personal ya existente. NOTA El equilibrio óptimo entre las contrataciones a corto plazo y de forma indefinida es particularmente importante cuando el proveedor del servicio está

planificando como proveer un servicio durante y después de cambios a gran escala en el número y habilidades del personal de apoyo. Los factores que se deberían considerar para establecer la combinación más adecuada de estos enfoques incluyen: a) el carácter de las competencias nuevas o modificadas: si son a corto o a largo plazo; b) la tasa de cambio en las habilidades y competencias; c) los picos y los descensos esperados en la carga de trabajo y la combinación de habilidades requeridas, datos basados

en la gestión del servicio y en la planificación de las mejoras del servicio; d) disponibilidad de personal competente; e) tasas de rotación de personal; f) planes de formación. Para todo el personal, el proveedor del servicio debería revisar el desempeño a nivel individual al menos anualmente y tomar las acciones oportunas. 4 PLANIFICACIÓN E IMPLEMENTACIÓN DE LA GESTIÓN DEL SERVICIO 4.1 Planificación de la gestión del servicio (Planificar)

Objetivo: Planificar la implementación y la prestación de la gestión del servicio. 4.1.1 Alcance de la gestión del servicio

El alcance de la gestión del servicio se debería definir como parte del plan de gestión del servicio. Por ejemplo, puede definirse según: a) la organización; b) la ubicación; c) el servicio.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 11: Une iso(iec 20000-2=2007

- 11 - ISO/IEC 20000-2:2005

La dirección debería definir el alcance como parte de sus responsabilidades de gestión (y como parte del plan de gestión del servicio). Luego se debería comprobar si el alcance resulta adecuado para la Norma ISO/IEC 20000-1. NOTA La planificación de los cambios operativos se describe en el apartado 9.2. 4.1.2 Enfoques de la planificación

Se pueden utilizar varios planes de gestión del servicio en lugar de un plan o programa de gran magnitud. En este caso, los procesos subyacentes a la gestión del servicio deberían ser coherentes entre ellos. También se debería poder demos-trar cómo se gestiona cada requisito de planificación vinculándolo a sus correspondientes funciones, responsabilidades y procedimientos. La planificación de la gestión del servicio debería formar parte del proceso para convertir las necesidades de los clientes y las intenciones de los directivos en servicios y para proporcionar una guía para dirigir el progreso. Un plan de gestión del servicio debería incluir: a) la implementación de la gestión del servicio (o de parte de la gestión del servicio); b) la entrega de los procesos de la gestión del servicio; c) los cambios de los procesos de la gestión del servicio; d) las mejoras de los procesos de la gestión del servicio; e) los nuevos servicios (hasta el punto que afecten a los procesos incluidos en el alcance acordado de la gestión del

servicio). 4.1.3 Eventos a considerar

El plan de gestión del servicio debería estar enfocado a los procesos de gestión del servicio y a los cambios en los servicios desencadenados por eventos como los siguientes: a) la mejora del servicio; b) los cambios en el servicio; c) la normalización de infraestructuras; d) los cambios de la legislación; e) las modificaciones de normativas como, por ejemplo, modificaciones de las tasas impositivas locales; f) la liberalización o la regulación de los sectores industriales; g) las fusiones y las adquisiciones. 4.1.4 Alcance y contenidos del Plan

Un plan de gestión del servicio debería definir: a) el alcance de la gestión del servicio del proveedor del servicio; b) los objetivos y requisitos que se pretenden conseguir con la gestión del servicio; c) los recursos, instalaciones y presupuestos necesarios para conseguir los objetivos definidos;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 12: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 12 -

d) la estructura de las funciones y las responsabilidades de gestión, incluyendo al responsable senior, a los gerentes de los procesos y a la gestión de suministradores;

e) las interfaces entre los procesos de la gestión del servicio y el modo en que se deberían coordinar los procesos y/o

las actividades; f) el enfoque que se debería aplicar para la identificación, la evaluación y la gestión de riesgos para la consecución de

los objetivos definidos; g) una planificación de los recursos expresada en términos de las fechas en las que deberían estar disponibles las fuen-

tes de financiación, las habilidades y los recursos; h) el enfoque para la modificación del plan y de los servicios definidos por el plan; i) el modo en que el proveedor del servicio demostrará la continuidad del control de calidad continuo (por ejemplo,

auditorías internas); j) los procesos que se van a ejecutar; k) las herramientas apropiadas para soportar los procesos

4.2 Implementación de la gestión del servicio y la provisión del servicio (Hacer)

Objetivo: Implementar los objetivos de la gestión del servicio y el plan. La consecución de los procesos de mejores prácticas de gestión de servicios capaces de satisfacer los requisitos de la Norma ISO/IEC 20000 no se alcanzará si los servicios originales no cumplen los requisitos descritos para la implemen-tación en la Norma ISO/IEC 20000-1. Una vez implementados tanto el servicio como los procesos de gestión de servicios se deberían mantener. Se deberían realizar revisiones de acuerdo con el apartado 4.3. NOTA Es posible que la persona que sea adecuada para realizar la planificación y la implementación inicial no sea la apropiada para la operación

continua.

4.3 Monitorización, medición y revisión (Verificar)

Objetivo: Monitorizar, medir y revisar que se alcanzan los objetivos de la gestión del servicio y del plan. El proveedor del servicio debería planificar e implementar la monitorización, la medición, el análisis y la revisión de los servicios, los procesos de gestión del servicio y los sistemas asociados. Entre los elementos que se deberían monitorizar, medir y revisar están los siguientes: a) los logros respecto a los objetivos de servicio definidos; b) la satisfacción del cliente; c) la utilización de los recursos; d) las tendencias; e) las no conformidades de mayor consideración; Los resultados del análisis deberían proporcionar una entrada a un plan para la mejora del servicio.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 13: Une iso(iec 20000-2=2007

- 13 - ISO/IEC 20000-2:2005

Además de las actividades de gestión del servicio relativas a la medición y el análisis, es posible que la alta dirección necesite recurrir a auditorías internas y a otros tipos de verificaciones. Al decidir la frecuencia de dichas auditorías internas y verificaciones, se deberían tener en cuenta, entre otros, factores como el nivel de riesgo implicado en un proceso, su frecuencia de realización y su historial de problemas pasados. Las auditorías internas y las verificaciones se deberían planificar, registrar y llevarse a cabo de una manera competente.

4.4 Mejora continua (Actuar)

Objetivo: Mejorar la eficacia y la eficiencia de la provisión y la gestión del servicio. 4.4.1 Política

Los proveedores del servicio deberían reconocer que siempre existe la posibilidad de conseguir que la provisión del servicio sea más eficaz y más eficiente. Debería hacerse pública una política de la calidad y de mejora del servicio. Todas las personas implicadas en la gestión del servicio y la mejora del servicio deberían ser conscientes de la política de ca-lidad del servicio y de cuál debería ser su contribución personal a la consecución de los objetivos establecidos en esta política. En particular, todo el personal del proveedor del servicio implicado en la gestión del servicio debería tener un conocimiento detallado de las repercusiones de estos factores sobre los procesos de gestión del servicio. Debería existir una coordinación eficaz entre la estructura de gestión propia del proveedor del servicio, los clientes y los suministradores del proveedor del servicio a la hora de tratar cuestiones que afecten a la calidad del servicio y a los requisitos del cliente. 4.4.2 Planificación de mejoras del servicio

Los proveedores del servicio deberían adoptar un enfoque metódico y coordinado para cumplir con los requisitos de la política desde su propia perspectiva y desde la perspectiva del cliente. Antes de implementar un plan de mejora del servicio, se deberían registrar los niveles de servicio y la calidad del servicio como línea de referencia sobre la que se puedan comparar las mejoras reales. Para evaluar la eficacia del cambio se debería 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 del servicio deberían animar a su personal y a sus clientes a proponer alternativas para mejorar 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 progreso tomando como referencia los objetivos formalmente acordados. 5 PLANIFICACIÓN E IMPLEMENTACIÓN DE NUEVOS SERVICIOS, O DE SERVICIOS MODIFICADOS

Objetivo: Asegurar que, tanto los servicios nuevos, como las modificaciones a los servicios existentes, serán gestiona-dos y entregados con los costes y la calidad acordados.

5.1 Temas a considerar

La planificación de los nuevos servicios o de los servicios modificados debería incluir la revisión de los siguientes aspectos:

a) los presupuestos;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 14: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 14 -

b) los recursos de personal;

c) los niveles de servicio existentes;

d) los SLAs y otros objetivos o compromisos del servicio;

e) los procesos de gestión del servicio, procedimientos y documentación existentes;

f) el enfoque de la gestión del servicio, incluyendo la implementación de los procesos de gestión del servicio que hubieran sido previamente excluidos del enfoque.

5.2 Registros de los cambios

Todas las modificaciones al servicio se deberían reflejar en los registros de gestión del cambio: Esto incluye a los planes para: a) la contratación y formación del personal; b) la reubicación; c) la formación al usuario; d) las comunicaciones sobre los cambios; e) los cambios en la naturaleza de la tecnología a la que se da soporte; f) el cierre formal de los servicios. 6 PROCESOS DE LA PROVISIÓN DEL SERVICIO 6.1 Gestión de nivel de servicio

Objetivo: Definir, acordar, registrar y gestionar los niveles de servicio. 6.1.1 Catálogo de servicios

Todos los servicios deberían estar definidos en un catálogo de servicios. Este catálogo puede ser referenciado desde el SLA y debería utilizarse para recoger aquellos aspectos considerados como demasiado cambiantes para ser introducidos en el SLA. El catálogo de servicios debería ser mantenido y estar actualizado en todo momento. NOTA El catálogo de servicios puede incluir información genérica como:

a) el nombre del servicio, b) los objetivos (por ejemplo tiempo de respuesta o de instalación de una impresora, tiempo para reiniciar un servicio tras un fallo

importante), c) datos de contacto, d) horario del servicio y excepciones, e) disposiciones de seguridad.

El catálogo de servicios en un documento clave para establecer las expectativas del cliente y debería ser fácilmente accesible y estar ampliamente disponible tanto para los clientes como para el personal de apoyo.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 15: Une iso(iec 20000-2=2007

- 15 - ISO/IEC 20000-2:2005

6.1.2 Acuerdos de nivel de servicio (SLAs)

Todo servicio debería estar formalmente documentado en un acuerdo de nivel de servicio (SLA). El SLA debería ser autorizado formalmente por la dirección del cliente y los representantes del proveedor del servicio. El SLA debería estar sujeto a la gestión del cambio, así como el servicio que describe. El presupuesto y las necesidades del cliente deberían ser los elementos en que se base el contenido, la estructura y los objetivos del SLA. Los objetivos, respecto de los cuales debería medirse el servicio prestado, se deberían definir desde la perspectiva del cliente. Los SLAs deberían incluir únicamente un conjunto adecuado de objetivos para centrar la atención en los aspectos más importantes del servicio. NOTA 1 Demasiados objetivos pueden generar confusión y conllevar un exceso de gastos. El contenido mínimo que debería tener un SLA, o que se debería referenciar desde él, es el siguiente:

a) descripción breve del servicio;

b) periodo de validez y/o mecanismo de control de cambios del SLA;

c) detalles sobre la autorización;

d) descripción breve de las comunicaciones, incluida la generación de informes;

e) datos de contacto de las personas autorizadas a actuar ante emergencias, participar en la resolución de incidentes y problemas, así como en la recuperación del servicio o en la aplicación de soluciones temporales;

f) horario de servicio, por ejemplo de 9:00 h a 17:00 h, y excepciones al mismo (por ejemplo fines de semana o periodos vacacionales), periodos críticos para el negocio y cobertura fuera del horario;

g) interrupciones planificadas y acordadas, incluido el aviso que se debe dar y el número por periodo;

h) responsabilidades del cliente, por ejemplo seguridad;

i) responsabilidades y obligaciones del proveedor del servicio, por ejemplo seguridad;

j) directrices sobre impactos y prioridades;

k) procesos de escalado y de notificación;

l) procedimientos de reclamación;

m) objetivos del servicio;

n) límites de la carga de trabajo (superior e inferior), por ejemplo la capacidad del servicio de soportar un número acordado de clientes o un volumen de trabajo o la capacidad de procesamiento del sistema;

o) detalles de alto nivel de la gestión financiera, por ejemplo códigos de imputación, etc.;

p) acciones a llevar a cabo en caso de interrupción del servicio;

q) procedimientos de mantenimiento interno;

r) glosario de términos;

s) servicios de soporte y otros relacionados con el propio servicio;

t) las excepciones a las cláusulas incluidas en el SLA. NOTA 2 La información volátil o común a varios SLAs (como datos de contacto) se pueden referenciar desde el SLA sin que esto suponga un

impacto en la calidad de los procesos de SLM siempre que los documentos de referencia estén también bajo el control del proceso de gestión del cambio.

NOTA 3 En el SLA se suele hacer referencia al plan de continuidad y a los detalles de la contabilidad y del presupuesto.

NOTA 4 El glosario de términos normalmente suele ser único y común a todos los documentos, incluyendo el catálogo de servicios.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 16: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 16 -

6.1.3 El proceso de gestión de nivel de servicio

Los cambios importantes en el negocio, debidos, por ejemplo, al crecimiento, fusiones y reorganizaciones del negocio, y los cambios en los requisitos del cliente, pueden implicar el ajuste de los niveles de servicio, su redefinición o incluso su suspensión temporal. El proceso de SLM debería ser flexible para adecuarse a estos cambios. El proceso de SLM debería asegurar que el proveedor del servicio continua focalizado en el cliente durante la planificación, implantación y la gestión continua del servicio prestado. Se le debería dar al proveedor del servicio la información adecuada para permitirle que comprenda las motivaciones y requisitos del negocio del cliente. El proceso de SLM debería gestionar y coordinar a quienes contribuyen al nivel de servicio, para incluir:

a) acuerdo en los requisitos del servicio y en las características de la carga de trabajo esperada del servicio;

b) acuerdo en los objetivos de servicio;

c) medición e informe de los niveles de servicio conseguidos, cargas de trabajo y explicaciones cuando no se alcanzan los objetivos acordados;

d) inicio de la acción correctiva;

e) entrada al programa de mejora del servicio. El proceso debería animar tanto al proveedor del servicio como al cliente a desarrollar una actitud proactiva con objeto de garantizar que ambos tienen una responsabilidad compartida sobre el servicio. La satisfacción del cliente es una parte importante de la gestión de nivel de servicio pero debería reconocerse que es una medida subjetiva, mientras que los objetivos de servicio incluidos en el SLA deberían ser medidas objetivas. El proceso de SLM debería trabajar conjuntamente con los procesos de gestión de relaciones con el negocio y gestión de suministradores. 6.1.4 Acuerdos de servicio de soporte

Los servicios de soporte de los cuales depende el servicio prestado se deberían documentar y acordar con cada suminis-trador de servicios. Esto incluye los grupos internos que proveen parte del servicio ofrecido por el proveedor del servicio.

6.2 Generación de informes del servicio

Objetivo: generar informes fiables y realistas en el tiempo acordado para posibilitar una toma de decisiones basada en la información así como una comunicación efectiva. NOTA El éxito de todos los procesos de gestión del servicio depende del uso de la información proporcionada en los informes de servicio. 6.2.1 Política

Los requisitos para la generación de informes para clientes y para gestión interna se deberían acordar y ser registrados. La supervisión del servicio y la generación de informes abarca todos los aspectos medibles del servicio, proporcionando datos actuales e históricos. Cuando existan múltiples proveedores, suministradores principales y suministradores subcontratados por éstos, los informes deberían reflejar las relaciones entre ellos. Por ejemplo, un suministrador principal debería informar sobre la totalidad del servicio que presta, incluyendo cualquier servicio realizado por un tercero y que forme parte del que el suministrador principal gestiona como parte del servicio al cliente. 6.2.2 Propósito de los informes del servicio y verificación de su calidad

Los informes de servicio se deberían generar a tiempo, y ser claros, fiables y concisos.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 17: Une iso(iec 20000-2=2007

- 17 - ISO/IEC 20000-2:2005

Se deberían adecuar a las necesidades de quien lo recibe y ser suficientemente precisos para poder ser utilizados como herramienta de apoyo en la toma de decisiones. La presentación debería ayudar a comprender los informes de forma que sean fácilmente asimilables, por ejemplo usan-do gráficos. Se deberían generar distintos tipos de informes:

a) informes reactivos, que muestran lo que ha ocurrido;

b) informes proactivos, que avisen por adelantado de eventos significativos con objeto de permitir que se puedan realizar acciones preventivas (por ejemplo, informes sobre inminentes rupturas de los SLAs);

c) distribución previa de informes que muestren las actividades planificadas. 6.2.3 Informes de servicio

El proveedor del servicio debería generar informes para los clientes y para la dirección, que cubran los siguientes aspectos: a) comportamiento frente a objetivos de nivel de servicio, por ejemplo informes de caídas del servicio, logros; b) no conformidades frente a normas; c) características de la carga de trabajo y volumen de la información, por ejemplo incidentes, problemas, cambios y tareas,

clasificación, ubicación, clientes, tendencias estacionales, combinación de prioridades, número de solicitudes de ayuda; d) informes de resultados después de eventos de alto nivel, por ejemplo cambios y entregas; e) información de tendencias por periodos (por ejemplo diaria, semanal, mensual); f) informes que incluyan información de cada proceso, por ejemplo número de incidentes y de preguntas más

frecuentes, componentes de la infraestructura poco fiables, tareas que consumen gran número de recursos económicos, técnicos o humanos;

g) informes para destacar cargas de trabajo futuras o planificadas.

6.3 Gestión de la continuidad y disponibilidad del servicio

Objetivo: Asegurar que los compromisos de continuidad y disponibilidad del servicio, acordados con los clientes pueden cumplirse bajo todas las circunstancias. NOTA Los desastres o fallos del servicio pueden ocurrir por muchas razones, incluyendo la denegación del servicio, ataques, virus, acceso no

permitido a las instalaciones o un desastre natural. 6.3.1 Generalidades

Los requisitos de continuidad y disponibilidad se deberían identificar sobre la base de las prioridades del negocio del cliente, los acuerdos de nivel de servicio y los riesgos evaluados. El proveedor del servicio debería mantener una capacidad suficiente para el servicio junto con planes fácilmente realizables, diseñados para asegurar que los requisitos acordados pueden ser alcanzados en todas las circunstancias, desde el funcionamiento habitual hasta los casos de caídas graves del servicio. El proveedor del servicio debería planificarse para satisfacer los datos conocidos de incrementos o decrementos de volumen de usuarios, picos o caídas previstos de la demanda y cualquier otro cambio futuro conocido. Los requisitos deberían incluir los derechos de acceso y los tiempos de respuesta así como la disponibilidad de los componentes del sistema. La gestión de la disponibilidad y continuidad del servicio debería trabajar conjuntamente con el objetivo de asegurar que se mantengan los niveles de servicio acordados. Estos requisitos deberían tener una influencia capital en las acciones, esfuerzos y recursos destinados para satisfacer la disponibilidad de los servicios que los soportan.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 18: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 18 -

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. 6.3.2 Actividades y supervisión de la disponibilidad

La gestión de la disponibilidad debería:

a) supervisar y registrar la disponibilidad del servicio;

b) mantener datos históricos precisos;

c) realizar comparaciones con los requisitos definidos en los SLAs para identificar no conformidades con los objetivos de disponibilidad acordados;

d) documentar y revisar las no conformidades;

e) predecir la disponibilidad a futuro;

f) cuando sea posible, se deberían predecir los posibles problemas y llevar a cabo las acciones preventivas. Se debería asegurar la disponibilidad de todos los componentes del servicio, registrando y llevando a cabo las acciones correctivas. 6.3.3 Estrategia de continuidad del servicio

El proveedor del servicio debería desarrollar y mantener una estrategia que defina el enfoque general a seguir para satisfacer las obligaciones de continuidad del servicio. Esta estrategia debería incluir la evaluación de riesgos y tener en cuenta los horarios de servicio acordados y los periodos críticos del negocio. El proveedor del servicio debería acordar lo siguiente con cada grupo de clientes y servicios:

a) los periodos máximos aceptables de pérdida continuada del servicio;

b) los periodos máximos aceptables de degradación del servicio;

c) los niveles aceptables de degradación del servicio durante un periodo de recuperación del servicio. La estrategia de continuidad debería ser revisada con una periodicidad acordada, al menos anualmente. Cualquier cambio a la estrategia debería ser acordado formalmente 6.3.4 Planificación y prueba de la continuidad del servicio

El proveedor del servicio debería asegurar que:

a) los planes de continuidad tienen en cuenta las dependencias entre el servicio y los componentes de los sistemas;

b) se registran y mantienen los planes de continuidad del servicio y el resto de documentos requeridos para dar soporte a la continuidad del servicio;

c) la responsabilidad para activar los planes de continuidad está claramente asignada y los planes establecen claramente la responsabilidad para la toma de las acciones necesarias frente a cada objetivo;

d) las copias de seguridad de los datos, los documentos, el software y cualquier equipo y personal necesario para la restauración del servicio están disponibles de forma rápida ante un desastre o un fallo importante del servicio;

e) al menos una copia de todos los documentos relativos a la continuidad del servicio debería estar almacenada y ser mantenida en una localización remota y segura, junto al equipamiento que sea necesario para permitir su uso;

f) el personal conoce y asume su rol para activar y/o ejecutar los planes y tiene acceso a la documentación relativa a la continuidad del servicio.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 19: Une iso(iec 20000-2=2007

- 19 - ISO/IEC 20000-2:2005

Los planes de continuidad del servicio y la documentación relacionada (por ejemplo los contratos) deberían estar liga-dos a los procesos de gestión del cambio y de gestión de los 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 siginificativos. Se deberían llevar a cabo pruebas con una frecuencia suficiente para asegurar que los planes de continuidad son efecti-vos y permanecen así aún cuando se producen cambios en los sistemas, procesos, personal y necesidades del negocio. El cliente y el proveedor del servicio deberían estar implicados conjuntamente en las pruebas, basadas en un conjunto acordado de objetivos. Los fallos en las pruebas se deberían documentar y revisar para proveer de información a un plan de mejora del servicio.

6.4 Elaboración del presupuesto y contabilidad de los servicios de TI

Objetivo: Presupuestar y contabilizar los costes de la provisión del servicio. 6.4.1 Generalidades

Esta sección cubre la realización de los presupuestos y de la contabilidad para los servicios de TI. En la práctica, muchos proveedores están implicados en la facturación del servicio. Sin embargo, dado que la facturación es una actividad opcional, no está cubierta por esta norma. Se recomienda a los proveedores del servicio que cuando lleven a cabo la facturación, el mecanismo empleado para ello esté definido en detalle y sea entendido por todas las partes implicadas. La responsabilidad sobre muchas de las decisiones financieras va a estar fuera del ámbito de la gestión del servicio y también podrían dictarse externamente los requisitos acerca de qué información financiera se debe facilitar, de qué manera y con qué frecuencia. Las disposiciones de esta sección están enfocadas en las prácticas que se deberían seguir para satisfacer los requisitos de la norma. Sin embargo, se pueden tener en cuenta requisitos más amplios en el caso de que impacten en alguna de las políticas y procedimientos definidos. 6.4.2 Política

Debería existir una política para la gestión financiera de los servicios. La política debería definir los objetivos a ser cumplidos por la realización de los presupuestos y la contabilidad. La política debería definir también el nivel de detalle al que se lleva a cabo 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, dividas en departa-mentos o según las diferentes ubicaciones;

d) las reglas para manejar las variaciones frente al presupuesto, por ejemplo el nivel de variación necesario para que se escale a la alta dirección;

e) los enlaces o vinculación con la gestión de nivel de servicio. El nivel de inversión en los procesos de elaboración del presupuesto y contabilidad debería estar basado en las necesidades de detalles financieros que tengan los clientes, el proveedor del servicio y los proveedores, según esté definido en la política. NOTA Los proveedores del servicio que operen en un entorno comercial podrían necesitar invertir mucho más esfuerzo y tiempo en la gestión

financiera. Contrariamente, para aquellos proveedores del servicio que sólo necesiten la simple identificación de los costes, esta gestión puede ser mucho más simple.

La realización de los presupuestos y la contabilidad se deberían realizar por todos los proveedores del servicio, cuales-quiera que fueran sus otras políticas en cuanto a gestión financiera.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 20: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 20 -

6.4.3 Elaboración del presupuesto

La elaboración del presupuesto debería tener en cuenta los cambios planificados de los servicios durante el periodo presupuestario y, en el caso de que las necesidades presupuestarias excedan los fondos disponibles, planificar la gestión que se va a hacer del déficit. La elaboración de los presupuestos puede tener en cuenta factores tales como variaciones estacionales y cambios planificados a corto plazo en los costes y facturación de los servicios. El seguimiento de los costes frente al presupuesto debería facilitar lo antes posible la información de las variaciones frente al presupuesto. Se debería establecer un proceso para gestionar las implicaciones de las variaciones frente al presupuesto. La elaboración de los presupuestos y el seguimiento de los costes deberían dar soporte a la planificación de la operación de cambios en los servicios para que los niveles de dichos servicios puedan mantenerse a lo largo del año. 6.4.4 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 eficacia en costes. Los modelos de costes deberían ser capaces de mostrar los costes de la provisión del servicio. Los estados de cuentas deberían mostrar las situaciones de excesos y defectos de gasto así como las recuperaciones de dichas situaciones y deberían permitir al lector entender los costes de niveles bajos de servicio o de pérdidas de servicio.

6.5 Gestión de la capacidad

Objetivo: Asegurar que el proveedor del servicio tiene, en todo momento, la capacidad suficiente para cubrir la demanda acordada, actual y futura, de las necesidades del negocio del cliente. Los requisitos actuales y esperados del negocio en relación al servicio se deberían conocer en términos de lo que el negocio va a necesitar para dar servicio a sus clientes. Las previsiones de negocio y las estimaciones de carga de trabajo se deberían traducir a requisitos específicos y quedar documentadas. El resultado de las variaciones en la carga de trabajo o en el entorno deberían ser predecibles; se deberían recoger y analizar datos actuales e históricos de utilización de componentes y recursos, al nivel adecuado, con el fin de dar soporte al proceso. La gestión de la capacidad debería ser el punto focal de todas las cuestiones de rendimiento y capacidad. El proceso debería ofrecer soporte directo al desarrollo de servicios nuevos y a la modificación de los mismos realizan-do un dimensionamiento y una modelización de servicios. Se debería generar un plan de capacidad donde se documente el rendimiento real de la infraestructura y los requisitos esperados, con la frecuencia suficiente para tener en cuenta el ritmo de cambios de los servicios y de los volúmenes de servicio, la información de los informes de gestión del cambio y del negocio del cliente. Dicho informe debería elaborarse al menos anualmente. Se deberían documentar las opciones existentes junto con su coste para cumplir con los requisitos del negocio así como las soluciones recomendadas para conseguir los objetivos de nivel de servicio tal como están definidos en el SLA. Debería existir una buena comprensión de la infraestructura técnica y sus capacidades presentes y las que estén pro-yectadas.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 21: Une iso(iec 20000-2=2007

- 21 - ISO/IEC 20000-2:2005

6.6 Gestión de la seguridad de la información

Objetivo: Gestionar la seguridad de la información de manera efectiva para todas las actividades del servicio. 6.6.1 Generalidades

La seguridad de la información es el resultado de un sistema de políticas y procedimientos diseñados para identificar, controlar y proteger la información y cualquier equipamiento empleado junto con el almacenamiento, transmisión y procesamiento de dicha información. El personal del proveedor del servicio con roles de especialista en seguridad de la información debería estar familia-rizado con la Norma ISO/IEC 17799, Tecnologías de la información. Técnicas de seguridad. Código de prácticas para la gestión de la seguridad de la información. 6.6.2 Identificación y clasificación de los activos de información

El proveedor del servicio debería:

a) mantener un inventario de los activos de información (por ejemplo, ordenadores, sistemas de comunicación, equipos del entorno, documentos y otra información) que son necesarios para la provisión del servicio;

b) clasificar cada activo de acuerdo con su criticidad para el servicio y el nivel de protección que éste requiera, así como nombrar a un propietario que sea el responsable de proporcionar dicha protección;

c) la responsabilidad para la protección de los activos debería recaer en el propietario de dichos activos, aunque estos pueden delegar las responsabilidades de la gestión diaria de la seguridad.

6.6.3 Prácticas para la evaluación de los riesgos de seguridad

La evaluación de los riesgos de seguridad debería:

a) ser realizada con una periodicidad acordada;

b) ser registrada;

c) ser mantenida durante los cambios (cambios de las necesidades del negocio, de procesos o de configuraciones);

d) ayudar a entender en qué podría impactar uno de los servicios gestionados;

e) proveer de información para las decisiones referentes a los tipos de controles a establecer. 6.6.4 Riesgos para los activos de información

Los riesgos para los activos de información se deberían evaluar en función de:

a) su naturaleza (por ejemplo: funcionamiento defectuoso del software, errores de operación, fallos de comunicación);

b) probabilidad;

c) impacto potencial para el negocio;

d) experiencias pasadas. 6.6.5 Seguridad y disponibilidad de la información

Al evaluar los riesgos, se debería prestar atención a los siguientes puntos:

a) revelación de información sensible a partes no autorizadas;

b) información inexacta, incompleta o inválida (por ejemplo: información fraudulenta);

c) información que quede inservible para su uso (por ejemplo: debido a un corte de energía eléctrica);

d) daño físico o destrucción de los equipos necesarios para proveer los servicios.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 22: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 22 -

También se deberían tener en cuenta los objetivos de la política de seguridad de la información, las necesidades para satisfacer los requisitos específicos de los clientes respecto a la seguridad (por ejemplo: niveles de disponibilidad) y los requisitos legales o regulatorios que apliquen. 6.6.6 Controles

Además de otros controles que puedan ser justificables y aconsejados en esta parte de la Norma ISO/IEC 20000 (por ejemplo: en la continuidad del servicio), los proveedores del servicio deberían aplicar los siguientes controles como una buena práctica en gestión de la seguridad de la información:

a) la alta dirección debería definir la política de seguridad de la información, comunicarla a su personal y a sus clientes y asegurarse de que se implanta eficazmente;

b) los roles y las responsabilidades para la gestión de la seguridad de la información se deberían definir y asignar a un puesto de trabajo;

c) un representante del equipo de dirección (el rol puede ser desempeñado por un propietario que sea un responsable senior) debería supervisar y mantener la eficacia de la Política de Seguridad de la Información;

d) el personal que ejerza un rol significativo en seguridad debería recibir formación en seguridad de la información;

e) todo el personal debe ser concienciado acerca de la política de seguridad de la información;

f) debería haber apoyo de expertos en la evaluación de riesgos y en la implementación de los controles;

g) los cambios no deberían comprometer la operación efectiva de los controles;

h) se debería hacer un informe de los incidentes de seguridad de la información siguiendo los procedimientos de gestión del incidente y, también, se debería iniciar una respuesta a dichos incidentes.

6.6.7 Documentos y registros

Los registros se deberían analizar periódicamente para proporcionar información a la dirección en cuanto a:

a) la eficacia de la política de seguridad de la información;

b) las tendencias que aparezcan en los incidentes en seguridad de la información;

c) dar entrada de información a un plan de mejora del servicio;

d) tener bajo control el acceso a la información, los activos y los sistemas. La gestión de la seguridad de la información debería estar documentada de una manera fiable. 7 PROCESOS DE RELACIONES 7.1 Generalidades

Los procesos de relación describen los dos aspectos relacionados de la gestión de suministradores y la gestión de 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 formalizarán mediante contratos. Las relaciones internas se formalizarán mediante acuerdos de servicio o de soporte interno que son a menudo designados como acuerdos de nivel operacional. La figura 2 muestra una representación simplificada de las relaciones.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 23: Une iso(iec 20000-2=2007

- 23 - ISO/IEC 20000-2:2005

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

7.2 Gestión de las relaciones con el negocio

Objetivo: Establecer y mantener una buena relación entre el proveedor del servicio y el cliente, basándose en el entendimiento del cliente y en los fundamentos de su negocio.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 24: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 24 -

7.2.1 Revisiones del servicio

El proveedor del servicio y los clientes deberían realizar revisiones del servicio, al menos anualmente y 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 inte-rés implicados como por ejemplo subcontratistas, clientes, grupos de usuarios u otros grupos representativos, pueden ser invitados a participar en las reuniones de revisión. El proveedor del servicio y los clientes deberían también acordar los procedimientos de revisión parcial para tratar el progreso, los logros y los problemas detectados. Estas reuniones deberían planificarse y ser notificadas a los grupos de interés para los que sea relevante. El proveedor del servicio debería planificar y registrar todas las reuniones formales, registrar los problemas tratados y realizar el seguimiento de las acciones acordadas. El proveedor del servicio debería establecer una relación con sus clientes de manera que éstos puedan estar al tanto de las necesidades del negocio y de los cambios principales para poder prepararse para dar una respuesta a los mismos. 7.2.2 Reclamaciones del servicio

El proveedor del servicio y los clientes deberían acordar un procedimiento formal de reclamaciones que elimine cualquier ambigüedad sobre qué constituye una reclamación y cómo se debería gestionar. El proveedor del servicio debería poner en marcha un proceso para tomar las acciones adecuadas en la resolución de los problemas. El proceso debería identificar a la persona de contacto en el proveedor del servicio al que dirigir las reclamaciones formales. El proveedor del servicio debería registrar, investigar, tomar acciones, elaborar informes y cerrar formalmente todas las reclamaciones de servicio. Las reclamaciones más relevantes se deberían revisar periódicamente y ser escaladas a la alta dirección si no se resuelven dentro de los plazos acordados con los clientes. Los proveedores del servicio deberían analizar periódicamente las reclamaciones registradas para identificar tendencias y elaborar informes con este análisis para los clientes. Los resultados de tal análisis se deberían usar cuando sea apropiado para el establecimiento de un plan de mejora del servicio. 7.2.3 Medición de la satisfacción del cliente

Se debería medir la satisfacción del cliente para permitir al proveedor del servicio comparar el desempeño con los objetivos de satisfacción de clientes y con encuestas previas. El alcance y la complejidad de la encuesta se deberían concebir de forma que los clientes puedan responder fácilmente y sin que se requiera un excesivo tiempo para cumplimentar de una manera adecuada dicha encuesta. Se deberían investigar las variaciones significativas en los niveles de satisfacción para llegar a entender las razones de las mismas. Los análisis de tendencias u otras comparaciones solo deberían realizarse sobre preguntas comparables y entre métodos de muestreo comparables. Los resultados y conclusiones de las encuestas de satisfacción del cliente se deberían tratar con el cliente. Se debería acordar un plan de acción, utilizándolo como entrada para un plan de mejora del servicio sobre cuyo progreso se informe al cliente. Las felicitaciones sobre el servicio se deberían documentar y dar a conocer al equipo que esté prestando el servicio.

7.3 Gestión de suministradores

Objetivo: Gestionar los suministradores para garantizar la provisión del servicio sin interrupciones de servicios de calidad.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 25: Une iso(iec 20000-2=2007

- 25 - ISO/IEC 20000-2:2005

7.3.1 Introducción

Los procedimientos de gestión de suministradores deberían garantizar que:

a) el suministrador entiende sus obligaciones frente al proveedor del servicio;

b) los requisitos acordados y legítimos son cumplidos dentro del alcance y los niveles de servicio acordados;

c) los cambios son gestionados;

d) se registran las transacciones de negocio entre todas las partes;

e) se puede controlar la información sobre el desempeño de todos los suministradores y actuar en consecuencia. 7.3.2 Gestión de contratos

El proveedor del servicio debería designar un responsable para hacerse cargo de los contratos y acuerdos con los sumi-nistradores. En el caso de que haya todo un grupo de personal involucrado en esta tarea, debería existir un proceso común para asegurar que la información sobre el desempeño de los suministradores está controlada y se actúa consecuentemente. Debería existir una persona de contacto definida dentro de la organización del proveedor del servicio que sea el responsable de la relación con cada suministrador. Todos los contratos con suministradores deberían contener una planificación de las revisiones para evaluar si los objetivos de negocio para el suministro de un servicio siguen siendo válidos. Debería existir un proceso claramente definido para la gestión de cada contrato. El proceso para la modificación de contratos debería estar también claramente definido. Cualquier cambio a este procedimiento se debería notificar formalmente a todos los suministradores afectados. Se debería mantener una lista de puntos de contacto dentro de las respectivas organizaciones (la del suministrador y la del proveedor del servicio). Si un contrato incluye penalizaciones o bonificaciones, se deberían establecer claramente sus fundamentos y elaborar un informe del cumplimiento de los requisitos. 7.3.3 Definición del servicio

Para cada servicio y suministrador el proveedor del servicio debería mantener:

a) una definición de servicios, roles y responsabilidades;

b) el alcance del servicio;

c) un proceso de gestión de contratos, los niveles de autorización y un plan de extinción del contrato;

d) las condiciones de pago, si son relevantes;

e) los parámetros de informe y el registro acordados sobre el desempeño alcanzado. 7.3.4 Gestión de múltiples suministradores

Debería quedar claro si el proveedor del servicio trata con todos los suministradores de forma directa o mediante un suministrador principal que toma la responsabilidad de los suministradores subcontratados. El suministrador principal debería registrar los nombres, responsabilidades y relaciones entre todos los suministradores subcontratados y ponerla a disposición del proveedor del servicio si así lo requiere. El proveedor del servicio debería obtener evidencias de que los suministradores principales gestionan formalmente a los suministradores subcontratados; guiándose, cuando sea apropiado, por los requisitos incluidos en la Norma ISO/IEC 20000-1.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 26: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 26 -

7.3.5 Gestión de los conflictos contractuales

Tanto el proveedor del servicio como el suministrador deberían funcionar conforme a un proceso para gestionar los con-flictos, el cual se debería definir o referenciar dentro del contrato. Debería existir un procedimiento o itinerario para poder escalar los conflictos que no puedan ser resueltos mediante el procedimiento ordinario. El proceso debería asegurar que los conflictos son registrados, investigados, que se toman las acciones necesarias sobre ellos y que se cierran formalmente. 7.3.6 Finalización del contrato

El proceso de gestión de contratos debería contemplar la extinción del contrato (tanto planificada, como prematura). También debería proporcionar un mecanismo de transferencia del servicio a otra organización. 8 PROCESOS DE RESOLUCIÓN 8.1 Antecedentes

La gestión del incidente y del problema son procesos distintos, aunque están estrechamente relacionados. El proceso de gestión del incidente se encarga de la restauración del servicio a los usuarios, mientras la gestión del problema tiene como misión la identificación y la eliminación de las causas de los incidentes. 8.1.1 Establecimiento de prioridades

Los objetivos para la resolución deberían estar basados en la prioridad. La prioridad se debería basar en el impacto y la urgencia. El impacto se debería basar en el nivel de daño real o potencial al negocio del cliente. La urgencia se debería basar en el tiempo entre la detección del problema o del incidente y el momento en que se produce el impacto sobre el negocio del cliente. La planificación de la resolución de incidentes o problemas debería tener en cuenta, como mínimo, lo siguiente: a) la prioridad; b) las habilidades disponibles; c) los requisitos de competencia para los recursos; d) el esfuerzo/coste necesario para proporcionar el método de resolución; e) el tiempo transcurrido para proporcionar un método de resolución. NOTA La prioridad se utiliza durante toda la gestión del servicio pero es fundamental para la gestión del incidente y del problema. 8.1.2 Soluciones provisionales

Siempre que sea necesario, la gestión del problema debería desarrollar y mantener soluciones provisionales para permi-tir a la gestión del incidente ayudar a los usuarios o al personal a restaurar el servicio. Un error conocido sólo se debería cerrar cuando se haya aplicado satisfactoriamente un cambio correctivo o el error deje de existir (por ejemplo, porque el servicio ya no se utilice). La gestión del problema debería tener acceso a la información sobre las áreas de negocio afectadas por los problemas. Se debería almacenar y mantener en la base de datos de conocimiento, la información sobre las soluciones provisiona-les, su aplicabilidad y su efectividad.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 27: Une iso(iec 20000-2=2007

- 27 - ISO/IEC 20000-2:2005

8.2 Gestión del incidente

Objetivo: Restaurar el servicio en los niveles acordados tan pronto como sea posible o responder a las peticiones de servicio. 8.2.1 Generalidades

NOTA 1 El proceso de gestión del incidente 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 incidentes debería ser:

a) un proceso tanto proactivo como reactivo, que responda a los incidentes que afecten, o que pudieran potencialmente, afectar al servicio;

b) un proceso centrado en la restauración del servicio a los clientes y no en la determinación de la causa de los incidentes. El proceso de gestión del incidente debería incluir lo siguiente: a) la recepción, el registro, la asignación de prioridad y la clasificación de las llamadas; b) la resolución de primera línea o la derivación; c) la consideración de cuestiones de seguridad; d) el seguimiento y la gestión del ciclo de vida de los incidentes; e) la verificación y el cierre de los incidentes; f) el contacto de primera línea con los clientes; g) el escalado. Se puede informar sobre incidentes mediante llamadas telefónicas, buzón de voz, visitas, cartas, faxes o mensajes de correo electrónico, o bien pueden ser registrados los avisos directamente por los clientes que tengan acceso al sistema de registro de incidentes, o se pueden registrar automáticamente mediante un software de supervisión automática. Todos los incidentes se deberían registrar de modo que la información relevante se pueda recuperar y analizar. El progreso (o su ausencia) de la resolución del incidente se debería comunicar a las partes real o potencialmente afectadas. Todas las acciones se deberían registrar en el registro del incidente. El personal de gestión del incidente debería tener acceso a una base de conocimientos actualizada que contenga información sobre técnicos especialistas, incidentes anteriores, problemas relacionados y errores conocidos, soluciones provisionales y listas de comprobación que ayuden a restaurar el servicio para la empresa. Siempre que sea posible, se debería proporcionar al cliente los medios necesarios para continuar con sus actividades empresariales, aunque sea con un servicio degradado (por ejemplo inhabilitando una función defectuosa). El motivo 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 la diagnosis continua del problema y cuando se produzcan incidentes similares. Un incidente sólo debería cerrarse definitivamente cuando el usuario que haya notificado dicho incidente haya podido confirmar que el incidente se ha resuelto y el servicio ha sido restaurado. 8.2.2 Incidentes graves

Se debería definir claramente qué constituye un incidente grave y quién está capacitado para llevar a cabo cambios en el funcionamiento habitual del proceso de incidentes/problemas. Todos los incidentes graves deberían tener en todo momento un gestor responsable claramente definido.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 28: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 28 -

La designación como responsable de un incidente grave debería proporcionar los niveles de autoridad individual adecuados para la función de coordinar y controlar todos los aspectos de la resolución. Esto debería incluir una responsabilidad del escalado y una comunicación eficaces entre todas las áreas implicadas en la resolución y hacia los clientes que se vean afectados por dicho incidente grave. NOTA Este nivel de autoridad puede ser temporal y aplicarse sólo mientras dure el incidente grave. El proceso para un incidente grave debería incluir una revisión que proporcionará información al plan de mejora del servicio.

8.3 Gestión del problema

Objetivo: minimizar las interrupciones de servicio de cara al negocio mediante la identificación y el análisis proactivos de las causas de los incidentes y mediante la gestión del problema hasta su cierre. 8.3.1 Alcance de la gestión del problema

El proceso de gestión del problema debería investigar las causas subyacentes de los incidentes. La gestión del problema debería prevenir de una manera proactiva la repetición o la duplicación de los incidentes o de los errores conocidos de acuerdo con los requisitos del negocio. 8.3.2 Inicio de la gestión del problema

Se deberían clasificar los incidentes para ayudar a determinar las causas de los problemas. La clasificación puede hacer referencia a los problemas y cambios existentes. NOTA Cuando se registren incidentes por primera vez, su categorización se verá influenciada por otros factores que incluyen el servicio, el área de

negocio afectada y los síntomas que se presenten. 8.3.3 Errores conocidos

Cuando la investigación de la gestión del problema haya identificado la causa del origen de un incidente y un método para resolver los incidentes, el problema se debería clasificar como un error conocido. Se deberían registrar todos los errores conocidos tomando como referencia los servicios real o potencialmente afectados además del elemento de configuración que se sospeche que causa el error en cuestión. La información sobre los errores conocidos en los servicios que se estén introduciendo en el entorno productivo se debería pasar a la gestión del servicio y se debería registrar en la base de datos de conocimiento, junto con las soluciones provisionales existentes. Un error conocido no se debería cerrar hasta que se haya resuelto satisfactoriamente. NOTA El cliente o el proveedor del servicio pueden decidir que la resolución resulta demasiado cara o que no aporta beneficio al negocio. En este

caso, esto debería quedar claramente documentado. No obstante, el error conocido debería permanecer abierto, puesto que aún existe la posibilidad de que se produzcan incidentes 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.

8.3.4 Resolución del problema

Cuando la causa raíz se haya identificado y se haya tomado una decisión para resolver el error, la resolución se debería conducir a través del proceso de gestión del cambio. 8.3.5 Comunicación

La información sobre soluciones provisionales, arreglos permanentes o el progreso de los problemas se debería comu-nicar a las partes afectadas o puede requerirse para dar soporte a los servicios afectados.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 29: Une iso(iec 20000-2=2007

- 29 - ISO/IEC 20000-2:2005

8.3.6 Seguimiento y escalado

Se debería realizar un seguimiento del progreso de todos los problemas. Todos los problemas se deberían escalar a las partes apropiadas. El proceso debería cubrir: a) el registro de los cambios de las identidades de los responsables de la resolución de problemas durante el ciclo de

vida de cada problema; b) la identificación de incidentes que rompan los objetivos del nivel de servicio; c) la distribución de información en cascada a los clientes y colegas para que puedan llevar a cabo las acciones adecua-

das para minimizar la repercusión del problema no resuelto; d) la definición de los puntos de escalado; e) el registro de los recursos empleados y de las acciones realizadas. 8.3.7 Cierre de registros de incidentes y problemas

El procedimiento de cierre del registro debería incluir comprobaciones para garantizar que: a) los detalles de la resolución se hayan registrado con precisión; b) la causa esté categorizada para facilitar el análisis; c) si es necesario, tanto el personal del cliente como el personal de soporte estén al corriente de la resolución; d) el cliente acepte que la resolución se ha conseguido; e) el cliente sea informado si no se va a llegar a una resolución o ésta no resulta posible. 8.3.8 Revisiones de problemas

Se deberían realizar revisiones de los problemas siempre que, la investigación para esclarecer los problemas no resueltos, no habituales o de gran repercusión, las justifique. La finalidad de estas revisiones es encontrar mejoras para el proceso y evitar la repetición de incidentes o errores. Las revisiones de problemas son normalmente: a) revisiones de los niveles de incidentes 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 información a otros procesos

como, por ejemplo, el de educación y formación del cliente. 8.3.9 Temas a tratar en las revisiones

Las revisiones deberían incluir información de: a) tendencias, por ejemplo, problemas e incidentes recurrentes, errores conocidos, etc.; b) problemas recurrentes de una determinada clasificación de componente o de ubicación; c) deficiencias causadas por la subcontratación, la formación o la documentación; d) no-conformidades, por ejemplo, conforme a normas, políticas y leyes;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 30: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 30 -

e) errores conocidos en las entregas planificadas; f) el compromiso del personal para resolver los incidentes y los problemas; g) repetición de incidentes o problemas ya resueltos. Las mejoras del servicio o del proceso de gestión de problemas se deberían registrar e incluir en un plan de mejora del servicio. La información se debería añadir a la base de conocimientos de gestión de problemas. Toda la documentación relevante se debería actualizar, por ejemplo, las guías del usuario y la documentación del sistema. 8.3.10 Prevención de problemas

La gestión proactiva de problemas debería conducir a una reducción de los incidentes y de los problemas. Debería incluir referencias a la información que resulte de ayuda para el análisis como, por ejemplo: a) activos y configuración; b) gestión del cambio; c) un error conocido y divulgado, información sobre las soluciones provisionales de los proveedores; d) información histórica sobre problemas similares. La prevención de problemas debería abarcar desde la prevención de incidentes individuales, tales como las dificultades reiteradas para utilizar una determinada función de un sistema, hasta las decisiones estratégicas. Es probable que estas últimas requieran un gasto de implementación considerable, por ejemplo, la inversión en una red mejor; a este nivel, la gestión del problema proactiva se funde con la gestión de la disponibilidad. La prevención de problemas también incluye el suministro de información a los clientes para evitar que tengan que pedir ayuda en el futuro, por ejemplo, para prevenir incidentes causados por la falta de conocimiento o la falta de for-mación del usuario. 9 PROCESOS DE CONTROL 9.1 Gestión de la configuración

Objetivo: Definir y controlar los componentes del servicio y de la infraestructura, y mantener actualizada la información de la configuración. 9.1.1 Planificación e implementación de la gestión de la configuración

La gestión de la configuración se debería planificar e implementar junto con la gestión del cambio y la gestión de entregas para asegurar que el proveedor del servicio pueda gestionar sus activos y configuraciones de TI de forma efectiva. Debería estar disponible una información precisa sobre la configuración para dar soporte a la planificación y al control de los cambios a medida que los sistemas y los servicios nuevos y modificados son liberados y distribuidos. El resultado debería ser un sistema eficiente que integre los procesos de gestión de la información de configuración del proveedor del servicio con los de los clientes y suministradores, cuando proceda. Todos los activos y configuraciones principales se deberían tener en cuenta y tener un gestor responsable que asegure que se mantienen la protección y el control apropiados, por ejemplo: los cambios son autorizados antes de la implemen-tación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 31: Une iso(iec 20000-2=2007

- 31 - ISO/IEC 20000-2:2005

Se podría delegar la tarea de implementar los controles, pero la responsabilidad sigue estando en el gestor responsable. Este gestor responsable debería disponer de la información necesaria para delegar esta responsabilidad, por ejemplo, la persona que autoriza un cambio podría requerirle información del coste, riesgos, impacto del cambio y recursos para la implementación. La infraestructura y/o los servicios deberían tener un plan(es) actualizado(s) de gestión de la configuración, que puede ser independiente o formar parte de otros documentos de la planificación. Éstos deberían incluir o describir:

a) ámbito, objetivos, políticas, roles y responsabilidades normalizados;

b) los procesos de gestión de la configuración para definir los elementos de configuración de los servicios e infraestructuras, controlar los cambios en las configuraciones, registrar e informar del estado de los ítems de configuración y verificar la integridad y la exactitud de los elementos de configuración;

c) los requisitos para la contabilidad, el seguimiento y la auditoria, por ejemplo, para propósitos de seguridad, legales, regulatorios o de negocio;

d) el control de la configuración (acceso, protección, versionado, construcción, control de entrega);

e) el proceso de control de los elementos de contacto que identifiquen, registren y gestionen los elementos y la infor-mación de la configuración en los límites comunes a dos o más organizaciones, por ejemplo: interfaces de sistemas, versiones;

f) la planificación y el establecimiento de los recursos para mantener los activos y las configuraciones bajo control y mantener el sistema de gestión de la configuración, por ejemplo, formación;

g) la gestión de los suministradores y subcontratistas que estén llevando a cabo labores de gestión de la configuración. NOTA Se debería implantar un nivel apropiado de automatización para asegurar que los procesos no se conviertan en ineficaces, o en proclives al

error o que no pudieran ejecutarse. 9.1.2 Identificación de configuración

Todos los elementos de configuración deberían estar identificados de manera unívoca y estar definidos por atributos que describan sus características funcionales y físicas. La información debería ser relevante y auditable. En la base de datos de la configuración se deberían utilizar y registrar los marcados apropiados u otros métodos de identificación. Los elementos a ser gestionados se deberían identificar usando los criterios de selección establecidos y deberían incluir:

a) todas las distribuciones y entregas de los sistemas de información y del software (incluyendo software de terceras partes) y la documentación relativa de los sistemas, por ejemplo, las especificaciones de requisitos, diseños, infor-mes de prueba, documentación de la entrega;

b) las líneas de referencia de la configuración o las premisas de construcción para cada entorno, módulo hardware normalizado y versión;

c) copia física maestra y bibliotecas electrónicas, por ejemplo: la biblioteca definitiva de software;

d) las herramientas o paquetes usados para la gestión de la configuración;

e) licencias;

f) componentes de seguridad, por ejemplo: cortafuegos;

g) activos físicos que sean necesarios para la gestión financiera de activos o bien por motivos de negocio, por ejemplo: medios magnéticos seguros, equipamiento;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 32: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 32 -

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 configuración. NOTA Otros elementos que podrían se considerados como elementos de configuración son:

a) otra documentación;

b) otros activos;

c) otras instalaciones, por ejemplo: emplazamientos;

d) unidades de negocio;

e) personas. Se deberían identificar las relaciones y dependencias adecuadas entre los elementos de configuración para proporcionar el nivel de control necesario. Cuando sea necesario establecer alguna trazabilidad, el proceso debería asegurar que se puede seguir el registro de los elementos de la configuración en todo su ciclo de vida, desde los documentos de requisitos hasta los registros de entrega, por ejemplo, utilizando una matriz de trazabilidad. 9.1.3 Control de la configuración

El proceso debería garantizar que sólo los elementos de la configuración autorizados e identificables son aceptados y registrados desde su recepción hasta su baja. Ningún elemento de la configuración se debería añadir, modificar, reemplazar o eliminar/retirar sin la documentación de control apropiada, por ejemplo: aprobación de la solicitud de cambio, información actualizada de la versión. Para proteger la integrad de los sistemas, servicios e infraestructura, los elementos de la configuración se deberían mantener en un entorno seguro y adecuado que:

a) los proteja de accesos no autorizados, cambios o corrupción, por ejemplo: virus:

b) proporcione algún medio de recuperación ante desastres;

c) permita la recuperación controlada de una copia del maestro controlado, por ejemplo: software. 9.1.4 Seguimiento del estado de configuración y elaboración de informes

Los registros de la configuración se deberían mantener actualizados y con la precisión adecuada para reflejar los cam-bios en el estado, localización y versión de los elementos de la configuración. El seguimiento del estado debería proporcionar información sobre los datos actuales e históricos de cada elemento de configuración a lo largo de su ciclo de vida. Esto debería permitir el seguimiento de los cambios en los elementos de la configuración a través de sus diferentes estados, por ejemplo: solicitado, recibido, en pruebas de aceptación, activo, bajo cambio, retirado y eliminado. La información de la configuración se debería mantener actualizada y disponible para: los planes, la toma de decisiones y la realización de cambios a las configuraciones definidas. Cuando sea requerida, la información de la configuración debería estar accesible a: usuarios, clientes, suministradores y socios para darles apoyo en sus planes y en la toma de decisiones. Por ejemplo, un proveedor externo de servicios podría poner accesible su información de la configuración a los clientes y a otras partes, para dar soporte a los procesos de gestión del servicio del resto de las partes implicadas para un servicio completo extremo a extremo. Los informes de gestión de la configuración deberían estar disponibles para todas las partes correspondientes. Los informes deberían cubrir: la identificación y el estado de los elementos de la configuración, sus versiones y la documentación asociada.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 33: Une iso(iec 20000-2=2007

- 33 - ISO/IEC 20000-2:2005

Los informes deberían cubrir:

a) las últimas versiones de los elementos de la configuración;

b) la localización del elemento de configuración y, para el software, la localización de las versiones maestras:

c) interdependencias;

d) historia de la versión;

e) estado de los elementos de la configuración que conjuntamente constituyan:

1) la configuración del servicio o del sistema;

2) un cambio, una línea de referencia, un paquete de instalación o una entrega;

3) una versión o una variante. 9.1.5 Verificación y auditoria de la configuración

Los procesos de verificación y auditoria, en sus aspectos físicos y funcionales, se deberían planificar y se debería reali-zar una comprobación para asegurar que los procesos y recursos adecuados están establecidos para:

a) proteger las configuraciones físicas y el capital intelectual de la organización;

b) asegurar que el proveedor del servicio tiene el control de sus configuraciones, las copias maestras y las licencias;

c) garantizar que la información de la configuración está actualizada, controlada y es visible;

d) asegurar que un cambio, una entrega, un sistema o un entorno es conforme a los requisitos contratados o especifica-dos y que los registros de la configuración son exactos.

Periódicamente se deberían realizar auditorías de la configuración, antes y después de un cambio importante, después de un desastre y a intervalos aleatorios. Las deficiencias y las no conformidades se deberían registrar, evaluar e iniciar una acción correctiva, actuar sobre ellas; y se debería realimentar a las partes correspondientes así como establecer un plan de mejora del servicio. NOTA Normalmente hay dos tipos de auditoria de la configuración:

a) auditoria funcional de la configuración: un examen formal para verificar que un elemento de configuración ha alcanzado el rendimiento y características funcionales especificadas en sus documentos de configuración;

b) auditoria física de la configuración: un examen formal de la configuración �según sale de fábrica� de un elemento de configuración para verificar su conformidad con sus documentos de configuración del producto.

9.2 Gestión del cambio

Objetivo: Asegurar que todos los cambios son evaluados, aprobados, implementados y revisados de una forma controlada. 9.2.1 Planificación e implantación

Los procesos y procedimientos de gestión de cambio deberían garantizar que: a) los cambios tienen claramente definido y documentado su alcance; b) sólo son aprobados los cambios que proporcionan beneficios al negocio, por ejemplo: comerciales, legales, regulato-

rios o estatutarios; c) los cambios son planificados en base a la prioridad y al riesgo; d) los cambios a las configuraciones pueden se verificados durante la implementación del cambio;

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 34: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 34 -

e) cuando sea requerido, el plazo para la implementación de los cambios es supervisado y mejorado; f) puede demostrarse cómo un cambio es:

1) generado, registrado y clasificado (con las referencias a los documentos que dieron origen al cambio);

2) evaluado en relación al impacto, la urgencia, el coste, los beneficios y el riesgo del cambio en el servicio, en los clientes y en los planes de despliegue;

3) revertido o remediado, si no tuvo éxito;

4) documentado, por ejemplo, la solicitud de cambio está asociada a los elementos de configuración afectados, a la versión actualizada de la implementación y a los planes de despliegue;

5) aprobado o rechazado por una autoridad de cambios, dependiendo de su tipo, tamaño o riesgo;

6) implementado por el responsable designado dentro de los grupos responsables de los componentes a ser cambiados;

7) probado, verificado y entregado;

8) cerrado y revisado;

9) planificado, supervisado e incluido en un informe;

10) asociado a incidentes, problemas, otro cambio y a los registros de elementos de configuración, cuando sea apropiado.

El estado de los cambios y las fechas de implementación planificadas se deberían usar como base para la planificación del cambio y del despliegue. La información de planificación debería estar disponible para las personas afectadas por el cambio. Cuando se pueda ocasionar una perdida del servicio durante el horario normal del servicio, las personas afectadas deberían acordar el cambio antes de su implementación. 9.2.2 Cierre y revisión de una solicitud de cambio

Todos los cambios se deberían revisar en relación a su éxito o fallo después de la implementación y cualquier mejora debería ser registrada. Se debería realizar una revisión después de la implementación en los cambios principales para comprobar que: a) el cambio cumple sus objetivos; b) los clientes están satisfechos con los resultados; c) no ha habido efectos colaterales inesperados. Toda no conformidad se debería registrar y tomarse las acciones pertinentes. Cualquier debilidad o deficiencia identificada en la revisión del proceso de gestión del cambio, debería alimentar los planes de mejora del servicio. 9.2.3 Cambios de emergencia

En ocasiones se requiere la realización de cambios de emergencia, y cuando sea posible, se debería seguir el proceso de cambio, aunque algunos detalles se documenten a posteriori. Cuando el proceso de emergencia se salte algunos requisitos del proceso de gestión del cambio, el cambio debería cumplir estos requisitos tan pronto como sea posible. Los cambios de emergencia se deberían justificar por quien los implementa y deberían ser revisados después del cambio para verificar que era una verdadera emergencia.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 35: Une iso(iec 20000-2=2007

- 35 - ISO/IEC 20000-2:2005

9.2.4 Informes, análisis y acciones de la gestión del cambio

Los registros de los cambios se deberían analizar de forma periódica, para detectar incrementos en el nivel de cambios, frecuencia de los tipos recurrentes, tendencias emergentes y cualquier otra información relevante. Los resultados y las conclusiones derivados del análisis de los cambios se deberían registrar y actuar sobre ellos. 10 PROCESOS DE ENTREGA 10.1 Proceso de gestión de la entrega

Objetivo: Entregar, distribuir y realizar el seguimiento de uno o más cambios en el entorno de producción. 10.1.1 Generalidades

La gestión de la entrega debería coordinar las actividades del proveedor del servicio, los diferentes proveedores y el ne-gocio para planificar y desplegar una entrega a lo largo de un entorno distribuido. Son esenciales una buena planificación y gestión para empaquetar y distribuir una entrega con éxito, y para gestionar los impactos y riesgos asociados al negocio y a las TI. Se debería planificar con el negocio la entrega de los sistemas de información, las infraestructuras, los servicios y la documentación afectados. Todas las actualizaciones asociadas a la documentación se deberían incluir en la entrega, por ejemplo: los procesos de negocio, los documentos de apoyo y los acuerdos de nivel de servicio. Se debería evaluar el impacto de todos los elementos de configuración, nuevos o cambiados, requeridos para efectuar los cambios autorizados. El proveedor del servicio se debería asegurar de que los aspectos técnicos y no técnicos de la entrega son considerados de forma conjunta. Los elementos de la entrega deberían poder ser trazables y no ser modificables. Solo se deberían aceptar en el entorno de producción las entregas adecuadas, probadas y aprobadas. 10.1.2 Política de entrega

Debería existir una política de entrega que incluya: a) la frecuencia y tipos de entregas; b) los roles y las responsabilidades para la gestión de la entrega; c) la autoridad para pasar la entrega a los entornos de pruebas de aceptación y de la producción; d) una identificación y descripción única para todas las entregas; e) una aproximación en torno a la agrupación de los cambios en una entrega; f) una aproximación para la automatización de los procesos de construcción, instalación, y distribución de la entrega

para ayudar a su repetibilidad y a su eficiencia; g) la verificación y la aceptación de una entrega. 10.1.3 Planificación de la entrega y del despliegue

El proveedor del servicio debería trabajar conjuntamente con el negocio para asegurar que los elementos de configu-ración que se van a desplegar en una entrega son compatibles entre sí y con los elementos de configuración del entorno de destino.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 36: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 36 -

La planificación de la entrega debería asegurar que los cambios de los sistemas de información, infraestructuras, servi-cios y documentación afectados son acordados, autorizados, planificados, coordinados y que se realiza un seguimiento de los mismos. La entrega y el despliegue se deberían planificar en etapas ya que los detalles del despliegue podrían no ser conocidos inicialmente. La planificación de una entrega y del despliegue normalmente debería incluir:

a) las fechas de la entrega y la descripción de los entregables;

b) los cambios y problemas relacionados, errores conocidos cerrados o resueltos por esta entrega y errores conocidos que hayan sido identificados durantes las pruebas de la entrega;

c) los procesos relacionados para la implementación de una entrega a lo largo de todo el negocio y las diferentes unidades geográficas;

d) el modo en el que se dará marcha atrás de la entrega o en que esta se remediará si no se concluye con éxito;

e) los procesos de verificación y aceptación;

f) la comunicación, preparación, documentación y formación para los clientes y personal de apoyo;

g) la logística y los procesos implicados para realizar la compra, el almacenamiento, la expedición, la conexión, la aceptación y la puesta a disposición de los bienes;

h) los recursos de apoyo necesarios para asegurar el mantenimiento de los niveles de servicio;

i) la identificación de las dependencias, los cambios relacionados y los riesgos asociados que pueden perjudicar el paso sin complicaciones de una entrega a los entornos de pruebas de aceptación y de producción;

j) la autorización de la entrega;

k) el calendario de auditorías del entorno de producción cuando sea necesario asegurar, para actualizaciones de gran tamaño, que el entorno de producción está en el estado esperado en el momento de instalar la entrega.

10.1.4 Desarrollo o compra de software

Se deberían verificar en el momento de la recepción, las entregas de sistemas de información y de software provenientes de equipos de desarrollo propios, desarrolladores de sistemas, integradores u otras organizaciones. El proceso completo se debería documentar en el plan de gestión de la configuración. 10.1.5 Diseñar, construir y configurar una entrega

Los procesos de gestión de la entrega y distribución se deberían diseñar e implementar para:

a) asegurar que existe conformidad con la arquitectura de sistemas, la gestión del servicio y las normas de infraestruc-tura del proveedor del servicio;

b) mantener la integridad durante la construcción, instalación, manipulación, empaquetado y entrega;

c) usar bibliotecas de software y repositorios relacionados para gestionar y controlar los componentes durante los procesos de construcción y de entrega;

d) asegurar que los riesgos estén claramente identificados y que se pueden llevar a cabo acciones de recuperación si se requieren;

e) habilitar verificaciones antes de la instalación para comprobar que la plataforma de destino satisface los requisitos previos;

f) habilitar verificaciones que comprueben que una entrega está completa cuando llega a su destino.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 37: Une iso(iec 20000-2=2007

- 37 - ISO/IEC 20000-2:2005

Las salidas de este proceso deberían incluir las notas de la entrega, las instrucciones de instalación y el software y hardware ya instalados, en relación a la línea de referencia de la configuración. Las salidas de la entrega se deberían entregar al grupo responsable de las pruebas. Los procesos de construcción, gestión de la entrega 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. 10.1.6 Verificación y aceptación de la entrega

El resultado final debería ser una aprobación basada en el grado en el que el paquete completo de la entrega recoge la totalidad de los requisitos. Los procesos de verificación y aceptación deberían: a) verificar que el entorno controlado de las pruebas de aceptación se ajusta a los requisitos del entorno de producción de

destino; b) asegurar que la entrega se ha creado a partir de versiones bajo el control de gestión de la configuración y que se han

instalado en el entorno de pruebas de aceptación usando el proceso de producción planificado; c) verificar que se ha completado el nivel adecuado de pruebas, por ejemplo, pruebas funcionales y no funcionales,

pruebas de aceptación por el negocio, pruebas en los procedimientos de construcción, despliegue de versiones, distribución e instalación;

d) asegurar que la entrega es probada a la satisfacción 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 la entrega aprueba cada etapa de las pruebas de aceptación; f) verificar antes de la instalación que la plataforma de destino satisface los requisitos previos de software y hardware; g) verificar que la entrega está completa cuando llega a su destino. 10.1.7 Documentación

La documentación apropiada debería estar disponible en su totalidad y almacenada según la gestión de la configuración en referencia al elemento de configuración desplegado. Esta documentación debería incluir: a) la documentación de apoyo, por ejemplo, los acuerdos de nivel de servicio; b) la documentación de apoyo, por ejemplo, el esquema del sistema, los procedimientos de instalación y de soporte, las

ayudas para el diagnóstico y las instrucciones de operación y administración; c) los procesos de construcción, despliegue de versiones, instalación y distribución; d) los planes de contingencia y marcha atrás; e) la planificación de la formación para los responsables del servicio, el personal de apoyo y los clientes; f) una línea de referencia de la configuración para la entrega, incluyendo elementos de configuración asociados tales

como documentación del sistema, entornos de pruebas, documentación de pruebas y versiones de las herramientas de construcción y desarrollo;

g) los cambios, problemas y errores conocidos relacionados; h) las evidencias de la autorización de la entrega y las evidencias relacionadas de la verificación y la aceptación.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 38: Une iso(iec 20000-2=2007

ISO/IEC 20000-2:2005 - 38 -

Si un sistema o servicio no cumple completamente con los requisitos especificados para él, antes de pasar a producción se debería identificar y registrar mediante la gestión de la configuración y la gestión del problema. La información sobre errores conocidos se debería comunicar a la gestión del incidente. Si la entrega es rechazada, retrasada o cancelada, se debería informar a la gestión del cambio 10.1.8 Despliegue, distribución e instalación

Se debería revisar el plan de despliegue y se deberían añadir detalles, si es necesario, para asegurar que se van a llevar a cabo todas las actividades necesarias. Es importante que la entrega sea proporcionada de un modo seguro para su destino en el estado esperado. Los procesos de despliegue, distribución e instalación deberían asegurar que: a) todas las zonas de almacenamiento de hardware y software son seguras; b) existen procedimientos adecuados para el almacenamiento, expedición, recepción y eliminación de bienes; c) se planifican y completan las comprobaciones sobre las instalaciones físicas, el entorno, las instalaciones eléctricas y

otros servicios; d) se notifican las nuevas entregas al personal del negocio y del proveedor del servicio; e) se eliminan los productos, servicios y licencias que quedan sin utilidad tras la nueva entrega. Después de una distribución de software en una red es esencial comprobar que la entrega está completa y es operativa cuando llega a su destino. Los registros de activos y de la gestión de la configuración se deberían actualizar con la ubicación y el propietario del software y el hardware tras una instalación llevada a cabo con éxito. Se debería usar un cuestionario de satisfacción y aceptación por parte del cliente de la instalación para registrar el éxito o el fracaso de dicha instalación. Todos los resultados de las encuestas de satisfacción de los clientes deberían constituir una realimentación para la gestión de las relaciones con el negocio. 10.1.9 Post-implantación y despliegue de la entrega

Se debería medir y analizar el número de incidentes relacionados con una entrega en el periodo inmediatamente poste-rior 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 del cambio debería incluir una revisión post-implantación. Las recomendaciones se deberían incluir en un plan de mejora del servicio.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 39: Une iso(iec 20000-2=2007

- 39 - ISO/IEC 20000-2:2005

BIBLIOGRAFÍA [1] ISO/IEC 20000-1 Tecnología de la información. Gestión del servicio. Parte 1: Especificaciones. [2] ISO/IEC 17799 Tecnología de la Información. Código de buenas prácticas para la Gestión de la Seguridad de

la Información. [3] ISO/IEC 12207 Tecnología de la información. Procesos del ciclo de vida del software. [4] ISO/IEC TR 15271 Tecnología de la información. Directrices para la aplicación de la Norma ISO/IEC 12207

(Procesos del ciclo de vida del software). [5] ISO/IEC TR 16326 Ingeniería de sistemas. Directrices para la aplicación de la Norma ISO/IEC 12207 a la

gestión de proyectos. [6] ISO/IEC 15288 Ingeniería de sistemas. Procesos del sistema de ciclo de vida. [7] ISO/IEC TR 19760 Ingeniería de sistemas. Guía para la aplicación de la Norma ISO/IEC 15288 (Procesos del

sistema de ciclo de vida). [8] ISO/IEC 15504-1 Tecnología de la información. Evaluación del proceso. Parte 1: Conceptos y vocabulario. [9] ISO/IEC 15504-2 Tecnología de la información. Evaluación del proceso. Parte 2: Interpretación de la

evaluación. [10] ISO/IEC 15504-3 Tecnología de la información. Evaluación del proceso. Parte 3: Directrices para la

interpretación de la evaluación. [11] ISO/IEC 15504-4 Tecnología de la información. Evaluación del proceso. Parte 4: Guía de uso para la mejora

del proceso y la determinación de la capacidad del proceso. [12] ISO/IEC 15504-5 Tecnología de la información. Evaluación del proceso. Parte 5: Un modelo de evaluación del

proceso. [13] ISO 10007 Sistemas de gestión de la calidad. Directrices para la gestión de la configuración. [14] ISO 9000 Sistemas de gestión de la calidad. Fundamentos y vocabulario. [15] ISO 9001 Sistemas de gestión de la calidad. Requisitos. [16] ISO/IEC 90003 Ingeniería del software. Guía de aplicación de la ISO 9001:2000 al software.

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.

Page 40: Une iso(iec 20000-2=2007

Dirección C Génova, 6 Teléfono 91 432 60 00 Fax 91 310 40 32 28004 MADRID-España

AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A VECTOR SOFTWARE FACTORY, S.L.