itil en el contexto del maagtic

ITIL en el contexto del MAAGTIC

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

ITILITIL ofrece un marco de buenas prácticas para la

administración de los servicios

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.

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.

Definición de ITIL

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service Improvement (CSI)

ITIL v3

ITIL v3

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.

Relación entre COBIT e ITIL

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?

Cumplimiento de requisitos

Vistazo a algunos de los 32 procesos de

ITIL

Service Level Agreement

Los SLA o Service Level Agreements 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.

Service Level Agreement

El cliente y los usuarios deben tener claro los servicios ofrecidos y los acuerdos de nivel de servicio para cada uno de ellos.

Catálogo de Servicios

Service Level 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.


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.


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.


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.

Cliente vs. usuario

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. Underpinning Contract (UC) (de

TI hacia sus proveedores externos).◦ Programa de mejoramiento de servicio (SIP).


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.


Aplicación en el manual

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.

Service Desk

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.

Service Desk

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.

Service Desk

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.

Service Desk

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

Service Desk

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.

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.

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.

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.

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.

Incident Management

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.

Actividad

Priorización de incidentes

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.

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

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.

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.

Problem Management

¿Qué nivel de profundidad o de detalle debe tener cada

proceso?

Ejemplo de MAAGTIC Mesa de Servicios

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.

Objetivos 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.

Actividades del proceso

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

Configuration Management

52

Configuration Management Las organizaciones necesitan tener actualizada la

información de la infraestructura con la que cuentan para proveer sus servicios de manera eficaz y eficiente al negocio.

Los CI´s.◦ Hardware◦ Software◦ Documentación

Procesos y procedimientos Documentación técnica Diagramas

◦ IT Staff, NO Usuarios Los CI´s son requeridos para brindar un servicio, con una

identificación única, cambiable y gestionable. Tienen una categoría, relaciones, atributos, estatus.

53

Objetivo◦ Identificar, controlar, mantener y verificar las

versiones de los elementos de configuración (CI) a fin de formar el modelo lógico de la infraestructura de IT

¿Para qué?◦ Contabilidad de todos los bienes de IT◦ Proveer información confiable que apoye a otros

procesos del service management◦ Proveer una base sólida para otros procesos◦ Verificar registros y corregir desviaciones respecto de

la realidad.◦ Mejora la seguridad controlando las versiones de los CI

´s en uso◦ Ayuda a cumplir con las obligaciones legales y

contractuales.


54

Conceptos Clave◦ Configuration Items (CIs) Componente de la

infraestructura que está (o va a estar) bajo el control de Configuration Management

◦ Configuration Management Database (CMDB), base de datos Una base de datos que contiene todos los detalles relevantes de cada CI y los detalles de las relaciones entre CI

◦ Nivel (Base Level) El nivel más bajo en el cual cada CI es identificado (una PC por ejemplo, el monitor es parte o no)

◦ Atributo. Información que define cada CI como único.


55

La CMDB puede registrar información relativa a CI´s tales como:◦ HW, SW y Comunicaciones◦ Incidentes y problemas◦ Errores conocidos◦ Cambios◦ Releases◦ Empleados TI◦ Proveedores◦ Unidades de negocios◦ SLA´s, OLAS y UC´s


56

Configuration Management Atributos

◦ Identificador único◦ Tipo o categoría◦ Nombre◦ Número de versión◦ Modelo / tipo identificación◦ Lugar / ubicación◦ Proveedor◦ Historia del CI◦ Estatus◦ Valores económicos◦ Relaciones

… Es un padre/hijo de… l … es una versión de… l … está conectado a … l … aplica a… (por ejemplo documentación) l … es usado por… (CI relacionado a un servicio)

57

Factores críticos de éxito:

◦ Interacción con el resto de los procesos◦ Disciplina para mantener el proceso◦ Mantener actualizada la base de datos (cambios

urgentes)◦ Herramientas flexibles◦ Definición correcta de alcance, atributos y nivel.


58

KPI´s◦ # de CI´s no autorizados◦ Incidentes y problemas generados por

información de configuración errónea◦ Errores en los elementos de configuración

(equivocados, duplicados, perdidos) El tiempo para aprobar e implementar cambios

◦ Fallas en cambios como resultado de información equivocada en la CMDB

◦ Ahorro en licencias / multas evitadas


Administración de la Capacidad

Se requiere tener un equilibrio entre:◦ Costo vs. Capacidad◦ Oferta vs Demanda

Los servicios de TI requieren ser respaldados por la capacidad de proceso y almacenamiento suficiente.

Es común que en las empresas se tenga capacidad en exceso lo que lleva a un desperdicio de recursos o, tal vez peor, capacidad insuficiente dar soporte al negocio.

Capacity Management

Objetivo◦ Entender los requerimientos del negocio (nivel

esperado), la operación de la organización (nivel actual de la entrega del servicio) y la infraestructura de TI, a fin de asegurarse de que exista la capacidad necesaria para satisfacer a una relación costo-efectiva, las necesidades presentes y futuras del negocio.

Para◦ Cubrir las necesidades del negocio.◦ Uso eficiente de los recursos.

Capacity Management

Business Capacity Management Requiere conocer:

◦ SLA’s◦ Niveles de Servicio a futuro SLR’s◦ Plan de Negocio y Plan de capacidad◦ Técnicas de modelado◦ Crecimiento de aplicaciones

Capacity Management

Capacity Data Base◦ Puede contener varios almacenes con:

