INTRODUCCION A ITIL V3

Hace un par de meses comencé a estudiar ITIL v3 con el objetivo de introducirme de una buena vez a la
“Gestión de TI” y es que siento que a mis 23 años me estoy haciendo viejo y si no entro en el mundo de la
gestión ahora!!, pues…. no lo haría nunca. Después de meses de estudio y una breve parada debido al
mes navideño, llegue a la conclusión que ITIL no me parece interesante!! me corrijo!! me parece SUPER
INTERESANTE; así que he decidido compartir algunas cosas en mi blog sobre ITIL v3.

Mi idea es abarcar los 6 módulos de un curso de certificación de ITIL v3:

 Introducción a ITIL y ITSM

 Service Strategy
 Service Design
 Service Transition
 Service Operation
 Continual Service Improvement

Aunque hay otro motivo por el cual quiero escribir sobre ITIL y se debe a que hay poca información en
español, una lastima!. Bueno… menos palabras y comencemos con el primer modulo: Introducción a ITIL
y ITSM.

Introducción a ITIL y ITSM

Breve Análisis
- Nadie que este leyendo este post ignora que en la actualidad IT es un factor desequilibrante en el
mercado actual, ¿alguien puede imaginarse un banco sin sistema? ¿pueden imaginar a Ripley o Saga
Falabella (tiendas importantes en Perú) sin un sistema informático de compras o ventas? imposible!!
debido a eso ITIL remarca que IT debe mantenerse competitivo en la económica global.

- ITIL reorienta la clásica área de HelpDesk lleno de conocimientos técnicos hacia proveer servicios que
sea un punto critico en el negocio. Si señores lo que hace el área de IT es proveer servicios es hora de
cambiar la forma de ver las cosas.

Best in Class
- ITIL no es subjetivo sino por el contrario es objetivo y como todo lo objetivo necesitamos algún indicador
de desempeño (KPI, algo medible!!!!) donde podemos medir el desempeño de un proceso.
- Las empresas exitosas en IT tienen por los general indicadores que anuncian que todo anda viento en
popa, por ejemplo:

 Logran el 90% del SLA pactado (SLA: Acuerdo de nivel servicio entre el cliente y el área de IT)
 El tiempo…. si señores el principal problema o queja de usuarios es el tiempo, pues un área de
IT sabe que va bien cuando cumple con el tiempo pactado en el SLA.
 Los procesos planteados funcionan en un 90% de los casos.

Un poco de historia (solo un poco)

- La imagen inferior muestra 3 versiones de ITIL y los años en que fueron apareciendo.
- ITIL v3 se focaliza en la Integración entre el Negocio-IT mientras que ITIL v2 solo es una alineación
entre el negocio-IT.
- ITIL v3 esta concorde con la ISO 20000, que ofrece a las organizaciones (solo organizaciones) la
oportunidad de brindar a sus clientes la integridad y seguridad de sus operaciones.
Gobierno Corporativo
ITIL pone su ladrillo en el Gobierno Corporativo de una organización y no solo ITIL sino también: PMI,
CMMI e ISO 27001/27002.

COSO: Modelo de Gobierno Corporativo, marco de referencia para el control interno conforme con la ley
SOX. [Más info. AQUI]
COBIT: Modelo de Gobierno de IT [Más info. AQUI]

ITIL v2 vs ITIL v3

El modelo de procesos de IVIL v2 se centraba en: Service Support y Service Delivery, desarrollando una
alineación entre el negocio y IT.

La clásica imagen del modelo

de procesos de ITIL v2 esta al
lado izquierdo y el foco de
ITSM (IT Service
Management) se basa solo en:
Service Support y Service
Deilvery, además cabe aclarar
que ITIL v2 cuenta con 7
libros:

 Planning to Implement
Service Management
 The Business Perspective
 Service Support
 Service Delivery
 Application Management
 Security Management
 ICT Infrastructure
Management

ITIL v3 tiene un nuevo enfoque denominado: ENFOQUE DEL CICLO DE VIDA DEL SERVICIO, donde se
logra una integración del negocio con IT. Otra diferencia importante y notable es el cambio de enfoque de
gestión de procesos (ITIL v2) hacia la gestión de Servicios (ITIL v3).

Así mismo, ITILV v3 esta alineado con la ISO 20000 y otros estándares como COBIT.
La clásica imagen del
MODELO DEL CICLO DE
VIDA de ITIL v3 es la rueda
que se muestra al lado
derecho, cabe resaltar que ITIL
v3 cuenta con sólo 5 libros:

 Service Strategy
 Service Design
 Service Transition
 Service Operation
 Continual Service
Improvement

Cada uno de esos 5 puntos los

vamos a tocar en los
siguientes posts.

Certificación ITIL

Algo no menos importante de

mencionar es acerca de los niveles de certificación de ITIL, existen 3 niveles:

 ITIL FOUNDATION: La visión general de ITIL

 Service Capability: Focalizado en agrupamiento y expertice
 Service Manager: Focalizado en áreas de proceso

IT Service Management (ITSM)

IT Service Management es la disciplina que se enfoca a la gestión del conjunto “personas, procesos y
tecnología” que cooperan para asegurar la calidad de los servicios TI, con arreglo a unos niveles de
servicio acordados previamente con el cliente (SLA). Existe un termino muy importante e innovador en
ITIL v3 no debemos olvidar y se llama “la mejora continua” este termino engloba a lo que ITIL v3 quiere
llegar. Existe todo un debate entre la diferencia entre “Best Practice” y “Good Practice” (un debate que en
este post no será tocado), una “Best Practice” es algo que general, algo que de manera general da
buenos resultados pero no olvidemos que todas las organizaciones difieren en muchos aspectos por lo
que lo que es una bueno para una organización no lo es para otra y es aquí brilla con mayor intensidad el
termino “Good Practice” ya que esto es mas especifico y es a lo que quiere llegar ITIL v3 con la mejora
continua.

¿Qué es un servicio?
Según ITIL v3 un servicio es un medio de entregar valor a los clientes a través de facilitar los resultados
que ellos quieren lograr (los clientes) sin tener responsabilidad de los riesgos, administración y costos
específicos. Creo que esta clarísimo y no resiste mayor análisis.

¿Qué es Service Management?

En cristiano (como diría mi Sra. madre cuando quiere entender algo complejo), ITSM es un conjunto de
capacidades que gestionan servicios en el ciclo de vida para entregarle al cliente servicios con un valor
 agregado; es decir
ITSM es un conjunto
de procesos que son
usados para
administrar
(estrategia, diseño,
transición, operación
y mejora continua) el
servicio que le vamos
a entregar al cliente.

¿Qué es un
proceso?
Es un conjunto
coordinado de
actividades, que
combinan e
implementan
recursos y
capacidades para
producir un resultado
que crea un valor en el cliente. Otras características de un proceso son:

- Cambia una o mas entradas en salidas bien definidas.

- Tiene roles, responsabilidades, herramientas y controles de gestión
- Consta de políticas, actividades, estándares, procedimientos e instrucciones

Además para ITIL todo proceso debe:

- Ser Medible: Debe ser medible desde 2 puntos de vista, debe ser medible en calidad y costo para el IT
Manager con el objetivo de imputar costos a distintas áreas y debe ser medible en tiempo y productividad
para el usuario y cliente.

- Dar Resultados Específicos: Identificable y contable.

- Debe responder a eventos específicos

 El ciclo de vida del Servicio
(CV)

El ciclo de vida es un termino

nuevo de ITIL v3 donde el
servicio es retroalimentado por
el conocimiento obtenido para
llegar a un resultado deseado
y mejorado, es obvio que para
lograr esto se necesita un
feedback muy bien
documentado, así como un
control y medición de los
procesos.

La imagen muestra claramente

como todo comienza por la
solicitud del cliente, pasa por el
Service Stategy, luego por el
Service Design, Service
Transition, Service Operation y por ultimo el Servicio de Mejora continua que retroalimenta a todos los
demás servicios.

Service Strategy: Eje de rotación del CV y es donde se dan las políticas, estándares y objetivos.
Service Design, Service Transition y Service Operation: Estos implementan la estrategia y representan el
cambio y transformación
Continual Service Improvement: Incorpora el aprendizaje y mejoramiento, se basa en el modelo (PDCA):
Plan, Do , Check and Act.

Conceptos y Definiciones Genéricas para ITIL v3

Portafolio de Servicios: Hace referencia a todos los servicios de IT, la descripción de cada servicio, su
status en el CV, etc. El portafolio incluye los servicios de terceros.
Catalogo de Servicios: Sub conjunto del portafolio de Servicio, representa los servicios ACTIVOS Y
APROBADOS, muestra el precio del servicio, SLA, términos del servicio, así como políticas y
responsabilidades.
Business Service Catalogue: Es la vista que tiene el cliente del Catalogo de Servicios y la relación que
tienen los procesos de negocio con los servicios que ofrece IT.
Technical Service Catalogue: Relación de servicios, componentes y CI (Item de Configuración) para
soportar el servicio.
 Business Case: Indica el
motivo del servicio, su objetivo
y lo que quiere lograr; justifica
si el servicio debe seguir en
curso o como podemos
mejorarlo. Además debe
presentar costos y los
beneficios esperados.

Riesgo: Presenta
oportunidades y amenazas y
define un marco de trabajo con
pasos bien definidos para
analizar y minimizar los riesgos.

Service Knowledge Management System (SKMS): Es la forma de guardar la información generada por los
eventos, incidentes, experiencias, etc para convertir la data en información para toma de decisiones.

Dueño del proceso: Responsable que el proceso sea ejecutado de acuerdo al SLA, así como de cumplir
las metas definidas.

