ITIL en el contexto del MAAGTIC

1. ITIL en el contexto del MAAGTIC

2. http://www.sg.com.mx/content/view/1063/1/

3. ITIL ITIL ofrece un marco de buenas prácticas para la administración de los servicios

4. IT Service Management • Es una estrategia para administrar la organización de TI, como si fuera un negocio dentro del negocio, a través de una metodología enfocada al cliente y orientada al servicio, habilitada y soportada por las mejores prácticas.

5. Definición de ITIL • Es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI.

6. ITIL v3 • ServiceStrategy • ServiceDesign • ServiceTransition • ServiceOperation • ContinualServiceImprovement (CSI)

8. ITIL v3

9. Relación entre COBIT e ITIL • COBiT tiene un mayor alcance que ITIL ya que pretende abarcar todo el espectro de actividades de IT, mientras que ITIL está centrado solo en “Service Management” (gestión del servicio). • Ambos modelos son también complementarios y se pueden usar juntos: • ITIL para lograr efectividad y eficiencia en los servicios TI • COBIT para verificar la conformidad en cuanto a disponibilidad, rendimiento, eficiencia y riesgos asociados de dichos servicios con los objetivos y estrategias de la compañía, usando para ello métricas claves y cuadros de mando que reporten dicha información.

10. Cumplimiento de requisitos • ITIL es un marco de referencia. Cada organización puede determinar que le aplica. • Sin embargo, para obtener una certificación ISO 20000 se DEBE CUMPLIR con una serie de requisitos (basados en ITIL). • Todo parece indicar que MAAGTIC es un conjunto de requisitos que DEBEMOS cumplir. • COBIT contempla un proceso de madurez gradual. ¿MAAGTIC permite ir madurando gradualmente?

11. Vistazo a algunos de los 32 procesos de ITIL

12. ServiceLevelAgreement

13. ServiceLevelAgreement • Los SLA o ServiceLevelAgreements son documentos contractuales usualmente utilizados entre empresas y proveedores o subcontratas que reflejan los principales acuerdos establecidos entre partes para la prestación de uno o varios servicios.

14. Catálogo de Servicios • El cliente y los usuarios deben tener claro los servicios ofrecidos y los acuerdos de nivel de servicio para cada uno de ellos.

15. ServiceLevel Management

16. ServiceLevel Management • Es esencial que para cualquier organización que los niveles de servicio de TI, requeridos por el negocio, estén bien determinados. • Debe reflejar claramente las espectativas de los clientes. • Se establece considerando: • Las exigencias del cliente. • Prioridades del negocio. • Capacidades de TI.

17. ServiceLevel Management • Objetivo: • Asegurar que se ofrece y mejora la calidad de los servicios de TI, a través de un ciclo constante de acordar, supervisar, y obtener reportes, para lograr su alineación a las necesidades del negocio y una mejor relación con los clientes. • Además, lleva a cabo acciones que buscan erradicar el mal servicio a un costo adecuado. • Su interés principal es que el cliente esté lo más satisfecho posible.

18. ServiceLevel Management • Beneficios: • Medidas respecto del servicio actual comparadas con el esperado. • Permite al cliente comprar el servicio vs. los cargos monetarios. • Potencial reducción de costos en el largo plazo. • Menos demandas impredecibles. • Mejora de la relación con los clientes.

19. Cliente vs. usuario • Cliente: Alguien que compra bienes o Servicios. El Cliente de un Proveedor de Servicios TI es la persona o grupo que define y acuerda el Objetivo de Nivel de Servicio. • Usuario: El que utiliza el servicio.

20. ServiceLevel Management • Conceptos Clave: • Catálogo de servicios. • Requerimientos de nivel de servicio (SLR). • Acuerdo de nivel de servicio (SLA) (del cliente hacia TI). • Acuerdo de nivel operacional (OLA) (interno entre áreas de TI) . • Contrato externo. UnderpinningContract (UC) (de TI hacia sus proveedores externos). • Programa de mejoramiento de servicio (SIP).

21. ServiceLevel Management • Actividades: • Producir y mantener el catálogo de servicios. • Negociar y acordar los niveles de servicio. • Medir y reportar los niveles de servicio vs. el SLA. • Revisar los acuerdos y mantenerlos acorde a las necesidades del negocio. • Proactivamente mejorar los niveles de servicio.

22. Aplicación en el manual

23. ServiceDesk • Objetivos • Actuar como punto único de contacto. • Facilitar la restauración de la operación normal del servicio, dentro de los niveles y prioridades establecidas, minimizando el impacto en el negocio. • Administrar los incidentes y requerimientos, así como proveer una interface con otros procesos de TI.

24. ServiceDesk • Conceptos clave: • Incidente: Cualquier desviación de la operación estándar y que causa o pueda causar una interrupción o reducción de la calidad en el servicio conforme a los SLAs. • Requerimiento de servicio: Cualquier incidente que no es una falla en la infraestructura de TI. • Cambio estándar: Es un cambio que ha sido preaprobado y que por lo tanto puede ser seguir un procedimiento previamente establecido.

25. ServiceDesk • Factores críticos de éxito: • Entendimiento de las necesidades del negocio y de los requerimientos de los clientes y los usuarios. • Inversión en capacitación. • Definición clara de objetivos, metas, entregables y catálogo de servicios. • Niveles de servicio prácticos, convenidos y revisados regularmente. • Apoyo de la organización. • Participación de clientes y usuarios.

