Transcript Ciatec - Cimat

http://www.sg.com.mx/content/view/1063/1/
ITIL ofrece un marco de buenas prácticas para la
administración de los servicios

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.

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service Improvement (CSI)


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.




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?

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.

El cliente y los usuarios deben tener claro los
servicios ofrecidos y los acuerdos de nivel de
servicio para cada uno de ellos.



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.

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.
◦
◦
◦
◦

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.

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.

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.

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.


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
◦
◦
◦
◦
◦
Reportes de estatus
Reporte de cierre
Reporte de desempeño
Plan de mejora
Solicitudes de cambio
Salidas




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.

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.

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.

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.

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.




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.



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.

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


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.

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.
◦
◦
◦
◦

General

Específicos
◦ 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.
◦ 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.






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.


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.
52
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.
53

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.
54

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
55

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)
56

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.
57

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
58

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.

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.


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 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

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

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

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.

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)

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.
http://www.sg.com.mx/content/view/1063/1/






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.

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.



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.