Itil en el contexto del maagtic
This presentation is the property of its rightful owner.
Sponsored Links
1 / 86

ITIL en el contexto del MAAGTIC PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on
  • Presentation posted in: General

ITIL en el contexto del MAAGTIC. http://www.sg.com.mx/content/view/1063/1/. ITIL. ITIL ofrece un marco de buenas prácticas para la administración de los servicios. IT Service Management.

Download Presentation

ITIL en el contexto del MAAGTIC

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Itil en el contexto del maagtic

ITIL en el contexto del MAAGTIC


Itil en el contexto del maagtic

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


Itil en el contexto del maagtic

ITIL

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


It service management

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.


Definici n de itil

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.


Itil v3

ITIL v3

  • ServiceStrategy

  • ServiceDesign

  • ServiceTransition

  • ServiceOperation

  • ContinualServiceImprovement (CSI)


Itil v31

ITIL v3


Relaci n entre cobit e itil

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.


Cumplimiento de requisitos

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?


Vistazo a algunos de los 32 procesos de itil

Vistazo a algunos de los 32 procesos de ITIL


Service level agreement

ServiceLevelAgreement


Service level agreement1

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.


Cat logo de servicios

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.


Service level management

ServiceLevel Management


Service level management1

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.


Service level management2

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.


Service level management3

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.


Cliente vs usuario

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.


Service level management4

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


Service level management5

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.


Aplicaci n en el manual

Aplicación en el manual


Service desk

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.


Service desk1

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.


Service desk2

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.


Service desk3

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.


Service desk4

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


Aplicaci n en el manual1

Aplicación en el manual


Incident management

Incident Management


Incident management1

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 management2

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 management3

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 management4

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 management5

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.


Actividad

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.


Priorizaci n de incidentes

Priorización de incidentes


Problem management

Problem Management


Problem management1

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 management2

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 management3

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 management4

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.


Aplicaci n en el manual2

Aplicación en el manual


Qu nivel de profundidad o de detalle debe tener cada proceso

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


Ejemplo de maagtic mesa de servicios

Ejemplo de MAAGTIC Mesa de Servicios


Objetivos del proceso

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.


Actividades del proceso

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.


Cada uno tiene factores cr ticos son obligatorios son solo deseables

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


Configuration management

Configuration Management


Configuration management1

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.


Itil en el contexto del maagtic

Configuration Management

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


Configuration management2

Configuration Management

  • Conceptos Clave

    • ConfigurationItems (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.


Configuration management3

Configuration Management

  • 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


Configuration management4

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)


Configuration management5

Configuration Management

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


Configuration management6

Configuration Management

  • 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


Aplicaci n en el manual3

Aplicación en el manual


Administraci n de la capacidad

Administración de la Capacidad


Capacity management

Capacity Management

  • 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 management1

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 management2

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 management3

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


Plan de la capacidad

Plan de la Capacidad

  • 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


Capacity management4

Capacity Management

  • 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 management5

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.


Aplicaci n en el manual4

Aplicación en el manual


Availability management

Availability Management


Availability management1

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.


Availability management2

Availability Management

  • 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).


Availability management3

Availability Management

  • 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 RequestsForChange (RFC)


Availability management4

Availability Management

  • KPI’s

    • % de disponibilidad real por servicio

    • Frecuencia y duración del downtime

    • MTTR (mean time toRepair)

    • MTBF (mean time betweenfailure)


Aplicaci n en el manual5

Aplicación en el manual


Continuity management

Continuity Management


Continuity management1

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.


Continuity management2

Continuity Management

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


Continuity management3

Continuity Management

  • 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

Conclusiones


Itil v32

ITIL v3


Aplicaci n en el manual6

Aplicación en el manual


El maagtic es un compendio

El MAAGTIC es un compendio

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


Retos

Retos

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


Tiempo

Tiempo

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


El problema de los formatos

El problema de los formatos


Posibles estrategias

Posibles estrategias

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


  • Login