Dueño del Servicio: Responsable ante el cliente de la iniciación, transición, mantenimiento y soporte del
servicio. Aquí entra en detalle la matriz RACI donde se asignan responsabilidades.

Bueno aquí llega a su fin la primera parte de ITIL

Este es el segundo post de ITIL v3, en el primer post se hizo una introducción a ITIL v3, las
certificaciones y algunos conceptos generales que nos ayudarán a entender mejor este tema y los
siguientes temas.
Comencemos por lo mas sencillo y a la vez lo más importante: ¿Qué hace la Estrategia del Servicio (SS)?
¿Cuál es su meta y objetivos?

Metas y Objetivos

 SS busca mejorar el impacto estratégico (utilidad del servicio y percepción del cliente) a través
del diseño, desarrollo, implementación y práctica de la Gestión del Servicio (ITSM).
 Transformar la gestión del servicio en un activo estratégico: Pensar como puedo mejorar el
servicio.
 Proveer principios de soporte (solo principios) para asistir en el desarrollo de: políticas, guías y
procesos.
 Gestión Financiera: ¿Cuanto me cuesta dar el servicio ofrecido?
Introducción

En otras palabras, SS analiza el tipo de cliente para decidir que deberíamos ofrecerle y como deberíamos
ofrecérselo para que esto permita realizar el negocio con éxito. La estrategia esta basada en las 4Ps:

- Perspectiva: La visión de la situación ¿Qué se necesita?

- Posición: ¿Dónde estoy? ¿Funcionaría?
- Plan: ¿Cómo lo hago?
- Patrón: Así lo voy hacer.

Si se dan cuenta es como un juego de ajedrez! así como el que pienso jugar mas tarde con mi amigo
Pepe. SS busca dar valor!!!! a través de RECURSOS (dinero, hardware, software) y HABILIDADES
(gestión, organización, procesos, knowledge y LAS PERSONAS). Desde el punto de vista del cliente el
valor significa: UTILIDAD (¿me sirve o no me sirve?) y garantía (¿Es confiable?).

Un ejemplo para entenderlo mejor…..

Pongámoslo más simple aun!! analicemos un ejemplo clásico de TI. Una organización quiere almacenar
información importante de sus clientes, es solo un ejemplo, entonces ellos que no saben de Sistemas
Gestores de Bases de Datos y hasta ahora lo están almacenando en archivos XLS en la computadora de
2 personas del área de logística. Hasta hace algún tiempo guardarlo en archivos XLS no estaba nada mal
porque tenían pocos clientes pero este ultimo año han crecido en un 200% y sus usuarios se han
triplicado y durante el ultimo año tuvieron algunos problemas: una de las computadoras de las personas
de logística que tenia el listado de clientes se malogro y con ello perdieron muchos usuarios, para mala
suerte de la organización la otra persona que tenia el listado de clientes (desactualizado) estaba de
vacaciones y no tenían como entrar a su computadora y cuando lograron entrar a la bendita computadora
no sabían cual era el archivo porque habían muchos files que tenían los siguientes nombres: clientes-
ultimo.xls, clientes-actualizado.xls, clientes-ok.xls y clientes-usar-este.xls.

SS aquí entra en acción!! les ofrece un SGBD (Sistema Gestor de BD) con tablas relacionales, con un
sistema Web para que cualquier usuario con un simple browser pueda usar el sistema y con un sistema
de backup diario. Todo perfecto!!!! pero… de que sirve todo esto si el cliente no advierte las ventajas que
todo esto puede tener para la organización, ¿Que pasa si el sistema arroja información poco relevante?
de inmediato el cliente pensará: “Mi archivo XLS era igualito y hasta me mostraba mas información”, ¿Que
pasa si el sistema esta mal programado y esta lento? nuevamente el usuario pensara: “Mi archivo XLS
era mas rápido”, entonces de nada habrá servido colocarles ORACLE, MySQL o MSSQL, de nada habrá
servido haber comprado un buen servidor y el sistema de aire acondicionado para ese servidor; es decir
el cliente tendrá la impresión de que todo el dinero fue una estafa y se tiro a la basura!. TODO GIRA
ALREDEDOR DE LA IMPRESION y PERSPECTIVA DEL CLIENTE.

Pero si por el contrario, el sistema le ofrece al cliente:

- Mayor información del cliente (dirección, rubro del negocio, etc), además información mejor organizada y
resaltando la información mas relevante; el cliente notara la diferencia porque así puede ganar mas
dinero.
- Sistema Web rápido y utilizable desde cualquiera sitio y a cualquier hora (porque esta colgado en la
nube), el cliente siente la diferencia entre este sistema y un XLS porque ahora puede hacer negocios a
cualquier hora y desde cualquier parte del mundo (se supone que el sistema ofrece una GARANTIA de
Seguridad).
- Un usuario borro casualmente los datos de un cliente y el backup entra acción en solo 15 minutos,
entonces el cliente ya no tendrá dudas y sabe que lo adquirido si vale la pena y se ha convertido en
un ACTIVO ESTRATEGICO.
- Para el cliente el valor depende de la UTILIDAD Y GARANTIA.

Todo esto fue planeado por SS, la ejecución e instalación fueron hechas por otras personas que mas
adelante veremos pero la idea fue planeada por SS, creo que el ejemplo esta sencillo y claro, verdad?.
Actividades de SS

 Actividad 1: Definición del mercado

 Actividad 2: Desarrollo de ofertas
 Actividad 3: Desarrollo de los activos estratégicos.
 Actividad 4: Preparación para la ejecución

Procesos de SS

 Gestión del portafolio de Servicios

 Gestión de la demanda
 Gestión Financiera

Tengo la impresión que después del ejemplo las actividades y procesos se explican por si solos pero voy
ahondar un poco mas.

ACTIVIDADES DE SS

ACTIVIDAD 1: Definición del mercado

 Define la estrategia para los servicios y servicios para la estrategia: Regresemos al ejemplo de
líneas arriba, la estrategia del servicio es entregar un servicio rápido, que tenga los mismos
usuarios que ya cuenta la empresa y pueda ser accedido desde cualquier parte del mundo y los
servicios para la estrategia es contactar con un ISP que nos brinde una IP pública.
 La definición del mercado se puede resumir en una frase: ENTENDER AL CLIENTE, es decir
entender que necesita y que es lo mejor que se le puede brindar, obviamente eso depende de
otras cosas como por ejemplo cual es el rubro de la organización.

ACTIVIDAD 2: Desarrollo de ofertas

 Basado en Market Space: Todas las oportunidades que el proveedor de servicios de TI puede
explotar para satisfacer las necesidades del negocio de los clientes.
 Es la lista de servicios que vamos a entregar y soportar. Es aquí donde aparece un nuevo
termino: Portafolio de Servicios, con un gráfico lo explico mejor.
 Portafolio de Servicios

ITIL nos dice que el área de IT debe

tener bien en claro cuales son los
servicios que estamos brindando y
cuales NO!, depende del acuerdo que
se ha llegado con el cliente (SLA).
¿Por qué hay que tener esto bien en
claro? Porque es clásico y recurrente
que en una organización los clientes
quieren que absolutamente todo sea
soportado por el área de IT, por
ejemplo: usuarios que tienen
problemas para usar WORD llaman
automáticamente al área de IT para
que le solucionen el problema, clientes
que desean que el correo les llegue a
su black berry (esto nunca se acordó),
clientes que desean usar el nuevo
OFFICE 2007 porque les parece mas
bonito; pero si el cliente y el área de IT
tienen en claro cual es el servicio que
se brinda y se soporta no tendremos
problemas en este aspecto.

En el portafolio de servicios consta de las siguientes partes:

 Catálogo de Servicios: Son los servicios ofrecidos y soportadas por el área de IT.
 Pipeline de Servicios: Servicios en desarrollo pero que aun no son soportados por el área de IT.
 Servicios retirados y SERVICIOS DE TERCEROS.

ACTIVIDAD 3: Desarrollo de Activos Estratégicos

Para desarrollar un Activo Estratégico debemos responder a la siguiente pregunta: ¿Qué es de vital
importancia para el cliente? Cuando sepamos eso sabremos que es un “Activo Estratégico” y podremos
desarrollarlo, monitorearlo y analizarlo de la manera correcta. Quizás para una organización el servicio de
correo electrónico es un activo estratégico debido a la importancia que tiene este en negocio, entonces
podremos desarrollar manuales de contingencia ante una posible caída del servicio para que este siga
funcionando (por ejemplo una imagen del servidor), además de un análisis de la demanda de este y
mejoramiento continuo del servicio.
ACTIVIDAD 4: Preparación
para la Ejecución

En esta actividad se hace una

evaluación estratégica de la
situación actual y de COMO
VAMOS A DAR EL SERVICIO.
Aquí se definen métricas de
éxito, objetivos, definición de
los factores críticos de éxito
(CSF: Critical Success Factor),
análisis potencial del negocio
(Análisis FODA) y un análisis
competitivo (una anticipación a
futuros cambios).

GESTION DE SS

Gestión del Portafolio de Servicio (SPM: Service Portfolio Management) : Un portafolio de servicios indica
todos los servicios de IT que tiene una organización, estos servicios cuentan con una descripción,
business case, nivel de prioridad, riesgos, ofertas de IT y obviamente un costo y precio del servicio;
debido a esto el portafolio de servicios es un método dinámico para gobernar inversiones y busca
maximizar el valor mientras se administra riesgos y costos.

SPM se establece con los siguientes métodos de trabajo:

 Define: Recolecta datos de los servicios existentes y propuestos que van en el portafolio de
servicio.
 Analiza: Responde a las preguntas: “¿Cómo mejoro el servicio?”, “¿Qué servicios necesita la
