Hace un par de meses comenc a estudiar ITIL v3 con el objetivo de introducirme de una

buena vez a la Gestin de TI y es que siento que a mis 23 aos me estoy haciendo viejo y
si no entro en el mundo de la gestin ahora!!, pues. no lo hara nunca. Despus de meses
de estudio y una breve parada debido al mes navideo, llegue a la conclusin 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 mdulos de un curso de certificacin de ITIL v3:

Introduccin 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
informacin en espaol, una lastima!. Bueno menos palabras y comencemos con el
primer modulo: Introduccin a ITIL y ITSM.
Introduccin a ITIL y ITSM
Breve Anlisis
- 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
informtico de compras o ventas? imposible!! debido a eso ITIL remarca que IT debe
mantenerse competitivo en la econmica global.
- ITIL reorienta la clsica rea de HelpDesk lleno de conocimientos tcnicos hacia proveer
servicios que sea un punto critico en el negocio. Si seores 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
algn indicador de desempeo (KPI, algo medible!!!!) donde podemos medir el desempeo
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 seores 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 aos en que fueron apareciendo.
- ITIL v3 se focaliza en la Integracin entre el Negocio-IT mientras que ITIL v2 solo es una
alineacin 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.
ITIL v2 vs ITIL v3
El modelo de procesos de IVIL v2 se centraba en: Service Support y Service Delivery,
desarrollando una alineacin entre el negocio y IT.

La clsica 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,
adems 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 integracin del negocio con IT. Otra diferencia importante
y notable es el cambio de enfoque de gestin de procesos (ITIL v2) hacia la gestin de
Servicios (ITIL v3).

As mismo, ITILV v3 esta alineado con la ISO 20000 y otros estndares como COBIT.

La clsica 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 slo 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.
Certificacin ITIL
Algo no menos importante de mencionar es acerca de los niveles de certificacin de ITIL,
existen 3 niveles:

ITIL FOUNDATION: La visin 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 gestin del conjunto
personas, procesos y tecnologa 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 organizacin 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?
Segn ITIL v3 un servicio es un medio de entregar valor a los clientes a travs de

