Itil v2.5

1,881 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Itil v2.5

  1. 1. Gestión de Servicios Informáticos75.46 Administración C t l d Proyectos II75 46 - Ad i i t ió y Control de P tLic. Sergio G. Martínez
  2. 2. Retomando…
  3. 3. El concepto de servicio Cliente Lavadero Transporte Lavadero Industrial Mismo día:500 En 4 H : 50 En 4 H : 50 PrecioP i por el S i i l Servicio Día Siguiente:300 En 2 H : 100 En 2 H : 100 SLA SLO
  4. 4. La Gestión del Servicio El concepto de servicio Los servicios son los medios para entregar valor a los clientes, facilitando sus tareas para obtener resultados, sin que los ellos deban asumir los costos específicos ni los riesgos asociados. Los proveedores de servicios asumen los riesgos y asignan costos a cada cliente por los servicios que ellos proveen. Los resultados se logran a través de la ejecución de tareas y están limitados por la presencia de ciertas restricciones. Los servicios facilitan la obtención de resultados por medio del aumento del rendimiento de las tareas asociadas y la reducción de los efectos de las restricciones. El resultado es el incremento de la probabilidad de obtener los resultados deseados.
  5. 5. Visión tradicional del Servicio Informáticos etc. ters Aplicaciones Negocio atos res Servidor RoutBase de Da es A Cliente de IT T Servicio de IT C e Servicio de IT
  6. 6. Tendemos a organizarnos de esta forma… Desarrollo de Aplicaciones Tecnología Operaciones Objetivos y Objetivos y Objetivos y Prioridades Prioridades Prioridades
  7. 7. Pero los clientes nos ven así…
  8. 8. Pero los clientes nos ven así…• Disponibilidad• Performance P f• Seguridad• Soporte• Etc.
  9. 9. Base de Da es atos Change Managemennt Servidor res Co onfiguratio on Managemen nt A Aplicaciones Incident Managemen ntOrganización Problem Rout ters Managemennt Se ervice Lev vel etc. Managemen nt Servicio de IT Servicio de IT Negocio C Cliente de IT e T Nueva visión del Servicio Informáticos
  10. 10. Tradicional Gestión de Servicios Informáticos Foco en Tecnología Foco en el Negocio Administrar Infraestructura Proveer Servicios Usuarios Us ari s Clientes Modalidad “Bombero” Prevención y Control Reactivo Proactivo Islas Integrado Caos y arbitrariedad Estabilidad y Confiabilidad Decisiones ad-hoc y personales Decisiones informadas y repetibles Procesos informales Estandarización y mejores prácticas Visiones de TI
  11. 11. Gestión de Servicios Informáticos15% Tecnología: Herramientas e infraestructura Procesos: Definición, diseño, estándares, mejora continua. Gente: Roles y85% responsabilidades, administración, administración desarrollo de habilidades y disciplinas. Cultura: Valores, normas tácitas, experiencia.
  12. 12. ITIL Information Technology Infrastructure Library Biblioteca sobre: ◦ Provisión de Servicios basados en IT ◦ Gestión de la Infraestructura de IT Generados por OGC, recolectando la experiencia de los f l referentes de mercado. d d
  13. 13. ITIL Mejores Prácticas (no metodología) Lineamientos (no recetas) Debe ser adaptado a cada caso: ◦ ¿Qué procesos son críticos en mi caso? ◦ ¿Cómo implemento en concreto cada proceso? (procedimientos, definición de d fi i ió d responsabilidades y autoridades, h bilid d id d herramientas) i )
  14. 14. ¿Qué no es ITIL? Una herramienta de Software. La solución que un proveedor quiere imponer. Un conjunto de procedimientos a cumplir/seguir. El reemplazo de todo lo que ya hacemos bien. El único componente requerido para brindar un mejor servicio. Independiente del comportamiento y cultura de la organización. organización La solución a todos nuestros males (La bala de plata).
  15. 15. El modelo ITIL ITIL V3 está compuesto por las siguientes cinco publicaciones: bli i 1. Service Strategy 2. 2 Service Design S i D i 3. Service Transition 4. 4 Service Operation 5. Continual Service Improvement
  16. 16. La Gestión del Servicio El concepto de Gestión del Servicio La Gestión del Servicio es un conjunto de habilidades organizacionales especializadas para proveer valor a los clientes en la forma de servicios. Las habilidades toman la forma de funciones y procesos para gestionar los servicios a través de un ciclo de vida, con especializaciones en: p 1. Estrategia 2. Diseño 3. Transición 4. Operación 5. Mejora continua 5 M j ti
  17. 17. Procesos de: • Transición • Operación
  18. 18. Gestión de Servicios InformáticosCENTRO DE SERVICIOS ALUSUARIO
  19. 19. Objetivo Proveer un punto único de contacto (SPOC) para los clientes li Centralizar la gestión de la resolución de incidentes
  20. 20. Alcance Restablecer la operación del servicio lo más rápido posible. Registrar todos los incidentes/solicitudes. Proveer un primer nivel de soporte y diagnóstico. Proveer un primer nivel de solución cuando fuese posible. Mantener informados a los usuarios del progreso de sus casos. Llevar a cabo las encuestas de satisfacción de los usuarios. Cerrar incidentes y solicitudes. s licit des Actualizar la CMS.
  21. 21. Actividades Clasificar, asignar, realizar diagnóstico inicial, priorizar y escalar a quien corresponda el incidente l i d l i id Facilitar la rápida recuperación de los servicios Ofrecer orientación a los usuarios Promover el servicio mediante comunicaciones Proveer información de gestión (tiempo resolución, incidentes que resultaron ser RFC, cambios planificación para el próximo período, etc ) período etc.)
  22. 22. Estructuras organizativas Local Centralizado Virtual Siguiendo al Sol
  23. 23. Local Usuario Local Usuario Local Usuario Local Usuario Local Service Desk Local Gestión deGestión Técnica Gestión de Soporte de Gestión de Operaciones de TI Aplicaciones p terceros Requerimientos q
  24. 24. Local Diseñado para soportar las necesidades locales del negocio. i El soporte se encuentra y brinda usualmente en la misma localidad que está siendo soportada soportada. Es práctico para pequeñas organizaciones. Es impráctico para organizaciones dispersas E i á ti i i di geográficamente.
  25. 25. Service Desk centralizado Sede Cliente 1 Sede Cliente 2 Sede Cliente 3 Service Desk Segunda línea Gestión deGestión Técnica Gestión de Soporte de Gestión de Operaciones de TI Aplicaciones terceros Requerimientos
  26. 26. Service Desk centralizado Se centraliza la atención de varios centros geográficos distintos en un S i D k central. di i Service Desk l Puede requerirse soporte en forma presencial, pero esto debe ser manejado y administrado desde el Service Desk. Ventajas para las grandes organizaciones: ◦ Reduce los costos operacionales. ◦ Una vista gerencial central consolidada. g ◦ Mejora el uso de los recursos.
  27. 27. Service Desk virtual San Francisco Service Desk Paris Rio de Janeiro Service Desk Service Desk Virtual Service Desk Sydney Beijing Service DeskService Desk Sistema de Gestión de los Servicios de Conocimiento London Service Desk
  28. 28. Service Desk virtual La ubicación de los analistas del SD es transparente al usuario. i Puede incluir elementos de tele-trabajo. Deben existir procesos y procedimientos comunes – un solo registro de incidentes. Lenguaje común acordado para la entrada de datos. L j ú d d l t d d d t Punto único de contacto con el cliente. Puede seguir requiriéndose presencia on-site para algunos puntos.
  29. 29. Siguiendo al Sol Permite brindar una cobertura de servicio total, basándose en los husos horarios de las distintas b á d l h h i d l di i regiones geográficas desde donde se da servicio. Se debe considerar en este caso especial atención caso, sobre las herramientas, procesos e idioma a utilizar por las distintas regiones.
  30. 30. Grupos de Service Desk especializados En algunos casos es recomendable crear grupos de especialistas dentro de l f ió de S i D k i li d d la función d Service Desk. Esto permitirá derivar los incidentes según el tipo de especialista que pueda resolverlos resolverlos.
  31. 31. Recomendaciones Recomendaciones de ambientación: ◦ Luz natural y suficiente espacio físico. ◦ Control acústico del ambiente. ◦ Área de esparcimiento o break. Recomendaciones para facilitar el contacto único: ◦ Hacer público el número telefónico del Service Desk. ◦ Adhesivos informando el número en los teléfonos. ◦ U l Utilización de salvapantallas con datos de contacto del S ó d l ll d d d l Service Desk. ◦ Incorporar merchandising con el número de contacto. p g
  32. 32. Gestión de Servicios InformáticosGESTIÓN DE INCIDENTES
  33. 33. Objetivos Restaurar la operación normal del servicio afectado lo más rápido posible, minimizando el impacto en el á á id ibl i i i d li l negocio y asegurando que se mantengan los niveles acordados de calidad y disponibilidad. p Se entiende por operación normal del servicio a lo que se haya definido dentro de los límites del SLA.
  34. 34. Alcance Abarca cualquier evento que impacte, o pueda impactar, a un servicio. i i Existen eventos de tipo informativo, para lo cual existe un tratamiento especial en el proceso de Gestión de Eventos. Las Peticiones de Servicio (Service Request) serán derivados al proceso específico correspondiente.
  35. 35. Incidente Se refiere tanto a la interrupción no planificada de un servicio de TI como a la reducción en la calidad de éste. i i d l d ió l lid d d é También se consideran incidentes a aquellas fallas de elementos de configuración que no hayan impactado (todavía) a un servicio (Ej. la falla de un disco físico correspondiente a un conjunto de discos espejados).
  36. 36. Modelos de incidentes Son aquellos incidentes que pueden considerarse repetitivos y para los cuales se crea un modelo ii l l d l predefinido de incidente. Se debe tener en cuenta: ◦ Los pasos a seguir en el incidente incidente. ◦ El orden de estos pasos. ◦ Responsabilidades. p ◦ Procedimientos de escalamiento. ◦ Líneas de tiempo.
  37. 37. Incidentes graves Debe existir un proceso que se encargue del manejo de incidentes graves. i id La definición de qué es un Incidentes graves debe ser realizada a nivel corporativo, teniendo en cuenta los corporativo criterios de priorización e impacto al negocio. Un Incidente grave no es un problema. Puede requerirse la utilización de un equipo de investigación dedicado.
  38. 38. Actividades Identificación Registro Categorización y priorización Diagnóstico Inicial Escalamiento Investigación y diagnóstico Resolución y recuperación eso uc ó ecupe ac ó Cierre
  39. 39. Identificación Puede ingresar en forma proactiva (monitoreo) o reactiva (avisos d l usuario). i ( i del i )
  40. 40. Registro Todos los incidentes deben ser registrados. En caso de detectar un Incidente al resolver otro, se debe abrir un nuevo registro. Datos básicos a incluir en un registro de incidente: ◦ Número único de referencia ◦ Prioridad ◦ Fecha y hora de registro ◦ CI relacionado ◦ Categoría de cierre ◦ Método de call-back ◦ E d del incidente Estado d l d
  41. 41. Categorización Se debe definir correctamente la granularidad del árbol de d categorización. i ió Pasos para lograr el diseño de las categorías: ◦ Sesión de brainstorming entre los involucrados. ◦ Definición del nivel inicial. ◦ U ili ió d l categorías i i i l por un período corto de Utilización de las í iniciales í d d tiempo. ◦ Realizar un análisis de lo registrado. ◦ Implementar las revisiones. ◦ Repetir el punto 4.
  42. 42. Priorización Normalmente la prioridad de un incidente se define en función de: ◦ La urgencia: Cuán rápido el negocio necesita una solución. ◦ El impacto: Generalmente medido con la cantidad de usuarios afectados por el incidente. Otros factores determinantes del nivel de impacto son: ◦ Riesgo de vida. ◦ Número de servicios afectados afectados. ◦ Nivel de pérdidas financieras. ◦ Efectos en la imagen (reputación) del negocio. ◦ Violación de marcos legales o regulatorios. Algunas organizaciones necesitarán definir una prioridad especial para usuarios VIP (Gerentes, Ejecutivos, Directores). (Gerentes Ejecutivos Directores)
  43. 43. Priorización Imapcto p Alto Medio Bajo Alta 1 2 3 Urgencia U Media M di 2 3 4 Baja 3 4 5 Código de Códi d Tiempo d resolución Ti de l ió prioridad Descripción promedio 1 Críitica 1 hora 2 Alta 8 horas 3 Media 24 horas 4 Baja 48 horas 5 Planificada Planificada
  44. 44. Diagnóstico inicial Se utiliza para esto los scripts de diagnóstico y la base de datos de errores conocidos conocidos. En esta actividad se intentará resolver el incidente en un primer nivel de atención. Escalamiento: ◦ Funcional ◦ J á Jerárquico Investigación y diagnóstico: ◦ Entender el orden cronológico de eventos que causaron el incidente. ◦ Búsquedas a la KEDB. ◦ C f Confirmar el impacto del incidente. l d l d
  45. 45. Resolución y recuperación Involucra la resolución del incidente para lo cual se pueden usar los siguientes métodos: d l i i é d ◦ Realizarlo conjuntamente con el usuario. ◦ R l l remotamente. Resolverlo ◦ Utilizando un grupo de soporte presencial. ◦ Contactando un proveedor externo externo.
  46. 46. Cierre Esta actividad será realizada siempre por el Service Desk. D k El Service Desk deberá validar junto con el usuario el cierre del incidente. También deberá verificar lo incidente siguiente: ◦ Categorización de cierre. g ◦ Encuesta de satisfacción. ◦ Documentación del incidente. ◦ Cierre formal.
  47. 47. Roles y responsabilidades Administrador de Incidentes ◦ Promover la eficiencia y eficacia del proceso. ◦ Producir información de gestión. ◦ Administrar los recursos humanos. ◦ Monitoreo de la efectividad del proceso y recomendaciones de mejora. ◦ Desarrollo y mantenimiento de los sistemas de la Gestión de Incidentes. ◦ Administración de Incidentes Mayores. ◦ Desarrollo y mantenimiento del proceso de la Gestión de Incidentes y sus procedimientos procedimientos.
  48. 48. Roles y responsabilidades Primera línea ◦ Atención inicial de incidentes ◦ Escalamiento Segunda línea ◦ Grupo de soporte (puede ser soporte de campo). ◦ Mayor conocimiento técnico. Tercera línea ◦ Incluye a los grupos de especialistas (Servers, bases de datos, redes).
  49. 49. Gestión de Servicios InformáticosGESTIÓN DE PROBLEMAS
  50. 50. Objetivos Prevenir la ocurrencia de problemas e incidentes asociados. i d Eliminar incidentes recurrentes. Minimizar el impacto de incidentes que no pudieron ser prevenidos.
  51. 51. Problema Causa desconocida de uno o más Incidentes.
  52. 52. Impacto, urgencia y prioridad Los problemas deben priorizarse utilizando los mismos criterios utilizados para l I id i i ili d los Incidentes ( (matriz d i de prioridades). Se debe tener en cuenta lo siguiente: ◦ Frecuencia e impacto de incidentes relacionados. ◦ Definición sobre qué constituye un problema problema. ◦ Incorporar el concepto de severidad del problema (costo, tiempo de resolución, recursos).
  53. 53. Solución alternativa En algunos casos puede ser encontrada una solución alternativa a l i id l i los incidentes causados por el problema. d l bl Es importante que aún así, se continúe con la investigación de la causa raíz del problema problema. Siempre debe registrarse en la herramienta de gestión el detalle de la solución alternativa encontrada.
  54. 54. Error conocido Una vez que se complete el diagnóstico del problema y que se haya encontrado una solución alternativa, se deberá registrar en la KEDB el error conocido. De esta manera, si surgen nuevos incidentes o problemas relacionados, éstos p , pueden ser resueltos rápidamente. p También puede detectarse la necesidad de registrar un error conocido en una fase previa al diagnóstico, a modo informativo. Identificación de errores conocidos ◦ La identificación y registro del error conocido debe llevarse a cabo aún si todavía no se ha encontrado la solución definitiva del error, proporcionando información de su existencia y/o posibles registros de soluciones temporales de prueba. ◦ Para evitar la duplicación de registros, se recomienda centralizar la administración d la KEDB en un único responsable. d i i t ió de l ú i bl
  55. 55. Base de datos de errores conocidos Permite el almacenamiento del conocimiento obtenido a través d l t é de la resolución de incidentes y problemas, para l ió d i id t bl permitir un rápido diagnóstico y solución en caso que ocurran. El registro de error conocido debe contener detalles exactos de la falla y sus síntomas, además de datos precisos para la solución (alternativa o definitiva) del problema. Pueden existir casos donde se decida convivir con un problema en la infraestructura de TI, cuando el caso de negocio no justifique la resolución. f l l ó Los datos incluidos en la KEDB debe ser fácilmente accesibles. accesibles
  56. 56. Roles y responsabilidades Gestor de Problemas Grupos de Resolución de Problemas
  57. 57. Gestión de Servicios InformáticosGESTIÓN DE CAMBIOS
  58. 58. Gestión de Cambios Objetivo: ◦ Mantener la Infraestructura bajo control ◦ Asegurar la aplicación de procedimientos estándares para la atención de los cambios, de manera de minimizar el impacto en cambios los servicios.
  59. 59. Gestión de Cambios Actividades: ◦ Aceptación (recepción y filtro inicial) ◦ Clasificación (menor, significativo, mayor, urgente) ◦ Aprobación y Planificación ◦ Seguimiento de la ejecución ◦ I f Información de G ó ( ó d Gestión (cantidad de Cambios que no se d dd C b aceptaron, cambios OK, etc.)
  60. 60. Actividades Crear RFC Propuesta de Cambios (opcional) Registrar el RFC Actualizar el ca Iniciador Solicitado Revisar el RFC Gestión del C bi G ió d l Cambio ambio y la información de la congig Listo para evaluación Evaluar el cambio Listo para decisión Ordenes de Trabajo Autorizar la propuesta de Autorizar el cambio cambio Change authority Autorizado Plan actualizado guración en el CM Gestión del Cambio Planificado Ordenes de Trabajo Coordinar la implementación de Cambio* Gestión del Cambio MS Implementado Revisar y cerrar el registro Reporte de evaluación de cambio Cerrado *Incluye construcción y prueba del cambio
  61. 61. Crear el RFC El cambio es originado por pedido de un iniciador. Para cambios mayores con implicaciones organizacionales y/o financieras significativas, puede ser requerida una propuesta de cambio (Change Proposal) Proposal). La propuesta de cambio contendrá una descripción completa del cambio junto con una justificación financiera y de negocio. Los procedimientos para registrar y documentar los cambios deben estar previamente definidos.
  62. 62. Crear el RFC Número RFC RFC Iniciación Motivo del Cambio Descripción del Cambio Análisis de Riesgo CI (atributos) e Impacto / Recursos Fecha y Hora de Prioridad U P i id d y Urgencia i Implementación Implementación Recomendación del CAB Programada Implementador d l I l t d del Resultados del Cambio Cambio Resutado de las Pruebas Autorizado por Fecha y Hora de Revisión Aprobación Post-Implementación
  63. 63. Revisar el RFC La Gestión de Cambios debe revisar cada uno de los requerimientos y fil i i filtrar l que considera que son: los id ◦ Imprácticos. ◦ R Repetidos en otros RFC recientes que fueron aprobados, id i f b d rechazados o continúan en revisión. ◦ Incompletos.
  64. 64. Evaluar el RFC Debe evaluarse la implementación de cada cambio. Se propone seguir el método d l siete ‘R’ d l G ió i l é d de las i de la Gestión del Cambio ◦ ¿Quién REQUIERE el cambio? ◦ ¿Cuál es la RAZÓN del cambio? ◦ ¿Cuál es el RETORNO esperado del cambio? ¿ p ◦ ¿Cuáles son los RIESGOS implicados en el cambio? ◦ ¿Cuáles son los RECURSOS necesarios para realizar el cambio? ◦ ¿Quién es RESPONSABLE de la construcción, prueba e implementación del cambio? ◦ ¿Cuál es la RELACIÓN entre éste y otros cambios? C ál l é bi ?
  65. 65. Gestión del CambioEvaluar el RFC Categorización de riesgos. Evaluación de cambios. Asignación de prioridad. Planificación de cambios.
  66. 66. Coordinar la Implementación Los especialistas técnicos deben construir el cambio. Change Management tiene la responsabilidad de asegurar que los cambios sean implementados tal como fueron planificados planificados. Verificar los procedimientos de vuelta atrás (Remediation Plan) Change Management tiene un rol de control para asegurar que todos los cambios hayan sido testeados.
  67. 67. Gestión del CambioRevisar y Cerrar el RFC Es necesario realizar una revisión post-implementación para confirmar fi ◦ Que el cambio cumplió con sus objetivos. ◦ Q el i i i d y los demás i Que l iniciador l d á interesados están conformes con el d á f l resultado. ◦ Que no se han producido efectos colaterales.
  68. 68. Gestión del CambioRoles y responsabilidades Administrador de Cambios ◦ Asigna prioridades a los RFC junto con el iniciador. ◦ Rechaza los RFC que son impracticables. ◦ Lista todos los RFC para ser revisados en las reuniones del CAB. ◦ Elabora la agenda de la reunión y la envía con anticipación a todos los miembros del CAB. ◦ Decide quiénes deben asistir a las reuniones, dependiendo de la naturaleza del RFC, qué es lo que será modificado y qué áreas RFC de conocimiento técnico son necesarias.
  69. 69. Gestión del CambioRoles y responsabilidades Administrador de Cambios ◦ Convoca las reuniones del Comité de Cambios / Comité de Emergencia (CAB/EC : Change Advisory Board / Emergency Committee) para los cambios urgentes. ◦ Preside todas las reuniones del CAB y del CAB/EC. ◦ Actualiza el registro del cambio. ◦ Revisa todos los cambios implementados. ◦ Cierra los RFC. ◦ Realiza reportes regulares de la gestión.
  70. 70. Gestión del CambioRoles y responsabilidades Comité de Administración de Cambios ◦ El CAB es un cuerpo que existe para dar soporte en la autorización de los cambios y en asistir en la evaluación y priorización de los mismos. ◦ Reglamento del CAB Deben distribuirse los RFC con antelación a la reunión. Responder y realizar el análisis de los RFC (mandatorio). Concurrir a la reunión del CAB (opcional). Aprobar o rechazar los RFC. Analizar cambios aplicados sin una referencia al CAB Revisión del proceso de cambios Resultados del negocio que salen del proceso de cambio
  71. 71. Gestión del CambioRoles y responsabilidades Comité de Emergencias ◦ Es un grupo pequeño de personas que se reúnen o contactan para la evaluar y autorizar los cambios de emergencia. ◦ La selección de los miembros puede depender de la naturaleza del cambio. Los miembros deben tener conocer y entender tanto las perspectiva del negocio como los temas técnicos, para poder tomar las decisiones apropiadas. ◦ El contacto vía teléfono o email puede ser el único medio factible de reunión.
  72. 72. Gestión de Servicios InformáticosGESTIÓN DE ACTIVOS DESERVICIO Y CONFIGURACIÓN
  73. 73. Gestión de la Configuración Objetivo: ◦ Identificar, registrar y ofrecer información de todos los componentes de IT que están bajo el control de Gestión de la Configuración
  74. 74. Gestión de la Configuración Los CI (configuration items) se registran en una CMDB (configuration management d b ) ( fi i database) Los CI tienen: ◦ Alcance (qué aplicativos, sectores, etc interesan?) ◦ Nivel (registro “1 PC” o registro “1 mouse” + 1 teclado”, etc) ◦ A ib Atributos ◦ Relaciones DSL (Definitive Software Library)
  75. 75. Gestión de la Configuración SLA Personas Ubicaciones Información Capacidad Activos InformaciónDisponibilidad Releases CMDB Licencias Documentación Información Cambios Incidentes Financiera
  76. 76. Gestión de la Configuración Actividades: ◦ Planificar ◦ Identificar ◦ Controlar ◦ Información de gestión (info de capacidad y crecimiento, clasificación de los CI’s, cambios que tuvo cada CI, datos CI s, incorrectos en la CMDB, etc )
  77. 77. Configuration Management System Para administrar configuraciones grandes y complejas, la gestión requiere el uso d algún sistema d soporte, al ió i l de l ú i de l que normalmente se conoce como Configuration Management System. g y El CMS mantiene en la CMDB toda la información de los CI bajo control de configuración según está definida en el alcance.
  78. 78. Definitive Media Library La Definitive Media Library es una biblioteca segura en la cual las versiones definitivas de todos los CI son almacenadas y protegidas. En la DML se almacenan todas las copias maestras que han p pasado por los controles de calidad. p La DML debe incluir copias definitivas de software comprado (junto con licencias e información) y de software desarrollado internamente. Las copias maestras de la documentación de un sistema también deben ser almacenada de forma electrónica en la DML. La DML incluirá un lugar físico para guardar copias. Sólo lo que ha sido debidamente autorizado podrá aceptarse en la DML DML.
  79. 79. Relación entre la DML y la CMDB DML and CMDB DML Cis Físicos Información sobre CIs Cis CMDB Electrónicos Registro de versión Construcción de una nueva versión Prueba de una Implementación de nueva versión una nueva versión Distribución de una nueva versión en producción
  80. 80. Configuration Baseline Es la configuración de un servicio producto o infraestructura que h sido formalmente revisada, i f ha id f l i d acordada Servirá de base para futuras actividades y puede ser modificada sólo a través de procedimientos formales de cambio. Contiene la estructura, los contenidos y los detalles de una configuración, y representa un conjunto de CI y sus relaciones. relaciones
  81. 81. Configuration Snapshot Es el estado actual de un CI o de un entorno, por ejemplo obtenido a través d una herramienta de j l b id é de h i d descubrimiento. Esta foto es guardada en el CMS y queda como un registro de estado histórico.
  82. 82. Roles del Proceso Administrador de Activos de Servicio Administrador de Configuraciones Analista de Configuraciones Administrador de la Librería de Medios Administrador de Herramientas / CSM Comité de Control de Configuración
  83. 83. Gestión de Servicios InformáticosGESTIÓN DE LIBERACIONESY DESPLIEGUE
  84. 84. Gestión de Liberaciones Objetivo: ◦ Asegurar que todos los aspectos de la liberación de un cambio (técnicos y no técnicos) sean tenidos en cuenta. ◦ Facilitar la introducción del software y hardware en un ambiente de IT controlado
  85. 85. Alcance Asegurar planes de despliegue e implementación claros y comprensibles comprensibles. Definir paquetes de versiones que puedan ser construidos, instalados, testeados y desarrollados eficientemente, para que sea posible una implementación exitosa. Permitir introducir servicios nuevos o modificados modificados, junto con los sistemas, tecnología y organización que lo soporten, que sean capaces de cumplir con los SLA. Lograr clientes, usuarios y personal de sistemas conformes con las prácticas y los entregables del p proceso.
  86. 86. Unidad de implementación Describe la porción de un servicio o de la infraestructura d TI que normalmente es lanzada en i f de l l d forma conjunta, de acuerdo con la política de versiones de la organización. g Puede variar dependiendo del tipo de elemento o componente de servicio, sea éste HW o SW. Las versiones deben ser identificados de forma única de acuerdo con el esquema definido en la política de release. release La identificación del release debe incluir una referencia a los CI que representa. Servicio A de TI A1 A2 A3 A2.1 A2.2 A3.1 A2.1.1
  87. 87. Paquete de implementación Un paquete puede ser una única versión o un conjunto estructurado de unidades de implementación . d d id d d i l ió
  88. 88. Formas de implementación Big Bang vs. Por fases ◦ Big Bang: El servicio nuevo o modificado es implementado conjuntamente a todos los usuarios. ◦ Por fases: El servicio es implementado inicialmente a una parte de los usuarios, y luego se repite la misma operación al resto de usuarios siguiendo un plan. Push vs. pull ◦ Push: El componente del servicio es distribuido desde una posición central a las estaciones de trabajo de los usuarios. ◦ Pull: El componente del servicio es colocado en una p p posición central y los usuarios lo bajan cuando disponen de tiempo a sus estaciones de trabajo. Automatizado vs. manual ◦ E el mecanismo de implementación de las versiones. Es l d l ó d l
  89. 89. Actividades Planificación (políticas, recursos) Preparación y automatización de la instalación Aceptación (de usuarios y demás áreas afectadas) Planificación del despliegue Comunicación Capacitación Distribución e instalación (despliegue) st buc ó sta ac ó ( esp egue) Información de Gestión (cantidad de despliegues, cantidad de CI’s impactados en cada despliegue, etc.)
  90. 90. ActividadesRoles de Administración de Cambios Órdenes de Trabajo para Cambio Menor Órdenes de Trabajo para Cambio Signif icativ o o May or 5 Administración de Cambios "Planeación de Corrección Menor no autorizada" "Planeación de Corrección Menor autorizada" "Planeación de Corrección Menor autorizada" "Planeación de Corrección Significativa o May no autorizada" "Planeación de Corrección Significativa o May autorizada"Administrador de Liberación Orden de Trabajo para mpletadasEmpresarial "Ciclo de Cambio Estándar Planeación de 8.1 Políticas de Liberación 8.2 82 Liberaciones" Revisar y Actualizar Políticas mbio Significativo o Mayor com Planear Liberación y Plan de Liberación Anual mbio Estándar completadas mbio Menor completadas Políticas y Plan de LiberaciónSistema de Administración de Anual actualizadosServicios Plan de Rev ersión de "Cambio Significativo o Mayo revertido" Liberación eración" "Cambio Menor revert ido" or Órdenes de Trabajo para Cam Órdenes de Trabajo para Cam Órdenes de Trabajo para Cam "Tiempo insuficiente para Libe Políticas y P líti yor yor "Cambio Estándar revertido" "Plan de Corrección Menor" "Plan de Corrección Mayor" Plan de LiberaciónRoles de Administración de AnualProblemas Notas de Liberación 3 (posibles errores conocidos) Administración de ProblemasAdministrador de Liberación "Prueba de Sistema de Aceptación Notif icación sobre 8.4 8.5 8.3 Monitoreo exitosa" serv icio prov isto Realizar Pre-Producción y Activar Liberación Preparar Liberación disponible Validación "Liberación f allida y "Liberación implementada" Corrección no autorizada" FIN FINRoles de Administración deIncidentes y Requerimientos de 2Servicio Administración de Incidentes y Requerimientos de Servicio
  91. 91. Roles Gestor de Implentación y Versión (Release and Deployment M D l Manager)) Gestor del Paquete de Implementación (Release Packaging and Build Manager) Personal del Despliegue (Deployment staff)
  92. 92. Interacción entre los principales procesos d Transición y Operación de T ó O ó Incidente escaladoCLIENTES Incidente / Gestión de  Requerimiento Incidentes De Servicio Incidente Problema resueltoMarketing ServiceVentas DeskFinanzas Incidente / RequerimientoClientes externos De servicioEtc. resuelto Gestión de  Gestión de  Problemas la Configu‐ l C fi Cis  ración RFC Base de  conocimiento SLA RFC Catálogo  de  Servicios Gestión de  Gestión de  Release Cambios
  93. 93. Escenario Genérico
  94. 94. Escenario Genérico ¿Tiene SLA? ¿Qué hacer? Cliente Incidente 1 Incident Manager Restauración de servicio (1), SL Gold, Tiempo: 15m. Incidente 2 Restauración de servicio (2), SL “Silver”, Tiempo: 1hr.Se evitan futuros incidentes ¿Tienerelacionados con l i d Identifica la Id ifi l SLA? la Causa Raíz Causa Raíz Incidentes Registrados ¿Cuál es el mejor Release/Operations momento? Change Problem Manager Manager Manager Service Request for Order Change
  95. 95. Escenario Genérico Cliente Incidente 1 Incident Restauración de servicio (1), SL Gold, Tiempo: 15m. Manager Incidente 2 Restauración de servicio (2), SL “Silver”, Tiempo: 1hr.Se evitan futuros incidentes CMDBrelacionados con l i d Configuration Mgmt. DB la Causa Raíz Incidentes Registrados Release/Operations Change Problem Manager Manager Manager Service Request for Order Change
  96. 96. Gestión de Servicios InformáticosGESTIÓN DE NIVELES DESERVICIO
  97. 97. Gestión de Niveles de Servicio Objetivo: ◦ Mantener y optimizar la calidad de los servicios de IT, a través de ciclos constantes de acuerdo y monitoreo para alcanzar los objetivos de negocios del cliente
  98. 98. Gestión de Niveles de Servicio SLA: ◦ Service level agreement es un acuerdo escrito entre el proveedor de servicios de IT y sus clientes donde se definen puntos claves de servicios y responsabilidades de ambas partes.
  99. 99. Gestión de Niveles de Servicio Actividades: ◦ Planificar: Establecer el proceso (mediciones actuales, iniciar acuerdos internos y con proveedores) ◦ Implementar SLA (definir catálogo de servicios acordar SLAs, servicios, SLAs definir frecuencia de revisiones y mediciones) ◦ Administrar el proceso (realizar y evaluar mediciones, revalidar con el cliente, actualizar SLA ) l l l SLAs)
  100. 100. Gestión de Niveles de Servicio OLAs Áreas SLRs Internas Catálogo deCliente Servicios S i i de TI Áreas SLAs UCs Externas
  101. 101. Gestión de Servicios InformáticosGESTIÓN DE CAPACIDAD
  102. 102. Gestión de la Capacidad Objetivo: ◦ Asegurar que todos los aspectos de performance (actuales y futuros) de los requerimientos de negocio sean provistos de manera efectiva en costos ◦ Balancear capacidad con demanda
  103. 103. Gestión de la Capacidad Actividades: ◦ Business Capacity Management: Asegura que se tengan en cuenta los requerimientos futuros del negocio para los servicios de IT, planificándolos e implementándolos en los tiempos requeridos ◦ Service Capacity Management: Identifica e interpreta la performance actual de los servicios de IT (donde están los picos? Se cumple con los SLAs?) ◦ Resource Capacity Management: Identifica e interpreta la capacidad y utilización de cada elemento de la infraestructura. Está al tanto de nuevas tecnologías. Asegura el uso óptimo de los recursos.
  104. 104. Gestión de Servicios InformáticosGESTIÓN DEDISPONIBILIDAD
  105. 105. Gestión de la Disponibilidad Objetivo: ◦ Optimizar la capacidad de la infraestructura de IT, los Servicios y la Organización de soporte para proveer un nivel de disponibilidad efectivo en costos y que facilite al negocio alcanzar sus objetivos ◦ Minimizar interrupciones en los servicios
  106. 106. Gestión de la Disponibilidad Actividades: ◦ Determinar requerimientos (OLO) ◦ Planificar ◦ Monitorear ◦ Información de Gestión
  107. 107. Gestión de Servicios InformáticosGESTIÓN DE LACONTINUIDAD DELSERVICIO
  108. 108. Gestión de Continuidad delServicio Objetivo: ◦ Asegurar que los servicios de IT puedan ser recuperados dentro de los plazos acordados
  109. 109. Gestión de Continuidad del Servicio Actividades: ◦ Inicio (definición y organización del proyecto, identificación de políticas, recursos requeridos, etc.) ◦ Requerimientos y estrategia (definición de procesos de negocio críticos, pérdida potencial, plazos; se trata de una evaluación de riesgos) ◦ I l Implementación (d f ó (definición de procedimientos, contratos con ó d d proveedores, instalaciones, capacitación, pruebas) ◦ Administración (pruebas p (p periódicas) )
  110. 110. Gestión de Servicios InformáticosGESTIÓN FINANCIERA
  111. 111. Gestión Financiera Objetivo: ◦ Costear y distribuir los servicios de IT
  112. 112. Gestión Financiera Actividades: ◦ Presupuestación ◦ Contabilidad ◦ Distribución ◦ Información de Gestión
  113. 113. Gestión Financiera Hardware Software TransferenciasServicios Externos Oficinas Gente
  114. 114. Gestión de Servicios InformáticosFIN

×