organización para cumplir sus metas?”, “¿Como conseguiremos esas metas?”.
 Aprobación: Aprueba el status del servicio, por ejemplo que el servicio pase del status de
desarrollo al de producción (muy importante!!)
 Comunicación: Comunica a los clientes del cambio de status.
 Refresco: Analiza las revisiones del SPM, cambios regulatorios dependiendo de un nuevo
requerimiento.

Aquí surge un rol: GERENTE DE PRODUCTO, esta persona se encarga de coordinar el Portafolio de
Servicios, trabaja frecuentemente con los gerentes para analizar los cambios del portafolio, es un experto
de la línea de servicios, evalúa nuevas oportunidades y tecnologías para las futuras necesidades del
cliente. Como se darán cuenta esta persona no es un Administrador en todo el sentido de la palabra sino
que debe de conocer de IT para poder desempeñar el cargo con éxito.

Gestión Financiera: ITIL tiene como objetivo financiero poder imputar costos al cliente y para poder
hacerlo necesita conocer al detalle el costo del valor del servicio ofrecido y no solo el costo del servicio
sino que debe conocer en mayor detalle los gatos que este servicio implica, como por ejemplo sabe el
valor de los activos subyacentes que proveen dichos servicios. La Gestión Financiera se encarga de:

 Valoración del servicio y análisis de la demanda: ¿Quienes usan el servicio?

 Coloca en el portafolio la velarización del servicio.
 Busca hacer servicios mas competitivos en términos de costo y calidad.
 Planeamiento confiable: Analiza la futura demanda y los futuros costos.
 Contabilización: Identifica todos los gastos que el servicio demanda.
 Análisis de la inversión: Obtiene un indicar entre el valor recibido por el cliente y el costo del
servicio.
Aquí surge otro rol: GERENTE FINANCIERO esta persona se encarga de documentar y acordar el valor
del servicio, analiza la demanda, provee de costos y se encarga del cumplimiento financiero de los
clientes.

Y por último……

Gestión de la demanda: Este tiene como objetivo reducir la indisponibilidad del servicio por una excesiva
demanda, además tiene como objetivo asegurar la calidad del servicio a través de un balanceo entre los
recursos ofrecidos y la demanda.

Aquí surge el ultimo rol de este post: GERENTE DE DEMANDA, esta persona participa en la creación de
los acuerdos (SLA), esto es evidente debido a que si se pacta un servicio que será usado por 50 personas
y luego es usado por 200 el SLA debe ser modificado; además esta persona siempre debe estar
monitoreando la demanda y capacidad general del servicio para responder a patrones de cambio de la
actividad del negocio (PBA: Patterns of Business Activity)

Con esto hemos terminado el segundo post de ITIL v3,

Aunque siempre tengo mil cosas por hacer me he dado un tiempo hoy domingo por la noche para escribir
EL TERCER POST DE ITIL, para aquellos que han llegado a este post sin antes haber leído los dos
primeros post sobre ITIL les recomiendo leer el primer post y el segundo post.

Habíamos explicado en el post anterior sobre Service Strategy (Estrategia del Servicio) que se encargaba
primordialmente de analizar lo que le vamos a brindar al cliente (Gestión del Portafolio del Servicio),
cuanto demanda el servicio brindado (Gestión Financiera) y analizar a cuantos clientes se provee el
servicio (Gestión de la demanda); pues bien después de haber analizado el rubro de la organización y de
decidir ¿Cómo? le vamos a brindar el servicio ahora toca diseñar el servicio, es aquí donde entra en
acción: Service Design (SD).

Definición
Service Design (SD) diseña los servicios de TI que se va a brindar, esto incluye: arquitecturas, procesos,
políticas y documentación; para cubrir con el actual SLA y las futuras necesidades (Integración con el
negocio), es decir y para entenderlo mas claro aun, lo que hace SD es trasladar los planes estratégicos y
objetivos que se decidió en SS, hacia la creación de diseños y especificaciones (procesos y políticas) que
luego serán ejecutados en las fases de Transición y Operaciones (que serán los 2 siguientes posts).

Vamos a poner un ejemplo y para seguir una misma idea voy a usar el ejemplo colocado en el post de
Service Stategy, el ejemplo trata de una organización que necesita almacenar información de sus
clientes y nosotros como expertos en TI mediante el Service Strategy hemos decidido brindar los
siguientes servicios: un SGBD (Sist. Gestor de BD) y un sistema web en la nube; después de haber
tomado esta decisión entra SD y su trabajo es:

 Crear políticas: Por ejemplo, el backup de la BD se hace al medio día y a la media noche y se
almacena en un lugar externo al de la empresa (obviamente se deben crear mas políticas).
 Diseño de arquitectura
 Apoyar al diseño del portafolio: SD apoya a SS en la creación del portafolio, imagínense que el
jefe de IT que esta negociando el servicio que va a brindar (SS) y el cliente solicita un servicio
bajo Red Hat Linux para su BD y aplicación, entonces el jefe de IT acepta pero luego se da
cuenta que ellos no cuentan con personas especialistas en Red Hat, es obvio que esto no puede
pasar, por eso SD apoya en el diseño del portafolio advirtiendo que no se puede brindar
servicios de Linux debido a que no se cuenta con personal capacitado para esta actividad.
 Tecnología efectiva: ¿Qué usamos? un switch CISCO o un switch no administrable.
 Diseño de proceso y sus métricas: El proceso son los pasos detallados para implementar el
servicio, por ejemplo:
o Paso 1: Instalar el SO bajo ciertas caracterices
o Paso 2: Instalar JAVA o PHP de la siguiente manera
 o Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parámetros
o Paso 4: ……..

¿Y todo esto para qué es necesario?

 Obviamente tener todo organizado tiene sus ventajas económicas y esto se refleja en el TCO
(Costo total de la propiedad), por ejemplo el TCO de una computadora es: Hardware + Software
+ Servicio recibido.
 Tener documentado paso por paso MEJORA LA CALIDAD DEL SERVICIO, MEJORA LA
CONSISTENCIA DEL SERVICIO y MEJORA EL GOBIERNO CORPORATIVO.

Actividades de SD

1. Gestión del Portafolio del Servicio

2. Identificación de los requerimientos del negocio, definición y diseño del servicio
3. Diseño de la arquitectura tecnológica
4. Diseño del proceso
5. Diseño de las métricas

Voy a explicar cada punto:

Gestión del Portafolio del Servicio (SPM): El dueño de este proceso no es SD sino SS, es decir SS
aprueba el portafolio de servicio que se va a brindar al cliente pero es obvio que necesita del apoyo de SD
para conocer precios, fortalezas, oportunidades, debilidades y amenazas del servicio.
Identificación de los requerimientos del negocio, definición y diseño del servicio: Para poder apoyar a la
SPM primero necesitamos saber que requiere el negocio con exactitud y recién sabiendo que quiere el
cliente podemos diseñar el servicio, evaluar las alternativas de diseño y conocer los costos que este
implica.

Diseño de la arquitectura tecnológica: Hace referencia al diseño arquitectónico y la arquitectura

empresarial.

Diseño del proceso: El proceso responde a la pregunta: ¿Qué hago primero? ¿Qué hago en segundo
lugar?, un proceso es conjunto estructurado de actividades para cumplir un objetivo. No olvidemos que un
proceso incluye cosas muy importantes como: roles, responsabilidades, herramientas y el control del
proceso.

Un proceso incluye no solo los pasos generales a seguir sino también las normas a seguir en caso de
excepciones, además de dueños del proceso y salidas cuantificables. ITIL exige que todo resultado de un
proceso sea medible para poder incluirlo en la mejora continua.

Diseño de las métricas: Si un proceso no puede ser medido no puede ser gestionado ni mejorado por lo
que lo importante aquí no es el concepto de medición sino saber ¿Cómo medir? y no existe una respuesta
exacta a esta pregunta porque saber como medir un proceso depende del servicio implementado y del
rubro del negocio, es decir debe estar alienado con los objetivos del negocio.

Procesos de SD

 Gestión del Nivel de Servicio (SLM)

 Gestión del Catalogo de Servicios (SCM)
 Gestión de la Capacidad
  Gestión de la Disponibilidad
 Gestión de la Continuidad del Servicio
 Gestión de la Seguridad de la Información
 Gestión de Proveedores Externos

Gestión del Nivel de Servicio (SLM)

Antes de que SS tome la decisión y acuerde con el cliente un SLA, SD tiene que asegurar un claro
entendimiento entre el cliente y TI, tener bien en claro lo que el cliente desea tiene un nombre y se llama
Requerimiento del Nivel de Servicio (SLR).

Las siguientes 2 imágenes resumen lo que hace la “Gestión del Nivel del Servicio”, la primera imagen
muestra el proceso lineal desde que llega una solicitud del cliente, identificación de los requisitos,
definición de lo que se puede brindar, firma del contrato que incluye: Acuerdo del Nivel del Servicio (SLA),
OLA (Acuerdo de Nivel Operacional) y UC (Underpinning Contract), por ultimo la fase de monitoreo e
informes para la mejora continua.

Nota: Un ejemplo de OLA es un acuerdo entre TI y el área de logística para poder cumplir con los
requerimientos del usuario, un caso practico podría ser la entrega de equipos de computo en 24 horas de
haber llegado a la organización. Un UC es un contrato formal con proveedor de servicios de IT (un
tercero) para cumplir con los requerimientos del usuario, por ejemplo el contrato con un ISP.

Solo para aclarar, es obvio que

no todos los pedidos deben ser
aceptados, por ejemplo si un
cliente solicita el cambio de
versión de Office 2003 a Office
2007 porque le gusta mas el
color y el diseño de la nueva
versión, ¿conviene hacer el
cambio? es obvio que NO.

