![Availability Management Cálculo de Disponibilidad: Básica : Disponibilidad = ( TSA - TC) x 100 TSA TSA= Tiempo de Servicio Acordado TC = Tiempo de Caída Configuración Serial: Disponibilidad = Servidor x Red x Estación de Trabajo Configuración Paralela: Disponibilidad = 1 – [ ( 1- Servidor_A) x (1-Servidor_B) ]](https://image.slidesharecdn.com/itiladicional-12988428298244-phpapp01/85/ITIL-FOUNDATION-66-320.jpg)
ITIL FOUNDATION
- 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. Ejemplo de proceso (I/III) Un usuario llama al centro de servicio a clientes reportando dificultades de tiempo de respuesta El proceso de gestión de incidentes trata el incidente El proceso de gestión de problemas investiga la causa por detrás, llama a la gestión de la capacidad por asistencia. La gestión del nivel de servicios se alerta de la violación a los acuerdos El proceso de gestión de cambios inicia y coordina solicitudes de cambio
- 7. Ejemplo de proceso (II/III) El proceso de gestión financiera asiste en la justificación del gasto para actualización del hardware El proceso de gestión de la continuidad de servicios de TI se involucra en el proceso de cambio para asegurar que es posible volver atrás después de implementar el cambio El proceso de gestión de versiones controla la implementación del cambio a través del roll-out de hardware y software. Informa a la gestión de la configuración detalles de lanzamientos y versiones
- 8. Ejemplo de proceso (III/III) La gestión de disponibilidad se involucra considerando actualizaciones de hardware para asegurar el cumplimiento de los niveles requeridos de disponibilidad y fiabilidad La gestión de la configuración se asegura de que la información de la CMDB está actualizada en todo el proceso El proceso de la gestión de relación al cliente coordina con el Cliente para informar el progreso
- 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. SD - Preguntas de implementación ¿Qué clases de incidentes habrá? ¿Cuál es el criterio? ¿Que tecnologías de Service Desk serán utilizadas? ¿Qué estructura organizacional existe? ¿Cuales son las horas laborales? ¿Cuál es el número de usuarios? ¿Cuál es el volumen de llamados? ¿Cuantas líneas de soporte serán necesarias? ¿Cuántas personas de soporte serán necesarias? ¿Cuál es el nivel de experiencia de los usuarios?
- 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. 1. Detección y registro de incidentes Registrar detalles básicos de incidentes Alertar al grupo de especialistas de soporte, de ser necesario Iniciar procedimientos para atención de pedidos de servicio Detalles de incidentes del Service Desk o de sistemas de gestión de eventos Actualizar detalles de incidentes Reconocimiento de cualquier error en la CMDB Notificar al Cliente cuando los incidentes han sido resueltos Entradas Proceso Resultados
- 16. 2. Clasificación y soporte inicial Clasificación de incidentes. Alineación con errores conocidos y problemas Informar a gestión de problemas acerca de la existencia de nuevos problemas y de múltiples incidentes Asignar impacto, urgencia y prioridad Evaluar detalles de configuración relacionados Proveer soporte inicial. Cerrar, informar al usuario o rutear al especialista Detalles de incidentes registrados Detalles de configuración de la CMDB Respuestas de incidentes provenientes de errores conocidos y problemas RFC para la resolución de incidentes Actualización de detalles de incidentes Soluciones temporales para incidentes Incidentes ruteados a soporte de primera, segunda y tercera línea Entradas Proceso Resultados
- 17. 3. Investigación y diagnóstico Evaluación de detalles de incidentes Colección y análisis de toda la información relacionada y resolución Solución temporal o escalada a soporte de cualquier línea Detalles de incidentes actualizados Detalles de configuración del CMDB Detalles de incidentes actualizados aún más Especificaciones de soluciones temporales Entradas Proceso Resultados
- 18. 4. Resolución y recuperación Resolver el incidente usando soluciones temporales o alternativamente levantando un RFC Realizar acciones de recuperación Detalle de incidentes actualizados Cualquier respuesta en un RFC que afecte la resolución de los incidentes Cualquier solución temporal o solución derivada RFC para futura resolución de incidentes Incidentes resueltos, incluyendo detalles de la recuperación Detalles de incidentes actualizados Entradas Proceso Resultados
- 19. 5. Cierre de incidentes Confirmación de la resolución al Cliente u originador Asignar “cerrado” a categoría Cerrar incidente Detalle de incidentes actualizados Incidentes resueltos Detalles de incidentes actualizados Registro de incidente cerrado Entradas Proceso Resultados
- 20. 6. Asignación, seguimiento y comunicación Supervisión Escalar incidentes Informar al usuario Registros de incidentes Reportes de gestión acerca del progreso de incidentes Detalles de incidentes escalados Reportes al cliente y comunicación Entradas Proceso Resultados
- 21. Problem Management Relación de incidentes (1/2): Comunicar Solución Temporaria Evaluar y seguir el Proceso de Rutina Alerta de Incidente Incidente de Rutina? Hay información en la KDB? Hay información en la PDB? Actualizar Contador del Registro de la KDB Actualizar Contador del Registro de la PDB Cargar la Solución en el Registro del Incidente Cargar el Problema en el Registro del Incidente Si Si Si
- 22. Problem Management Relación de incidentes (2/2): Cargar Clasificación en Registro de Incidente Nuevo Registro en la PDB Nuevo Problema Generar nuevo registro en la PDB Procesar el Incidente o Problema Se requiere soporte ? Proceder a la solución Extraer la solución de la KDB Si Si Cargar Clasificación en Registro de Incidente Se requiere soporte ? Proceder a la solución Extraer la solución de la KDB
- 23. Problem Management Errores en Producción y Desarrollo: Sistemas en Producción Gestión de Versiones Pedidos de Cambio (RfC) Gestión de Cambios Desarrollo y Mantenimiento de Aplicaciones Problemas Problemas Investigación y Diagnóstico Investigación y Diagnóstico Errores en Producción Errores en Desarrollo
- 24. Kepner y Tregoe Fases en el análisis de problemas: Definir el problema Describir el problema en términos de identidad, ubicación, tiempo y tamaño Establecer posibles causas Probar la causa más probable Verificar la verdadera causa
- 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. Diagramas de relación de entidades Se usan dos tipos de representaciones gráficas (Diagramas de relacion de entidades): Representación gráfica de las relaciones de infraestructura Representaciones gráficas de las relaciones padre-hijo y los atributos de los componentes
- 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)
- 28. A. Relaciones de infraestructura (II/II)
- 29. B. Relaciones padre-hijo
- 30. B. Otras Relaciones Hardware Red externa Mainframe PC 1 Servidor de archivos PC 2 Relación de uso Relación “conectado a”
- 31. Roles y responsabilidades (I/II) Jefe de la configuración: Evalúa los sistemas de gestión de la configuración existentes Desarrolla los estándares del proceso de gestión (información que será registrada, procedimientos, funciones, planes, elementos que serán controlados) Entrena al personal de gestión de la configuración Crea el plan de implementación de la gestión Propone las interfaces con otros procesos Planifica y ejecuta la carga y mantenimiento de la CMDB Evalúa herramientas para la gestión de acuerdo a los requerimientos técnicos y el presupuesto Realiza la auditoria para verificar que la CMDB refleja la realidad
- 32. Roles y responsabilidades (II/II) El Bibliotecario: Proveer información sobre estado de EC Controlar la recepción, identificación, almacenamiento y retiro de todos los EC soportados Crear un esquema de identificación para las librerías de gestión de la configuración y para la DSL Crear librerías y otras áreas de almacenamiento Mantener información de EC y sus estados Archivar las copias supersedidas Mantener copias maestras Producir reportes de estado Asistir en las auditorías
- 33. Change, Configuration y Release Management Configuration Management Change Management Pedido de Cambio Evaluación Aprobación Implementación Revisión post- Implementación Cierre Fin ReleaseManagement Liberar y Distribuir Software, Hardware y Documentación Configuration Management Verificación del Ambiente Informe de Áreas y componentes impactados Actualización de registros Informes de Líneas base, liberar software y actualizar registros Verificación Base de Datos de Configuración (CMDB)
- 34. Proceso de gestión de cambios Filtrado de cambios Manejo de cambios y procesos de cambios Presidir el CAB y el CAB/Comité de emergencias Revisar y cerrar RFC Reportes de gestión RFC CMDB Calendario de cambios (Forward Schedule of Changes – FSC) Calendario de cambios (FSC) RFC Minutas y acciones del CAB Reportes de gestión de cambios Entrada Proceso Resultado
- 35. Relación entre procesos Gestión de cambios Evalúa impacto Gestión de la capacidad Evalúa impacto en el negocio y desempeño de TI Gestión de configuración Identifica áreas impactadas Gestión de cambios Autoriza cambios Gestión de release Controla la entrega de nuevas versiones de software o hardware si se requiere para implementar el cambio Gestión de la configuración Actualiza registros
- 36. Roles – Jefe de cambios (I/II) Responsabilidades: Recibir, registrar, asignar prioridad con el iniciador, a todos los RFC. Rechazar RFC que son impracticables Convocar al CAB y decidir cuales serán sus miembros Presidir los encuentros Después de considerar las recomendaciones del CAB, autorizar los cambios aceptables Publicar un calendario de cambios (FSC) a través del Service Desk
- 37. Roles – Jefe de cambios (II/II) Responsabilidades: Coordinar a los grupos necesarios para construir, probar e implementar de acuerdo con el calendario Revisar todos los cambios implementados para verificar el cumplimiento de objetivos Determinar tendencias a partir de registros de cambios Cerrar RFC Producir reportes
- 38. Roles – Comité de cambios (CAB) Responsabilidades: Revisar RFC. Determinar y proveer detalles de su impacto, recursos de implementación y costos de todos los cambios Asistir a todas las reuniones del CAB o CAB/EC. Participar en la aprobación y creación del calendario de cambios (CAB/EC solamente). Estar disponibles para consulta por cambios urgentes
- 39. Objetivos de Release Management Planificar el rollout exitoso del soft y hard relacionado Diseñar e implementar procedimientos eficientes para la distribución e instalación de Cambios a los sistemas Asegurar que el soft y hard modificados sean trazables, seguros y que sólo se instalen versiones autorizadas y probadas. Comunicar y manejar las expectativas del Cliente Acordar el contenido exacto y el plan de rollout del Release, ligado con Change Management. Implementar nuevos Releases de Soft y Hard en ambiente operacional usando los procesos de control de Config. y Change Management Asegurar la copias maestras en la DSL y actualizar la CMDB
- 40. Planificación Ciclo de vida del proyecto Entregables relacionados al servicio RFCs autorizados Política del software Panorama de las necesidades del negocio Limitaciones y dependencias Output del CAB Templates Ganar consenso sobre los contenidos del lanzamiento Acordar en el plan de roll-out para las ubicaciones geográficas, unidades de negocio y clientes Producir un calendario de lanzamiento de alto nivel Conducir encuestas para conocer software y hardware existente en los lugares Producir planes de reversa “back-out” Planificar niveles de recursos Entradas Actividades
- 41. Diseño, construcción y configuración Definición del Release Plan del Release Ensamble detallado del Release Instrucciones de construcción, secuencia de operaciones Órdenes de compra, licencias y garantías para software y hardware de terceras partes Scripts de instalación automática Copias maestras de los medios de instalación e instrucciones de instalación para ser almacenados en el DSL Procedimientos de back-out Entradas Resultados
- 42. Comunicación, preparación y entrenamiento Plan de roll-out Definición detallada del Release Copias de los medios de instalación e instrucciones de instalación Versiones actuales de documentos de soporte, entrenamiento, usuario Formularios de aceptación Versiones finales de documentación y materiales de entrenamiento de usuarios y soporte Planes de Release y documentación actualizados Entradas Actividades
- 43. Distribución e instalación Plan de roll-out detallado Procedimientos de instalación probados Componentes del Release probados Planes de reversa “back-out” probados Actualización del servicio de TI Actualización de la documentación de soporte y usuarios Registros de la CMDB actualizados que reflejan el entorno en producción Cualquier error conocido que sea parte del nuevo Release Entradas Actividades
- 44. Ambiente de Desarrollo Ambiente de Pruebas bajo control Ambiente de Producción Release Management Principales actividades: Base de Datos de Configuración y Librería de Software Definitivo Release Management Política de versiones Planes de distribución Diseño y desarrollo o Pedido y compra de software Diseño y armado de la versión Prueba final Aceptación de la versión Diseño del plan de distribución Comunicación y entrenamiento Distribución e instalación
- 45. Release Management Verificaciones previas (1/2): ¿ Están bien definidas las responsabilidades? ¿ Son confiables los procedimientos? ¿ Fueron asignados y reservados los recursos? ¿ Se poseen todas las autorizaciones necesarias? ¿ Se cumplió con el plan de entrenamiento? ¿ Fue considerado el nivel de soporte requerido? ¿ Están resueltos los aspectos relacionados con las licencias?
- 46. Release Management Verificaciones previas (2/2): ¿ Se analizó el impacto potencial? (Capacidad) ¿ Fueron verificadas las dependencias entre otros softwares y el equipamiento? ¿ Hay un procedimiento para verificar el éxito? ¿ No hay impacto entre éste y otros cambios? ¿ Fue publicado el plan de distribución? ¿ Fueron informadas las áreas de Soporte y Mesa de ayuda?
- 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. Roles y responsabilidades (I/II) Jefe de capacidad - Rol Asegurar que hay una adecuada capacidad de TI para cumplir con los niveles de servicio requeridos Aconsejar al proceso de gestión de nivel de servicio sobre el nivel de servicio apropiado
- 51. Roles y responsabilidades (II/II) Responsabilidades Asegurar el nivel apropiado de supervisión de recursos y del rendimiento del sistema, y que la información registrada se mantiene actualizada y utilizada por todos los procesos de gestión de capacidad Producir el plan de capacidad en línea con el ciclo de planeamiento de negocios de la organización Documentar los incrementos o reducciones de hardware basados en SLRs y restricciones de costos Producir reportes regulares de nivel de uso actual, tendencias y pronósticos de los recursos
- 52. Procesos Tecnología SLAs, SLRs y Catálogo de Servicio Planes de negocios y estratégicos Planes de IS/TI Requerimientos de negocios y volúmenes Programas operacionales Planes y programas de desarrollo e implantación Programa de cambios potenciales Incidentes y problemas Revisiones de servicios Brechas en SLAs Planes financieros Presupuestos Entradas Gestión de capacidad de negocios tendencias, pronósticos prototipos, cálculos, y requerimientos futuros de negocios Gestión de capacidad de servicios supervisa, analiza, optimiza e informa rendimiento de servicios, establece líneas básicas de uso de servicios, maneja demanda de servicios Gestión de capacidad de recursos supervisa, analiza, ejecuta y reporta la utilización de componentes, establece líneas básicas y perfiles de uso de componentes Sub-Procesos Plan de capacidad CDB Líneas básicas y perfiles Umbrales y alarmas Reportes de capacidad Recomendaciones de SLA y SLR Recomendaciones de costos y cobranzas Cambios proactivos y mejoramiento de servicios Programas operacionales revisados Revisiones eficientes Reportes de auditoría Salidas
- 53. Relación con otros procesos (I/III) informa sobre incidentes relacionados a capacidad y rendimiento Gestión de problemas diagnostica y resuelve problemas relacionados con capacidad provee scripsts y herramientas de diagnóstico apoya el rol proactivo de la gestión de problemas resuelve y documenta incidentes relacionados con capacidad coordina a través de gestión de problemas provee scripsts y herramientas de diagnóstico mantiene informado a las gestiones de incidentes y problemas a través de alertas y registros de errores conocidos informa sobre problemas relacionados a capacidad y rendimiento Gestión de cambios es representado en el CAB, evalúa impacto de cambios supervisa el efecto acumulativo de cambios genera RFCs para requerimientos adicionales incluidos en e l plan de capacidad se informa sobre temas relacionados con capacidad en el tratamiento de RFCs Gestión de capacidad Gestión de incidentes
- 54. Relación con otros procesos (II/III) requiere asistencia en tareas de distribución e implementación de software Gestión de configuración complementa datos del CMDB con el CDB ayuda en la distribución estratégica de los componentes (red, host, etc.) informa sobre demoras en la distribución e implementación de software toma el CDB y lo incorpora al CMDB Gestión de acuerdo de servicios asegura los requerimientos de rendimiento y capacidad proporciona conocimiento técnico en revisiones de OLAs y contratos de terceros en temas de capacidad y rendimiento Gestión financiera provee un resumen de costos proporciona recomendaciones de adquisiciones informa sobre perfiles de uso para cobranzas asiste en en la definición y ejecución de los cálculos de cobranzas de capacidad asiste en la justificación financiera Gestión de capacidad Gestión de release
- 55. Relación con otros procesos (III/III) requerimientos de continuidad de servicios RFCs evaluados por su impacto en las opciones de recuperación Gestión de disponibilidad capacidad de todas las opciones de recuperación utilizadas configuraciones mínimas de hardware y software requeridas Problemas de capacidad y rendimiento resultan en no disponibilidad, ej. bajo rendimiento es lo mismo que no disponibilidad. Por lo tanto las gestiones de capacidad y disponibilidad comparten metas comunes y complementarias entre ellas, generalmente comparten la utilización de técnicas y herramientas como espejado o duplicación Gestión de capacidad Gestión de continuidad
- 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. Otras actividades de la gestión financiera Planeamiento de la contabilidad de TI y la cobranza actividades necesarias para la implementación enfoque de project management Implementación herramientas e información disponible esquema de prueba (piloto) supervisión Operación y seguimiento gestión de cambios r eportes auditorías
- 61. Roles y responsabilidades (I/III) Jefe de finanzas - Rol Trabajar, a un nivel apropiado, con la gerencia de la organización y el departamento de finanzas Desarrollar las políticas de elaboración de presupuesto, de contabilidad de TI y de cobranza Implementar y mantener los procesos de gestión financiera de TI, abarcando elaboración de presupuesto, de contabilidad de TI y de cobranza Asistir en el desarrollo de planes de cuentas y casos de inversión
- 62. Roles y responsabilidades (II/III) Responsabilidades Elaboración de presupuesto manejar el presupuesto de TI preparar pronósticos y asistir a los clientes en la preparación de elementos de TI de sus presupuestos informar regularmente a los gerentes de Ti y a los clientes de la marcha de los presupuestos Contabilidad de TI seleccionar herramientas y procesos para reunir datos de costos desarrollar modelos de costos acordar políticas de contabilidad de TI, ej. amortización asistir en el desarrollo de casos de costo beneficio de inversiones de TI
- 63. Roles y responsabilidades (III/III) Responsabilidades (cont...) Cobranza identificar métodos de cobranza dentro de la política de cobranza de la organización proporcionar justificaciones y comparaciones de los cargos preparar cuentas regulares a los clientes preparar una lista de precios de servicios
- 64. Disponibilidad - Principios guías La disponibilidad es el núcleo de los negocios y la satisfacción de los usuarios. Es un componente clave en la percepción del usuario sobre la calidad del servicio de IT. Usuarios Satisfechos Usuarios Encantados Disponibilidad Servicios de TI Disponibilidad Cuando las cosas van mal, todavía es posible alcanzar los negocios y lograr la satisfacción de los usuarios El mejoramiento de la disponibilidad es posible entendiendo como los servicios de TI soportan los negocios
- 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. Availability Management Cálculo de Disponibilidad: Básica : Disponibilidad = ( TSA - TC) x 100 TSA TSA= Tiempo de Servicio Acordado TC = Tiempo de Caída Configuración Serial: Disponibilidad = Servidor x Red x Estación de Trabajo Configuración Paralela: Disponibilidad = 1 – [ ( 1- Servidor_A) x (1-Servidor_B) ]
- 67. Relación con otros procesos (I/II) detalle del SLA que establece las medidas apropiadas de disponibilidad y reportes Gestión de continuidad criterio de disponibilidad y recuperación para mantener la marcha de los negocios en forma usual evaluación de la disponibilidad de un nuevo servicio de TI evaluación de impacto en los negocios detallando funciones vitales dependientes de la disponibilidad de TI Gestión financiera costo de no disponibilidad de un servicio para ayudar a justificar costos dentro de un plan de disponibilidad costos asociados con actualizaciones Gestión de capacidad una completa evaluación de fallas de componentes para un nuevo servicio de TI, denotando las técnicas de disponibilidad plan de capacidad detallando como deben ser cumplidos los requerimientos de capacidad en función de la fiabilidad necesaria Gestión de disponibilidad Gestión de nivel de servicios
- 68. Relación con otros procesos (II/II) cronograma de actividades de mantenimiento planeadas detallando los tiempos que los servicios de TI serán impactados detalle de régimen de mantenimiento planeado que considere frecuencia, duración e impacto de nuevos servicios de TI Gestión de disponibilidad Gestión de cambios
- 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. Roles y responsabilidades (I/III) Jefe de la gestión del nivel de servicio Implementar y mantener el proceso de gestión del nivel de servicio requerido por la organización jerárquica Poseerá un nivel apropiado de negociación con clientes en nombre de la organización Iniciativa para tomar acciones requeridas para mejorar o mantener la calidad del servicio Antigüedad adecuada dentro de la organización
- 71. Roles y responsabilidades (II/III) Responsabilidades Crea y mantiene un catálogo de servicios Formula, acuerda y mantiene una estructura de SLM apropiada para la organización que incluya: Estructura de SLA OLAs dentro de la organización de TI Terceras partes relacionadas con el proceso de SLM Negocia, acuerda y mantiene los SLAs Negocia,acuerda y mantiene los OLAs Negocia y acuerda con el cliente y con el proveedor de TI los requerimientos de nivel de servicio
- 72. Roles y responsabilidades (III/III) Responsabilidades (cont...) Analiza y revisa desempeño del servicio contra SLAs Organiza y mantiene el proceso de revisión regular de nivel de servicio con con el cliente y con el proveedor de TI Conduce revisiones anuales del proceso completo de nivel de servicio, y negocia, acuerda y control a cualquier enmienda necesaria
- 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. IT Service Continuity Management Etapa 1: Inicio Iniciar BCM Etapa 1 Inicio Establecimiento de políticas Especificar términos y alcances Asignar Recursos Definir la organización del proyecto y la estructura de control Acordar el proyecto y planes de calidad
- 75. IT Service Continuity Management Etapa 2: Requerimientos y Estrategia Etapa 2 Requerimientos y Estrategia Análisis de Impacto: Cuanto puede perder la organización como resultado de un desastre o la interrupción de un servicio Evaluación de Riesgos: Probabilidad de que se produzca efectivamente un desastre o una interrupción seria a los servicios. Evaluación de riesgos y vulnerabilidades Estrategia: Desarrollo de la estrategia apropiada en función a la información recolectada, balanceando la reducción de riesgos y opciones de recuperación Análisis de Impacto en el negocio Evaluación de Riesgos Estrategia de continuidad del negocio
- 76. IT Service Continuity Management Etapa 3: Implementación Etapa 3 Implementación Planificación de la Organización . La estructura de control está basada en 3 capas: Ejecutiva, Coordinación y Recuperación Planificación de la Implementación . El plan debe incluir : Plan de Respuesta de Emergencia Plan de Evaluación de Daños Plan de Salvataje Plan de Registros Vitales Plan de Gestión de Crisis y Relaciones Públicas Plan de Instalaciones y Servicios Plan de Computadoras y Redes Plan de Telecomunicaciones Plan de Seguridad Plan de Personal Plan de Administración y Finanzas Planificación de la Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgo Implementar acuerdos Desarrollar Procedimientos Prueba Inicial
- 77. IT Service Continuity Management Etapa 3: Implementación Etapa 3 Implementación Acciones necesarias para implementar acuerdos de reserva (“stand by”): Negociar asistencia de terceras partes para la recuperación e ingresar dentro de un acuerdo contractual Preparar y equipar el alojamiento de reserva Comprar e instalar sistemas de computación de reserva Negociar con proveedores de servicios externos sobre sus planes de contingencia Plan de la Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgo Implementar acuerdos Desarrollar Procedimientos Prueba Inicial
- 78. IT Service Continuity Management Etapa 3: Implementación Etapa 3 Implementación Desarrollar planes de recuperación para habilitar la información necesaria para los sistemas y servicios críticos para que se continúe con su provisión o para que sean reinstalados dentro de un periodo de tiempo aceptable para el negocio Los planes deben ser documentos controlados de manera que sólo la última versión esté en circulación Plan de la Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgo Implementar acuerdos Desarrollar Procedimientos Prueba Inicial
- 79. IT Service Continuity Management Etapa 3: Implementación Etapa 3 Implementación Se implementan en conjunción con la Gestión de la Disponibilidad, ya que muchas de estas reducen la probabilidad de fallas que afecten la disponibilidad del servicio Algunas típicas son: Instalación de UPS y energía de back-up Sistemas tolerantes a fallas para aplicaciones críticas Almacenamiento y Archivo externo Arreglos de discos (RAID) y Discos espejados para Servidores Equipamiento y componentes de repuesto Plan de la Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgo Implementar acuerdos Desarrollar Procedimientos Prueba Inicial
- 80. IT Service Continuity Management Etapa 3: Implementación Etapa 3 Implementación ITSCM depende de la realización de tareas técnicas específicas. Es necesario que se documenten y sean comprendidas completamente. Los procedimientos deben incluir: Instalación y Prueba de reemplazo de hardware y redes . Restauración de software y datos a un punto de referencia común que es consistente a través de todos los procesos de negocio . Diferentes zonas de tiempo . Puntos de corte del negocio . Plan de la Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgo Implementar acuerdos Desarrollar Procedimientos Prueba Inicial
- 81. IT Service Continuity Management Etapa 3: Implementación Plan de la Organización e Implementación Desarrollar planes de recuperación Implementar medidas de reducción de riesgos Implementar acuerdos Desarrollar Procedimientos Prueba Inicial Etapa 3 Implementación Es una parte crítica dentro del proceso ITSCM y es la única forma de asegurar que la estrategia seleccionada, los acuerdos de reserva, la logística, los planes y procedimientos de recuperación del negocio funcionarán realmente en la práctica. Permite confirmar: Objetivos de tiempo . Preparación del personal . Duplicación de staff y sobre asignación de recursos claves . Respuesta y efectividad de las partes externas .
- 82. IT Service Continuity Management Modelo del Proceso Etapa 4 Gestión Operativa Factores clave: 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 . Revisar regularmente todos los entregables del proceso . Establecer un programa de pruebas regulares . ITSCM debe ser incluido como parte del proceso de Gestión de Cambios . Asegurar que la calidad de los entregables sea aceptable Educación y Comunicación Revisión y Auditoria Prueba Gestión de Cambios Capacitación Aseguramiento de la Calidad
- 83. Roles y responsabilidades (I/II) Jefe de la continuidad - Rol Implementar y mantener los procesos de ITSCM de acuerdo con los requerimientos globales de los procesos de gestión de continuidad Responsabilidades Desarrollar y manejar el plan de ITSCM para asegurar los objetivos de recuperación Asegurar que los servicios de TI están preparados cuando son invocados por los planes de continuidad
- 84. Roles y responsabilidades (II/II) Responsabilidades (cont...) Mantener un cronograma de pruebas Comprometer revisiones de calidad de los procedimientos Comunicar y mantener alineados los objetivos de ITSCM con las áreas de negocios y las áreas de servicio de TI Realizar revisiones regulares de los planes de continuidad Negociar y manejar contratos con terceros de servicios de recuperación Manejar la entrega de los servicios en momentos de crisis
Notas del editor
- #3: 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.
- #5: 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.
- #6: 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.
- #11: 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.
- #12: 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
- #13: 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.
- #15: 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.
- #22: El proceso de comparación y relación de incidentes.
- #24: 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.
- #34: 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.
- #36: 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).
- #45: 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.
- #48: 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.
- #57: 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.
- #59: 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.
- #60: 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.
- #66: 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.
- #67: 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%)
- #70: 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.
- #74: 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 ”.
- #75: 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.
- #83: 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.