ENERO 17, 201010 COMMENTSITIL

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:

Paso 1: Instalar el SO bajo ciertas caracterices

Paso 2: Instalar JAVA o PHP de la siguiente manera

Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parmetros

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

Popularity: 12% [?]

10

ITIL V3: SERVICE TRANSITION (TRANSICIN DEL

SERVICIO)
MARZO 2, 201012 COMMENTSITIL

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.

11

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.

12

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

13

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

14

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.

Numero de cambios no autorizados que se han llevado a cabo.

Numero de cambios forzosos o de emergencia que se realizaron

15

Tiempo, esfuerzo y costo que ocasiono el cambio

Mtricas de trabajo
o

Frecuencia de cambios

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.

16

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,

17

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.

18

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.

19

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

20

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.

21

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.

ITIL V3: SERVICE OPERATION (OPERACIN DEL SERVICIO)

ABRIL 22, 20106 COMMENTSITIL

Ha pasado casi un mes desde que escrib mi ultimo post sobre ITIL y si alguno pens que estaba vagando o
simplemente me haba aburrido de escribir, djenme decirles que uno de mis principales defectos (o quizs
virtud.) es estar siempre estudiando algo, lo que me resta tiempo para cosas como escribir en mi blog y
dems actividades de ocio.

22

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:
- Introduccin a ITIL v3
- Estrategia del Servicio
- Diseo del Servicio
- Transicin del Servicio
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:

23

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.

24

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

25

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

26

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

27

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.

28

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.

29

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

30

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

31

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.

32

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.

33

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.

34

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.

ITIL V3: SERVICE OPERATION (OPERACIN DEL SERVICIO) PARTE II

ABRIL 28, 20108 COMMENTSITIL

Voy a tratar de ser breve porque el

primer post sobre Service Operation me explaye bastante pero creo que vala la pena. Hasta ahora hemos
tocado los siguiente captulos de ITIL v3:
- Introduccin a ITIL v3
- Estrategia del Servicio
- Diseo del Servicio
- Transicin del Servicio
- Service Operation Parte I
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.

35

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?

36

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

37

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.

38

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.

39

40

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.

41