La gestión del Nivel de

Servicio tiene como fin armar
el SLA y las métricas que
estarán incluidas en el SLA, es
obvio que existen distintos
tipos de SLA y enfocados de
distinta manera, por ejemplo
puede ser basado en el servicio o basado en el cliente.

 Basado en el Servicio
Un SLA basado en el servicio es cuando solo existe un SLA para un servicio pero que involucra
a muchos clientes, por ejemplo un SLA para el Email corporativo indica que todos los usuarios
cuentan con un correo.
 Basado en el Cliente
En SLA basado en el cliente es cuando existe un SLA que cubre muchos servicios pero solo
para un cliente o área en especifico.

¿Qué contiene un SLA?

 Descripción, horario, disponibilidad y fiabilidad del servicio

 Tiempo de respuesta del servicio, vía de comunicación y cambios
 Continuidad, seguridad, costo, informes y penalizaciones.
Gestión del Catalogo de Servicio
SD es quien sabe que podemos brindar y que no podemos brindar, es decir brindar la información de lo
que podemos poner en el catalogo y lo que no podemos.

Gestión de la Capacidad
Cuando hablamos de capacidad debemos asociar esta palabra con “performance”, la Gestión de la
capacidad se encarga de evaluar el impacto de cambios, incidentes y problemas para generar un plan de
capacidad. Las tareas de la Gestión de la capacidad son:

 Monitorear el rendimiento
 Monitorear Cargas
 Previsión de recursos
 Pronosticar demanda

Una imagen explica mejor todo lo que yo puedo escribir, en la imagen se muestran las entradas, los sub-
procesos que ocurren en la gestión de la Capacidad y los resultados, donde resaltan 2 muy importantes:
Plan de Capacidad y la Base de Datos de Capacidad (CDB). Por ejemplo de ambos es: el año 2008 el
uso del procesador del servidor web en promedio fue un 50% durante las campañas de venta, el año
2009 el uso del procesador subió a 75% debido a que la organización ha crecido, el año 2010 el
procesador estará en un 95% y las transacciones estarán lentas perjudicando las ventas, el plan de
capacidad debería indicar que para el 2010 se debió haber reemplazado el servidor por uno mas potente.

Gestión de la Disponibilidad
La capacidad y disponibilidad son temas muy comprometidos, no se puede hablar de disponibilidad sin
antes haber tocado capacidad; por ejemplo… si un servidor ha excedido su capacidad y producto de eso
sufre una caída afectando el negocio llegamos a la conclusión de que el servidor NO ESTA DISPONIBLE,
sin embargo hay otros aspectos importantes que tocar y debido a eso ITIL v3 hace una separación entre
capacidad y disponibilidad.
Sus tareas son:

 Generar un plan de disponibilidad

 Evaluar el impacto de cambios en el plan de disponibilidad
 Explicar a los usuarios la importancia de la información y su disponibilidad, esto incluye el
manejo de backups, lugar físico adecuado para el procesamiento de información (DataCenter) y
obviamente esto afecta también el performance.
Como todo proceso, la gestión de la disponibilidad tiene sus entradas y salidas, destacando como salida
los reportes y el monitoreo, es decir que debemos tener un reportes de la caída de un servidor, la fecha,
la duración, descripción, componente fallado e impacto en el numero de usuarios.

Gestión de la Continuidad
La gestión de la continuidad aparece cuando un incidente se ha convertido en un problema y negocio
debe seguir andando, por ejemplo cuando cae un servidor. Es decir deben planear y recuperarse ante
una crisis de TI de modo que los usuarios no se vean perjudicados. Sus objetivos son:

 Mantener un plan de continuidad y plan de recuperación

 Completar Business Impact Analysis (BIA)
 Revisar la gestión del riesgo
 Al igual que la gestión de la disponibilidad, evalúa el impacto de un cambio

Esto que nos ofrece:

1. Mejor administración de los riesgos

2. Credibilidad organizacional
3. Recuperación de los sistemas de TI de manera controlada
4. Interrupción mínima del negocio

Algunos Conceptos
Imaginemos que el DataCenter sufrió un incendio y debemos recuperar la información en otro ambiente,
la recuperación recibe un nombre dependiendo de donde se haga:

 Recuperación gradual o Cold Standby: Colocar un ambiente de computo en otro ambiente NO de

computo.
 Recuperación intermedia o Warm Standby: Recuperación en un ambiente y equipo adecuado
  Recuperación inmediata o Hot Standby: Sistemas en paralelo, es decir cae un ambiente y
automáticamente entra a trabajar el otro.

Maximun Tolerable Downtime (MTD): Periodo máximo de tiempo entre que el sistema cayo y todo vuelve
a funcionar con normalidad.
Recovery Time Objetive (RTO): Tiempo de recuperación de sistemas y/o recursos.
Recovery Point Objetive (RPO): Tiempo durante los datos se perdieron.
Work Recovery Time (WRT): Tiempo para recuperar datos perdidos.

Para que todo esto funcione correctamente debemos tener en cuenta algunos factores críticos:
  Realizar análisis de riesgo
 Plan de contingencia en términos del negocio (no es lo mismo el plan de contingencia de un
banco que de un empresa convencional)
 Pruebas del plan de contingencia

Gestión de la Seguridad de la Información

La seguridad es analizada de manera muy somera y superficial por ITIL, ¿por qué? Porque la seguridad
es un campo muy grande para tratar y es prácticamente otro curso. Sin embargo ITIL da unos conceptos
generales.
La seguridad tiene 3 pilares: Confidencialidad, Integridad y Disponibilidad. Aquí surge una pregunta muy
importante, ¿qué tanto debo asegurar mi información? la respuesta depende del rubro del sistema, por
ejemplo los bancos en el Perú están obligados a cumplir con la norma ISO 27000, mientras que otros
tipos de organizaciones no lo están.

Actividades de la Gestión de la Seguridad

Mantener una política de seguridad, que incluye un comité de seguridad, un responsable de seguridad
(CISO: Chief Information Security Officer) y un gerente de seguridad (CSO: Chief Security Officer).
Planear, implementar y evaluar la seguridad periódicamente
Hacer informes conforme a las métricas

Gestión de Proveedores Externos

Objetivos:

Obtener y negociar el dinero a pagar a los UC

Negociar el acuerdo y contrato con los UC
Mantener una política con proveedores externos, así como una BD de esos proveedores (SCD: Supplier
Contract Database)
Cuarto post sobre ITIL v3, en donde hablaremos sobre la transición del servicio. Para poder entender
correctamente este post y relacionar correctamente todos los temas deberíamos haber leído
antes: Introducción a ITIL v3, Estrategia del Servicio (SE) y Diseño del Servicio (SD).

ITIL se baja en algo tan simple como la lógica!!! no hay nada misterioso o que nunca hayamos hecho
antes los que estamos metidos en el mundo de TI, analicemos un poco; primero analizamos la estrategia
para saber como podemos enfrentar una solución de TI, luego diseñamos los pasos a seguir es decir los
procedimientos y ahora lo que debe continuar es IMPLEMENTAR EL SERVICIO, es decir la TRANSICION
de lo pensado hacia sistemas tangibles.

Entonces Service Transition (ST) se encarga de coordinar los procesos y funciones para empaquetar,
construir, probar y desplegar una versión del servicio según lo acordado en el SLA, con el objetivo de
llevar un control e información de los cambios realizados, mejorar el impacto sobre el ambiente de
producción e incrementar la satisfacción del cliente durante el proceso de transición.

Algunos conceptos y definiciones de ITIL v3

 Ítem de configuración (CI): Es todo activo, servicio, componente de servicio o cualquier ítem
que es o esta bajo el control de la gestión de la configuración, aunque el termino parece sencillo
el examen de certificación de ITIL trae siempre preguntas sobre esta definición.
 Sistema de congestión de la configuración (CMS): Gestiona todos los CIs.
 Definitive Media Library (DML): Biblioteca segura que almacena y protege las versiones
autorizadas y definitivas de todos los CIs.
 Unidad de liberación (Release Unit): Porción de un servicio o infraestructura de TI que es
liberada o desplegada según las políticas de la organización.

Como ya habíamos comentado en las primeras líneas, la “Transición del Servicio” ejecuta y plasma el
diseño del servicio en un servicio táctil y utilizable; sin embargo no es están simple como “hacerlo o
ejecutarlo” sino que hay toda una gestión y procesos detrás de estos, estos procesos son:

 Gestión del Cambio

 Gestión del Activo servicio y la configuración (SACM)
 Gestión de la liberación y el despliegue

GESTION DEL CAMBIO

La gestión del cambio se asegura que todos los cambios sean registrados, evaluados, autorizados,
priorizados, planeados, probados, implementados, documentados y revisados de manera controlada, para
que el impacto en los usuarios sea confortable.

Conceptos en la gestión del cambio

 Políticas y estándares: reglas que proveen una cultura y ambiente que soporta el cambio. Por
ejemplo una política de cambio es que todo cambio debe ser probado por el periodo de 15 días
hábiles como mínimo.
 Requerimientos de cumplimiento regulatorio: Este se aplica a disposiciones legales, por ejemplo
si el estado decide aplicar un aumento al IGV, el sistema informático debe cambiar, a esto se le
llame un cumplimiento regulatorio.
 Pruebas y procedimientos de post evaluación: La gestión encargada de evaluar que el cambio ha
sido implementado con éxito es la GESTION DEL CAMBIO (pregunta de certificación)
 CAB (Comité de Cambio) y ECAB (comité de cambio de emergencia)
 Stakeholders: Involucrados en la planeación y preparación del cambio, aconsejan cronograma de