26. ServiceDesk • KPI’s • Servicios solucionados en el primer nivel de soporte. • Tiempo de respuesta a un incidente. • Incidentes clasificados y escalados correctamente. • Consultas por estatus por parte del usuario. • Satisfacción del cliente, satisfacción de los usuarios.

27. ServiceDesk • Entradas: • Planeación de TI • Información Organiacional • SLA’s, OLA’s y UC’s • Catálogo de servicios • Calendario de cambios • Solicitud de servicio o incidente • Salidas • Reportes de estatus • Reporte de cierre • Reporte de desempeño • Plan de mejora • Solicitudes de cambio

28. Aplicación en el manual

29. Incident Management

30. Incident Management • Los incidentes y problemas son inevitables. • Afectan a la normalidad y estabilidad de los servicios e impactan en la productividad del negocio. • Afectan también la calidad de los procesos y es importante minimizar el impacto en los negocios. • Se asignan prioridades a los incidentes de acuerdo a el impacto y a la urgencia.

31. Incident Management • Objetivos: • Restaurar el estado normal de las operaciones y servicio de TI tan pronto como sea posible a fin de minimizar el impacto adverso de las operaciones asegurando el cumplimiento de los niveles de servicio. • ¿Para qué? • Asegurar el mejor uso de los recursos para el soporte. • Llevar registros detallados acerca de incidentes y solicitudes de servicio. • Medición para comparar contra los SLA’s • Desarrollar una estrategia consistente de resolución de incidentes.

32. Incident Management • Conceptos clave • Incidente. Cualquier evento que no es parte de la operación estándar de un servicio y que causa, o puede causar la interrupción o reducción en la calidad de ese servicio. • Solución temporal (workaround). Método para solucionar un problema del que no se conoce la causa raíz (solo es temporal y se sabe que el problema continua). • Prioridad. Es la secuencia en la cual unincidente o problema requiere ser resuelto, de acuerdo a su impacto y urgencia. • Impacto. Se refiere al número de usuarios/módulos/departamentos afectados. Es el grado en el cuál la pérdida del servicio impactará al negocio. • Urgencia. Retraso en tiempo aceptable para el usuario, el cliente y el negocio con respecto a la interrupción de un servicio.

33. Incident Management • Factores críticos de éxito: • Mantener la calidad en el servicio de TI • Mantener la satisfacción del cliente • Resolver incidentes dentro de los términos establecidos. • Mantener actualizada la CMDB. • Un sistema adecuado para el registro y seguimiento, así como base de datos de conocimientos. • La estrecha relación con el SLM.

34. Incident Management • KPI’s • Soluciones en línea o % de incidentes cerrados por el SD sin escalación. • Número total de incidentes. • Tiempo promedio de acuerdo a la prioridad • % de incidentes resueltos dentro de los SLA’s • Costo promedio por incidente. • Incidentes por operador/especialista • # de incidentes con una clasificación inicial correcta/incorrecta. • % de incidentes resueltos de forma remota.

35. Actividad • Diseñar un proceso de Incident Management para la empresa con la que han trabajado. • Debe buscarse nuevamente aplicar lo aprendido, pero acorde a las necesidades de la empresa. • Debe ser algo factible y práctico de llevar a cabo con el personal de TI que tiene la empresa. • Preparar un documento para mostrar al frente.

36. Priorización de incidentes

37. Problem Management

38. Problem Management • Se debe minimizar el impacto negativo de los incidentes y de los problemas de manera proactiva. • De esta manera se mejoran los servicios de TI a través de la identificación, definición, administración y eliminación de las causas de un problema originado por errores en la infraestructura de TI. • Se evita la recurrencia de problemas.

39. Problem Management • Objetivo: • Encontrar la causa raíz de los problemas actuales y potenciales, a fin de minimizar el impacto adverso sobre el negocio causado por incidentes y problemas relacionados con errores dentro de la infraestructura de TI. • Es reactivo y proactivo

40. Problem Management • Problema es la causa raíz desconocida de uno o más incidentes. • Se convertirá en un error conocido cuando la causa raíz es conocida y una solución temporal ha sido implementada.

41. Problem Management • Factores críticos de éxito: • Registro efectivo de incidentes. • Registro del comportamiento de la infraestructura. • Objetivos cuantificables. • Aprovechamiento del nivel de experiencia del personal. • Coordinación y cooperación efectiva con Incident Management. • Comunicación de los errores conocidos.

42. Aplicación en el manual

43. ¿Qué nivel de profundidad o de detalle debe tener cada proceso?

44. Ejemplo de MAAGTIC Mesa de Servicios

45. Objetivos del proceso • General • Establecer y operar un punto único de contacto para que los usuarios de los servicios hagan llegar sus solicitudes de soporte, recibirlas, registrarlas, clasificarlas, categorizarlas, atenderlas y documentarlas. • Específicos • Gestionar el ciclo de vida de los soportes que se prestan a la dependencia o entidad. • Generar y distribuir la información de los procesos realizados por la mesa de servicio, para la toma de decisiones. • Solucionar el mayor número de solicitudes de soporte en los primeros niveles de soporte para reducir su tiempo de resolución y costo. • Medir la satisfacción del usuario final con respecto al uso de los servicios provistos y difundir sus resultados.

49. Actividades del proceso • OMS-1: Establecer el punto único de contacto. • OMS-2: Definir la solicitud de soporte, sus tipos y estados. • OMS-3: Establecer procedimientos para atender y solucionar solicitudes de soporte • OMS-4: Establecer el esquema de operación de la mesa de servicios • …. • OMS-10: Medir la satisfacción del usuario.

50. Cada uno tiene factores críticos: ¿Son obligatorios? ¿Son solo deseables?