facilitar los resultados que ellos quieren lograr (los clientes) sin tener
responsabilidad de los riesgos, administracin y costos especficos. Creo que esta
clarsimo y no resiste mayor anlisis.
Qu es Service Management?
En cristiano (como dira 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, diseo, transicin,
operacin 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
caractersticas de un proceso son:
- Cambia una o mas entradas en salidas bien definidas.
- Tiene roles, responsabilidades, herramientas y controles de gestin
- Consta de polticas, actividades, estndares, procedimientos e instrucciones
Adems 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 Especficos: Identificable y contable.
- Debe responder a eventos especficos
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 medicin 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
dems servicios.
Service Strategy: Eje de rotacin del CV y es donde se dan las polticas, estndares
y objetivos.
Service Design, Service Transition y Service Operation: Estos implementan la
estrategia y representan el cambio y transformacin
Continual Service Improvement: Incorpora el aprendizaje y mejoramiento, se basa
en el modelo (PDCA): Plan, Do , Check and Act.
Conceptos y Definiciones Genricas para ITIL v3
Portafolio de Servicios: Hace referencia a todos los servicios de IT, la descripcin
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,
trminos del servicio, as como polticas y responsabilidades.

Business Service Catalogue: Es la vista que tiene el cliente del Catalogo de

Servicios y la relacin que tienen los procesos de negocio con los servicios que
ofrece IT.
Technical Service Catalogue: Relacin de servicios, componentes y CI (Item de
Configuracin) 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. Adems
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
informacin generada por los eventos, incidentes, experiencias, etc para convertir la
data en informacin para toma de decisiones.
Dueo del proceso: Responsable que el proceso sea ejecutado de acuerdo al SLA,
as como de cumplir las metas definidas.
Dueo del Servicio: Responsable ante el cliente de la iniciacin, transicin,
mantenimiento y soporte del servicio. Aqu entra en detalle la matriz RACI donde se
asignan responsabilidades.

ESTRATEGIA DE SERVICIO
Este es el segundo post de ITIL v3, en el primer post se hizo una introduccin a ITIL v3, las
certificaciones y algunos conceptos generales que nos ayudarn a entender mejor este tema
y los siguientes temas.
Comencemos por lo mas sencillo y a la vez lo ms importante: Qu hace la Estrategia del
Servicio (SS)? Cul es su meta y objetivos?
Metas y Objetivos

SS busca mejorar el impacto estratgico (utilidad del servicio y percepcin del

cliente) a travs del diseo, desarrollo, implementacin y prctica de la Gestin del
Servicio (ITSM).

Transformar la gestin del servicio en un activo estratgico: Pensar como puedo

mejorar el servicio.

Proveer principios de soporte (solo principios) para asistir en el desarrollo de:

polticas, guas y procesos.

Gestin Financiera: Cuanto me cuesta dar el servicio ofrecido?

Introduccin
En otras palabras, SS analiza el tipo de cliente para decidir que deberamos ofrecerle y
como deberamos ofrecrselo para que esto permita realizar el negocio con xito. La
estrategia esta basada en las 4Ps:
- Perspectiva: La visin de la situacin Qu se necesita?
- Posicin: Dnde estoy? Funcionara?
- Plan: Cmo lo hago?
- Patrn: 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 travs de RECURSOS (dinero, hardware,
software) y HABILIDADES (gestin, organizacin, procesos, knowledge y LAS
PERSONAS). Desde el punto de vista del cliente el valor significa: UTILIDAD (me sirve
o no me sirve?) y garanta (Es confiable?).
Un ejemplo para entenderlo mejor..
Pongmoslo ms simple aun!! analicemos un ejemplo clsico de TI. Una organizacin
quiere almacenar informacin importante de sus clientes, es solo un ejemplo, entonces ellos
que no saben de Sistemas Gestores de Bases de Datos y hasta ahora lo estn almacenando
en archivos XLS en la computadora de 2 personas del rea de logstica. Hasta hace algn
tiempo guardarlo en archivos XLS no estaba nada mal porque tenan pocos clientes pero
este ultimo ao han crecido en un 200% y sus usuarios se han triplicado y durante el ultimo
ao tuvieron algunos problemas: una de las computadoras de las personas de logstica que
tenia el listado de clientes se malogro y con ello perdieron muchos usuarios, para mala
suerte de la organizacin la otra persona que tenia el listado de clientes (desactualizado)
estaba de vacaciones y no tenan como entrar a su computadora y cuando lograron entrar a
la bendita computadora no saban cual era el archivo porque haban muchos files que tenan
los siguientes nombres: clientes-ultimo.xls, clientes-actualizado.xls, clientes-ok.xls y
clientes-usar-este.xls.
SS aqu entra en accin!! 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
organizacin, Que pasa si el sistema arroja informacin poco relevante? de inmediato el
cliente pensar: Mi archivo XLS era igualito y hasta me mostraba mas informacin, Que
pasa si el sistema esta mal programado y esta lento? nuevamente el usuario pensara: Mi
archivo XLS era mas rpido, 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 impresin 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 informacin del cliente (direccin, rubro del negocio, etc), adems informacin
mejor organizada y resaltando la informacin mas relevante; el cliente notara la diferencia
porque as puede ganar mas dinero.
- Sistema Web rpido 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 accin 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 ejecucin e instalacin 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: Definicin del mercado

Actividad 2: Desarrollo de ofertas

Actividad 3: Desarrollo de los activos estratgicos.

Actividad 4: Preparacin para la ejecucin

Procesos de SS

Gestin del portafolio de Servicios

Gestin de la demanda

Gestin Financiera

Tengo la impresin que despus del ejemplo las actividades y procesos se explican por si
solos pero voy ahondar un poco mas.
ACTIVIDADES DE SS
ACTIVIDAD 1: Definicin del mercado

Define la estrategia para los servicios y servicios para la estrategia: Regresemos al

ejemplo de lneas arriba, la estrategia del servicio es entregar un servicio rpido, 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 pblica.

La definicin 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
organizacin.

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 grfico 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 clsico y recurrente que en una
organizacin los clientes quieren que absolutamente todo sea soportado por el rea de IT,
por ejemplo: usuarios que tienen problemas para usar WORD llaman automticamente 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:

Catlogo 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 Estratgicos

Para desarrollar un Activo Estratgico debemos responder a la siguiente pregunta: Qu es
de vital importancia para el cliente? Cuando sepamos eso sabremos que es un Activo
Estratgico y podremos desarrollarlo, monitorearlo y analizarlo de la manera correcta.
Quizs para una organizacin el servicio de correo electrnico es un activo estratgico
debido a la importancia que tiene este en negocio, entonces podremos desarrollar manuales

de contingencia ante una posible cada del servicio para que este siga funcionando (por
ejemplo una imagen del servidor), adems de un anlisis de la demanda de este y
mejoramiento continuo del servicio.
ACTIVIDAD 4: Preparacin para la Ejecucin
En esta actividad se hace una evaluacin estratgica de la situacin actual y de COMO
VAMOS A DAR EL SERVICIO. Aqu se definen mtricas de xito, objetivos, definicin de
los factores crticos de xito (CSF: Critical Success Factor), anlisis potencial del negocio
(Anlisis FODA) y un anlisis competitivo (una anticipacin a futuros cambios).
GESTION DE SS
Gestin del Portafolio de Servicio (SPM: Service Portfolio Management) : Un portafolio de
servicios indica todos los servicios de IT que tiene una organizacin, estos servicios
cuentan con una descripcin, 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
mtodo dinmico para gobernar inversiones y busca maximizar el valor mientras se
administra riesgos y costos.
SPM se establece con los siguientes mtodos de trabajo:

Define: Recolecta datos de los servicios existentes y propuestos que van en el

portafolio de servicio.

Analiza: Responde a las preguntas: Cmo mejoro el servicio?, Qu servicios

necesita la organizacin para cumplir sus metas?, Como conseguiremos esas
metas?.

Aprobacin: Aprueba el status del servicio, por ejemplo que el servicio pase del
status de desarrollo al de produccin (muy importante!!)

Comunicacin: 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 lnea de servicios, evala nuevas oportunidades y
tecnologas para las futuras necesidades del cliente. Como se darn cuenta esta persona no
es un Administrador en todo el sentido de la palabra sino que debe de conocer de IT para
poder desempear el cargo con xito.
Gestin 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 Gestin Financiera se encarga de:

Valoracin del servicio y anlisis de la demanda: Quienes usan el servicio?

Coloca en el portafolio la velarizacin del servicio.

Busca hacer servicios mas competitivos en trminos de costo y calidad.

Planeamiento confiable: Analiza la futura demanda y los futuros costos.

Contabilizacin: Identifica todos los gastos que el servicio demanda.

Anlisis de la inversin: 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
Gestin de la demanda: Este tiene como objetivo reducir la indisponibilidad del servicio
por una excesiva demanda, adems tiene como objetivo asegurar la calidad del servicio a
travs 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 creacin 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;
adems 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)