cambios.

¿Que es para ITIL un cambio?

 Un cambio en el estado de un CI
 Un cambio de un CI en las relaciones con otro CI
 UN NUEVO CI (pregunta de certificación)
 Un nuevo propietario o cambio de ubicación de un CI

Actividades del proceso

La imagen superior resume todo lo que hace la gestión del cambio, voy ahondar un poco tratando de no
caer en la redundancia:

1. Registro: Registrar todos los RFC (Request for change – Solicitud de cambio) y cambios en la
CMDB, registrar el tipo de cambio, si fue un cambio estándar (planeado) o fue un cambio no
estándar (un cambio de emergencia por ejemplo).
2. Aceptación: Evaluación inicial del RFC donde se puede rechazar RFC poco claras e ilógicas y
hasta innecesarias. Esto es muy importante porque si el RFC es rechazada por ser poco clara
hará que el solicitante sea mas explicito y mejore el entendimiento del cambio.
3. Clasificación: Especifica la prioridad (importancia del cambio frente a otro cambio) y la categoría
(en base del impacto y recursos).
Asignación de la prioridad

 Inmediato: Un cambio que origina que el servicio este caído o el impacto en la organización sea
muy grande, esto debe hacer que el ECAB deba reunirse.
 Alto: Afecta un buen numero de usuarios.
 Medio: No hay un impacto severo.
 Bajo: Cambio justificado y necesario, puede esperar la calendarización.

La imagen muestra procedimientos de cambio de emergencia y es evidente que este no sigue

procedimientos normales, debe tener la mayor prioridad y debe contar con la reunión del ECAB.

4. Planificación: Los cambios se planifican usando utilizando un Calendario de Cambio a futuro (FSC:
Forward Schedule of Changes)

Políticas de Cambio
Las políticas determina si se combinan RFCs, horarios y fechas de cambio.

Reuniones del CAB

RFCs que deben ser evaluadas por el comité, cambios abiertos y cerrados, evaluación de cambios
pasados, cambios autorizados que no han sido remitidos al cab y revisar los cambios que no han sido
autorizadas son las tareas del comité de cambio (CAB).

5. Coordinación: Los cambios aprobados se comunican con los especialistas para que implementen el
cambio. Aquí hay algo importante que decir, la gestión del cambio NO IMPLEMENTA EL CAMBIO
(pregunta de certificación), entonces…. ¿quién implementa el cambio? la respuesta esta en este mismo
post así que sigue leyendo.

6 Evaluación: Se encargan de cerrar el RFC si el cambio fue exitoso y se registra en el PIR (Post –
Implementation Review) y si el cambio no fue exitoso se retorna al punto de error.

Todo creo que esta claro hasta aquí y para aquellos que ya han leído los primeros posts sobre ITIL saben
que todos los procesos para ITIL deben ser cuantitativos, es decir que a partir de esto nosotros debemos
hacer reportes donde se indique lo siguiente:

 Métricas de Salida:
o Numero de interrupciones, incidente y problemas que hubo con el servicio.
o Numero de cambios no autorizados que se han llevado a cabo.
o Numero de cambios forzosos o de emergencia que se realizaron
o Tiempo, esfuerzo y costo que ocasiono el cambio
 Métricas de trabajo
o Frecuencia de cambios
o Volumen de cambios
 Proceso de medición
o Satisfacción del usuario

Si olvidan que para ITIL todo debe ser medido y por ende registrado, están olvidando la esencia de ITIL.

GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION

¿Suena raro el nombre verdad? Pues cuando yo escuche por primera vez esto no entendí muy bien a lo
que se refería pero luego lo entendí fácilmente y eso es lo que voy a tratar de hacer aquí, que los que lo
lean lo entiendan fácilmente.

Entonces… un ACTIVO SERVICIO es todo lo que se pueda registrar referente a TI, desde un switch,
software, dueños de hardware/software hasta documentación. Teniendo esto en cuenta LA GESTION
DEL ACTIVO SERVICIO Y LA CONFIGURACION define y controla todos los componentes de los
servicios brindados, así como la infraestructura con el objetivo de mantener los registros actualizados y
exactos, aun no lo entendiste? OK digámoslo mas sencillo aun y con un ejemplo, si mañana se reemplaza
un switch no administrable por un switch cisco administrable, la configuración y la relación de este switch
con los demás switches debe ser actualizada y registrada por este proceso.

Esto obviamente tiene sus ventajas, por ejemplo…. si tenemos toda la configuración debidamente
registrada la GESTION DEL CAMBIO puede tomar la decisión de un cambio de manera mas sencilla y
con mejor precisión, además se puede resolver problemas con mayor rapidez y además tenemos un
control de todos los activos.

Conceptos en la Gestión del Activo Servicio y la Configuración (SACM)

 Sistema de Gestión de la configuración (CMS)

La CMS mantiene toda la información relativa al activo servicio y a la gestión de la configuración.

Nota: CMDB –> CMS –> SERVICE KNOWLEDGE MANAGEMENT SYSTEM, este es el modo evolutivo
de almacenamiento de información de ITIL. [Aquí pueden leer acerca de esta evolución]

 Definitive Media Library (DML)

Sobre DML vienen muchas preguntas de certificación, la DML es el sitio FISICO donde se
almacena el software que se utiliza en la organización, pero no cualquier software sino la versión
final y de uso del software; es decir no una versión incompleta del software sino la versión
autorizada por el equipo de desarrollo por ejemplo.
 Línea base de configuración (Baseline)
Es una solo una línea de referencia para configuraciones, por ejemplo la “baseline” de las
computadoras de una organización es para todos igual (sistema operativo Windows, drivers,
codecs, etc.) y dependiendo del área donde trabaje se le instalan otras aplicaciones.
 Gestión de Configuración
Por un lado esta Gestión del activo servicio que se encarga de almacenar la información de un
CI y por otro lado esta la Gestión de la Configuración que no solo almacena la configuración de
un CI también almacena la relación que tiene el CI con otros CIs.
La grafica superior muestra como actúa la gestión de la configuración, aplicando ITIL nosotros debemos
ser capaces de saber cuantos usuarios y de que departamentos serán afectados sin un servidor de Base
de Datos falla y la respuesta debe ser en un periodo corto de tiempo sin necesidad de ir preguntado
usuario por usuario por el problema.

Nota: Es obvio que llegar a este punto no es sencillo, si me preguntaran a mi cuantos usuarios y que
servicios se ven afectados si se cae determinado switch tendría que revisar la ubicación física, los tipos
de usuarios, etc; por lo tanto para llegar al nivel que recomienda ITIL me falta aun bastante (pero voy
rumbo a ese objetivo).

En conclusión lo que hace la GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION almacenar los
atributos de un CI y su relación con otros CI, que almacenar de un CI? pues eso depende lo que sea
relevante para una organización, aunque ITIL recomienda algunos atributos básicos,

Es evidente que esto no es todo lo que se debe de almacenar de un CI, existen otros datos importantes
como el numero de serie, numero de modelo, fabricante, categoría, ubicación, propietario responsable,
licencia, estado actual, costos y algunos otros comentarios.

¿Existe relación entre la Gestión del Cambio y la Gestión de la Configuración?

Evidentemente existe una relación, cuando se realiza un cambio en un CI la información de ese CI y la

relación con otros CI debe ser almacenada, la grafica inferior lo explica mejor.
No hay mucho que comentar acerca de la grafica y es que es evidente que la Gestión de la Configuración
esta relacionada directamente con la Gestión del Cambio debido a que todo cambio debe ser almacenado
y esa es la función de la Gestión de la configuración.

Definitivamente almacenar todos los atributos de un CI, el status y sus relaciones con otros CI no es tarea
sencilla pero tiene sus beneficios como una mejor gestión de los componentes de TI, se reduce errores y
costos, eficacia en la solución de problemas, cambios mas veloces, mejor control de hardware y software.

Gestión de las Versiones y el Despliegue (RDM – Release and Deployment Management)

Lo primero que hay que saber aquí es que los gringos utilizan la palabra “RELEASE” y nosotros no hemos
encontrado una mejor traducción que “VERSION”, quizás una mejor traducción hubiera sido
“LANZAMIENTO” aunque no se…. ya me acostumbre a decir “Gestión de las Versiones” y así pienso
dejarlo.

Un release es un conjunto de elementos de configuración nuevos y/o modificados que están evaluados
(gestión del cambio) y se introducen en el entorno de producción, en conclusión la gestión de versiones
es quien implementa los cambios en los servicios de TI y dirige todos los aspectos técnicos y no técnicos
de los cambios.
La imagen superior que parece tan inofensiva es una “caserita” de examen de certificación de ITIL, ¿quién
implementa el cambio? ¿quién verifica el cambio? lo han preguntado mil veces y lo seguirán preguntando.

Objetivos

- Hace los planes de liberación y despliegue

- Construir, instalar, hacer las pruebas y desplegar los paquetes de liberación
- Diseñar e implementar los procedimientos para instalar los cambios en los servicios de TI
- SACM es el responsable de todos los CIs, sin embargo RDM debe de apoyar que todas las copias de
software estén en el DSL y el hardware necesario esta en el DHS.

Nota: En ITIL v2 hay dos términos importantes, DSL (Definitive software library) y DHS (Definitive
hardware store), en ITIL v3 esos dos términos carecen de sentido porque existe un nuevo concepto
llamando DML (Definitive media library) y que esta bajo la gestión de SACM. Pueden leer un poco mas
sobre eso [AQUI].

Conceptos de RDM

