1. Modelo de Gestión de Servicios Gestión de Versiones Gestión de Cambios Gestión de Configuraciones Gestión de Capacidad Gestión Financiera Para Servicios de TI Gestión de Seguridad Gestión de Continuidad de Servicios de TI Gestión de Problemas Gestión de Disponibilidad Provisión de Servicios Soporte de Servicios Service Desk Gestión de Nivel de Servicio Gestión de Incidentes IT Customer Relationship Management
2. BS 15000; ITIL & ISO Especificaciones Código de Práctica Librería de Infraestructura BS 15000 PD0005 ITIL (Mejores Prácticas) Procedimientos Internos Desarrollo de Soluciones Definición de Procesos Revisión de la Gestión Objetivo Final ISO ???
3. Gestión de Seguridad - Meta La meta de la gestión de seguridad es manejar un nivel de seguridad definido en un servicio, incluyendo la reacción a incidentes de seguridad
4. Gestión de Seguridad - Aspectos Confidencialidad Disponibilidad Integridad Seguridad Hardware, Software, Documentación y Procedimientos
5. Gestión de Seguridad - Relaciones Gestión de Seguridad Gestión de cambios Evalúa el impacto en cambios propuestos en seguridad. Genera RFCs en respuesta a problemas de seguridad Gestión de incidentes Los incidentes de seguridad son el principal vínculo Gestión de nivel de servicio Los incidentes de seguridad necesitan ser definidos de acuerdos a requerimientos d e seguridad definidos en SLAs (Sección d e Seguridad).
6.
7.
8.
9. Ciclo de Vida de un Incidente Incident Management Problem Management Change Management Configuration Management Release Management Service Level Management Capacity Management Financial Management Availability Management IT Service Continuity Management Base de Datos de Configuración Alarma Customer Relationship Management
10. Service Desk – Tipos de Estructura Usuario Local Usuario Local Usuario Local Service Desk Soporte de PC’s Soporte de Aplicaciones Soporte Externo (3os) Soporte de Redes y Operaciones Soporte de Primer Nivel Service Desk Local:
11. Service Desk – Tipos de Estructura Sitio 1 Sitio 2 Sitio 3 Service Desk Centralizado Soporte de PC’s Soporte de Aplicaciones Soporte Externo (3os) Soporte de Redes y Operaciones Service Desk Centralizado: Soporte de segundo Nivel
12. Service Desk – Tipos de Estructura Tokio Service Desk Virtual Nueva Delhi Madrid Amsterdam Paris Nueva York Service Desk Virtual: Base de Datos de Gestión
13.
14. Incident Management Ciclo de Vida de un Incidente: Detección y Registración Clasificación Inicial y Soporte Requerimiento de Servicio Investigación & Diagnóstico Resolución & Recuperación Cierre Requerimiento de Servicio? Propiedad, Monitoreo, Seguimiento y Comunicación Si
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25. Configuración - Identificación Detalle (atributos) Alcance (tipos) ¿Incluimos los teléfonos? ¿Incluimos el monitor? ¿Son el alcance y el detalle mantenibles y a un costo efectivo? Número de serie Cantidad de instalaciones Memoria Ubicación Administrador Dueño Administrador Vendedor Usuario Nombre Licencias IP Puertos Versión Nombre Ruteadores SO PC
26.
27. A. Relaciones de infraestructura (I/II) Mainframe A1 SRV 0 DT 01 DT 02 Server B1 LAN de piso (BF2) LAN de piso (BF1) LAN entre pisos (BL) LAN entre pisos (AL) LAN de piso (AF1) LAN de piso (AF2) WAN (W)
30. B. Otras Relaciones Hardware Red externa Mainframe PC 1 Servidor de archivos PC 2 Relación de uso Relación “conectado a”
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47. Proceso de gestión de release Construir y probar el software Probar y construir la versión DSL V 1.0 V 1.1 CMDB V 1.0 operacional y también en la DSL V1.1d en prueba V 1.0 operacional y también en la DSL. Aprobada la construcción. V 1.1a (basada en V1.0) En desarrollo V1.0 operacional y también en la DSL V 1.1 lanzado a través de la DSL para prueba de la versión V 1.0 operacional y también en la DSL (actualización agendada) V 1.1 construcción en la DSL Aprobado el lanzamiento V 1.1 operacional y también en la DSL V1.0 archivado en la DSL Entorno de prueba Construcción Entorno de producción Entorno de prueba Entorno de desarrollo V 1.1a-d V 1.1d Copiar Entregar Distribuir Distribuir RfC ¿Autorizado? Implementar ¿Lanzar?
48. Roles y responsabilidades Desarrollo Entorno de prueba controlado Producción CMDB DSL Jefe de soporte de escritorios Jefe de cambios Jefe de pruebas Jefe de desarrollo Construcción de escritorio (nueva aplicación) CMDB DSL Administrador de bases de datos Jefe de cambios Administrador de bases de datos Jefe de desarrollo Cambios a la base de datos física CMDB DSL Jefe de operaciones Jefe de cambios Jefe de pruebas Jefe de desarrollo Módulos personalizados CMDB DSL Jefe de operaciones Jefe de cambios Jefe de pruebas Jefe de desarrollo Paquete comprado Control de registros Aceptado y soportado por Autoridad para lanzar a producción Aceptado por Lanzado por Clase de objeto
49. Capacity - Alcance Estrategia de Negocios Plan de Negocios Estrategia de TI/SI Plan de Negocios de TI/SI Gestión de Capacidad R e n d i m i e n t o y C a p a c i d a d Hardware Redes Periféricos Software Recursos Humanos
50.
51.
52.
53.
54.
55.
56. Financial - Alcance ------------------------------------------------------------- ---------------------------------------------- ----------------------------------------------------------------------------------- ---------------------------------------------- ------------------------------------------------------------- ---------------------------------------------- Cargos Requerimientos de negocios de TI ----------------------------------------- --------------------------------------- ------------------------------------------- ---------------------- -------------------------------------- ------------------------------------------ ------------------------------------------ ------------------------------------------ ----------- ----------------------------------------- ---------------------------------------- ---------------------------------------- ---------------------------------------- ------------------------------- ---------------------------------------- ---------------------- Análisis de Costo (contabilidad) Modelo de Costos Política de Cobranzas Retroalimentación de cargos propuestos a unidades de negocios Plan operacional de TI (inc. Presupuesto) Objetivos Financieros
57. Proceso de gestión financiera Organización 1. Elaboración de presupuesto . 1 limitaciones . 2 Costos de elementos del presupuesto . 3 Costos de carga de trabajo dependientes de los elementos del presupuesto 0. Gestión Financiera Limitaciones Presupuestos Requerimientos de negocios 2. Desarrollando el modelo de contabilidad de TI . 1 Alcance . 2 Perspectivas de negocios .3 Modelo de costos .4 Tipos de costos .5 Apreciación de inversiones .6 TCO ...... Presupuestos Políticas, líneas básicas costos 3. Desarrollando el sistema de cobranza . 1 Alcance . 2 Políticas de cobranza .3 Cálculo de precios ..... ..... Sistema de cobranza Modelo de Costos Organización Cobranza costos
58. Financial Management Modelo de Costo por Cliente V P F Ventas V Parte de los CI asignables a Ventas Costos no absorbidos X (%) = --------------------------------- x 100 Costos Directos + Absorbidos Costos Directos + Absorbidos Factor Ajuste: Costos No Absorbidos Costos Totales de IT para Ventas Ventas Producción Finanzas Costos Directos Costos Indirectos Costos absorbidos Costos no absorbidos Elementos de Costo Hardware Software Personal Infraestructura Servicios Externos Transferencias
59. Financial Management Modelo de Costo por Servicio Costos Directos Costos Indirectos no absorbidos Costos Indirectos absorbidos por servicio Instalaciones HW y SW Empleados Servicios Externos HW y SW Costo Total del servicio de TI Elementos de Costo Hardware Software Personal Infraestructura Servicios Externos Transferencias Empleados Transferencias Servicios Externos Instalaciones HW y SW
60.
61.
62.
63.
64.
65. Availability Management Proceso Gestión de la Capacidad Requerimientos de disponibilidad del negocio Evaluación de Impacto Requerimientos de disponibilidad, fiabilidad y capacidad de mantenimiento Datos sobre Incidentes y Problemas Datos sobre configuraciones y monitoreos Niveles de Servicio alcanzados Criterios de diseño de disponibilidad y recuperación Resistencia de la Infraestructura y Evaluación de Riesgos Acuerdo de objetivos de disponibilidad, fiabilidad y capacidad de mantenimiento Reportes de disponibilidad, fiabilidad y capacidad de mantenimiento Monitoreo de disponibilidad Planes de mejora
66.
67.
68.
69. ¿ Qu é es un acuerdo de nivel de servicio? Acuerdo de l nivel de servicio Gestión de l nivel de servicio Clientes Clientes Clientes Servicio B Servicio A Servicio C Infraestructura
70.
71.
72.
73. IT Service Continuity Management Modelo del Proceso Iniciar BCM Etapa 1 Inicio Etapa 2 Requerimientos y Estrategia Etapa 3 Implementación Etapa 4 Gestión Operativa Análisis de Impacto en el negocio Evaluación de Riesgos Estrategia de continuidad del negocio Planif. Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgo Implementar acuerdos Desarrollar Procedimientos Prueba Inicial Educación y Comunicación Revisión y Auditoria Prueba Gestión de Cambios Capacitación Aseguramiento de la Calidad
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
Notes de l'éditeur
Estándar BS 15000: Es un estándar desarrollado por la British Standards Institution que define los requerimientos de una organización de TI para proveer servicios con una calidad aceptable para sus clientes. Es una formalización de los elementos clave de las mejores prácticas para la gestión de servicios de TI provistas por ITIL. Este estándar ayuda a las empresas a certificar y demostrar que sus procesos siguen las mejores prácticas aceptadas por la industria. Incluye los siguientes documentos: BS 15000-1: 2002. IT Service Management Specification BS 15000-2: 2003. IT Service Management Code of Practice PD 0005: 2003. IT Service Management. A manager´s guide. PD 0015: 2002. IT Service Management. Self-assesment Workbook.
La gestión de seguridad es intentada para asegurar la salvaguarda de información. Más especificamente, el valor de la información tiene que ser protegido. Este valor es determinado en términos de: Confidencialidad : prote giendo información sensible de revelación no autorizada ; Integridad: salvaguardando la exactitud y totalidad de información y sof tware; Disponibilidad : asegurando que la información y los servicios están disponibles cuando son requeridos.
La gestión de seguridad se vincula con los procesos de Gestión de servicios de IT cuando temas de seguridad están involucrados. Temas como confidencialidad, integridad y disponibilidad, como así también la seguridad de componentes de hardware y software, documentación y procedimientos. En las relaciones definidas en la figura de arriba, es importante notar la necesidad de que cada SLA tiene que tener una sección de seguridad . Para prevenir confusiones entre procesos, Gestión de seguridad puede ser visto como responsable por asegurar el cumplimiento de la política de seguridad de TI en la implementación de servicios de TI. Gestión de Disponibilidad es responsable por asegurar que los requerimiento de seguridad están definidos e incorporados en el diseño global de disponibilidad.
El tipo de mesa de ayuda puede variar de acuerdo a varios factores. La mesa de ayuda local es práctica mientras no se involucre múltiples ubicaciones requiriendo servicios de soporte. La duplicación de recursos y habilidades puede resultar muy costosa. Consideraciones: - Establecer procesos y procedimientos comunes para todas la ubicaciones. - Asegurar compatibilidad de hardware, software e infraestructura de red. - Usar los mismos procesos de escalación y los mismos códigos de impacto, gravedad, prioridad y estado en todas las ubicaciones. - Normalizar la clasificaciones para permitir reportes comunes. - Utilizar métricas de gestión comunes. - Utilizar un base de datos compartida común. - Eventualmente debe proveer la capacidad de pasar o escalar requerimientos entre las mesas de ayuda.
Es esta implementación de la mesa de ayuda todos los requerimientos de servicio son registrados en una ubicación central física. Esto permite: - reducir costos operacionales, - consolidar la visión de la gestión - mejorar el uso de los recursos disponibles
La mesa de ayuda virtual se puede situar y acceder desde cualquier lugar. Si la organización tiene múltiples organizaciones , un único servicio de soporte global tiene grandes beneficios: - reduce costos operativos - mejora el aprovechamiento de los recursos disponibles - permite una visión consolidada para la gestión. La principal restricción operacional es la necesidad de la presencia física del especialista. Consideraciones: - Todas las personas que acceden a la mesa de ayuda virtual deben usar procesos, procedimientos y terminologías comunes. - Se debe acordar un lenguaje común para ingresar los datos. - Los clientes y usuarios deben acceder por un único punto de contacto. - La presencia física de los especialistas será necesaria. - La performance de la red. - La herramientas de soporte deben permitir partición de los trabajos y vistas con distintas autorizaciones.
Al recibir el incidente se debe registrar el detalle del mismo: Número de Referencia, clasificación, fecha y hora de registro, solicitante, método de contacto, descripción del síntoma, prioridad , etc. . Este registro será actualizado y completado a lo largo del ciclo de vida del incidente, tanto su estado como los detalles históricos, modificaciones en la prioridad e impacto, tiempo y costo incurrido, escalaciones , incluyendo el nombre, fecha, hora, detalle y motivo de la modificación. El estado de un incidente refleja su posición actual dentro del ciclo de vida: nuevo, aceptado, programado, asignado /delegado, en proceso, pendiente, resuelto, cerrado. En la clasificación inicial del incidente se asigna su Prioridad. La prioridad de un incidente está determinada por el impacto ( sobre los servicios de negocio y frecuencia de incidente similares) y la urgencia con que se requiere su resolución. Para poder asignar una prioridad inicial se puede referenciar a una tabla de prioridades indicativas de acuerdo a incidente recibido: Tipo de incidente (Falla, Requerimiento de servicio), Categoría ( Software, Hardware, etc.) Subcategoría ( Procesador de Texto, Aplicación de Negocio, Servidor, etc.) Prioridad indicativa ( 1 - Critica, 2 - Alta, 3 - Media, 4 - Baja, 5 - Planificación). Se debe establecer una resolución o workaround lo más rápido posible restaurando el servicio al cliente con la menor interrupción de su trabajo. Después de su resolución el incidente es cerrado.
El proceso de comparación y relación de incidentes.
Los procesos de control de problemas y errores para el ambiente de producción y para el de desarrollo son esencialmente iguales. Los errores encontrados durante las operaciones en vivo resultan en la acumulación de requerimientos de cambios (RFCs). La estrategia de distribución de versiones permite la creación eventual de una versión para incorporar los cambios autorizados para la correcciones a los sistemas. El equipo de desarrollo debe conocer todos los problemas y errores conocidos asociados con el paquete de distribución, borrarlos a medida que los corrigen y agregar los nuevos errores introducidos por la actividad de desarrollo dentro de la base de datos de errores revisados (o dentro de la CMDB) Luego de la implementación de una nueva versión la base de datos de errores revisados reemplaza la base de datos de la versión previa como la nueva versión en línea. El ciclo de repite a medida que se encuentra n nuevos errores en el ambiente de producción.
Relaciones entre la CMDB y otros procesos: La gestión de Cambios describe los procedimientos para autorizar e implementar cambios en la infraestructura de TI. Idealmente, la gestión de Cambios podría considerarse como una parte integral de la G estión de Configuraci ones . La Gestión de Cambios utiliza la CMDB para estimar el impacto de los cambios a implementar. Autoriza la cambios, y estos deben asociarse con los CIs pertinentes . La gestión de cambios es responsable del registro de los RFCs. La Gestión de Configuraciones contribuye al control efectivo de Incidentes y Problemas. La Gestión de Incidentes consulta información sobre toda la infraestructura y su s servicios, para poder determinar la ubicación de un CI, su propietario, si tiene un problema o un error conocido asociado a una solución temporal, para qué cliente y para qué servicio se dispuso y por que SLA está cubierto. La Gestión de Problemas requiere información sobre la complejidad de la infraestructura de TI. La Gestión de Versiones puede ser considerada también como parte integral de la Gestión de Configuraciones. Incluye la construcción, distribución e implementación de versiones.
La gestión de cambios no es responsable por identificar componentes afectados por cambios o actualizar registros de cambios (dominio de la gestión de la configuración), ni es responsable por la versión de nuevos componentes (dominio de gestión de release).
Todas la salidas deben ser manejadas efectivamente, desde el desarrollo o compra del software, a través de la configuración y personalización, testeo e implementación hasta la operación dentro del ambiente en línea. Esta figura muestra las actividades principales de la gestión de versiones y sus posición dentro del ciclo de vida del cambio. Los registros de la gestión de configuraciones deben ser actualizados durante la construcción y distribución para asegurar versiones confiables que puedan ser revertidas en caso de problemas. Una versión debe estar bajo la gestión de cambios y el contenido y tiempo de una versión deben ser autoriza d os a través del proceso de gestión de cambios.
Gestión de release cubre desde que el software es adoptado en el DSL hasta que el software es transferido a archivos. Durante el ciclo de vida de un programa se realizan los siguientes pasos: · El proceso comienza con la compra del software , o la asignación para desarrollar el software. · Cuando el software es entregado a control de calidad . · En control de calidad el software e s aceptado para su incorporación dentro de la DSL. Se debe examinar po r ejemplo si el software fue ordenado, si nuevas vesiones han sido desarrolladas de fuentes correctas, si todos los ajustes están autorizados por Gestión de Cambios y todos los CE están registracdos en el CMDB. · Una vez que el so ftware es aceptado, se debe realizar un backup de la DSL antes de que el software sea adoptado en la DSL. Estos backups ocurren frecuentemente para que en cado de desastre la última versión correcta pueda rápidaamente ser configurada. · La compilación de cada release es decidida por adelantado por Gestión de Cambios, un 'Release Record' es realizado en el CMDB y todos los detalles son registrados. · Cuando todos los componentes del software están listos, el paquete puede ser envi a do al área de pruebas donde todos las pruebas obligatorias tienen que ser ser ejecutadas. Cuando existen muchos errores, el software es devuelto para más desarrollo. Cuando el software es aprobado deberá ser lanzado para explotación. La versión debe ser distribuida para explotación.
El alcance de la gestión financiera de TI incluye la elaboración de presupuestos, la contabilidad y la cobranza, aunque la responsabilidad por los procesos y tareas pueden estar coordinados con el departamento de finanzas. En muchas organizaciones las reglas de presupuestos alcanzan a todas las partes de la organización y la supervisión y reporte de presupuestos es ejecutado por personal que informa al departamento de finanzas más que a la organización de TI. Para los propósitos de éste módulo, se asume que la elaboración de presupuestos, la contabilidad y la cobranza para los servicios de TI es responsabilidad de la gestión financiera de TI. Siempre es aconsejable trabajar conjuntamente con el departamento de finanzas.
Para calcular los costos de la provisión de Servicios de TI es necesario diseñar el marco en el que todos los costos conocidos puedan ser requeridos y asignados a Clientes, actividades u otras categorías específicas. Este marco constituye el modelo de costo. Elementos de Costo: Hardware: Mainframes, Servidores, Redes, PCs, etc. Software: Sistemas Operativos, aplicaciones, base de datos, herramientas de monitoreo y administración. Personal: Infraestructura: Oficinas, almacenes, áreas de seguridad, etc. Servicios Externos: Servicios de seguridad, Servicios de recuperación de desastres, servicios tercerizados. Transferencias: Cargos internos de otros centros de costos dentro de la organización.
Para calcular el costo por servicio el modelo de costo requiere mayor detalle. Los pasos son los siguientes: - Identificar todos los costos que puedan ser atribuidos directamente al servicio analizado, por ejemplo hardware, software, personal o contratos dedicados. - Decidir cómo proporcionar los Costos Indirectos ( por ejemplo la Infraestructura) - Ajustar el total con los costos encubiertos o no absorbidos ( Gestión de TI o Instalaciones ) por medio del mismo factor de ajuste calculado en el modelo de costo por cliente.
El alcance de la gestión de la disponibilidad cubre el diseño, implementación, medición y gestión de la disponibilidad de la infraestructura de TI. Es un proceso continuo que empieza desde que se definen los requerimientos de disponibilidad y termina sólo cuando los servicios provistos por TI dejan de ser requeridos. Las entradas claves al proceso son: Requerimientos de Disponibilidad del Negocio, es lo que el negocio define como necesario para alcanzar su misión. Evaluación de impacto: para cada función vital del negocio se debe definir el impacto de la pérdida de servicio por períodos de tiempo específicos. Requerimientos de disponibilidad, fiabilidad y capacidad de mantenimiento de los componentes de la infraestructura de TI, sistemas y servicios. Datos sobre incidentes y problemas provistos por la mesa de ayuda en referencia a ítems de configuración específicos. Datos sobre configuraciones y monitoreos, provistos por la CMDB relacionados con la configuración de los ítems de configuración y los datos relacionados con el monitoreo de esos ítems. Datos de niveles de servicio alcanzados por cada servicio de acuerdo al cumplimientos de los objetivos establecidos en los SLAs.
Básica: se utiliza para medir el porcentaje de disponibilidad de un componente de la infraestructura. Ejemplo: Un servicio 24x7 requiere 2 horas de downtime planificado por semana para tareas de mantenimiento de la aplicación. Un error en la aplicación produjo 3 horas de downtime no planeado. TSA= (24 horas x 7 días ) - 2 (horas planificadas) = 168 - 2 = 166 TC= 3 horas Disponibilidad = (166 - 3) / 166 x 100 = 98,78 % Paralela : Cuando se incorporan componentes adicionales para proveer resistencia en la infraestructura ( componentes redundantes para proveer tolerancia a fallos) el porcentaje de disponibilidad del componente se calcula restándole a 1 (disponibilidad total) a la multiplicación de la indisponibilidad de cada componente (indisponibilidad resultante). Disponibilidad Servidor 1= 98 % Disponibilidad Servidor 2= 98 % Disponibilidad servidor = 1 - ( (1-0,98)*(1-0,98) ) = 0,9996 Serial : La disponibilidad total de la infraestructura se calcula mediante el producto de todos los porcentajes de disponibilidad de cada componente individual. Disponibilidad Infraestructura= Disp. Server x Disp. Red x Disp. PC Disponibilidad = 0,9996 x 0,98 x 0,96 =0,9404 ( 94,04%)
Un SLA es un acuerdo escrito entre un proveedor de servicios de TI y los clientes de TI, definiendo los resultados claves del servicio y las responsabilidades de las partes. Se debe enfatizar el acuerdo y no deberían ser utilizados como una suerte de chantaje entre las partes. Una relación de confianza debe desarrollarse entre el proveedor de TI y el cliente, para que un acuerdo de beneficio mutuo sea logrado, de otra modo el SLA puede desvirtuarse rápidamente.
No es posible desarrollar un plan de ITSCM efectivo aislado, debe soportar de manera completa los requerimientos del negocio. Este modelo presenta el ciclo de vida de la Continuidad del Negocio con un énfasis en los aspectos de TI. Un comprensión completa de este proceso puede obtenerse a través de las publicaciones de OCG: “ An introduction to Business Continuity Management ” y “ A Guide to Business Continuity Management ”.
Establecimiento de políticas: Deben ser establecidas y comunicadas a la brevedad de manera que todos los miembros de la organización involucrados o afectados por la Continuidad del Negocio están advertidos de sus responsabilidades. Especificar términos y alcances: Incluye definir el alcance y responsabilidades de la gerencia y el personal de la organización, y el método de trabajo. Asignar Recursos: El requerimiento de recursos tanto monetarios como de personal es muy alto. Definir la organización del proyecto y la estructura de control: Los proyectos de BCM e ITSCM son potencialmente complejos y necesitan ser organizados y controlados de la mejor manera. Es recomendable utilizar una metodología de proyecto estándar ( por ejemplo, PRINCE2) complementada con un a herramienta de planificación de proyectos. Acordar el proyecto y planes de calidad: Los planes permiten que los proyectos puedan ser controlados y las variaciones identificadas. Los planes de Calidad aseguran que los entregables sean cumplidos y con un nivel aceptable de calidad.
La educación y comunicación debe incluir toda la organización y el particular la organización de TI. Capacitar el equipo de recuperación del negocio para asegurar que tengan los niveles de competencia necesarios. Revisar regularmente todos los entregables del proceso para asegurar que se mantienen actualizados. Establecer un programa de pruebas regulares para asegurar que los componentes críticos de la estrategia son probados al menos anualmente o de acuerdo a la dirección o auditoria. ITSCM debe ser incluido como parte del proceso de Gestión de Cambios para asegurar que los cambios sean reflejados en los planes de recuperación. Asegurar que la calidad de los entregables es aceptable para la dirección y que los procesos operativos trabajan satisfactoriamente.