DISEO

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 ledo los dos primeros post sobre ITIL les recomiendo leer el primer post y
el segundo post.
Habamos 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 (Gestin del
Portafolio del Servicio), cuanto demanda el servicio brindado (Gestin Financiera) y
analizar a cuantos clientes se provee el servicio (Gestin de la demanda); pues bien despus
de haber analizado el rubro de la organizacin y de decidir Cmo? le vamos a brindar el
servicio ahora toca disear el servicio, es aqu donde entra en accin: Service Design (SD).
Definicin
Service Design (SD) disea los servicios de TI que se va a brindar, esto incluye:
arquitecturas, procesos, polticas y documentacin; para cubrir con el actual SLA y las
futuras necesidades (Integracin con el negocio), es decir y para entenderlo mas claro aun,
lo que hace SD es trasladar los planes estratgicos y objetivos que se decidi en SS, hacia la
creacin de diseos y especificaciones (procesos y polticas) que luego sern ejecutados en
las fases de Transicin y Operaciones (que sern 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 organizacin que necesita almacenar
informacin 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; despus de haber tomado esta decisin entra SD y su trabajo es:

Crear polticas: Por ejemplo, el backup de la BD se hace al medio da y a la media

noche y se almacena en un lugar externo al de la empresa (obviamente se deben
crear mas polticas).

Diseo de arquitectura

Apoyar al diseo del portafolio: SD apoya a SS en la creacin del portafolio,

imagnense 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 aplicacin, 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
diseo del portafolio advirtiendo que no se puede brindar servicios de Linux debido
a que no se cuenta con personal capacitado para esta actividad.

Tecnologa efectiva: Qu usamos? un switch CISCO o un switch no administrable.

Diseo de proceso y sus mtricas: 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 parmetros
o Paso 4: ..

Y todo esto para qu es necesario?

Obviamente tener todo organizado tiene sus ventajas econmicas 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. Gestin del Portafolio del Servicio
2. Identificacin de los requerimientos del negocio, definicin y diseo del servicio
3. Diseo de la arquitectura tecnolgica
4. Diseo del proceso
5. Diseo de las mtricas
Voy a explicar cada punto:
Gestin del Portafolio del Servicio (SPM): El dueo 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.

Identificacin de los requerimientos del negocio, definicin y diseo del servicio: Para
poder apoyar a la SPM primero necesitamos saber que requiere el negocio con exactitud y
recin sabiendo que quiere el cliente podemos disear el servicio, evaluar las alternativas de
diseo y conocer los costos que este implica.
Diseo de la arquitectura tecnolgica: Hace referencia al diseo arquitectnico y la
arquitectura empresarial.
Diseo 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 tambin las normas a seguir en
caso de excepciones, adems de dueos del proceso y salidas cuantificables. ITIL exige que
todo resultado de un proceso sea medible para poder incluirlo en la mejora continua.
Diseo de las mtricas: Si un proceso no puede ser medido no puede ser gestionado ni
mejorado por lo que lo importante aqu no es el concepto de medicin sino saber Cmo
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

Gestin del Nivel de Servicio (SLM)

Gestin del Catalogo de Servicios (SCM)

Gestin de la Capacidad

Gestin de la Disponibilidad

Gestin de la Continuidad del Servicio

Gestin de la Seguridad de la Informacin

Gestin de Proveedores Externos

Gestin del Nivel de Servicio (SLM)

Antes de que SS tome la decisin 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 imgenes resumen lo que hace la Gestin del Nivel del Servicio, la
primera imagen muestra el proceso lineal desde que llega una solicitud del cliente,
identificacin de los requisitos, definicin 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 logstica para poder cumplir
con los requerimientos del usuario, un caso practico podra ser la entrega de equipos de
computo en 24 horas de haber llegado a la organizacin. 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 versin de Office 2003 a Office 2007 porque le gusta mas el
color y el diseo de la nueva
versin, conviene hacer el
cambio? es obvio que NO.
La gestin del Nivel de
Servicio tiene como fin
armar el SLA y las mtricas
que estarn 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?

Descripcin, horario, disponibilidad y fiabilidad del servicio

Tiempo de respuesta del servicio, va de comunicacin y cambios

Continuidad, seguridad, costo, informes y penalizaciones.

Gestin del Catalogo de Servicio

SD es quien sabe que podemos brindar y que no podemos brindar, es decir brindar la
informacin de lo que podemos poner en el catalogo y lo que no podemos.
Gestin de la Capacidad
Cuando hablamos de capacidad debemos asociar esta palabra con performance, la
Gestin de la capacidad se encarga de evaluar el impacto de cambios, incidentes y
problemas para generar un plan de capacidad. Las tareas de la Gestin de la capacidad son:

Monitorear el rendimiento

Monitorear Cargas

Previsin 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 gestin 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 ao 2008 el uso del procesador del servidor web en promedio
fue un 50% durante las campaas de venta, el ao 2009 el uso del procesador subi a 75%
debido a que la organizacin ha crecido, el ao 2010 el procesador estar en un 95% y las
transacciones estarn lentas perjudicando las ventas, el plan de capacidad debera indicar
que para el 2010 se debi haber reemplazado el servidor por uno mas potente.
Gestin 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 cada afectando el negocio llegamos a la
conclusin de que el servidor NO ESTA DISPONIBLE, sin embargo hay otros aspectos
importantes que tocar y debido a eso ITIL v3 hace una separacin 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 informacin y su disponibilidad, esto

incluye el manejo de backups, lugar fsico adecuado para el procesamiento de
informacin (DataCenter) y obviamente esto afecta tambin el performance.

Como todo proceso, la gestin 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 cada
de un servidor, la fecha, la duracin, descripcin, componente fallado e impacto en el
numero de usuarios.
Gestin de la Continuidad
La gestin 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 recuperacin

Completar Business Impact Analysis (BIA)

Revisar la gestin del riesgo

Al igual que la gestin de la disponibilidad, evala el impacto de un cambio

Esto que nos ofrece:

1. Mejor administracin de los riesgos

2. Credibilidad organizacional
3. Recuperacin de los sistemas de TI de manera controlada
4. Interrupcin mnima del negocio
Algunos Conceptos
Imaginemos que el DataCenter sufri un incendio y debemos recuperar la informacin en
otro ambiente, la recuperacin recibe un nombre dependiendo de donde se haga:

Recuperacin gradual o Cold Standby: Colocar un ambiente de computo en otro

ambiente NO de computo.

Recuperacin intermedia o Warm Standby: Recuperacin en un ambiente y equipo

adecuado

Recuperacin inmediata o Hot Standby: Sistemas en paralelo, es decir cae un

ambiente y automticamente entra a trabajar el otro.

Maximun Tolerable Downtime (MTD): Periodo mximo de tiempo entre que el sistema
cayo y todo vuelve a funcionar con normalidad.
Recovery Time Objetive (RTO): Tiempo de recuperacin 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
crticos:

Realizar anlisis de riesgo

Plan de contingencia en trminos del negocio (no es lo mismo el plan de

contingencia de un banco que de un empresa convencional)

Pruebas del plan de contingencia

Gestin de la Seguridad de la Informacin

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 prcticamente 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 informacin? la respuesta depende
del rubro del sistema, por ejemplo los bancos en el Per estn obligados a cumplir con la
norma ISO 27000, mientras que otros tipos de organizaciones no lo estn.
Actividades de la Gestin de la Seguridad

Mantener una poltica 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 peridicamente
Hacer informes conforme a las mtricas
Gestin de Proveedores Externos
Objetivos:
Obtener y negociar el dinero a pagar a los UC
Negociar el acuerdo y contrato con los UC
Mantener una poltica con proveedores externos, as como una BD de esos proveedores
(SCD: Supplier Contract Database)

Cuarto post sobre ITIL v3, en donde hablaremos sobre la transicin del servicio. Para poder
entender correctamente este post y relacionar correctamente todos los temas deberamos
haber ledo antes: Introduccin a ITIL v3, Estrategia del Servicio (SE) y Diseo del
Servicio (SD).

ITIL se baja en algo tan simple como la lgica!!! 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 solucin de TI,
luego diseamos 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 versin del servicio segn lo acordado en el
SLA, con el objetivo de llevar un control e informacin de los cambios realizados, mejorar
el impacto sobre el ambiente de produccin e incrementar la satisfaccin del cliente durante
el proceso de transicin.
Algunos conceptos y definiciones de ITIL v3

tem de configuracin (CI): Es todo activo, servicio, componente de servicio o

cualquier tem que es o esta bajo el control de la gestin de la configuracin, aunque
el termino parece sencillo el examen de certificacin de ITIL trae siempre preguntas
sobre esta definicin.

Sistema de congestin de la configuracin (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 liberacin (Release Unit): Porcin de un servicio o infraestructura de

TI que es liberada o desplegada segn las polticas de la organizacin.

Como ya habamos comentado en las primeras lneas, la Transicin del Servicio ejecuta y
plasma el diseo del servicio en un servicio tctil y utilizable; sin embargo no es estn
simple como hacerlo o ejecutarlo sino que hay toda una gestin y procesos detrs de
estos, estos procesos son:

Gestin del Cambio

Gestin del Activo servicio y la configuracin (SACM)

Gestin de la liberacin y el despliegue

GESTION DEL CAMBIO

La gestin 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 gestin del cambio

Polticas y estndares: reglas que proveen una cultura y ambiente que soporta el
cambio. Por ejemplo una poltica de cambio es que todo cambio debe ser probado
por el periodo de 15 das hbiles como mnimo.

Requerimientos de cumplimiento regulatorio: Este se aplica a disposiciones legales,

por ejemplo si el estado decide aplicar un aumento al IGV, el sistema informtico
debe cambiar, a esto se le llame un cumplimiento regulatorio.

Pruebas y procedimientos de post evaluacin: La gestin encargada de evaluar que

el cambio ha sido implementado con xito es la GESTION DEL CAMBIO
(pregunta de certificacin)

CAB (Comit de Cambio) y ECAB (comit de cambio de emergencia)

Stakeholders: Involucrados en la planeacin y preparacin 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 certificacin)

Un nuevo propietario o cambio de ubicacin de un CI

Actividades del proceso

La imagen superior resume todo lo que hace la gestin 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 estndar
(planeado) o fue un cambio no estndar (un cambio de emergencia por ejemplo).

2. Aceptacin: Evaluacin inicial del RFC donde se puede rechazar RFC poco claras e
ilgicas 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. Clasificacin: Especifica la prioridad (importancia del cambio frente a otro cambio)
y la categora (en base del impacto y recursos).
Asignacin de la prioridad

Inmediato: Un cambio que origina que el servicio este cado o el impacto en

la organizacin 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 calendarizacin.

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 reunin
del ECAB.
4. Planificacin: Los cambios se planifican usando utilizando un Calendario de Cambio a
futuro (FSC: Forward Schedule of Changes)
Polticas de Cambio
Las polticas 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, evaluacin 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. Coordinacin: Los cambios aprobados se comunican con los especialistas para que
implementen el cambio. Aqu hay algo importante que decir, la gestin del cambio NO
IMPLEMENTA EL CAMBIO (pregunta de certificacin), entonces. quin implementa
el cambio? la respuesta esta en este mismo post as que sigue leyendo.
6 Evaluacin: 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 ledo 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:

Mtricas 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

Mtricas de trabajo
o Frecuencia de cambios
o Volumen de cambios

Proceso de medicin
o Satisfaccin del usuario

Si olvidan que para ITIL todo debe ser medido y por ende registrado, estn 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 refera pero luego lo entend fcilmente y eso es lo que voy a tratar de
hacer aqu, que los que lo lean lo entiendan fcilmente.
Entonces un ACTIVO SERVICIO es todo lo que se pueda registrar referente a TI, desde
un switch, software, dueos de hardware/software hasta documentacin. 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
digmoslo mas sencillo aun y con un ejemplo, si maana se reemplaza un switch no
administrable por un switch cisco administrable, la configuracin y la relacin de este
switch con los dems switches debe ser actualizada y registrada por este proceso.
Esto obviamente tiene sus ventajas, por ejemplo. si tenemos toda la configuracin
debidamente registrada la GESTION DEL CAMBIO puede tomar la decisin de un cambio
de manera mas sencilla y con mejor precisin, adems se puede resolver problemas con
mayor rapidez y adems tenemos un control de todos los activos.
Conceptos en la Gestin del Activo Servicio y la Configuracin (SACM)

Sistema de Gestin de la configuracin (CMS)

La CMS mantiene toda la informacin relativa al activo servicio y a la gestin de la
configuracin.

Nota: CMDB > CMS > SERVICE KNOWLEDGE MANAGEMENT SYSTEM, este es
el modo evolutivo de almacenamiento de informacin de ITIL. [Aqu pueden leer acerca de
esta evolucin]

Definitive Media Library (DML)

Sobre DML vienen muchas preguntas de certificacin, la DML es el sitio FISICO
donde se almacena el software que se utiliza en la organizacin, pero no cualquier
software sino la versin final y de uso del software; es decir no una versin
incompleta del software sino la versin autorizada por el equipo de desarrollo por
ejemplo.

Lnea base de configuracin (Baseline)

Es una solo una lnea de referencia para configuraciones, por ejemplo la baseline
de las computadoras de una organizacin es para todos igual (sistema operativo
Windows, drivers, codecs, etc.) y dependiendo del rea donde trabaje se le instalan
otras aplicaciones.

Gestin de Configuracin
Por un lado esta Gestin del activo servicio que se encarga de almacenar la
informacin de un CI y por otro lado esta la Gestin de la Configuracin que no
solo almacena la configuracin de un CI tambin almacena la relacin que tiene el
CI con otros CIs.

La grafica superior muestra como acta la gestin de la configuracin, aplicando ITIL

nosotros debemos ser capaces de saber cuantos usuarios y de que departamentos sern
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 tendra que revisar la
ubicacin fsica, 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 conclusin lo que hace la GESTION DEL ACTIVO SERVICIO Y LA
CONFIGURACION almacenar los atributos de un CI y su relacin con otros CI, que
almacenar de un CI? pues eso depende lo que sea relevante para una organizacin, aunque
ITIL recomienda algunos atributos bsicos,

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, categora, ubicacin,
propietario responsable, licencia, estado actual, costos y algunos otros comentarios.
Existe relacin entre la Gestin del Cambio y la Gestin de la Configuracin?
Evidentemente existe una relacin, cuando se realiza un cambio en un CI la informacin de
ese CI y la relacin 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 Gestin de la
Configuracin esta relacionada directamente con la Gestin del Cambio debido a que todo
cambio debe ser almacenado y esa es la funcin de la Gestin de la configuracin.
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 gestin de los
componentes de TI, se reduce errores y costos, eficacia en la solucin de problemas,
cambios mas veloces, mejor control de hardware y software.
Gestin 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 traduccin que VERSION, quizs una mejor
traduccin hubiera sido LANZAMIENTO aunque no se. ya me acostumbre a decir
Gestin de las Versiones y as pienso dejarlo.
Un release es un conjunto de elementos de configuracin nuevos y/o modificados que estn
evaluados (gestin del cambio) y se introducen en el entorno de produccin, en conclusin
la gestin de versiones es quien implementa los cambios en los servicios de TI y dirige
todos los aspectos tcnicos y no tcnicos de los cambios.

La imagen superior que parece tan inofensiva es una caserita de examen de certificacin
de ITIL, quin implementa el cambio? quin verifica el cambio? lo han preguntado mil
veces y lo seguirn preguntando.
Objetivos
- Hace los planes de liberacin y despliegue
- Construir, instalar, hacer las pruebas y desplegar los paquetes de liberacin
- Disear 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 estn en el DSL y el hardware necesario esta en el DHS.
Nota: En ITIL v2 hay dos trminos importantes, DSL (Definitive software library) y DHS
(Definitive hardware store), en ITIL v3 esos dos trminos carecen de sentido porque existe
un nuevo concepto llamando DML (Definitive media library) y que esta bajo la gestin 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 idntico al de produccin donde solo tienen acceso

los tester, aqu se hacen pruebas tcnicas, de performance, funcionales y es aqu
donde se recibe la aceptacin final por el grupo de usuarios para pasar el software a
produccin.

Entorno de produccin: Aqu se ponen los servicios a disposicin de los usuarios,

este ambiente no se sin antes haber pasado por desarrollo y pruebas.

Tipos de versiones:

Versin delta: slo se testean e instalan los elementos modificados. Esta opcin
tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan
aparecer problemas e incompatibilidades en el entorno de produccin.

Versin completa: Se distribuyen todos los elementos afectados ya hayan sido

modificados o no. Aunque esta opcin es obviamente ms trabajosa es ms
improbable que se generen incidentes tras la instalacin si se han realizado las
pruebas pertinentes.

Paquete de Versiones: La Gestin 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 opcin es obligada por
incompatibilidades entre una nueva versin con software o hardware previamente
instalado. Pensemos, por ejemplo, en la migracin a un nuevo sistema operativo que
requiere hardware ms avanzado y/o nuevos versiones de los programas ofimticos.

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 ledo los primeros post de ITIL, ya comprenden acerca del Nivel
de Servicio, la Gestin del Cambio, la Gestin de la configuracin y pueden notar que todo
ITIL esta relacionado, ahora lo que falta ahondar mas es en la Gestin de Versiones y sus
actividades internas, ven el cuadrito que dice Gestin 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 gestin
del release y los respectivos ambientes donde se realiza la actividad. Vamos a explicar las
actividades y con esto trminos este extenso post.
1.- Poltica y planificacin de liberacin de versiones: Define polticas que responden a
preguntas: cmo y cuando se configura y despliega una versin?, define horarios de
liberacin, horas/hombre.
2.- Diseo, construccin y configuracin: Desarrollo procedimientos para construir y
configurar.
3.- Prueba y aceptacin de le versin: Pruebas funcionales de los usuarios, prueba operativa
del personal de TI (la gestin del cambio debe coordinar la aceptacin final por parte del
usuario)
4.- Planificacin del despliegue: Detalla recursos y responsabilidades, adems analiza las
formas de implementacin (una implementacin total Big Bang- o una implementacin
por partes)
5.- Comunicacin, preparacin y capacitacin: Capacitacin e informacin al usuario.
6.- Distribucin e instalacin de versiones: Finalmente poner en produccin todo lo
probado.

Habamos dejado la accin en la implementacin del servicio (Transicin del Servicio

ST), acurdense que en la ST habamos visto la gestin del cambio, gestin del activo
servicio y configuracin, y la gestin del despliegue, lo recuerdan, verdad?. Pues la lgica
me indica que despus 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 algn
mantenimiento? Analicemos un poco, los desarrolladores siempre tienen nuevos
requerimientos por parte de los usuarios, los DBA siempre tienen que monitorear que sus
BDs estn funcionando, los sysadmin revisar que todo el sistema corporativo este
funcionando y as podra pasarme todo el da 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 lneas arriba he tratado de resumir lo que hace la Operacin del Servicio y
que entramos a analizar en este mismo instante:
Definicin, metas y objetivos
SO (Service Operation), conduce, gestiona y controla las operaciones del da a da 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 das, 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 logstica 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.
Terminologa: En este tema existen muchos trminos nuevos y definiciones muy tcnicas
as que me gustara explicarlo mejor con un ejemplo para que quede bien claro:
Se tiene una aplicacin llamada ABC programada en Java que utiliza una BD Oracle,
esta aplicacin es accedida mediante un browser por los clientes quienes agregan
informacin de manera diaria.
Cierto da, 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 das 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 da (y
justo fin de mes) llama un cliente indicando que el sistema ABC no funciona y que no
puede adjuntar informacin 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 pequea historia que es totalmente real, tenemos:

Evento: Aumento del consumo del ancho de banda en un 40% (lo mas seguro es que algn
usuario estaba agregando bastante informacin)
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 (Solucin 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 solucin y causa del problema esta documentada.
Reactivo: Personas que actan solo frente a un aviso o problema.
Proactivo: Personas que estn en bsqueda 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 podramos decirle al cliente que el tiempo de respuesta
frente a la cada de un servicio ser de solo 10 minutos pero necesitamos:
- Herramientas costosas de monitoreo, con un valor aprox de 30 mil dlares anuales
- 25 personas dedicadas al rea de TI, con un valor de 100 mil dlares 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 Operacin del servicio son:

- Gestin de Incidentes
- Gestin de Eventos
- Cumplimiento de Solicitudes
- Gestin de Problemas
- Gestin de Accesos
GESTION DE INCIDENTES
El objetivo principal de la Gestin de incidentes es restaurar los niveles normales del
servicio lo mas rpido posible, asegurando el cumplimiento del SLA (calidad, tiempo y
disponibilidad)

El
diagrama explica la relacin entre un incidente, problemas, KE (error conocido),
workaround (solucin 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 jerrquico (vertical): Cuando se necesita de autoridad para realizar una
accin.
Sobre los tipos de escalamiento, siempre vienen preguntas en el examen de ITIL.

Lo que hace la gestin de incidentes se puede resumir en un solo grafico.

La gestin de incidentes tiene un proceso bastante grande y por consiguiente complejo, voy
a describir al detalle cada uno de las actividades del proceso:
Deteccin, comunicacin y registro
Parece sencillo poder describir la deteccin de incidentes y en efecto la descripcin es
sencilla pero la implementacin no lo es, ITIL recomienda herramientas automatizadas para
la deteccin de un incidente; cuando hablamos de herramientas automatizadas estamos
hablando de SOFTWARE que nos ayude en dicha funcin.
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 deteccin de un incidente no sea la llamada de alerta de un usuario sino que
sea un mecanismo de alerta automatizado.
Entonces la deteccin debera 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 deteccin 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 podra resultar y parecer.
Dnde 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 deberan concordar con nuestra BD de incidentes.
Qu registro?
Pues absolutamente todo!!! ITIL recomienda registrar lo siguiente:
Numero de identificacin, clasificacin, fecha, quien detecto el incidente, sntomas,
categoras, IMPACTO, PRIORIDAD, CIs, KnowError, fecha de resolucin y notas de
seguimiento. Como habrn notado el xito de la implementacin de ITIL esta en NO
SUPONER u OBVIAR DETALLES.
A quin 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.

Clasificacin, comparacin y apoyo inicial

La imagen superior muestra un ejemplo de clasificacin, ITIL no te dice como debes
clasificarlo eso depende de los procesos de la organizacin, de la misma manera la
clasificacin por prioridad debe regirse a polticas particulares dentro de la organizacin.
Despus de haber detectado el problema la gestin de incidentes debe tratar de resolver de
manera rpida, ellos son la primera lnea 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 sntomas de otros incidentes.
Investigacin y diagnostico
Despus de haber sido detectado, registrado, clasificado y no haber podido resolver el
problema de manera rpida, pasamos a la investigacin del incidente hasta dar con la causa
del problema. Este proceso puede pasar por distintos niveles de escalamiento y de expertos.
Resolucin y Recuperacin
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 tambin hay tener en cuenta como por ejemplo MANTENER AL
USUARIO SIEMPRE INFORMADO!, cmo 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 rpidamente distrayendo a los
especialista en temas que no son importantes. (ESTA ES PREGUNTA DE
CERTIFICACION ITIL).
Y por ultimo y quizs el mayor problema que presenta la gestin de incidentes es la falta de
un SLA y Catalogo de servicios, cuando estos documentos no estn presentes cualquier
problema relacin con tecnologa va ser automticamente 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 gestin de incidentes que respondan a las siguientes preguntas:
- Cuntos incidentes se han presentado en un periodo de tiempo?
- Cuntos incidentes de software hemos tenido?
- Cuntos 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 rpida y presta
deteccin de incidentes u acontecimientos irregulares dentro de la organizacin.
CUMPLIMIENTO DE SOLICITUDES
ITIL v3 establece un proceso para atender las solicitudes de los usuarios. Los objetivos de
este proceso es:
- Establecer un procedimiento estndar de solicitud de servicios, por ejemplo el estndar
podra ser ingresar a una pagina web y responder ciertas preguntas.
- Realizar cambios menores que no sean crticos en la organizacin y que tampoco puedan
tener un impacto en el servicio, por ejemplo la solicitud de cambio de contrasea de un
usuario para algn 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 Gestin de problemas administra todo el ciclo de vida del problema, desde que se inicia
hasta que se tiene una solucin 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

pequeo, algo asilado quizs 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 solucin, 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 Gestin de incidentes, el

incidente es repetitivo (se convierte en un problema) y por ende pasa a la Gestin 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
(solucin temporal) y el problema sufre un cambio, una mutacin!!; 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 Gestin del Cambio se encargara de este proceso.
Como habremos notado la Gestin de Incidentes y la Gestin de Problemas van de la mano
y estn muy relacionados.
De qu manera estn relacionados?
Lo primero que debemos notar es que la gestin de problemas no va a estar preocupndose

por todos los incidentes que ocurren en la organizacin, la Gestin del Problema NO
SOLUCIONA INCIDENTES!!!, la gestin de problemas no busca una solucin rpida sino
que toma cierto tiempo para investigar la causa del problema para poder eliminarla en la
Gestin del Cambio.
La nica manera en que la Gestin de Problemas apoya a la Gestin de Incidentes es
proporcionndole soluciones temporales (workarounds).

La Gestin de Problemas tiene los siguientes procesos:

Control de problemas
- Define e investiga los problemas y su principal funcin es transformar los problemas en
KE.
- La principal fuente de informacin para el registro de problemas es la BD del registro de
incidentes.

Control de Errores
- Se ocupa de resolver Errores Conocidos (KE) mediante la Gestin de Cambios, la Gestin
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 Gestin de Cambios.

Como en todos los procesos de ITIL con la BD de los Errores Conocidos nosotros debemos
poder sacar informes de gestin: cantidad de problemas resueltos, tiempo tomado para
resolver problemas, costos asociados con los problemas, etc.
GESTION DE ACCESO
Hablar de seguridad de la informacin 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 Gestin de Acceso.
La gestin de acceso lo que hace es brindar derechos a los usuarios para facilitarles el uso
de uno o varios servicios. Por ejemplo el da de maana va ingresar un nuevo Director
General a la organizacin, 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 Catlogo de Roles de Usuarios y Perfiles de Acceso
Asegurar que el Catlogo de Roles de Usuarios y los Perfiles de Acceso de Usuarios sean
apropiados para los servicios ofrecidos a los clientes, y prevenir una acumulacin 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 slo
los usuarios autorizados tengan derecho a usar determinados servicios.
Hasta aqu ha llegado la primera parte de Service Operation (Operacin del Servicio) aun
faltan tocar mas puntos y el mas importante el de Service Desk, la decisin 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.

Es evidente que para poder entender en su totalidad este post, les recomiendo antes haber
ledo los posts arriba mencionados. La Operacin del Servicio (SO) se encarga de mantener
que todos los servicios funcionen correctamente siempre, se encarga de las operaciones del
da a da 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 lgica y la que seguro la mayora de las personas, que inclusive estn
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 trminos prcticos 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 acta sobre la Gestin de eventos, Gestin incidentes y
cumplimiento de solicitudes. Acta sobre la Gestin de problemas y la Gestin de Acceso?
La respuesta es obvia, NO!! la Gestin 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 Gestin de problemas actan los especialistas; de la misma manera en la Gestin
de Acceso son personas con cierto nivel de autorizacin quienes son capaces de poder dar
los privilegios correspondientes a los usuarios.
Service Desk es un punto rpido de contacto donde se resuelven incidentes de la
manera mas rpida 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 atencin del SLA.
Service Desk adems 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 rpido.
- Dame tu numero de anexo para llamarte cualquier cosa.
- Al Helpdesk? Psame con el que sepa mas de Outlook.
Estoy seguro que alguna vez han escuchado estas frases,verdad? y como resolver este
problema? la solucin no estn sencilla y tomar la decisin 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; adems de un cambio de tecnologa tambin como por
ejemplo agregar mas nmeros telefnicos 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 botn, cuando
llaman directamente a un Administrador de BD o Servidores lo que esta haciendo es
distraerlo de sus verdaderas funciones y le resta tiempo; adems 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 clsico 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 mltiples 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 versin Enterprise de MySQL
brinda este servicio) tiene diferentes centros de Servicio: uno para Latinoamrica, otro para
China, etc etc pero todos son contactados por un nico medio, mediante la creacin de un
ticket mediante su pagina web.

La imagen superior explica las maneras en como Service Desk recibe solicitudes de
atencin: correo, va telefnica, va web, etc y adems no olvidemos que cualquier tipo de
servicio, CUALQUIER!!! debe ser recibido por Service Desk.
IMPLEMENTAR UN SERVICE DESK
La implementacin no es tan simple como parece, requiere una dedicada planificacin y
debe responderse las siguientes preguntas:
- Cules son las necesidades?
- Cules sern sus funciones?
- Que calificaciones profesionales poseern sus integrantes?
- Qu tipo de Service Desk necesitamos: local, centralizado o virtual?
- Qu herramientas tecnolgicas necesitamos?
- Qu mtricas determinaran el rendimiento?
El factor humano juega aqu un rol muy importante, el factor humano debe:
- Establecer estrictos protocolos de interaccin con el cliente, estndares de comunicacin
desde el saludo hasta las preguntas de rutina a realizar.
- Informar a los clientes de los beneficios del Service Desk.
Estructura lgica del Service Desk
- Conocer los protocolos de comunicacin 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 interaccin con el
usuario.

- Conocer cuando hacer un escalado a instancias superiores.

- Tener rpido 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 rpido el telfono?
- 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 telfono con educacin?
Informes de Gestin
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 resolucin y promedios de tiempo de resolucin.
- Etc
Factores Crticos de xito
Existen factores que determinan el xito o fracaso de un Service Desk, estos factores son:
- Difcil manera de contactar a Service Desk, si los usuarios encuentran complicado
contactar con Service Desk simplemente no vern los beneficios de este y buscaran otro
tipo de soporte.
- Si los usuarios tratan de contactar directamente a los especialistas, automticamente deben
ser remitidos al Service Desk.
Cul es el objetivo principal de Service Desk?
Resolver el mayor numero de incidentes, ser la primera lnea de defensa de TI de manera
que los especialistas puedan concentrarse en su verdadero trabajo.

Existen adems diversas polticas de como implementar un Service Desk y depende de las
necesidades de la organizacin 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 polticas de la organizacin.