- Entornos de Software: ITIL v3 recomienda tres entornos o tres ambientes de software

 Entorno de desarrollo: Aquí se puede instalar de todo y todos los usuarios tienen acceso.
 Entorno de pruebas: Ambiente idéntico al de producción donde solo tienen acceso los tester,
aquí se hacen pruebas técnicas, de performance, funcionales y es aquí donde se recibe la
aceptación final por el grupo de usuarios para pasar el software a producción.
 Entorno de producción: Aquí se ponen los servicios a disposición de los usuarios, este ambiente
no se sin antes haber pasado por desarrollo y pruebas.

Tipos de versiones:

 Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como
ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e
incompatibilidades en el entorno de producción.
 Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o
no. Aunque esta opción es obviamente más trabajosa es más improbable que se generen
incidentes tras la instalación si se han realizado las pruebas pertinentes.
 Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada
diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI.
En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con
software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo
sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas
ofimáticos.

Llegado a este punto, debemos ser capaces de entender todo el proceso que ITIL propone y la siguiente
grafica lo explica claramente.
Hasta este punto y si han leído los primeros post de ITIL, ya comprenden acerca del Nivel de Servicio, la
Gestión del Cambio, la Gestión de la configuración y pueden notar que todo ITIL esta relacionado, ahora
lo que falta ahondar mas es en la Gestión de Versiones y sus actividades internas, ¿ven el cuadrito que
dice “Gestión de Versiones” en la imagen superior? pues vamos hacerle un zoom y hablar sobre eso.
Este es el zoom del recuadro, la imagen muestra todas las actividades que realiza la gestión del release y
los respectivos ambientes donde se realiza la actividad. Vamos a explicar las actividades y con esto
términos este extenso post.

1.- Política y planificación de liberación de versiones: Define políticas que responden a preguntas: ¿cómo
y cuando se configura y despliega una versión?, define horarios de liberación, horas/hombre.
2.- Diseño, construcción y configuración: Desarrollo procedimientos para construir y configurar.
3.- Prueba y aceptación de le versión: Pruebas funcionales de los usuarios, prueba operativa del personal
de TI (la gestión del cambio debe coordinar la aceptación final por parte del usuario)
4.- Planificación del despliegue: Detalla recursos y responsabilidades, además analiza las formas de
implementación (una implementación total – Big Bang- o una implementación por partes)
5.- Comunicación, preparación y capacitación: Capacitación e información al usuario.
6.- Distribución e instalación de versiones: Finalmente poner en producción todo lo probado.

Aquí llega a su final este cuarto post sobre ITIL, ahora solo me faltan dos post para terminar con este mini
review de ITIL v3. Espero sus comentarios.

Ha pasado casi un mes desde que escribí mi ultimo post sobre ITIL y si alguno pensó que estaba
vagando o simplemente me había aburrido de escribir, déjenme decirles que uno de mis principales
defectos (o quizás virtud….) es estar siempre estudiando algo, lo que me resta tiempo para cosas como
escribir en mi blog y demás actividades de ocio.

Bueno hoy pienso dar un paso mas para ir concluyendo mis posts sobre ITIL v3; hasta el momento ya he
escrito 4 posts y no quiero caer pesado pero les recomiendo leer los posts anteriores para entender todo
el contexto de ITIL.

Si quieres darle un review a los post anteriores, aquí lo puedes hacer:

- Introducción a ITIL v3
- Estrategia del Servicio
- Diseño del Servicio
- Transición del Servicio

Habíamos dejado la “acción” en la implementación del servicio (Transición del Servicio – ST), acuérdense
que en la ST habíamos visto la gestión del cambio, gestión del activo servicio y configuración, y la gestión
del despliegue, ¿lo recuerdan, verdad?. Pues la lógica me indica que después de implementar el servicio
en un cliente viene algo que cae por su propio peso…. MANTENER EL SERVICIO SIEMPRE
FUNCIONANDO.
¿Acaso existe un sistema de TI que funcione completamente solo y sin necesidad de algún
mantenimiento? Analicemos un poco, los desarrolladores siempre tienen nuevos requerimientos por parte
de los usuarios, los DBA siempre tienen que monitorear que sus BDs estén funcionando, los sysadmin
revisar que todo el sistema corporativo este funcionando y así podría pasarme todo el día diciendo que
este trabajo nunca tiene fin, por eso en ITIL v3 existe algo que se llama MEJORA CONTINUA que será el
tema del siguiente y ultimo post.

Con esas cuantas líneas arriba he tratado de resumir lo que hace la Operación del Servicio y que
entramos a analizar en este mismo instante:

Definición, metas y objetivos

SO (Service Operation), conduce, gestiona y controla las operaciones del día a día de los procesos, con
la finalidad de tener los servicios estables, registrar incidentes, registrar problemas y sugerir el uso de
nuevos procesos. Seamos sinceros …. muchas personas desmerecen este tipo de trabajo, no? pero por
el contrario este trabajo tiene una importancia estrategia importante! porque estas son las personas que
dan la cara frente al usuario, son los que dicen: “Buenos días, el área de TI le habla; ¿en que puedo
ayudarlo?” y nunca debemos olvidar que el área de TI brinda servicios a los clientes y son estos quienes
perciben el valor del servicio.

Cuando hablamos de gente que esta constantemente monitoreando los servicios, atendiendo llamadas y
dando soluciones temporales, hablamos de nuevos conceptos como: impacto, urgencia y prioridad.
Imaginemos….. llama un usuario de logística indicando que no puede abrir un archivo PDF y llama el
director general indicando que no le funciona el outlook, ¿a quien se atiende primero? ¿al que llamo
primero?, pues…. eso depende de muchos factores como la cantidad de gente con la que se cuente, la
cantidad de recursos y de tiempo.
Terminología: En este tema existen muchos términos nuevos y definiciones muy técnicas así que me
gustaría explicarlo mejor con un ejemplo para que quede bien claro:

Se tiene una aplicación llamada “ABC” programada en Java que utiliza una BD Oracle, esta aplicación es
accedida mediante un browser por los clientes quienes agregan información de manera diaria.
Cierto día, los chicos de SO reciben un correo de sistema CACTI (sistema que monitorea el ancho de
banda de la red) indicando que el consumo del ancho de banda de la red se ha incrementando en un 40%
desde las 12pm hasta las 4pm. A los 2 días de recibido este correo, llega otro correo del sistema CACTI
indicando que el disco duro del servidor de BD ha pasado el 80% de su capacidad y que se recomienda
liberar espacio. Al tercer día (y justo fin de mes) llama un cliente indicando que el sistema “ABC” no
funciona y que no puede adjuntar información y que necesita hacerlo lo antes posible porque tiene que
terminar su trabajo de fin de mes, a los 10 minutos de esta llamada se reciben 5 nuevas llamadas de otros
usuarios con el mismo inconveniente.

De este pequeña historia que es totalmente real, tenemos:

Evento: Aumento del consumo del ancho de banda en un 40% (lo mas seguro es que algún usuario
estaba agregando bastante información)
Alerta: Uso del disco duro en un 80%
Incidente: Primera llamada del usuario que no puede adjuntar archivos
Problema: 5 clientes que no pueden usar el sistema el fin de mes
Workaround (Solución temporal): Montar nuevo disco duro para aumentar el espacio en disco
KnowError (Error conocido-KE): Este error se ha presentado con anterioridad y el procedimiento de
solución y causa del problema esta documentada.
Reactivo: Personas que actúan solo frente a un aviso o problema.
Proactivo: Personas que están en búsqueda de la mejora continua

A partir de este punto se crean nuevos paradigmas: Calidad del Servicio Vs. Costo del servicio. Es que
nosotros como TI podríamos decirle al cliente que el tiempo de respuesta frente a la caída de un servicio
será de solo 10 minutos pero necesitamos:
- Herramientas costosas de monitoreo, con un valor aprox de 30 mil dólares anuales
- 25 personas dedicadas al área de TI, con un valor de 100 mil dólares anuales
- ETC

¿Es esto posible? la mejor idea es siempre buscar un equilibrio entre la calidad del servicio y el costo de
modo que se pueda cumplir con los requerimientos del negocio.

Los procesos en la Operación del servicio son:

- Gestión de Incidentes
- Gestión de Eventos
- Cumplimiento de Solicitudes
- Gestión de Problemas
- Gestión de Accesos

GESTION DE INCIDENTES
El objetivo principal de la Gestión de incidentes es restaurar los niveles normales del servicio lo mas
rápido posible, asegurando el cumplimiento del SLA (calidad, tiempo y disponibilidad)

El
diagrama explica la relación entre un incidente, problemas, KE (error conocido), workaround (solución
temporal) y un RFC (solicitud de cambio).
Cuando hablamos de incidentes es inevitable hablar de escalamiento, imaginemos que llaman por un
problema de red, la persona que le contesta no puede ayudarlo entonces pasa a otra persona que
conoce mas del asunto y si esta persona no puede, pasa a un certificado en CCNA y así sucesivamente;
a este proceso se le llama ESCALAMIENTO y existen 2 tipos:

- Escalamiento funcional (horizontal): Cuando se involucra a otra persona con mayores conocimientos en
el tema.
- Escalamiento jerárquico (vertical): Cuando se necesita de autoridad para realizar una acción.

Sobre los tipos de escalamiento, siempre vienen preguntas en el examen de ITIL.

Lo que hace la gestión de incidentes se puede resumir en un solo grafico.
La gestión de incidentes tiene un proceso bastante grande y por consiguiente complejo, voy a describir al
detalle cada uno de las actividades del proceso:

Detección, comunicación y registro

