4.2 Control de servicios de TI
4.2.1 Planificación e implementación de nuevos servicios o de servicios modificados 5
Objetivo: Asegurar que, tanto los servicios nuevos, como las modificaciones a los existentes, se pueden gestionar y proveer con los costes y la calidad acordados.
Las especificaciones ISO 20000-1 dicen:
En las propuestas de nuevos servicios o modificaciones en los existentes, se deben considerar los costes y el impacto a nivel organizativo, técnico y comercial que pudiera derivar de su
entrega y gestión.
La implementación de nuevos servicios o modificaciones en los existentes, incluyendo la eliminación de un servicio, debe ser planificada y aprobada a través de un proceso formal de
gestión de cambios.
La planificación e implementación deben incluir los fondos y recursos adecuados para llevar a cabo los cambios necesarios para la provisión y la Gestión del Servicio.
Los planes deben incluir: a Los roles y responsabilidades para implementar, operar y mantener los nuevos servicios o
modificaciones en los existentes, incluyendo las actividades a llevar a cabo por clientes y suministradores.
b Los cambios en el marco de trabajo existente de Gestión del Servicio y en los propios servicios.
c La comunicación a las partes afectadas. d Los nuevos contratos y acuerdos, o modificaciones a los contratos y acuerdos existentes,
para estar alineados con las necesidades del negocio. e Los requisitos de mano de obra y contratación.
f Los requisitos de perfiles y formación, por ejemplo usuarios, soporte técnico. g Los procesos, medidas, métodos, herramientas que han de usarse con relación a los nuevos
servicios o modificaciones en los existentes, por ejemplo gestión de la capacidad, gestión financiera.
h Los presupuestos y plazos de tiempo. i Los criterios de aceptación del servicio.
j Los resultados esperados al operar con el nuevo servicio, expresados en términos medibles.
Los nuevos servicios, o las modificaciones en los existentes, deben ser aceptados por el proveedor del servicio antes de ser implementados en el entorno de producción real.
Tras la implementación, el proveedor del servicio debe informar de los resultados alcanzados por el servicio nuevo, o por el servicio modificado, comparándolos con los resultados
previstos. Se debe realizar una revisión posterior a la implementación, que compare los resultados reales con los planificados a través del proceso de gestión de cambios.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
El Código de buenas prácticas ISO 20000-2 dice:
Temas a considerar La planificación de los servicios nuevos o modificados debería incluir la revisión de:
a Los presupuestos b Los recursos de personal
c Niveles de servicio existente d Los SLAs y otros objetivos o compromisos del servicio
e Los procesos de Gestión del Servicio, procedimientos y documentación existentes f El enfoque de la Gestión del Servicio, incluyendo la implementación de los procesos de Gestión del
Servicio que hubieran sido previamente excluidos del enfoque
Propuesta de servicios nuevos o
modificados Debe tener en cuenta:
- Coste - Impacto organizativo
- Impacto técnico - Impacto comercial
Incluye: - Roles y responsabilidades
- Cambios en los servicios y en el marco de trabajo existente para Gestión del Servicio
- Comunicación con las partes afectadas existente para Gestión del Servicio
- Contratos nuevos o modificados para alinearlos con los cambios en las necesidades de negocio
- Requisitos de mano de obra y contratación - Requisitos de formación y conocimientos
- Uso adaptado de procesos, medidas, métodos y herramientas
- Presupuestos y escalas de tiempo - Criterios de aceptación del servicio
- Resultados previstos expresados en términos medibles - Alcance de la Gestión del Servicio
Registros de gestión de cambios, incluidos:
- Contrataciónformación de personal
- Reubicación - Formación de usuarios
- Comunicaciones acerca de los cambios
- Cambios en el tipo de tecnología compatible
- Cierre formal de servicios
Planificar servicios nuevos o
modificados Aprobar el plan a
través de gestión de cambios
Aceptar los servicios
modificados
Implantar los servicios nuevos o
modificados a tr avés de gestión de
cambios
Revisión Post-Implantación
PIR Comunicar los
resultados obtenidos en relación con los
planificados Interfaces:
Mejora continua Actuar: - Sugerir mejoras para SIP
Gestión de cambios: - Planificar y aprobar la implantación de servicios nuevos o
modificados, incluidos la financiación y los recursos adecuados; con aceptación formal
- Presentar solicitudes de cambio Informes del servicio:
- Recibir información
Figura 4.2.1 Planificación e implantación de servicios nuevos o modificados Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
Registros de los cambios Todas las modificaciones al servicio se deberían reflejar en los registros de gestión de cambios:
Esto incluye a los planes para: a La contratación y formación del persona
b La reubicación c La formación al usuarios
d Las comunicaciones sobre los cambios e Los cambios en la naturaleza de la tecnología a la que se da soporte
f El cierre formal de los servicios
La Figura 4.2.1 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos.
Cuando el negocio de un proveedor de servicios esté en marcha, siempre existirá la necesidad de introducir servicios nuevos o modificados. Estos nuevos servicios o los cambios en el catálogo
de servicios se tienen que tramitar a través del proceso de gestión de cambios. La sección de ISO 20000-1 sobre planificación e implantación de servicios nuevos o modificados estipula
los requisitos que tienen que cumplir las propuestas de servicios nuevos o modificados, que constituyen una entrada para el proceso de gestión de cambios.
La planificación e implantación de servicios nuevos o modificados tiene que colaborar con el proceso de gestión de cambios. La interfaz entre ambos debe estar documentada.
4.2.2 Procesos de control: gestión de la configuración 9.1
Objetivo: Definir y controlar los componentes del servicio y de la infraestructura, y mantener información precisa sobre la configuración.
Las especificaciones ISO 20000-1 dice:
Debe existir una visión integrada para la planificación de la gestión de cambios y de la configuración.
El proveedor del servicio debe definir la interfaz con los procesos de contabilidad financiera de activos.
NOTA: La contabilidad financiera de los activos queda fuera del ámbito de esta sección. Debe existir una política que defina qué se considera como elemento de configuración y qué
componentes lo constituyen. Se debe definir la información que se debe registrar para cada elemento, y se deben incluir las
relaciones y la documentación necesaria para la Gestión efectiva del Servicio. La gestión de la configuración debe proporcionar los mecanismos para identificar, controlar
y hacer el seguimiento de las versiones de los componentes identificables del servicio y de
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
la infraestructura. Se debe asegurar que el grado de control es suficiente para cubrir las necesidades del negocio, los riesgos de fallo y la criticidad del servicio.
La gestión de la configuración debe proporcionar información al proceso de gestión de cambios sobre el impacto de un cambio solicitado sobre la configuración del servicio y de la
infraestructura. Los cambios en los elementos de configuración deben ser fáciles de identificar y auditables cuando sea apropiado, por ejemplo para cambios y movimientos en el software y
el hardware.
Los procedimientos de control de configuración deben asegurar que se mantiene la integridad de los sistemas, servicios y componentes de servicio.
Antes de un paso al entorno real, debe establecerse una línea de referencia de los elementos de configuración correspondientes.
Deben estar controladas, en una biblioteca física o electrónica segura, las copias maestras de los elementos de configuración digitales, con referencias a los registros de configuración,
por ejemplo software, productos de prueba, documentos de soporte. Todos los elementos de configuración deben ser identificables de manera única y registrados en la base de
datos de gestión de la configuración, cuyo acceso para actualizaciones se debe controlar de manera estricta. La base de datos de la gestión de la configuración se debe gestionar y
verificar activamente para asegurar su fiabilidad y precisión. El estado de los elementos de configuración, sus versiones, ubicación, cambios y problemas relacionados, así como la
documentación asociada deben estar visibles para quienes lo requieran.
Los procedimientos de auditoría de la configuración deben incluir el registro de deficiencias, el lanzamiento de acciones correctivas y la comunicación de su resultado.
El Código de buenas prácticas ISO 20000-2 dice: La gestión de la configuración se debería planificar e implementar junto con la gestión de cambios
y la gestión de entregas para asegurar que el proveedor del servicio pueda gestionar sus activos y configuraciones de TI de forma efectiva.
Debería estar disponible una información precisa sobre la configuración para dar soporte a la planificación y al control de los cambios a medida que los sistemas y los servicios nuevos y modificados son
liberados y distribuidos. El resultado debería ser un sistema eficiente que integre los procesos de gestión de la información de configuración del proveedor del servicio con los de los clientes y suministradores,
cuando proceda.
Todos los activos y configuraciones principales se deberían tener en cuenta y tener un gestor responsable que asegure que se mantienen la protección y el control apropiados, por ejemplo: los cambios son
autorizados antes de la implementación.
Se podría delegar la tarea de implementar los controles, pero la responsabilidad sigue estando en el gestor responsable. Este gestor responsable debería disponer de la información necesaria para delegar
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
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 yo los servicios deberían tener un planes actualizados de gestión de la configuración, que puede ser independiente o formar parte de otros documentos de la planificación.
Éstos deberían incluir o describir: a Ámbito, objetivos, políticas, roles y responsabilidades normalizados.
b Los procesos de gestión de la configuración para definir los elementos de configuración de los servicios
e infraestructuras, controlar cambios en las configuraciones, resgistrar e informar del estado de los ítems de configuración y verificar la integridad y la exactitud de los elementos de configuración.
c Los requisitos para la contabilidad, el seguimiento y la auditoría, por ejemplo, para propósitos de seguridad, legales, regulatorios y de negocio.
d El control de la configuración acceso, protección, versionado, construcción, control de entrega. e El proceso de control de los elementos de contacto que identifiquen, registren y gestionen los elementos
y la información de la configuración en los límites comunes a dos o más organizaciones, por ejemplo: interfaces de sistemas, versiones.
f La planificación y el establecimiento de los recursos para mantener los activos y las configuraciones bajo control y mantener el sistema de gestión de la configuración, por ejemplo, formación.
g La gestión de los suministradores y subcontratistas que estén llevando a cabo labores de gestión de la configuración.
NOTA: Se debería implantar un nivel apropiado de automatización para asegurar que los procesos no se convierten en ineficaces en proclives al error o que no pudieran ejecutarse.
Identificación de configuración Todos los elementos de configuración deberían estar identificados de manera unívoca y estar definidos
por atributos que describan sus características funcionales y físicas. La información debería ser relevante y auditable.
En la base de datos de la configuración deberían utilizar y registrar los marcas apropiados u otros métodos de identificación.
Los elementos a ser gestionados se deberían identificar usando los criterios de selección establecidos y deberían incluir:
a Todas las distribuciones y entregas de los sistemas de información y del software incluyendo software de terceras partes y la documentación relativa de los sistemas, por ejemplo, las especificaciones de
requisitos, diseños, informes de prueba, documentación de la entrega. b Las líneas de referencia de la configuración o las premisas de construcción para cada entorno,
módulo hardware normalizado y versión. c Copia física maestra y bibliotecas electrónicas, por ejemplo: la biblioteca definitiva de software.
d Las herramientas o paquetes usados para la gestión de la configuración. e Licencias.
f Componentes de seguridad, por ejemplo: cortafuegos. g Activos físicos que sean necesarios para la gestión financiera de activos o bien por motivos de negocio,
por ejemplo: medios magnéticos seguros, equipamiento. h Documentación relativa al servicio, por ejemplo: SLAs, procedimientos.
i Instalaciones para el soporte del servicio, por ejemplo: energía eléctrica para la sala de ordenadores.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
j Relaciones y dependencias entre los elementos de la configuración. NOTA: Otros elementos que podrían ser considerados como elementos de configuración son:
a Otra documentación b Otros activos
c Otras instalaciones, por ejemplo: emplazamientos d Unidades de negocio
e Personas
Se deberían identificar las relaciones y dependencias adecuadas entre los elementos de configuración para proporcionar el nivel de control necesario.
Cuando sea necesario establecer alguna trazabilidad, el proceso debería asegurar que se puede seguir el registro de los elementos de la configuración en todo su ciclo de vida, desde los documentos de requisitos
hasta los registros de entrega, por ejemplo, utilizando una matriz de trazabilidad.
Control de la configuración El proceso debería garantizar que sólo los elementos de la configuración autorizados e identificables son
aceptados y registrados desde su recepción hasta su baja.
Ningún elemento de la configuración se debería añadir, modificar, reemplazar o eliminarretirar sin la documentación de control apropiada, por ejemplo: aprobación de la solicitud de cambio, información
actualizada de la versión.
Para proteger la integridad de los sistemas, servicios e infraestructura, los elementos de la configuración se deberían mantener en un entorno seguro y adecuado que:
a Los proteja de accesos no autorizados, cambios o corrupción, por ejemplo: virus. b Proporcione algún medio de recuperación ante desastres.
c Permita la recuperación controlada de una copia del maestro controlado, por ejemplo: software.
Seguimiento del estado de configuración y elaboración de informes Los registros de la configuración se deberían mantener actualizados y con la precisión adecuada para
reflejar los cambios en el estado, localización y versión de los elementos de la configuración.
El seguimiento del estado debería proporcionar información sobre los datos actuales e históricos de cada elemento de configuración a lo largo de su ciclo de vida. Esto debería permitir el seguimiento de los
cambios en los elementos de la configuración a través de sus diferentes estados, por ejemplo: solicitado, recibido, en pruebas de aceptación, activo, bajo cambio, retirado y eliminado.
La información de la configuración se debería mantener actualizada y disponible para: los planes, la toma de decisiones y la realización de cambios a las configuraciones definidas.
Cuando sea requerida, la información de la configuración debería estar accesible a: usuarios, clientes, suministradores y socios para darles apoyo en sus planes y en la toma de decisiones. Por ejemplo, un
proveedor externo de servicios podría poner accesible su información de la configuración a los clientes y a otras partes, para dar soporte a los procesos de Gestión del Servicio y al resto de las partes implicadas
para un servicio completo extremo a extremo.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Los informes de gestión de la configuración deberían estar disponibles para todas las partes correspondientes. Los informes deberían cubrir: la identificación y el estado de los elementos de la
configuración, sus versiones y la documentación asociada.
Los informes deberían cubrir: a Las últimas versiones de los elementos de la configuración.
b La localización del elemento de configuración y, para el software, la localización de las versiones maestra.
c Interdependencias. d Historia de la versión.
e Estado de los elementos de la configuración que conjuntamente constituyan: 1 La configuración del servicio o del sistema.
2 Un cambio, una línea de referencia, un paquete de instalación o una entrega. 3 Una versión o variante.
Verificación y auditoría de la configuración Los procesos de verificación y auditoría, en sus aspectos físicos y funcionales, se deberían planificar
y se debería realizar una comprobación para asegurar que los procesos y recursos adecuados están establecidos para:
a Proteger las configuraciones físicas y el capital intelectual de la organización. b Asegurar que el proveedor del servicio tiene el control de sus configuraciones, las copias maestras y
las licencias. c Garantizar que la información de la configuración está actualizada, controlada y es visible.
d Asegurar que un cambio, una entrega, un sistema o un entorno es conforme a los requisitos contratados o especificados y que los registros de la configuración son exactos.
Periódicamente se deberían realizar auditorías de la configuración, antes y después de un cambio importante, después de un desastre y a intervalos aleatorios.
Las deficiencias y las no conformidades se deberían registrar, evaluar e iniciar una acción correctiva, actuar sobre ellas; y se deberían realimentar a las partes correspondientes así como establecer un plan
de mejora del servicio.
NOTA: Normalmente hay dos tipos de auditoría de la configuración: a Auditoría funcional de la configuración - Un examen formal para verificar que un elemento
de configuración ha alcanzado el rendimiento y características funcionales especificadas en sus documentos de configuración.
b Auditoría física de la configuración - Un examen formal de la configuración “según sale de
fábrica” de un elemento de configuración para verificar su conformidad con sus documentos de configuración del producto.
Las actividades básicas de la gestión de la configuración son: planificación e implantación; identificación; control; seguimiento de estado e informes; y verificación y auditoría.
Los documentos que se exigen explícitamente en el proceso de gestión de la configuración son los registros de configuración y los registros de deficiencias.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
La gestión de la configuración tiene interfaces con el proceso de gestión de cambios, con el proceso de gestión de entregas y con los procesos de contabilidad de activos financieros. Estas
interfaces deben estar documentadas Figuras 4.2.2, 4.2.3 y 4.2.4.
Guía
La gestión de la configuración incluye las siguientes actividades: •
Planificación •
Identificación •
Control •
Seguimiento del estado •
Verificación •
Informes La meta, los objetivos, el alcance y las prioridades de la gestión de la configuración deben estar
alineados con los objetivos del negocio. El alcance de la gestión de la configuración se detalla en el paso de identificación.
La identificación está relacionada con la definición y mantenimiento de convenciones de nomenclatura y números de versión de componentes físicos de la infraestructura de TI, junto
con documentación, las relaciones entre ellos y los atributos correspondientes. Las líneas base de configuración del hardware existente y futuro se describen mediante clústeres de CIs.
Plan de gestión de la configuración
Incluidas relaciones y documentación
Política en la que se defina qué se entiende
por elemento de configuración CI y sus
componentes constituyentes
El plan debe incluir: -Alcance, objetivos, políticas,
normas, roles y responsabilidades
-Procedimientos de control de cambios y configuración
-Requisitos de seguimiento, trazabilidad y realización de
auditorías -Definición de la interfaz con
la gestión de entregas -Proceso de control de interfaz
-Gestión de proveedores
Definir la interfaz con los procesos de
contabilidad de activos financieros
Proporcionar mecanismos de
identificación, control y
seguimiento de versiones de CIs
Designar a un gestor responsable
para todos los activos y configuraciones
principales Planificar la gestión
de la configuración en línea con la
gestión de cambios y definir la información
que se debe registrar
Figura 4.2.2 Gestión de la configuración
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
La pregunta básica para la identificación de componentes de TI es: “¿Qué servicios y componentes asociados de la infraestructura de TI tienen que estar controlados por
disciplinas de Gestión del Servicio y qué información se necesita para ello?” Para desarrollar un sistema de identificación es necesario tomar decisiones acerca del alcance y
el nivel de detalle de la información que se va a registrar. Para cada propiedad característica
Todos los activos se deben clasificar según su
importancia para el servicio y el nivel de protección que
requieran Registros de
configuración CMDB
Control read and update access
to CMDB Identificar CIs
Mantener la integridadde los
CIs
CMDB actualizada Marcar CIs
Incluidas relaciones y dependencias entre CIs
Restringido a los CIs autorizados
Mantener los CIs en un entorno
seguro Evitar cualquier
modificación de CIs sin la
documentación de control
correspondiente Registrar CIs
Copias maestras de elementos electrónicos
de configuración
CMDB Controlar copias
maestras de elementos
electrónicos de configuración en
bibliotecas seguras Referenciar las
copias maestras a registros de
configuración
Figura 4.2.3 Gestión de la configuración cont.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
se debe identificar a un propietario o grupo de interés. Cuantas más propiedades se registren, mayor esfuerzo habrá que hacer para actualizar la información. La pregunta básica enunciada
anteriormente se puede descomponer en otras más detalladas para determinar la información que se va a registrar. Por ejemplo:
Informe con: - Registros de
deficiencias - Acciones correctivas
emprendidas - Resultado de las acciones
correctivas
Informes para todas las partes afectadas
Línea base de CIs Proporcionar
información sobre impacto a gestión
de cambios
Programa de auditorías
Informes de gestión de la
configuración Incluyen:
- Información de versiones - Ubicación de CIs y
versiones maestras - Interdependencias
- Estado de CIs Medir una línea
base de los CIs apropiados antes
de una entrega
Programar auditorías
Proporcionar información sobre
datos de configuración
Programa de auditorías
Verificar y auditar activamente la
CMDB para emprender acciones correctivas
Interfaces: Procesos de contabilidad de activos financieros
Mejora continua Actuar: - Sugerir mejoras para SIP
Gestión de cambios: - Presentar solicitudes de cambio
- Programar auditorías de configuración antes y después de cambios importantes - Proporcionar información sobre impacto a gestión de cambios
Informes del servicio: - Recibir información
Presupuestos y contabilidad: - Presupuesto y contabilidad de todos los componentes
Gestión de la disponibilidad y la continuidad del servicio: - Permitir el acceso a la CMDB cuando no esté permitido el acceso normal de oficina
- Programar auditorías de configuración después de un desastre Gestión de la seguridad de la información:
- Incluir en la CMDB información sobre activos que sean relevantes para la seguridad de la información
- Mantener un inventario de activos de información Gestión de incidencias:
- Intercambiar la información relevante
Figura 4.2.4 Gestión de la configuración cont.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
• ¿De qué recursos se dispone para recopilar y actualizar la información?
• ¿Qué grado de madurez tienen los procesos administrativos y logísticos?
• ¿A qué niveles instala, cambia, desarrolla o distribuye componentes la organización,
independientemente del componente principal? •
¿Qué actividades realizadas por terceros tienen que ser medibles y mantenerse bajo control? •
¿Qué componentes afectarán a los servicios en caso de sufrir una avería y qué información se necesita para diagnosticar dicha avería?
• ¿Qué componentes de coste elevado tienen que estar protegidos contra robos o pérdidas?
• ¿Cuáles son las necesidades de información presentes y futuras de los otros procesos?
• ¿Qué requisitos están asociados con lo estipulado en el SLA?
• ¿Qué información se necesita para los cobros?
• ¿Son realistas los objetivos o es preferible dejar algunas cosas para más adelante?
Las respuestas a estas preguntas ofrecen información sobre diversas actividades. Hay que tomar una decisión sobre el alcance extensión de la CMDB, el nivel de detalle y el nivel de desglose
profundidad.
Por lo que se refiere al alcance, la Figura 4.2.5 muestra las relaciones entre un servicio y los componentes de la CMDB. Por debajo de este alcance quedan los otros CIs necesarios para
el servicio. Controlar estas relaciones hace que resulte más sencillo determinar el impacto de incidencias sobre los servicios. También es posible generar un informe de todos los componentes
que se utilizan en un servicio. Toda esta información puede ser útil para planificar la introducción de mejoras en el servicio. El CI “servicio” también puede tener relaciones con otros CIs, como
acuerdos con el cliente en forma de acuerdo de nivel de servicio. En el ejemplo de la figura, el Servicio B queda completamente fuera del alcance de la CMDB; como consecuencia, no
todos los CIs que contribuyen al “Servicio A” están incluidos en el alcance de la CMDB, lo que significa que no se puede dar un soporte completo al Servicio A.
Infraestructura de TI CI 1
Aplicación A CI 2
Módulo A CI 4
Módulo B CI 5
LAN 2 CI 3
Sistema 21 CI 6
NIC 12 CI 7
PABX Línea 1 digital
Línea 2 digital Módem 5
CI 8 Línea 3 analógica
Servicio B Alcance
Servicio A
Figura 4.2.5 Alcance de la CMDB Copyright protected. Use is for Single Users only via a VHP Approved License.
For information and printed versions please see www.vanharen.net
Una vez determinado el número de áreas en el alcance, se puede pasar a identificar los elementos del ciclo de vida de CIs que van a estar incluidos en el alcance. Para ello hay que resolver cuestiones
como: ¿Se deben incluir CIs en la CMDB cuando su estado sea “en desarrollo” o “en pedido”, o bien se deben incluir sólo cuando hayan sido incorporados a la infraestructura? La ventaja de
incluir productos en desarrollo es que sus especificaciones no se pueden modificar sin realizar consultas y que su transferencia al entorno de gestión resulta más sencilla. Esta decisión afectará
a la actividad de monitorización de estado, pero también puede ampliar el alcance de la gestión de la configuración en términos de ciclo de vida del producto, lo que supone un aumento de
recursos.
Determinar el nivel de detalle de atributos para cada tipo de CI es muy importante para definir la gestión de la configuración, ya que de ello depende la información disponible sobre CIs
individuales y los nombres y atributos incluidos.
Para determinar el nivel de detalle es necesario buscar un equilibrio entre los requisitos de gestión de cambios, gestión de incidencias, gestión de problemas y otras disciplinas de gestión,
así como la carga de trabajo asociada y los recursos necesarios para dar soporte a la gestión de la configuración.
Las relaciones entre CIs son útiles para diagnosticar errores, predecir la disponibilidad de servicios y valorar cambios. Es posible registrar muchas relaciones diferentes, tanto físicas como lógicas:
• Relaciones físicas
− Forma parte de: Es la relación padre-hijo del CI; por ejemplo, un disco duro forma parte
de un ordenador personal y un módulo de software forma parte de un programa Figura 4.2.6.
− Está conectado a: Por ejemplo, un ordenador personal conectado a un segmento de LAN.
− Se necesita para: Por ejemplo, el hardware necesario para ejecutar una aplicación.
• Relaciones lógicas
− Es copia de: Copia de un modelo estándar, línea base o programa.
− Está relacionado con: Un procedimiento, manual, documentación, un SLA o un área de
clientes. −
Es utilizado por: Por ejemplo, un CI necesario para la provisión de un servicio o un módulo de software utilizado por diversos programas.
Para definir la profundidad de la CMDB, o los niveles de desglose de un sistema o componente, hay que crear una jerarquía de componentes y elementos Figura 4.2.7 seleccionando los CIs
padres y definiendo el número de niveles de desglose de CIs. El nivel más alto está formado por la propia infraestructura de TI, mientras que el más bajo es el más detallado sobre el que se puede
ejercer control. Incluir un CI en la CMDB sólo es útil si el control de ese CI y la información relacionada redundan en beneficio de otros procesos de ISO 20000. Las implantaciones suelen
empezar a un nivel elevado, tras lo cual se van introduciendo niveles más bajos de forma selectiva, especialmente cuando se implanta la gestión de entregas.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
En la definición de la CMDB hay que tener en cuenta las siguientes reglas generales: •
Cuantos más niveles haya, más información habrá que gestionar; esto aumenta la carga de trabajo y hace que la CMDB sea más grande y compleja.
• Cuantos menos niveles haya, se tendrá menos control y menos información sobre la
infraestructura de TI. También se utilizan variantes cuando coexisten distintas formas de un CI, lo que implica una
relación paralela. Existen versiones, por ejemplo, si se utilizan al mismo tiempo una versión nueva y otra antigua de un mismo CI, lo que implica una relación en serie. El uso eficaz de estos dos
conceptos facilita la planificación de cambios.
Cada CI debe tener un nombre único y sistemático que permita distinguirlo de otros CIs. La opción más sencilla consiste en un simple sistema de numeración, tal vez dividido en distintos
intervalos para cada área. Se pueden generar nuevos números cada vez que se cree un nuevo CI.
Relaciones padre-hijo
Sistema A A1
A1 A3
A 4 A 3.1
A 3.2 A 3.3
Figura 4.2.6 Relaciones padre-hijo entre CIs Fuente: OGC
Infraestructura de TI
Hardware Software
Red Documentación
Suite 1 Suite 2
Programa 1-1 Programa 1-2
Programa 1-3
Módulo 1-2-1 Módulo 1-2-2
Figura 4.2.7 Desglose de la CMDB Fuente: OGC
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Si es posible, los nombres deben tener sentido para facilitar la comunicación con los usuarios. Estas convenciones de nomenclatura también se pueden usar para poner etiquetas físicas a los
CIs de forma que sean fácilmente identificables durante auditorías, labores de mantenimiento y registros de incidencias.
Para cada tipo de CI se debe definir el desarrollo detallado de la CMDB, sus atributos y relaciones. Los atributos se utilizan para almacenar información sobre el tipo de CI. Los atributos indicados
en la Tabla 4.2.1 pueden ser útiles para configurar CIs de infraestructura en una CMDB.
Atributo Descripción
Númeroetiqueta o número de código de barras de CI
Identificación exclusiva del CI. Suele ser un número de registro asignado automáticamente por
la base de datos. Aunque no todos los CIs pueden llevar una etiqueta física, todos ellos tienen un
número exclusivo.
Copia o número de serie Número de identificación del suministrador en
forma de número de serie o de licencia.
Número de identificación de herramienta de auditoría
Las herramientas de auditoría suelen tener sus propios identificadores, que pueden ser distintos
para cada área. Este atributo proporciona un vínculo para este
entorno.
Número de modeloreferencia de catálogo Identificación exclusiva empleada en el catálogo
por el suministrador. Cada versión de un modelo tiene un número
distinto por ejemplo, PAT-NL-C366-4000-T.
Nombre de modelo Nombre completo del modelo, que suele incluir
un identificador de versión por ejemplo, PII MMX 400 MHz.
Fabricante Fabricante del CI.
Categoría Clasificación del CI por ejemplo, hardware,
software o documentación.
Tipo Descripción del tipo de CI con detalles sobre
la categoría por ejemplo, configuración de hardware, paquete de software o módulo de
programa.
Fecha de caducidad de la garantía Fecha en que caduca la garantía.
Número de versión Número de la versión del CI.
Ubicación Ubicación del CI por ejemplo, la biblioteca o
medio donde residen los CIs software o el centro sala donde están los CIs hardware.
Responsable propietario Nombre yo designación del propietario o persona
responsable del CI.
Fecha de responsabilidad Fecha en que la persona anterior se hizo
responsable del CI.
Origensuministrador El origen del CI por ejemplo, desarrollado en la
organización o adquirido por el suministrador X.
Licencia Número de licencia o referencia al acuerdo de
licencia.
Fecha de suministro Fecha en que el CI fue suministrado a la
organización.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Dependiendo de la herramienta de Gestión del Servicio, los eventos incidencias, por ejemplo se pueden incluir en la CMDB como atributos de CIs o de otra manera. En general, se indican
los números de los CIs correspondientes en los registros de incidencias, problemas y cambios. Sea cual sea el método seleccionado, se deben mantener las relaciones entre el CI y los registros como
se indica en la Tabla 4.2.2.
El mantenimiento de las relaciones entre CIs es una parte importante de la gestión de la configuración. Dependiendo del tipo de base de datos, estas relaciones se pueden incluir como
atributos de CIs o en una tabla aparte Tabla 4.2.3.
Algunas bases de datos disponen de un método que permite ver un registro histórico de atributos y relaciones. Esto puede ser útil para obtener información sobre tiempo de parada, reparaciones
y mantenimiento en los campos de “Estado actual”, así como para llevar un seguimiento de los propietarios anteriores.
Puede ser necesario mantener listas de atributos con información técnica sobre cada tipo de CI. También se deben crear vínculos con otras fuentes de información fiable sobre: ubicaciones,
Tabla 4.2.1 Ejemplos de atributos
Atributo Descripción
Número de Solicitud de Cambio RFC Números de RFCs activas o abiertas previamente
para el CI. Número de problema
Números de problemas activos o abiertos previamente para el CI.
Número de incidencia Números de incidencias relacionadas con el CI.
Tabla 4.2.2 Otros registros relacionados con CIs
Atributo Descripción
Relaciones de CIs padres Clave o número de CI de los CIs padres.
Relaciones de CIs hijos Clave o número de CI de los CIs hijos.
Otras relaciones Relaciones entre el CI y otros CIs, aparte de
las relaciones padre-hijo ya mencionadas por ejemplo, un CI “utiliza” o “está conectado a”.
Tabla 4.2.3 Atributos de relaciones
Atributo Descripción
Fecha de aceptación Fecha en que el CI fue aceptado y aprobado por
la organización.
Estado actual Estado actual del CI por ejemplo, “en pruebas”,
“activo” o “retirado”.
Estado previsto El siguiente estado previsto del CI, con fecha e
indicación de la acción a realizar.
Coste Coste de adquisición del CI.
Valor residual después de depreciación Valor actual del CI después de su depreciación.
Comentarios Campo de texto para comentarios por ejemplo,
para describir las diferencias entre variantes.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
usuarios, departamentos, números de teléfono, titulares de presupuestos y números de presupuestos. Existen más opciones, pero siempre hay que tener en cuenta la carga de trabajo y
los métodos de control de cambios necesarios para el mantenimiento de estos archivos.
Una línea base de configuración es una instantánea de un grupo de CIs en un momento concreto. Se puede utilizar como:
• Un producto con soporteautorizado que se puede incorporar a la infraestructura de TI estas
líneas base están incluidas en el catálogo de productos. •
CIs estándar para registrar información de costes elementos de coste. •
Puntos de partida para el desarrollo y las pruebas de nuevas configuraciones. •
Puntos de marcha atrás en caso de problemas con nuevas configuraciones después de cambios.
• Un estándar para la entrega de configuraciones a usuarios por ejemplo, una “estación de
trabajo estándar”. •
Un punto de partida para el suministro de nuevo software. Una estación de trabajo estándar es un ejemplo habitual de línea base de producto. Al limitar
el número de estaciones de trabajo estándar diferentes, resulta más fácil estimar el impacto y los recursos necesarios para el despliegue y las pruebas de nuevas funciones y mejoras. Las líneas base
también se pueden usar para establecer una política de combinación y planificación de cambios por ejemplo, para Paquetes de Entrega. Las líneas base ayudan a reducir los costes de gestión y
facilitan la planificación de proyectos.
Otra aplicación útil de las líneas base es el catálogo de productos, que contiene una lista de las configuraciones certificadas que se pueden usar en la infraestructura de TI y que los usuarios
pueden solicitar. En este caso, un CI nuevo es una copia del catálogo con un número exclusivo y una etiqueta. Antes de añadir un producto al catálogo siempre hay que analizar su caso de
negocio.
El ciclo de vida de un componente se puede dividir en varias fases, cada una de ellas con un código de estado asignado. Esta división depende de las características de la infraestructura de TI
que la organización quiera registrar. Mantener un registro de la fecha de cada cambio de estado puede proporcionar información útil sobre el ciclo de vida de un producto: fecha de pedido,
fecha de instalación y mantenimiento y soporte necesarios. El estado de un componente también puede determinar su posible uso. Por ejemplo, si se efectúa un seguimiento del estado de los
repuestos no operativos, es posible que este hardware no se pueda desplegar en otros lugares sin una consulta previa por ejemplo, como parte de un plan de recuperación ante desastres.
El siguiente es un ejemplo de una posible clasificación de estados: •
CIs nuevos
– En desarrolloen pedido
– Probado
– Aceptado
• CIs existentes
– Recibido
– Solicitud de Cambio RFC abierta para el CI se ha pedido una nueva versión
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
– Cambio aprobado e incluido en los planes se proporcionará un nuevo CI y documentación,
que también es un CI –
Mantenimiento en curso –
Parado •
CIs archivados
– Retirado
– Borrado
– Eliminado
– Robado
– Vendido o alquiler no renovado
– En archivo a la espera de donación, venta o destrucción
– Destruido
• Todos los CIs
– En reserva
– Pedido recibido o versión modificada disponible
– En pruebas
– Entregado para instalación
– Activo CI en uso
– Repuesto
La información se tiene que gestionar de una manera eficaz para mantener actualizada la CMDB. Siempre que una actividad cambie las características registradas de un CI o las relaciones entre
CIs, el cambio debe quedar registrado en la CMDB. Nota: Las características de los CIs sólo se pueden modificar mediante cambios debidamente autorizados por la gestión de cambios; la
gestión de incidencias únicamente puede cambiar el estado de un CI existente para reflejar la realidad de una situación por ejemplo, una parada del sistema.
La gestión de la configuración controla todos los componentes de TI recibidos por la organización y garantiza que están registrados en el sistema. El hardware se puede registrar en el momento del
pedido o la entrega, mientras que el software se puede registrar cuando se incluye en la Biblioteca de Software Definitivo DSL o en la Biblioteca de Medios Definitivos DML.
Una de las tareas de control consiste en garantizar que los CIs sólo se registran si han sido autorizados y están incluidos en el catálogo de productos. Por este motivo, la gestión de la configuración
mantiene una relación muy estrecha con la gestión de proveedores, la gestión de incidencias, la gestión de problemas y la gestión de cambios. Si en la infraestructura de TI se introducen cambios
coordinados por la gestión de cambios, la gestión de la configuración tendrá que incorporar esta información a la CMDB. La gestión de la configuración impone requisitos sobre la madurez
de otros procesos en la organización, y especialmente sobre los procesos de gestión de cambios, gestión de entregas y los procesos del departamento de compras.
Para garantizar que la situación real refleja la CMDB autorizada, la gestión de la configuración monitoriza las acciones siguientes cuando:
• Se añade un CI.
• Cambia el estado de un CI; por ejemplo, “encendido” o “parado” útil para gestión de la
disponibilidad.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
• Cambia el propietario de un CI.
• Cambia la relación de un CI con otro CI.
• Se elimina un CI.
• Cambian las relaciones de un CI con un servicio, con la documentación o con otros CIs.
• Se renueva o modifica la licencia de un CI.
• Se modifican los detalles de un CI después de una auditoría.
La gestión de la configuración también tiene la responsabilidad de hacer que se resuelva cualquier problema que pueda surgir en un proceso.
Las auditorías se utilizan para verificar que la situación actual continúa reflejando los datos de la CMDB. Por ejemplo, las herramientas de auditoría pueden realizar análisis automáticos de
estaciones de trabajo y generar informes sobre la situación actual y el estado de la infraestructura de TI. Esta información permite comprobar y actualizar la CMDB. Se pueden realizar auditorías
en las situaciones siguientes:
• Después de la implantación de la nueva CMDB
• Un tiempo después de la implantación
• Antes y después de cambios importantes
• Después de un proceso de recuperación ante desastres
• Aleatoriamente cuando el gestor de la configuración considere que la información puede ser
incorrecta Las herramientas de auditoría no deben tener capacidad para modificar automáticamente la
CMDB cuando se detecten discrepancias. Todas las discrepancias indican que se han omitido procesos de la gestión de cambios, por lo que su investigación y resolución corresponden a la
gestión de cambios.
El factor crítico de éxito para la gestión de la configuración consiste en mantener actualizada la información de la base de datos. Esto significa que se tienen que cumplir todos los requisitos de
la gestión de cambios y la gestión de entregas y que para que se registre información debe existir siempre un grupo de interés.
Es muy importante que la implantación de la gestión de la configuración se divida en varias fases. Los intentos de forzar en exceso el alcance de la gestión de la configuración en un solo paso
están generalmente condenados al fracaso. Los registros mantenidos antes de la implantación del proceso tienen que ser retirados para evitar duplicaciones. El éxito de la introducción del
proceso se verá favorecido si se consiguen algunos éxitos rápidos y si los elementos de registro del proceso se asignan a personal que no sólo tiene los conocimientos precisos, sino también la
actitud adecuada.
Los informes de gestión de la configuración pueden incluir los siguientes elementos: •
Información sobre la calidad del proceso. •
Número de diferencias detectadas entre los registros y la situación real durante una auditoría deltas.
• Número de ocasiones en que se ha detectado que una configuración no estaba autorizada.
• Número de ocasiones en que no se pudo localizar una configuración registrada.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
• Diferencias de nivel de atributos descubiertas por auditorías.
• Tiempo necesario para procesar una solicitud de registro de información.
• Lista de CIs para los que se registraron cambios o incidencias por encima de un número
determinado. •
Información estadística sobre la estructura y composición de la infraestructura de TI.
4.2.3 Procesos de control: Gestión de cambios 9.2
Objetivo: Asegurar que todos los cambios son evaluados, aprobados, implementados y revisados de una manera controlada.
Las especificaciones ISO 20000-1 dicen:
Los cambios en los servicios y la infraestructura deben tener un ámbito claramente definido y documentado.
Todas las peticiones de cambio se deben registrar y clasificar, por ejemplo en urgentes, de emergencia, importantes, menores. Se debe evaluar el riesgo, el impacto y los beneficios para
el negocio de las peticiones de cambio.
El proceso de gestión de cambios debe incluir la forma en que puede darse marcha atrás o corregir cada cambio si no se realiza con éxito.
Los cambios se deben aprobar y tras ello deben ser comprobados, y deben ser implementados de una forma controlada.
Se debe revisar el éxito de todos los cambios y, en caso contrario, se deben decidir y llevarse a cabo acciones correctivas tras la implementación.
Deben existir políticas y procedimientos para controlar la autorización e implementación de cambios de emergencia.
La fechas planificadas para la implementación de los cambios se deben utilizar como base para la planificación de cambios y entregas. Se debe mantener y comunicar a las partes
correspondientes la planificación que contenga los detalles de todos los cambios aprobados para su implementación y las fechas propuestas.
Los registros de cambios se deben analizar regularmente para detectar incrementos en el volumen de cambios, tipos recurrentes frecuentemente, tendencias emergentes y cualquier
otra información relevante. Los resultados y conclusiones obtenidos a partir del análisis de los cambios se deben registrar.
Las acciones de mejora identificadas para la gestión de cambios se deben registrar y debe proporcionar información de entrada al plan de mejora del servicio.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
El Código de buenas prácticas ISO 20000-2 dice:
Planificación e implantación Los procesos y procedimientos de gestión de cambios deberían garantizar que:
a Los cambios tienen claramente definido y documentado su alcance. b Sólo son aprobados los cambios que proporcionan beneficios al negocio, por ejemplo: comerciales,
legales, regulatorios y estatuarios. c Los cambios son planificados en base a la prioridad y al riesgo.
d Los cambios a las configuraciones pueden ser verificados durante la implementación del cambio. e Cuando sea requerido, el plazo para la implementación de los cambios es supervisado y para
identificar propuestas de mejora. f Puede demostrarse cómo un cambio es:
1 Generado, registrado y clasificado con las referencias a los documentos que dieron origen al cambio.
2 Evaluado en relación al impacto, la urgencia, el coste, los beneficios y el riesgo del cambio en el servicio, en los clientes y en los planes de despliegue.
3 Revertido y remediado, si no tuvo éxito. 4 Documentado, por ejemplo, la solicitud de cambio está asociada a los elementos de configuración
afectados, a la versión actualizada de la implementación y a los planes de despliegue. 5 Aprobado o rechazado por la autoridad de cambios, dependiendo de su tipo, tamaño o
riesgos. 6 Implementado por el responsable designado dentro de los grupos responsables de los componentes
a ser cambiados. 7 Probado, verificado y entregado.
8 Cerrado y revisado. 9 Planificado, supervisado e incluido en un informe.
10 Asociado a incidencias, problemas, otro cambio y a los registros de elementos de configuración,
cuando sea apropiado. El estado de los cambios y las fechas de implementación planificadas se deberían usar como base para
la planificación del cambio y del despliegue. La información de planificación debería estar disponible para las personas afectadas por el cambio.
Cuando se pueda ocasionar una perdida del servicio durante el horario normal del servicio, las personas afectadas deberían acordar el cambio antes de su implementación.
Cierre y revisión de una solicitud de cambio Todos los cambios se deberían revisar en relación a su éxito o fallo después de la implementación y
cualquier mejora debería ser registrada. Se debería realizar una revisión después de la implementación en los cambios principales para comprobar que:
a El cambio cumple sus objetivos. b Los clientes están satisfechos con los resultados.
c No ha habido efectos colaterales inesperados.
Toda no conformidad se debería registrar y tomarse las acciones pertinentes. Cualquier debilidad o deficiencia identificada en la revisión del proceso de gestión de cambios, debería
alimentar los planes de mejora del servicio.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Cambios de emergencia En ocasiones se requiere la realización de cambios de emergencia, y cuando sea posible, se debería
seguir el proceso de cambio, aunque algunos detalles se documenten a posteriori. Cuando el proceso de emergencia se salte algunos requisitos del proceso de gestión de cambios, el cambio debería cumplir
estos requisitos tan pronto como sea posible. Los cambios de emergencia se deberían justificar por quien los implementa y deberían ser revisados después del cambio para verificar que era una verdadera
emergencia.
Informes, análisis y acciones de la gestión de cambios Los registros de los cambios se deberían analizar de forma periódica, para detectar incrementos en el
nivel de cambios, frecuencia de los tipos recurrentes, tendencias emergentes y cualquier otra información relevante. Los resultados y las conclusiones derivados del análisis de los cambios se deberían registrar y
actuar sobre ellos.
La Figura 4.2.8 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos.
Las actividades básicas del proceso de gestión de cambios consisten en registrar, aceptar y clasificar solicitudes de cambio. Si un cambio es autorizado, se tiene que programar, implantar, cerrar y
revisar. Los documentos exigidos explícitamente para la gestión de cambios son los registros de cambio y los registros para acciones de mejora. Una solicitud de cambio puede proceder de otros
procesos, de un usuario o de un empleado. Estas interfaces con el proceso de gestión de cambios tienen que estar debidamente documentadas, al igual que la interfaz de la gestión de cambios con
el proceso de mejora continua.
Guía
El proceso de gestión de cambios aprueba o rechaza todas las Solicitudes de Cambios RFC. El proceso está dirigido por el gestor de cambios, aunque las decisiones sobre los cambios más
significativos se adoptan en el Comité de Cambios CAB. El CAB incluye miembros de muchas partes de la organización, así como clientes y suministradores. La gestión de la configuración se
encarga de proporcionar información sobre el impacto potencial de cada cambio propuesto.
Las entradas de la gestión de cambios son: •
RFCs procedentes de clientes, legislación o suministradores. •
Información de la CMDB específicamente, el análisis de impacto de los cambios. •
Información procedente de otros procesos, como gestión de problemas y gestión de la capacidad.
• Planificación de cambios Lista de Cambios Planificados, FSC.
Las salidas del proceso son: •
Lista actualizada de cambios FSC •
Disparadores para gestión de la configuración y gestión de entregas •
Orden del día, actas y decisiones del CAB •
Informes de gestión de cambios
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Planificar la gestión de
cambios Todos los cambios
de emergencia tienen que acabar
siguiendo el proceso de cambio
estándar
Utilizar como entrada para SIP
Con un alcance bien definido y
documentado para cambios en servicio
e infraestructura
Comunicar la programación a las
partes afectadas
Registros de acciones de mejora
Registros de análisis de cambios
Incluye el impacto sobre:
- Planes de disponibilidad y
continuidad y documentos
relacionados - Controles de
seguridad - Evaluaciones de
riesgos para la seguridad
Solicitud de cambio RFC
Controlar los cambios
introducidos en SLAs y otros
contratos Controlar la
implantación y el retiro de servicios
Incluida revisión post-implantación
Definir políticas y procedimientos
para controlar los cambios de
emergencia
Registrar RFC Clasificar RFC:
evaluar riesgo, impacto, beneficio
para el negocio y coste
Aprobar y comprobar el
cambio Programación de
cambios Programar el
cambio Implantar el
cambio Revertir o corregir
los cambios fallidos
Registros de cambios
Registros de acciones de mejora
Analizar registros de cambios y
revisar el cambio Política y
procedimiento para cambios de
emergencia
Registros de cambios
Programación de cambios
actualizada Registros de RFC
Interfaces: Todos los procesos relevantes:
- Presentar solicitudes de cambio Mejora continua Actuar:
- Sugerir mejoras para SIP Planificación e implantación de
servicios nuevos o modificados: - Planificar y aprobar la
implantación de servicios nuevos o modificados,
incluyendo la financiación y los recursos adecuados; con
aceptación formal Gestión de la configuración:
- Programar auditorías de configuración antes y después
de cambios importantes Gestión de entregas:
- Controlar la implantación de servicios
- Valorar el impacto de las solicitudes de cambios sobre
los planes de entrega - Actualizar registros de cambios
- Gestionar entregas de emergencia según el proceso
de gestión de cambios de emergencia
Gestión del nivel de servicio: - Controlar los cambios
introducidos en SLAs y otros contratos
Informes del servicio: - Recibir información
Presupuestos y contabilidad: - Presupuesto y contabilidad de
todos los componentes - Estimar el coste y aprobar
cambios en servicios Gestión de relaciones con el
negocio: - Gestionar los cambios
introducidos en contratos en su caso y SLAs
Gestión de proveedores: - Gestionar los cambios
introducidos en contratos y SLAs
Gestión de la disponibilidad y la continuidad del servicio:
- Evaluar el impacto de cualquier cambio sobre el plan de
disponibilidad y continuidad del servicio
- Controlar todos los cambios introducidos en la
documentación de disponibilidad y continuidad
del servicio - Vincular la documentación con
la gestión de cambios Gestión de la seguridad de la
información: - Valorar el impacto de los
cambios sobre los controles de seguridad antes de implantar
los cambios - Realizar evaluaciones de
riesgos para la seguridad - Evitar que los cambios
reduzcan la eficacia de los controles
Figura 4.2.8 Gestión de cambios
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
La gestión de cambios utiliza las siguientes actividades para el procesamiento de cambios Figura 4.2.9:
• Registro
• Aceptación
• Clasificación
• Planificación y aprobación
• Coordinación
• Evaluación
Coordinación Aceptación;
Filtrado de RFCs
Clasificación; categoría y prioridad
Planificación; impacto y recursos
Evaluación y cierre No
Sí Procedimientos
de urgencia
Iniciar plan de marcha atrás
No Presentación de RFC;
Registro
Construcción Pruebas
Implantación
Sí Rechazo; posible
RFC nueva
Puede ser iterativo
¿Funciona? ¿Es urgente?
Figura 4.2.9 Actividades de la gestión de cambios según ITIL V2
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
En primer lugar hay que registrar todas las RFCs. Si se presenta una RFC para resolver un problema, también se debe registrar el número del error conocido.
No todas las solicitudes de modificación se tratan como cambios; algunas tareas de gestión rutinarias, que están claramente definidas y cubiertas por procedimientos cambios estándar
pero que no implican la modificación de la infraestructura, se pueden tratar como si fueran peticiones de servicio. El resultado es la siguiente clasificación de cambios:
• Cambios estándar como peticiones de servicio - Cuando existen modelos de cambios
aprobados y perfectamente definidos que se registran individualmente, pero que no son evaluados individualmente por la gestión de cambios; estos cambios son rutinarios. Nota: No
todas las peticiones de servicio son cambios.
• Cambios no estándar - Todas las demás modificaciones de la infraestructura gestionada que
no son cambios estándar. Entre la información que puede contener una RFC figura la siguiente:
• Número de identificación de la RFC.
• Número del error conocidoproblema asociado en su caso.
• Descripción e identificación de los correspondientes CIs.
• Motivo del cambio, incluidos justificación y beneficio para el negocio.
• Versión actual y nueva de los CIs que se vayan a cambiar.
• Nombre, ubicación y número de teléfono de la persona que presenta la RFC.
• Fecha de presentación.
• Estimación de recursos y escalas de tiempo.
Una vez registradas las RFCs, la gestión de cambios llevará a cabo una valoración inicial para comprobar si alguna de las RFCs está poco clara o si es ilógica, impracticable o innecesaria. Estas
solicitudes son rechazadas especificando el motivo para ello. La persona que haya presentado la solicitud debe tener siempre la oportunidad de defender su posición.
Un cambio conduce a la modificación de los datos en la CMDB; por ejemplo: •
Un cambio en el estado de un CI existente. •
Un cambio en la relación entre un CI y otros CIs. •
Un nuevo CI o una variación de un CI existente. •
Un nuevo propietario o ubicación de un CI. Si la RFC es aceptada, la información necesaria para seguir adelante con el procesamiento del
cambio se incluye en un registro de cambio.
En primer lugar se determinan la prioridad y la categoría:
• La prioridad indica la importancia de un cambio en relación con otras RFCs. Puede variar
entre baja y alta máxima y depende de la urgencia, la escala de tiempos y la necesidad de cambio para el negocio.
• La categoría se determina en función del impacto del cambio sobre el riesgo para los servicios
y la disponibilidad de recursos. El impacto puede oscilar entre leve y grave.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Posteriormente se añade al registro la siguiente información: •
Recomendaciones del gestor de cambios •
Fecha y hora de la autorización •
Fecha prevista para la implantación del cambio •
Planes de back-up •
Requisitos de soporte •
Plan de implantación •
Información sobre los encargados de la construcción y la implantación •
Fecha y hora reales del cambio •
Fecha de la evaluación •
Resultados de pruebas y problemas detectados •
Motivos para rechazar la solicitud en su caso •
Información sobre la evaluación y el escenario La gestión de cambios planifica los cambios mediante un calendario o Lista de Cambios Planificados
FSC. La FSC contiene detalles de todos los cambios aprobados y las fechas previstas para su implantación. Los miembros del CAB asesoran sobre la planificación de cambios importantes, la
disponibilidad de personal, los costes y los aspectos afectados del servicio, además de garantizar la participación de los clientes. El CAB funciona así como un comité asesor. La gestión de cambios
goza de una autoridad delegada, ya que actúa en representación de la dirección de TI. Es posible que los cambios más importantes tengan que ser aprobados por la dirección de TI antes de llegar
al CAB. Esta aprobación puede incluir aspectos financieros, técnicos y de negocio.
Para que la planificación resulte eficaz es necesario que la gestión de cambios se mantenga en contacto con las oficinas del proyecto y con todos los demás miembros de la organización
encargados de construir e implantar los cambios. También la comunicación del plan de cambios se tiene que realizar con la máxima eficacia.
Previa consulta con los departamentos de TI afectados, el CAB puede especificar ventanas de tiempo periódicas para la implantación de cambios aprovechando los momentos que minimicen
el impacto sobre el servicio. Los mejores momentos podrían ser los fines de semana o fuera del horario habitual de oficina. Del mismo modo se pueden establecer períodos durante los cuales no
esté permitido realizar cambios o sólo unos pocos, como durante las horas de oficina o al final del año fiscal, cuando todos los departamentos de usuarios están cerrando sus cuentas.
La información sobre la planificación de un cambio se debe distribuir antes de la reunión del CAB, al igual que los documentos relevantes para los puntos del orden del día.
• El orden del día de las reuniones del CAB tiene que incluir algunos puntos fijos, como:
• Cambios no autorizados
• Cambios autorizados que no hayan sido presentados al CAB
• RFCs que deban ser valoradas por los miembros del CAB
• Cambios abiertos y cerrados
• Evaluaciones de cambios anteriores
A la hora de estimar los recursos necesarios y el impacto del cambio, los miembros del CAB, el gestor de cambios y todas las demás partes involucradas identificadas por el CAB deben tener
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
en cuenta los siguientes aspectos: •
Capacidad y rendimiento de los servicios afectados •
Fiabilidad y capacidad de recuperación •
Planes de gestión de la continuidad de los servicios de TI •
Planes de marcha atrás •
Seguridad •
Impacto del cambio sobre otros servicios •
Registros y aprobación •
Costes y recursos necesarios soporte y mantenimiento •
Número y disponibilidad de los especialistas necesarios •
Duración necesaria del ciclo del cambio •
Nuevos recursos que deban ser adquiridos y probados •
Impacto sobre las operaciones •
Posibles conflictos con otros cambios Los miembros del CAB también pueden asesorar sobre la prioridad.
Los cambios aprobados se comunican a los especialistas en los productos correspondientes para que puedan construir e integrar los cambios. La construcción puede incluir la creación de una
nueva versión de software con nueva documentación, manuales, procedimientos de instalación, un plan de marcha atrás y cambios de hardware. La gestión de cambios se encarga del control y la
coordinación. Para ello cuenta con el apoyo de la gestión de entregas y la dirección de línea, que tienen que garantizar que se han asignado los recursos apropiados para implantar los planes.
Como parte de la entrega de un cambio se debe redactar un procedimiento de marcha atrás para invertir el cambio si no ofrece el resultado necesario. La gestión de cambios no debería aprobar
el cambio si no existe un procedimiento de marcha atrás. También es necesario redactar un plan de comunicación en caso de que el cambio tenga algún impacto sobre el entorno del usuario.
Durante la fase de construcción se prepara igualmente un plan de implantación.
El procedimiento de marcha atrás, la implantación del cambio y el resultado previsto del cambio se tienen que someter a pruebas completas, teniendo en cuenta los criterios definidos anteriormente
por el CAB. En la mayor parte de los casos, las pruebas requieren un laboratorio o un entorno de pruebas independiente. Las primeras fases de las pruebas pueden ser realizadas por los encargados
de la construcción, pero no se debe implantar ningún cambio sin someterlo a algunas pruebas independientes. Estas pruebas suelen ser de dos tipos:
• Pruebas de aceptación del usuario - La comunidad del negocio el cliente del cambio, por lo
general prueba la funcionalidad del cambio. •
Pruebas de aceptación de operaciones - Pruebas independientes realizadas por los encargados del soporte y mantenimiento de la infraestructura modificada, como el centro de atención al
usuario.
Si no se puede probar un cambio de forma adecuada, es posible que se pueda aplicar el cambio a un pequeño grupo piloto de usuarios para evaluar los resultados antes de implantarlo a una
escala mayor.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Cualquier miembro del departamento afectado que sea responsable de gestionar la infraestructura de TI puede recibir el encargo de implantar un cambio en esa infraestructura. La gestión
de cambios tiene que hacer que se cumpla el programa del cambio. Debe existir un plan de comunicación que indique claramente a quién se tiene que informar del cambio por ejemplo,
los usuarios, el centro de atención al usuario y la gestión de red.
Con la posible excepción de los cambios estándar, todos los cambios implantados se tienen que evaluar. El CAB decide si es necesario efectuar algún seguimiento. Para ello se deben tener en
cuenta las siguientes cuestiones: •
¿Ha conducido el cambio al objetivo deseado? •
¿Están los usuarios satisfechos con el resultado? •
¿Ha habido algún efecto secundario? •
¿Se han superado los esfuerzos y los costes estimados? •
¿Se han cumplido los plazos? •
¿Qué ha salido mal? La RFC se puede cerrar si el cambio ha tenido éxito. Los resultados se incluyen en la Revisión Post-
Implantación PIR o en la evaluación del cambio. Si, por el contrario, el cambio no ha tenido éxito, el proceso se reinicia en el punto en que falló utilizando un método distinto. Normalmente
es aconsejable dar marcha atrás en el cambio y crear una nueva RFC basada en la RFC original, puesto que seguir adelante con un cambio frustrado suele empeorar más las cosas.
El uso de procedimientos de evaluación con un límite de tiempo concreto puede ayudar a impedir que se ignoren las evaluaciones de cambios. Dependiendo de la naturaleza del cambio,
la evaluación se puede realizar al cabo de unos días o de unos meses.
Por muy buena que sea la planificación, siempre puede haber cambios que tengan una prioridad absoluta. Los cambios urgentes son muy importantes y se deben llevar a cabo lo antes posible. En
la mayor parte de los casos es necesario desviar para estos cambios los recursos dedicados a otras actividades. Los cambios urgentes pueden tener un gran impacto sobre el trabajo planificado. Por
lo tanto, el objetivo es que el número de cambios urgentes o imprevistos prioridad “máxima” sea lo más bajo posible. Algunas medidas preventivas consisten en:
• Garantizar que los cambios se soliciten a tiempo, antes de que pasen a ser urgentes.
• Al corregir errores debidos a un cambio mal preparado, no se debe revertir la situación más
allá de una versión anterior llamada Estado Previo de Confianza; posteriormente se tiene que preparar con todo cuidado una implantación mejorada del cambio.
A pesar de estas medidas, existe la posibilidad de que surjan cambios urgentes que requieran procedimientos para tratarlos con rapidez y sin que la gestión de cambios pierda el control
del proceso. Si hay tiempo suficiente, el gestor de cambios puede organizar una reunión de emergencia del CAB en la que participen únicamente los miembros necesarios para evaluar,
autorizar y asignar recursos para el cambio. Si no se dispone de tiempo, o si la petición se presenta fuera del horario de oficina, tiene que haber un método alternativo para obtener la autorización.
El proceso CABEC no tiene que ser necesariamente una reunión en persona, sino que también puede tratarse de una llamada telefónica.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Es posible que no haya tiempo suficiente para realizar las pruebas normales, por lo que después de la implantación se deben ejecutar todas las fases necesarias de los procedimientos normales
de prueba. De esta forma se garantiza la realización de las pruebas omitidas anteriormente, la actualización de los archivos registros de cambios y CMDB y la posibilidad de efectuar un
seguimiento del cambio “¿qué es lo que ha cambiado?”.
El objetivo de la gestión de cambios es conseguir un equilibrio entre flexibilidad y estabilidad. Para reflejar la situación de la organización en cada momento se pueden preparar informes de
gestión que cubran los siguientes aspectos: •
Número de cambios implantados en un período en total y para cada categoría de CI •
Lista de causas de cambios y RFCs •
Número de cambios implantados con éxito •
Número de marchas atrás y sus motivos •
Número de incidencias relacionadas con los cambios implantados •
Gráficos y análisis de tendencias en períodos determinados Los KPIs para la gestión de cambios son:
• Número de cambios realizados por unidad de tiempo y categoría
• Velocidad de implantación de cambios
• Número de cambios rechazados
• Número de incidencias debidas a cambios
• Número de marchas atrás relacionadas con cambios
• Coste de los cambios implantados
• Número de cambios realizados dentro del plazo y con los recursos previstos
Es posible combinar varias RFCs en una sola entrega, en cuyo caso un único plan de marcha atrás será suficiente si algo va mal. Este tipo de entrega conjunta puede ser considerada un cambio en sí
misma aunque conste de varios cambios, cada uno de los cuales debe ser aprobado por separado. La implantación de entregas corresponde a la gestión de entregas, que se discute en la siguiente
sección.
4.2.4 Proceso de gestión de entregas 10.1
Objetivo: Entregar, distribuir y realizar el seguimiento de uno o más cambios en la entrega en el entorno de producción.
Las especificaciones ISO 20000-1 dicen:
NOTA: El proceso de gestión de entregas se debería integrar con los procesos de gestión de la configuración y de gestión de cambios.
Se debe documentar y acordar la política de entrega que establezca la frecuencia y el tipo de la entregas.
El proveedor del servicio debe planificar con el negocio la entrega de los servicios, sistemas, software y hardware.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Los planes sobre cómo desplegar una entrega se deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes, usuarios, personal de operaciones y de soporte.
El proceso debe incluir la forma en que se dé marcha atrás o se corrige la entrega si no se realiza con éxito.
Los planes deben registrar los entregables y las fechas de la entrega, y hacer referencia a las peticiones de cambio, errores conocidos y problemas relacionados. El proceso de gestión de
entregas debe proporcionar la información adecuada al proceso de gestión de incidencias.
Las peticiones de cambio se deben evaluar en cuanto a su impacto en los planes de entregas. Los procedimientos de gestión de entregas deben incluir la actualización y el cambio de la
información de configuración y los registros de cambio. Las entregas de emergencia se deben gestionar de acuerdo a un proceso definido que realice la interfaz con el proceso de gestión de
cambios de emergencia.
Se debe establecer un entorno controlado de pruebas de aceptación para construir y probar todas las entregas previamente a su distribución.
Las entregas y su distribución se deben diseñar e implementar de forma que la integridad del hardware y del software se mantenga a lo largo de la instalación, la manipulación, el
empaquetado y la provisión.
Se debe medir el éxito y el fallo de las entregas. Las mediciones deben incluir las incidencias relacionados con la entrega en el periodo siguiente a su despliegue. Los análisis deben incluir
la evaluación del impacto en el negocio y en el personal de operación y soporte de TI, y deben proporcionar información de entrada al plan para la mejora del servicio.
El Código de buenas prácticas ISO 20000-2 dice:
Generalidades La gestión de entregas debería coordinar las actividades del proveedor del servicio, los diferentes
proveedores y el negocio para planificar y desplegar una entrega a lo largo de un entorno distribuido.
Son esenciales una buena planificación y gestión para empaquetar y distribuir una entrega con éxito, y para gestionar los impactos y riesgos asociados al negocio y a las TI. Se debería planificar con el
negocio la entrega de los sistemas de información, las infraestructuras, los servicios y la documentación afectados.
Todas las actualizaciones asociadas a la documentación se deberían incluir en la entrega, por ejemplo: los procesos de negocio, los documentos de apoyo y los acuerdos de nivel de servicio.
Se debería evaluar el impacto de todos los elementos de configuración, nuevos o cambiados, requeridos para efectuar los cambios autorizados.
El proveedor del servicio se debería asegurar que los aspectos técnicos y no técnicos de la entrega son considerados de forma conjunta.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Los elementos de la entrega deberían poder ser trazables y no ser modificables. Sólo se deberían aceptar en el entorno de producción las entregas adecuadas, probadas y aprobadas.
Política de entrega Debería existir una política de entrega que incluya:
a La frecuencia y tipos de entregas. b Los roles y las responsabilidades para la gestión de entregas.
c La autoridad para pasar la entrega a los entornos de pruebas de aceptación y de la producción. d Una identificación y descripción única para todas las entregas.
e Una aproximación en torno a la agrupación de los cambios en una entrega. f Una aproximación para la automatización de los procesos de construcción, instalación, y distribución
de la entrega para ayudar a su receptibilidad y a su eficiencia. g La verificación y la aceptación de una entrega.
Planificación de la entrega y del despliegue El proveedor del servicio debería trabajar conjuntamente con el negocio para asegurar que los elementos
de configuración que se van a desplegar en una entrega son compatibles entre sí y con los elementos de configuración del entorno de destino.
La planificación de la entrega debería asegurar que los cambios de los sistemas de información, infraestructuras, servicios y documentación afectados son acordados, autorizados, programados,
coordinados y que se realiza un seguimiento de los mismos.
La entrega y el despliegue se deberían planificar en etapas ya que los detalles del despliegue podrían no ser conocidos inicialmente.
La planificación de una entrega y del despliegue normalmente debería incluir: a Las fechas de la entrega y la descripción de los entregables.
b Los cambios y problemas relacionados, errores conocidos cerrados o resueltos por esta entrega y errores conocidos que hayan sido identificados durante las pruebas de la entrega.
c Los procesos relacionados para la implementación de una entrega a lo largo de todo el negocio y las diferentes unidades geográficas.
d El modo en el que se dará marcha atrás de la entrega o en que ésta se remediará si no se concluye con éxito.
e Los procesos de verificación y aceptación. f La comunicación, preparación, documentación y formación para los clientes y personal de apoyo.
g La logística y los procesos implicados para realizar la compra, el almacenamiento, la expedición, la conexión, la aceptación y la puesta a disposición de los bienes.
h Los recursos de apoyo necesarios para asegurar el mantenimiento de los niveles de servicio. i La identificación de dependencias, los cambios relacionados y los riesgos asociados que pueden
perjudicar el paso sin complicaciones de una entrega a los entornos de pruebas de aceptación y de producción.
j La autorización de la entrega. k El calendario de auditorías del entorno de producción cuando sea necesario asegurar, para
actualizaciones de gran tamaño, que el entorno de producción está en el estado esperado en el momento de instalar la entrega.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Desarrollo o compra de software Se deberían verificar en el momento de la recepción, las entregas de sistemas de información y de
software provenientes de equipos de desarrollo propios, desarrolladores de sistemas, integradores u otras organizaciones. El proceso completo se debería documentar en el plan de gestión de la configuración.
Diseñar, construir y configurar una entrega Los procesos de gestión de entregas y distribución se deberían diseñar e implementar para:
a Asegurar que existe conformidad con la arquitectura de sistemas, la Gestión del Servicio y las normas de infraestructura del proveedor del servicio.
b Mantener la integridad durante la construcción, instalación, manipulación, empaquetado y entrega.
c Usar bibliotecas de software y repositorios relacionados para gestionar y controlar los componentes durante los procesos de construcción y de entrega.
d Asegurar que los riesgos estén claramente identificados y que se pueden llevar a cabo acciones de recuperación si se requieren.
e Habilitar verificaciones antes de la instalación para comprobar que la plataforma de destino satisface los requisitos previos.
f Habilitar verificaciones que se comprueben que una entrega está completa cuando llega a su destino.
Las salidas de este proceso deberían incluir las notas de la entrega, las instrucciones de instalación y el software instalado y hardware ya instalados, en relación a la línea de referencia de la configuración.
Las salidas de la entrega se deberían entregar al grupo responsable de las pruebas.
Los procesos de construcción, gestión de entregas y distribución se deberían automatizar para reducir errores, asegurando que el proceso es repetible y que se pueden desplegar rápidamente las nuevas
entregas.
Verificación y aceptación de la entrega El resultado final debería ser una aprobación basada en el grado en el que el paquete completo de la
entrega recoge la totalidad de los requisitos.
Los procesos de verificación y aceptación deberían: a Verificar que el entorno controlado de las pruebas de aceptación se ajusta a los requisitos del entorno
de producción de destino. b Asegurar que la entrega se ha creado a partir de versiones bajo el control de gestión de la configuración
y que se han instalado en el entorno de pruebas de aceptación usando el proceso de producción planificado.
c Verificar que se ha completado el nivel adecuado de pruebas, por ejemplo, pruebas funcionales y no funcionales, pruebas de aceptación por el negocio, pruebas en los procedimientos de construcción,
despliegue de versiones, distribución e instalación. d Asegurar que la entrega es probada y satisfacce las necesidades de los clientes del negocio y del
personal del proveedor del servicio. e Asegurar que la autoridad apropiada en cuanto a la gestión de entregas aprueba cada etapa de las
pruebas de aceptación.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
f Verificar antes de la instalación que la plataforma de destino satisface los requisitos previos de software y hardware.
g Verificar que la entrega está completa cuando llega a su destino.
Documentación La documentación apropiada debería estar disponible en su totalidad y almacenada según la gestión
de la configuración en referencia al elemento de configuración desplegado. Esta documentación debería incluir:
a La documentación de apoyo, por ejemplo, los acuerdos de nivel de servicio. b La documentación de apoyo, por ejemplo, la esquema del sistema, los procedimientos de instalación
y de soporte, las ayudas para el diagnóstico y las instrucciones de operación y administración. c Los procesos de construcción, despliegue de versiones, instalación y distribución.
d Los planes de contingencia y marcha atrás. e La planificación de la formación para los responsables del servicio, el personal de apoyo y los
clientes. f Una línea de referencia de la configuración para la entrega, incluyendo elementos de configuración
asociados tales como documentación del sistema, entornos de pruebas, documentación de pruebas y versiones de las herramientas de construcción y desarrollo.
g Los cambios, problemas y errores conocidos relacionados. h Las evidencias de la autorización de la entrega y las evidencias relacionadas de la verificación y la
aceptación. Si un sistema o servicio no cumple completamente con los requisitos especificados, antes de pasar a
producción se debería identificar y registrar mediante la gestión de la configuración y la gestión de problemas. La información sobre errores conocidos se debería comunicar a la gestión de incidencias. Si
la entrega es rechazada, retrasada o cancelada, se debería informar a la gestión de cambios.
Despliegue, distribución e instalación Se debería revisar el plan de despliegue y se deberían añadir detalles, si es necesario, para asegurar que
se van a llevar a cabo todas las actividades necesarias.
Es importante que la entrega sea ejecutada de un modo seguro para su destino en el estado esperado. Los procesos de despliegue, distribución e instalación deberían asegurar que:
a Todas las zonas de almacenamiento de hardware y software son seguras. b Existen procedimientos adecuados para el almacenamiento, expedición, recepción y eliminación de
bienes. c Se planifican y completan las comprobaciones sobre las instalaciones físicas, el entorno, las
instalaciones eléctricas y otros servicios. d Se notifican las nuevas entregas al personal del negocio y del proveedor del servicio.
e Se eliminan los productos, servicios y licencias que quedan sin utilidad tras la nueva entrega. Después de una distribución de software en una red es esencial comprobar que la entrega está completa
y es operativa cuando llega a su destino. Los registros de activos y de la gestión de la configuración se deberían actualizar con la ubicación y el
propietario del software y el hardware tras una instalación llevada a cabo con éxito.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Se debería usar un cuestionario de satisfacción y aceptación por parte del cliente de la instalación para registrar el éxito o el fracaso de dicha instalación.
Todos los resultados de las encuestas de satisfacción de los clientes deberían constituir una realimentación para la gestión de las relaciones con el negocio.
Post-implantación y despliegue de la entrega Se debería medir y analizar el número de incidencias relacionadas con una entrega en el periodo
inmediatamente posterior a un despliegue para evaluar su impacto en el negocio, en las operaciones y en los recursos de personal de apoyo.
El proceso de gestión de cambios debería incluir una revisión post-implantación Las recomendaciones se deberían incluir en un plan de mejora del servicio.
La Figura 4.2.10 muestra cómo se puede visualizar esta parte de la norma mediante un flujo de procesos.
Los pasos principales del proceso de gestión de entregas son: desarrollo de una política de entregas; diseño, construcción y configuración; pruebas y aceptación; despliegue, distribución
e instalación; y comprobación de la entrega. Las salidas de la comprobación de la entrega son registros del éxito o el fracaso de la entrega, que a su vez pasan a ser entradas para un plan de
mejora del servicio. El único documento exigido explícitamente para la gestión de entregas es la política de entregas, mientras que los únicos registros que se exigen son los de fechas de entrega y
entregables, con referencia a solicitudes de cambio, errores conocidos y problemas relacionados.
ISO 20000 define tres interfaces para el proceso de entrega: 1. Con el proceso de gestión de cambios - Para evaluar el impacto de las solicitudes de cambio
sobre los planes de entrega. 2. Con el proceso de gestión de cambios - Para actualizar los registros de cambios.
3. Con el proceso de gestión de emergencias - Para gestionar entregas de emergencia. Las otras interfaces definidas son la interfaz con el proceso de gestión de incidencias para transmitir
la información adecuada y la interfaz con el proceso de gestión de la configuración para actualizar los registros de información sobre activos y configuraciones.
Guía
Como ya se ha dicho, es posible combinar varias RFCs en una sola entrega. Las entregas pueden estar planificadas con un objetivo funcional para el negocio, generalmente como entregas de
mantenimiento de aplicaciones concretas. Pueden incluir hardware y software y su implantación es responsabilidad de la gestión de entregas. Es aconsejable definir una política para esta área y
comunicarla a la organización de TI y a los clientes. El objetivo de la política debe ser evitar las interrupciones innecesarias para el usuario “rehacer el camino todas las semanas”.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Especifica la frecuencia y el tipo
de las entregas Política de entregas
Utilizar como entrada para SIP
Plan de entrega y despliegue
Especifica la manera en que se va a revertir
o corregir la entrega en caso de no tener
éxito Registra fechas de
entrega y entregables, con referencia a las
correspondientes solicitudes de
cambios, errores conocidos y
problemas
En un entorno controlado de
pruebas de aceptación
Incluyen:- - Medidas de
incidencias relacionadas con la
entrega - Evaluación del
impacto sobre los recursos del personal
de soporte, operaciones de TI y
negocio Registros de
éxitos y fracasos de la entrega y
oportunidades de mejora
Incluye planes para comunicación,
preparación y formación
Incluyendo el software adquirido
Notas de la entrega Instrucciones de
instalación Línea base de
configuración
Documentación: - Documentación de
soporte, como SLAs, listas de sistemas,
procedimientos de instalación y soporte,
herramientas de diagnóstico o
instrucciones de operación y
administración - Procesos de
construcción, entrega, instalación
y distribución - Planes de
contingencia y marcha atrás
- Programas de formación
- Línea base de configuración
- Cambios, problemas y errores conocidos
relacionados - Evidencia de
autorización, verificación y
aceptación Incluye
actualizaciones de toda la
documentación asociada
Visado Informe de faltas
de conformidad para gestión de
problemas y gestión de
incidencias Visado por la
autoridad de entregas
Interfaz definida con el proceso de gestión
de cambios de emergencia
Evaluar el impacto de RFCs sobre el
plan de entrega Documentar y
definir la política de entregas
Planificar el despliegue de la
entrega e informar a gestión de
incidencias Diseñar, construir
y configurar la entrega
Notas de la entrega Instrucciones de
instalación Línea base de
configuración Plan de despliegue
Probar y aceptar la entrega
Identificar y registrar faltas de
conformidad errores conocidos
con los requisitos Desplegar,
distribuir e instalar la entrega
emergencia Encuesta de
clientes Medir y analizar
el éxito de la entrega
Corregirrevertir la entrega si no
tiene éxito Requisitos
Registros de éxitos y fracasos
de la entrega y oportunidades de
mejora Actualizar los
registros de cambios y la
configuración Certificar la
completitud y el cumplimiento
de requisitos Interfaces:
Mejora continua Actuar: - Sugerir mejoras para SIP
Gestión de la configuración: - Actualizar registros de
información sobre activos y configuraciones
Gestión de cambios: - Evaluar el impacto de RFCs
sobre los planes de entrega - Actualizar registros de
cambios - Gestionar entregas de
emergencia según el proceso de gestión de
cambios de emergencia Informes del servicio:
- Recibir información Presupuestos y contabilidad:
- Presupuesto y contabilidad de todos los componentes
Gestión de incidencias: - Intercambiar la
información relevante Crear el entorno
de pruebas de aceptación
Figura 4.2.10 Gestión de entregas
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
El proceso de gestión de entregas incluye las siguientes actividades: •
Política y planificación de entregas •
Diseño, construcción y configuración de entregas •
Pruebas y aceptación de entregas •
Planificación de despliegue •
Comunicación, preparación y formación •
Distribución e instalación de entregas Estas actividades no siempre se ejecutan en el orden indicado. La política y planificación de
entregas se puede definir cada seis meses o un año, mientras que otras actividades suelen ser diarias. La Figura 4.2.11 muestra las actividades de la gestión de entregas.
Para cada sistema, el gestor de entregas debe desarrollar una política de entregas en la que se defina cómo y cuándo se configuran las entregas. Las entregas más importantes se pueden planificar
por anticipado junto con el número de versión o la identificación de la entrega, de forma que los cambios se puedan incorporar en los momentos más adecuados.
El gestor de entregas también especifica a qué nivel es posible distribuir CIs de forma independiente unidades de entrega. Esto depende de la naturaleza del sistema sometido a control de entregas:
• El impacto potencial de la entrega sobre otros componentes.
• El número de personas-horas y la duración del ciclo para construir y probar cambios aislados,
comparado con el esfuerzo que conlleva compilarlos e implantarlos de forma simultánea. •
La dificultad de la instalación en los centros de los usuarios. •
La complejidad de las dependencias entre el nuevo software y hardware y el resto de la infraestructura de TI; cuanto más fácil resulte aislar el software o hardware, más sencillo será
probarlo.
Antes de planificar una entrega es necesario reunir información sobre el ciclo de vida del producto, los productos que se deben entregar, la descripción del servicio de TI relevante y los niveles de
servicio, junto con la autorización de las correspondientes RFCs.
Planificación de
entregas
Entorno de desarrollo
Entorno controlado de pruebas
Entorno de producción
Política de
entregas Diseño y
desarrollo o pedido y
adquisición de software
Construcción y configura
ción de la entrega
Pruebas de ajuste
al propósito
Comunicación, preparación
y formación Distribución
e instalación
Base de Datos de Gestión de la Configuración CMDB y
Biblioteca de Software Definitivo DSL Gestión de entregas
Aceptación de la
entrega Planificación
de despliegue
Figura 4.2.11 Actividades de la gestión de entregas según ITIL V2 Fuente: OGC
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
La planificación de una entrega debe incluir los siguientes puntos: •
Coordinar los contenidos de la versión. •
Acordar el programa, los centros y las unidades organizativas. •
Confeccionar el calendario de entrega. •
Preparar un plan de comunicación. •
Realizar visitas para determinar el hardware y software que se está utilizando. •
Definir roles y responsabilidades. •
Obtener presupuestos detallados y negociar con los suministradores sobre nuevo hardware, software y servicios de instalación.
• Preparar planes de marcha atrás.
• Preparar un plan de calidad para la entrega.
• Planificar la aceptación de la entrega por la organización de gestión y los usuarios.
Los resultados de esta actividad forman parte del plan de cambio e incluyen planes para la entrega, planes de pruebas y criterios de aceptación.
Es conveniente desarrollar procedimientos estándar para diseñar, construir y configurar entregas. Una entrega puede estar basada en conjuntos de componentes CIs desarrollados por la
propia organización o adquiridos a terceros y configurados. Las instrucciones de instalación y configuración de entregas también se deben considerar parte de la entrega y se pondrán, como
CIs, bajo el control de la gestión de cambios y la gestión de la configuración.
Es recomendable configurar y probar todo el hardware y software en un entorno de pruebas antes de su instalación definitiva. La configuración y el registro de los componentes software y hardware
de una entrega se deben realizar con el máximo cuidado para garantizar su reproducibilidad. Se tienen que redactar instrucciones de operación para utilizar siempre el mismo conjunto de
elementos de configuración. Es frecuente que se reserve hardware normalizado para utilizarlo exclusivamente en la compilación o creación de imágenes. Es aconsejable automatizar esta parte
del proceso para que sea más fiable. En entornos de desarrollo de software, esta actividad se conoce con el nombre de gestión de construcción y es responsabilidad de la gestión de entregas.
Un plan de marcha atrás a nivel de toda la entrega define las actividades necesarias para recuperar el servicio en caso de que haya algún problema con la entrega. La creación de planes de marcha atrás
es responsabilidad de la gestión de cambios, aunque la gestión de entregas tiene que colaborar para garantizar la viabilidad de dichos planes. Lo mejor es satisfacer por adelantado los requisitos
del plan de marcha atrás, como realizar copias de seguridad o disponer de un segundo servidor. El plan de marcha atrás tiene que estar incluido en el análisis de riesgos del cambio y debe haber
sido aceptado por los usuarios.
El proceso de construcción de la entrega puede incluir la compilación y vinculación de módulos software o el llenado de bases de datos con datos de pruebas o de otro tipo, como tablas de
códigos postales, tasas de impuestos, zonas horarias o tablas de divisas, además de información de usuarios. Para ello es frecuente utilizar guiones de instalación automatizados, que se guardan en la
DSL junto con los planes de marcha atrás. Las entregas completas deben estar identificadas en la CMDB como configuraciones estándares para facilitar su uso ante futuros requisitos. Los planes
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
de pruebas cubren la prueba y aceptación de la calidad del software, hardware, procedimientos, instrucciones de operación y guiones de despliegue antes de la entrega, y posiblemente también
su evaluación después de la entrega. Igualmente se deben probar los guiones de instalación. La información necesaria para esta actividad incluye:
• Definición de la entrega
• Calendario de entrega
• Instrucciones para configurar y construir la entrega
• Descripción de los elementos que hay que comprar o para los que se debe adquirir una
licencia •
Guiones de instalación automatizados y planes de pruebas •
Copias originales del software para su inclusión en la DSL •
Procedimientos y planes de marcha atrás Antes de la implantación, la entrega debe ser sometida a una prueba funcional por representantes
de los usuarios y a una prueba operativa por personal de gestión de TI, quienes tendrán en cuenta la operación técnica, las funciones, los aspectos operativos, el rendimiento y la integración con
el resto de la infraestructura. Las pruebas deben incluir también los guiones de instalación, los procedimientos de marcha atrás y cualquier cambio que se introduzca en los procedimientos de
gestión. Cada uno de los pasos tendrá que ser aceptado formalmente por la gestión de cambios. El último paso consiste en la aprobación de la entrega para su implantación. La gestión de cambios
debe organizar la aceptación formal por parte de los usuarios y el visado de la entrega por los desarrolladores antes de que la gestión de entregas pueda iniciar el despliegue.
Las entregas sólo se deben aceptar en un entorno de pruebas controlado en el que sea posible reproducir un determinado estado de configuración. Este estado de referencia para la entrega
tiene que estar especificado en la definición de la entrega, que estará registrada en el CMDB. Si la entrega no es aceptada, será devuelta a la gestión de cambios como cambios fallidos. Los
resultados de esta actividad incluyen:
• Procedimientos de instalación probados
• Componentes de la entrega probados
• Errores conocidos y defectos en la entrega
• Resultados de pruebas
• Documentación de soporte y gestión
• Lista de sistemas afectados
• Instrucciones de operación y herramientas de diagnóstico
• Planes de contingencia y marcha atrás probados
• Programa de formación para personal, gestores y usuarios
• Documentos firmados de aceptación
• Autorización firmada de la entrega
Al plan de entrega redactado en las fases anteriores se añade ahora información sobre las actividades y el calendario exacto de implantación, es decir, una planificación de despliegue:
• Calendario, lista de tareas y recursos humanos necesarios.
• Lista de los CIs que se deben instalar y retirar, junto con la forma en que se van a retirar.
• Plan de actividades para cada centro de implantación, teniendo en cuenta las posibles fechas de
entrega y, en el caso de una organización internacional, las zonas horarias.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
• Envío de notas de la entrega y otras comunicaciones a las partes afectadas.
• Planes para la adquisición de hardware y software.
• Adquisición, almacenamiento seguro, identificación y registro de todos los nuevos CIs en la
CMDB para la entrega. •
Actualización del calendario y reuniones de revisión con la dirección, los departamentos de gestión, la gestión de cambios y representantes de los usuarios.
Un despliegue se puede implantar de diversas formas: •
Despliegue completo de la entrega método “Big Bang”. •
Despliegue de la entrega por fases, con varias opciones: –
Incrementos funcionales todos los usuarios reciben nuevas funciones al mismo tiempo –
Incrementos de localización por grupos de usuarios –
Evolutivo las funciones se van ampliando por fases El personal que mantiene contacto con los clientes centro de atención al usuario y gestión de
relaciones con el cliente, el personal operativo y los representantes de la organización de usuarios tienen que conocer los planes y su posible impacto sobre las actividades rutinarias. Esto se puede
conseguir mediante sesiones de formación conjunta, cooperación y participación conjunta en la aceptación de la entrega. Es necesario comunicar las responsabilidades y comprobar que todo el
mundo las conoce. Si el despliegue de la entrega se realiza por fases, se debe informar de ello a los usuarios, comunicándoles también los planes previstos y cuándo recibirán las nuevas funciones.
Los cambios introducidos en acuerdos de nivel de servicio SLAs, acuerdos de nivel operativo OLAs y contratos de soporte UCs se deben comunicar por anticipado a todo el personal
afectado.
La gestión de entregas monitoriza los procesos de logística para la adquisición, almacenamiento, transporte, entrega y cesión de software y hardware. El proceso incluye procedimientos, registros
y documentos de soporte como hojas de embalaje, por lo que puede proporcionar información fiable a la gestión de la configuración. La instalación donde se almacene el hardware y el software
tiene que ser segura y sólo puede acceder a ella el personal autorizado.
Siempre que sea posible, se recomienda utilizar herramientas personalizadas para la distribución e instalación de software. De esta forma se reducirá el tiempo y los recursos necesarios para la
distribución, además de aumentar la calidad. Por lo general, estas herramientas también permiten comprobar más fácilmente el éxito de la instalación.
Antes de iniciar una instalación, es conveniente comprobar que el entorno donde se va a instalar la entrega cumple todas las condiciones espacio suficiente en disco, seguridad, controles o
limitaciones ambientales como aire acondicionado, espacio en piso y alimentación eléctrica SAI.
Una vez realizada la instalación, hay que actualizar la información en la CMDB para facilitar la verificación de los acuerdos de licencia.
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
La planificación e implantación de la gestión de entregas depende en gran medida de la implantación de la gestión de la configuración y la gestión de cambios. Debe incluir la planificación
e implantación inicial de las capacidades de gestión de entregas, seguida de una revisión y mejora continuas de:
• Políticas de entregas que incluyan niveles, tipos, unidades, identificación, frecuencia y fases de
entregas, el alcance de los entregables controlados y la documentación necesaria. •
Procedimientos de entrega que cubran todas las actividades de gestión de entregas anteriormente descritas.
• Roles y responsabilidades de todo el personal, y especialmente del de gestión de entregas.
Herramientas, incluidas herramientas de gestión de cambios, herramientas de CMDB y herramientas de gestión de la configuración software.
4.3 Alineación entre el negocio y las Tecnologías de la Información
Kategori