Información del negocio # de computadoras, cargas de trabajo cíclicas,

transacciones Información del servicio

Tiempo de respuesta de las transacciones, nivel percibido por le usuario.

Información técnica % máximo de uso, capacidad de almacenamiento,

memoria. Costo de las actualizaciones

Capacity Management

Ejemplo del contenido de un Plan de Capacidad◦ Introducción◦ Contenido

Antecedentes de la capacidad Niveles actuales de la capacidad Problemas presentados debido al exceso o falta de

capacidad Alcance del Plan Métodos empleados y fuentes de información Costos Escenario de ocurrencia

Número de empleados Plan de reubicación o expansión Oficinas

Plan de la Capacidad

Factores críticos de éxito:◦ Previsiones exactas del éxito◦ Conocimiento de las estrategias de TI◦ Adecuada comprensión de las tecnologías

actuales y futuras◦ Estrecha vinculación con otros procesos

Capacity Management

KPI’s◦ Tendencias del rendimiento de los servicios de TI

como consecuencia de los cálculos realizados en el proceso de Capacity Management.

◦ Reducción del excedente de capacidad innecesaria o cara.

◦ Reducción de la cantidad de incidentes originados en problemas de rendimiento.

Capacity Management

Availability Management

Objetivo◦ Optimizar la capacidad de la infraestructura de TI,

los servicios y la organización que le da soporte, a fin de proporcionar a una relación costo efectiva, los niveles de disponibilidad que permitan cumplir con los objetivos del negocio.

◦ Permite Medir los niveles de disponibilidad del servicio y se

mejoren Brindar una rápida y eficaz respuesta a situaciones

de falla.


Actividades◦ Análisis de disponibilidad

Debe determinar hasta que punto se puede soportar los requerimientos de los clientes. El análisis debe considerar: Periodo de medición de servicio Tiempo máximo de caída por evento Número máximo de eventos por periodo de servicio. Alcance del impacto

Debe probar la infraestructura de TI a través de métodos de análisis de falla (CFIA) y considerar medidas para evitar dichas fallas.

También puede comprender análisis de riesgo para valorar la vulnerabilidad (CRAMM).


Actividades◦ Desarrollar Plan de Disponibilidad

Debe ser comunicado al SLM para que se base en él para el diseño de Acuerdos de Nivel de Servicio (SLA) en lo referente a disponibilidad.

Debe contener objetivos de disponibilidad por servicio.

◦ Generar Requests For Change (RFC)


KPI’s◦ % de disponibilidad real por servicio◦ Frecuencia y duración del downtime◦ MTTR (mean time to Repair)◦ MTBF (mean time between failure)


Continuity Management

Objetivo◦ Dar soporte al proceso de Administración de

Continuidad del Negocio asegurando que los servicios y activos de IT pueden recuperarse dentro de los tiempos que el negocio requiere.


Justificación◦ Asegurar la permanencia del negocio reduciendo

el impacto de un desastre o falla mayor.◦ Reducir la vulnerabilidad y riesgo del negocio

aplicando análisis de riesgos y administración de riesgos.

◦ Prevenir la pérdida de confianza de los usuarios y clientes.

◦ Producir planes de recuperación de desastre que apoye integralmente al Plan de Administración de la Continuidad.


Site Alterno. Localidad de trabajo diferente, que será utilizada cuando la primaria no se accesible.

Continuidad del negocio: Un esfuerzo completo para priorizar los procesos de negocio clave, identificar amenazas a las operaciones normales, y planificar estrategias de mitigación para asegurar una respuesta organizacional efectiva y eficiente, durante y después de una crisis.

Análisis de riesgo: Detemrinar el impacto en caso de crisis.


Conclusiones

ITIL v3

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

El MAAGTIC es un compendio

El tiempo es MUY CORTO. Aún cuando trabajemos en conjunto los centros,

existen muchas definiciones que no pueden ser generalizadas, es decir, cada Centro tendrá que trabajar en personalizar lo que otros hagan.

Algunos de los procesos incluso requieren autorizaciones o llegar a acuerdos institucionales (SLA). Seguramente eso aumentará los tiempos.

Se requiere experiencia para diseñar muchos de estos procesos de forma adecuada.

No todos los formatos que diseñaron son útiles. Al igual que los marcos de buenas prácticas solo nos

dicen «que hacer», no dicen «como hacerlo», por lo que se requiere investigación.

Retos

Son 2.5 procesos por mes. Debemos tener más de un proceso nuevo cada dos semanas:◦ Comprender los requerimientos◦ Investigar alternativas para llevarlo a cabo◦ Diseño general del proceso◦ Obtener aprobación (p.e. SLAs)◦ Documentar el proceso◦ Implementar el proceso◦ Monitorear el proceso (para asegurar que se lleve a cabo)

¿No auditarán en el futuro? ¿Cuándo? ¿Qué parte del manual es requisito? ¿Qué es opcional?

En una auditoría requerirán EVIDENCIA.

Tiempo

El problema de los formatos

Aprovechar al máximo lo que ya se tiene dentro de las UTIC y de otros departamentos (p.e. adquisiciones).

Buscar el cumplimiento de lo mínimo indispensable (p.e. no cubrir todos los factores críticos en caso de ser opcionales).

Trabajar en conjunto todos los Centros, aprovechando la experiencia que cada uno tiene en ciertos procesos.

Posibles estrategias

itil en el contexto del maagtic

Documents