Parece sencillo poder describir “la detección de incidentes” y en efecto la descripción es sencilla pero la
implementación no lo es, ITIL recomienda herramientas automatizadas para la detección de un incidente;
cuando hablamos de herramientas automatizadas estamos hablando de SOFTWARE que nos ayude en
dicha función.
En el mercado existen diversas herramientas, desde OpenSource como CACTI o NAGIOS hasta
herramientas de pago como TIVOLI o UNICENTER, lo ideal es que el principal mecanismo de detección
de un incidente no sea la llamada de alerta de un usuario sino que sea un mecanismo de alerta
automatizado.

Entonces la “detección” debería ser automatizada en primera instancia, recibida por el personal del centro
de servicios, reportada por el mismo personal de TI o directamente reportada por el usuario final;
cualquiera que sea el mecanismo de detección TODO INCIDENTE DEBE SER REGISTRADO Y DEBE
SER ASIGNADO UN NUMERO.

¿Absolutamente todo debe ser registrado?

Sí!!! absolutamente todo incidente debe ser registrado, ITIL insiste en registrar todo incidente por mas
insignificante que podría resultar y parecer.

¿Dónde lo registro?
ITIL v3 no especifica donde registrarlo pero se recomienda tener una herramienta de registro de
incidentes que nos ayudara para los reportes y futuras auditorias de TI.
No quiero irme por las ramas con el tema de auditoria pero en empresas serias existe algo que se llama
CONTROL INTERNO (Auditoria Interna) que registra todos los incidentes que deberían concordar con
nuestra BD de incidentes.

¿Qué registro?
Pues absolutamente todo!!! ITIL recomienda registrar lo siguiente:

Numero de identificación, clasificación, fecha, quien detecto el incidente, síntomas, categorías, IMPACTO,
PRIORIDAD, CIs, KnowError, fecha de resolución y notas de seguimiento. Como habrán notado el éxito
de la implementación de ITIL esta en NO SUPONER u OBVIAR DETALLES.

¿A quién comunico el incidente?

Los incidentes de gran impacto deben ser comunicados a todo el personal de TI con el objetivo de
mantenerse informado y alerta y no registrar 2 veces el mismo incidente.

Registrar 2 veces el mismo evento es uno de los principales errores que se comente en la GESTION DE
INCIDENTES.
Clasificación, comparación y apoyo inicial
La imagen superior muestra un ejemplo de clasificación, ITIL no te dice como debes clasificarlo eso
depende de los procesos de la organización, de la misma manera la clasificación por prioridad debe
regirse a políticas particulares dentro de la organización.
Después de haber detectado el problema la gestión de incidentes debe tratar de resolver de manera
rápida, ellos son la primera línea de defensa, son EL APOYO INICIAL. Para tratar de resolver el incidente
y restablecer el funcionamiento correcto se ayuda de la BD de Errores conocidos y la BD de Workarounds
(soluciones temporales), si a pesar de ello no se puede solucionar el incidente se procede a escalar el
incidente.

Hay que tener cuidado en NO REPETIR EL TRABAJO y esto pasa por una COMPARACION de síntomas
de otros incidentes.

Investigación y diagnostico
Después de haber sido detectado, registrado, clasificado y no haber podido resolver el problema de
manera rápida, pasamos a la investigación del incidente hasta dar con la causa del problema. Este
proceso puede pasar por distintos niveles de escalamiento y de expertos.

Resolución y Recuperación
Se dio con la causa del problema y se provee de un workaround y se restablece el servicio; si es
necesario un cambio se le comunica a la GESTION DE CAMBIOS.

Cierre del incidente

Se confirma que el incidente ha sido resuelto y se documenta el cierre del caso.

Hay otros temas que también hay tener en cuenta como por ejemplo MANTENER AL USUARIO
SIEMPRE INFORMADO!, ¿cómo piensa el usuario? el usuario cuando nadie lo llama piensa que nadie se
esta encargando de resolver su problema y luego vienen las quejas!!! es mejor mantener al usuario
siempre informado.

Otro tema muy importante es el MAL ESCALAMIENTO, muchas veces se abusa del escalamiento y
cualquier problema es ESCALADO rápidamente distrayendo a los especialista en temas que no son
importantes. (ESTA ES PREGUNTA DE CERTIFICACION ITIL).

Y por ultimo y quizás el mayor problema que presenta la gestión de incidentes es la falta de un SLA y
Catalogo de servicios, cuando estos documentos no están presentes cualquier problema relación con
tecnología va ser automáticamente asignado al área de TI sin importar temas como tiempo y recursos.

No olvidar que ITIL cuantifica todo, por ello nosotros debemos ser capaces de tener reportes de la gestión
de incidentes que respondan a las siguientes preguntas:
- ¿Cuántos incidentes se han presentado en un periodo de tiempo?
- ¿Cuántos incidentes de software hemos tenido?
- ¿Cuántos incidentes han sido escalados hasta los especialistas?
- ¿Cual es el tiempo de respuesta ante un incidente? ¿Cumplo con el SLA?
- ¿Qué área presenta mayores incidentes?
- Etc

GESTION DE EVENTOS

La principal diferencia entre evento e incidente radica en que TODO INCIDENTE es un evento pero NO
TODO EVENTO es un incidente, por ejemplo en el primer ejemplo de este post (que esta casi al
comienzo) se tiene un evento en la red, un aumento del 40% del ancho de banca, este evento no es un
INCIDENTE porque el aumento de 40% del ancho de banda en un red LAN esta dentro del rango de lo
permitido. Sin embargo un incidente como la caida de un servicio definitivamente es un evento perjudicial.

Sobre los evento ITIL v3 no hace demasiado hincapié pero debemos tener bien claro lo siguiente:

- ITIL v3 no se puede implementar sin herramientas que monitoreen los eventos, necesariamente
necesitamos herramientas que automaticen el trabajo!
- Todos los eventos deben ser registrados, absolutamente todos, para la rápida y presta detección de
incidentes u acontecimientos irregulares dentro de la organización.

CUMPLIMIENTO DE SOLICITUDES

ITIL v3 establece un proceso para atender las solicitudes de los usuarios. Los objetivos de este proceso
es:

- Establecer un procedimiento estándar de solicitud de servicios, por ejemplo el estándar podría ser
ingresar a una pagina web y responder ciertas preguntas.
- Realizar cambios menores que no sean críticos en la organización y que tampoco puedan tener un
impacto en el servicio, por ejemplo la solicitud de cambio de contraseña de un usuario para algún sistema
especifico; por lo general este tipo de cambios no necesitan un RFC (Request For Change).
- Establecer mecanismos y protocolos de respuesta a inquietudes y preguntas de usuarios.

GESTION DE PROBLEMAS

La Gestión de problemas administra todo el ciclo de vida del problema, desde que se inicia hasta que se
tiene una solución al problema, entonces aquí salta una pregunta: “¿Que es un problema para ITIL?”.
ITIL hace un diferencia importante entre incidente y problema, un incidente es algo pequeño, algo asilado
quizás o cuyo impacto es menor; en cambio un problema es un incidente recurrente, un incidente que
afecta a muchos usuarios o un incidente de un gran impacto.

Algunos conceptos:

KnowError (KE – Error conocido): ITIL apunta a que todo problema debe ser resuelto y dar como
resultado un KE, un KE es entender la causa de la falla y no necesariamente conocer la solución, es decir
ITIL recomienda tener registrado todos los errores en una BD, Base de Datos de Errores conocidos
(KEDB).
ITIL v3 lo ve de la siguiente manera, todo comienza en la Gestión de incidentes, el incidente es repetitivo
(se convierte en un problema) y por ende pasa a la Gestión de problemas, se investiga las causas del
problema hasta dar con el origen del mismo, cuando se tiene el conocimiento necesario de las causas del
problema se genera un Workaround (solución temporal) y el problema sufre un cambio, una mutación!!;
pasa de ser un problema a un Know Error (KE).
Por ultimo KE debe generar un RFC para hacer el cambio correspondiente y solucionar el problema, La
Gestión del Cambio se encargara de este proceso.

Como habremos notado la Gestión de Incidentes y la Gestión de Problemas van de la mano y están muy
relacionados.
¿De qué manera están relacionados?
Lo primero que debemos notar es que la gestión de problemas no va a estar preocupándose por todos los
incidentes que ocurren en la organización, la Gestión del Problema NO SOLUCIONA INCIDENTES!!!, la
gestión de problemas no busca una solución rápida sino que toma cierto tiempo para investigar la causa
del problema para poder eliminarla en la Gestión del Cambio.

La única manera en que la Gestión de Problemas apoya a la Gestión de Incidentes es proporcionándole

soluciones temporales (workarounds).
La Gestión de Problemas tiene los siguientes procesos:

Control de problemas
- Define e investiga los problemas y su principal función es transformar los problemas en KE.
- La principal fuente de información para el registro de problemas es la BD del registro de incidentes.
Control de Errores
- Se ocupa de resolver Errores Conocidos (KE) mediante la Gestión de Cambios, la Gestión de problemas
se encarga de todo el ciclo de vida del problema lo que quiere decir que debe estar monitoreando el
cambio que sera realizado por la Gestión de Cambios.

Como en todos los procesos de ITIL con la BD de los Errores Conocidos nosotros debemos poder sacar
informes de gestión: cantidad de problemas resueltos, tiempo tomado para resolver problemas, costos
asociados con los problemas, etc.

GESTION DE ACCESO

Hablar de seguridad de la información es un tema demasiado relevante en la actualidad e ITIL v3 no

puede estar totalmente aislado de este tema. Si bien es cierto que el negocio de ITIL no es la seguridad
porque para eso existen ISOs como la 27001, ITIL de alguna manera quiere contribuir con la Gestión de
Acceso.

La gestión de acceso lo que hace es brindar derechos a los usuarios para facilitarles el uso de uno o
varios servicios. Por ejemplo el día de mañana va ingresar un nuevo Director General a la organización,
esta persona debe tener acceso a ciertos sistemas que normalmente no son accedidos por cualquier
trabajador convencional, ESTO ES EL TRABAJO DE LA GESTION DE ACCESO.

Mantenimiento al Catálogo de Roles de Usuarios y Perfiles de Acceso

Asegurar que el Catálogo de Roles de Usuarios y los Perfiles de Acceso de Usuarios sean apropiados
para los servicios ofrecidos a los clientes, y prevenir una acumulación indeseada de derechos de acceso.

Procesamiento de Solicitudes de Acceso al Usuario

Procesar pedidos para agregar, cambiar o revocar derechos de acceso, y asegurar que sólo los usuarios
autorizados tengan derecho a usar determinados servicios.
Hasta aquí ha llegado la primera parte de Service Operation (Operación del Servicio) aun faltan tocar mas
puntos y el mas importante el de Service Desk, la decisión de hacer otro post se debe a que este ya se ha
dilatado bastante y continuar escribiendo puede ser tedioso por lo que otro post es necesario.

Voy a tratar de ser breve porque el primer post sobre Service Operation me explaye bastante pero creo
que valía la pena. Hasta ahora hemos tocado los siguiente capítulos de ITIL v3:

- Introducción a ITIL v3
- Estrategia del Servicio
- Diseño del Servicio
- Transición del Servicio
- Service Operation – Parte I

Es evidente que para poder entender en su totalidad este post, les recomiendo antes haber leído los posts
arriba mencionados. La Operación del Servicio (SO) se encarga de mantener que todos los servicios
funcionen correctamente siempre, se encarga de las operaciones del día a día y son los que tienen
contacto directo con los usuarios. ¿Quienes son los que realizan este trabajo? Existe un grupo humano
encargado de realizar esta laboriosa y a veces tedioso trabajo, ellos son los chicos de SERVICE DESK.

Si alguien pensó que la respuesta a la pregunta era HELP DESK, no lo culpo porque es la respuesta mas
lógica y la que seguro la mayoría de las personas, que inclusive están envueltos en el mundo de IT,
hubieran respondido.

¿Service Desk o Help Desk?

Para comenzar a despejar el panorama sobre la diferencia entre ambos es importante recalcar que la
principal diferencia radica en una nueva manera de atender a los usuarios finales. En términos prácticos
Service Desk esta un nivel mas arriba que Help Desk ya que contiene nuevas funciones que mejoran todo
el proceso de Service Operation. No desesperen que mas abajo lo explico mejor y prometo que al
terminar de leer esto van a entender claramente la diferencia.

¿Donde trabaja Service Desk?

ITIL v3 indica que Service Desk actúa sobre la Gestión de eventos, Gestión incidentes y cumplimiento de
solicitudes. ¿Actúa sobre la Gestión de problemas y la Gestión de Acceso? La respuesta es obvia, NO!! la
Gestión de problemas se toma cierto tiempo para poder encontrar la causa del problema y generar un
Know Error y un RFC por lo que se infiere que en la Gestión de problemas actúan los especialistas; de la
misma manera en la Gestión de Acceso son personas con cierto nivel de autorización quienes son
capaces de poder dar los privilegios correspondientes a los usuarios.

Service Desk es un punto rápido de contacto donde se resuelven incidentes de la manera mas
rápida posible, esto nunca lo olviden!!! (lo voy a poner en negrita y de rojo).
Entonces…. ¿Qué hace Service Desk?

- Resuelve incidentes
- Escalamiento adecuado, no todo debe ser escalado lo ideal es que Service Desk pueda resolver un 70%
u 80% de todos los casos.
- Mantener a los usuarios informados del status de su incidente o problema.
- Cumplir el acuerdo de atención del SLA.

Service Desk además cumple un ROL importante, Service Desk es el único punto de contacto para
atender servicios, a esto ITIL llama SPOC. Aquí entra un poco de cultura organizacional, aquí unos
ejemplos:

- Llama directo al Administrador de Base de Datos, el sabe como solucionar el problema.

- Llama a este chico porque es mi amigo y nos va atender rápido.
- Dame tu numero de anexo para llamarte cualquier cosa.
- ¿Aló Helpdesk? Pásame con el que sepa mas de Outlook.

Estoy seguro que alguna vez han escuchado estas frases,verdad? y ¿como resolver este problema? la
solución no están sencilla y tomar la decisión de cambiar esto y no contestar llamadas personalizadas
pasa por un cambio en la cultura organizacional y de los usuarios, un cambio gradual es lo ideal; además
de un cambio de tecnología también como por ejemplo agregar mas números telefónicos a la central de
Service Desk.

No debemos olvidar que no es posible implementar ITIL v3 si no contamos con las herramientas debidas.

¿Por qué es malo que llamen a una persona de IT de manera individual?

Existen una infinidad de respuestas para esta pregunta pero para muestra un botón, cuando llaman
directamente a un Administrador de BD o Servidores lo que esta haciendo es distraerlo de sus verdaderas
funciones y le resta tiempo; además que estos casos o incidentes no son registrados en la CMDB por lo
que no podemos llevar un control cuantitativo de todos los casos atendidos por el Service Desk. ITIL debe
ser capas de registrar todo para poder estimar tiempos, costos y mejorar el servicio.

Tipos de Service Desk

Service Desk Local: Es el clásico service desk de una empresa, donde existe un grupo de usuarios
locales y un solo centro de servicio.

Service Desk Centralizado: El mejor ejemplo aquí son las organizaciones que prestan servicios de
Service Desk a otras organizaciones, por ejemplo las organizaciones que brindan soporte a los Bancos.
Aquí existen múltiples usuarios y un solo centro de servicio.

Service Desk Virtual de Servicios Centralizados: Aquí el ejemplo son las grandes empresas de
Internet, por ejemplo MySQL Support (La versión Enterprise de MySQL brinda este servicio) tiene
diferentes centros de Servicio: uno para Latinoamérica, otro para China, etc etc pero todos son
contactados por un único medio, mediante la creación de un ticket mediante su pagina web.

La imagen superior explica las maneras en como Service Desk recibe solicitudes de atención: correo, vía
telefónica, vía web, etc y además no olvidemos que cualquier tipo de servicio, CUALQUIER!!! debe ser
recibido por Service Desk.

IMPLEMENTAR UN SERVICE DESK

La implementación no es tan simple como parece, requiere una dedicada planificación y debe
responderse las siguientes preguntas:

- ¿Cuáles son las necesidades?

- ¿Cuáles serán sus funciones?
- ¿Que calificaciones profesionales poseerán sus integrantes?
- ¿Qué tipo de Service Desk necesitamos: local, centralizado o virtual?
- ¿Qué herramientas tecnológicas necesitamos?
- ¿Qué métricas determinaran el rendimiento?

El factor humano juega aquí un rol muy importante, el factor humano debe:

- Establecer estrictos protocolos de interacción con el cliente, estándares de comunicación desde el

saludo hasta las preguntas de rutina a realizar.
- Informar a los clientes de los beneficios del Service Desk.

Estructura lógica del Service Desk

- Conocer los protocolos de comunicación con el cliente, conoces los cheklists (preguntas de rutina a
realizar para determinar la causa del incidente).
- Disponer y conocer las herramientas de software para el registro e interacción con el usuario.
- Conocer cuando hacer un escalado a instancias superiores.
- Tener rápido acceso a la base del conocimiento para ofrecer un mejor servicio a los usuarios.

Indicadores Claves de Rendimiento

La manera de saber si mi Service Desk esta funcionando adecuadamente para por responder las
siguientes preguntas:

- ¿Se atiende rápido el teléfono?

- ¿Cumplo con los tiempos acordados en el SLA?
- ¿Cuanto tiempo pasa hasta escalar la llamada a un segundo nivel?
- ¿Cuantos casos escalo a un segundo o tercer nivel?
- ¿Los usuarios reciben consejos de como prevenir incidentes?
- ¿Se atiende el teléfono con educación?

Informes de Gestión
Como en todos los procesos de ITIL, debemos ser capaces de poder tener informes detallados sobre
nuestro Service Desk.

- % de incidentes que pueden resolverse sin recurrir a otros niveles de soporte.

- Numero total de llamadas recibidas.
- Tiempo total de resolución y promedios de tiempo de resolución.
- Etc

Factores Críticos de Éxito

Existen factores que determinan el éxito o fracaso de un Service Desk, estos factores son:

- Difícil manera de contactar a Service Desk, si los usuarios encuentran complicado contactar con Service
Desk simplemente no verán los beneficios de este y buscaran otro tipo de soporte.
- Si los usuarios tratan de contactar directamente a los especialistas, automáticamente deben ser
remitidos al Service Desk.

¿Cuál es el objetivo principal de Service Desk?

Resolver el mayor numero de incidentes, ser la primera línea de defensa de TI de manera que los
especialistas puedan concentrarse en su verdadero trabajo.
 Existen además diversas políticas de como implementar un Service Desk y depende de las necesidades
de la organización y del SLA, por ejemplo en algunas organizaciones como las publicas se tiene un
Service Desk con personas especializas y dedicas en brindar ayuda a personas de alto cargo como
ministros o embajadores; es decir su único trabajo es brindarles servicio a ellos mientras que otros
atienden al resto de usuarios; todo esto depende obviamente de las políticas de la organización.

Hasta aquí llego este post, he tratado de cubrir lo mas que he podido todo el tema sobre Service Desk,
además les comparto un video que encontré en Youtube sobre Service Desk, es bastante corto pero
resumen muy bien este tema.