Resumen Personal ITIL V3

7/18/2019 Resumen Personal ITIL V3

1/32

Area de Formacin Continua

Resumen ITIL V3 ing. Hugo Ernesto Silva Beltrn

INTRODUCCIN A ITIL V3

El objetivo de este resumen es entender en trminos mortales todo referente a

ITIL, abarcando 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 ITS M.

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) s in 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 serviciosque 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 generales 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.


2/32



Gobierno Corporativo

ITIL pone su ladrillo en el Gobierno Corporativo de una organizacin y no solo ITIL sino tambin: PMI, CMMI e ISO 27001/27002.

COSO: Modelo de Gobierno Corporativo, marco de referencia para el control interno conforme con la ley SOX.

El modelo de procesos de ITIL 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, ITIL 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


3/32



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 po st 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 e sto 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; esdecir 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:


4/32



- 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.
http://www.el-palomo.com/wp-content/uploads/2010/01/estrategia755494.gif


5/32



ITIL V3: SERVICE STRATEGY (ESTRATEGIA DEL SERVICIO)

Este es el segundo post de ITIL v3, en elprimer postse hizo una introduccin a ITIL v3, las

certificaciones y algunos conceptos generales que nos ayudarn a entender mejor este tema y lossiguientes 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) atravs del diseo, desarrollo, implementacin y prctica de la Gestin del Servicio (ITSM).

Transformar la gestin del servicio en un activo estratgico: Pensar como puedomejorar 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 d iario. 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 serv ido

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
http://www.el-palomo.com/2009/12/introduccin-a-itil-v3/http://www.el-palomo.com/2009/12/introduccin-a-itil-v3/http://www.el-palomo.com/2009/12/introduccin-a-itil-v3/http://www.el-palomo.com/2009/12/introduccin-a-itil-v3/


6/32



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 delservicio 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 lomejor 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 lasnecesidades 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, conun 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 ysoportadas 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.


7/32



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 delnegocio (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 (muyimportante!!)

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


8/32



ITIL V3: SERVICE DESIGN (DISEO DEL SERVICIO)

para dejar en claro acerca de 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 elservicio (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 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 alde 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 deIT 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 caractericeso Paso 2: Instalar JAVA o PHP de la siguiente manerao Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parmetroso 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), porejemplo 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 ELGOBIERNO CORPORATIVO.

Actividades de SD

1. Gestin del Portafolio del Servicio2. Identificacin de los requerimientos del negocio, definicin y diseo del servicio3. Diseo de la arquitectura tecnolgica4. Diseo del proceso5. 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.


9/32



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.


10/32



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 linea l desdeque 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 ServicioUn 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 ClienteEn 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


11/32



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 con clusin

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.


12/32



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 riesgos2. Credibilidad organizacional3. Recuperacin de los sistemas de TI de manera controlada4. Interrupcin mnima del negocio

Algunos Conceptos

Imaginemos que el DataCenter sufri un incendio y debemos recuperar la informacin en otro ambiente, la recuperacin recibe unnombre 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.


13/32



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


14/32



ITIL V3: SERVICE TRANSITION (TRANSICIN DEL SERVICIO)

ITIL se basa en algo tan simple como la lgica!!! no hay nada misterioso o que nunca hayamos hech

o 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 dela 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 laspolticas 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 detr s 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
http://www.el-palomo.com/2010/03/itil-v3-service-transition-transicin-del-servicio/http://www.el-palomo.com/2010/03/itil-v3-service-transition-transicin-del-servicio/http://www.el-palomo.com/2010/03/itil-v3-service-transition-transicin-del-servicio/


15/32



Polticas y estndares: reglas que proveen una cultura y ambiente que soporta el cambio. Por ejemplo una polt ica de cambioes 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 unaumento 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 xitoes 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 changeSolicitud de cambio) y cambios en la CMDB, registrar el tipo decambio, 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 muyimportante porque si el RFC es rechazada por ser poco clara har que el sol icitante sea mas explicito y mejore elentendimiento del cambio.


16/32



3. Clasificacin: Especifica la prioridad (importancia del cambio frente a otro cambio) y la categora (en base del impacto yrecursos).

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 hacerque 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 paraITIL 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 realizarono Tiempo, esfuerzo y costo que ocasiono el cambio

Mtricas de trabajoo Frecuencia de cambioso Volumen de cambios

Proceso de medicino 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]
http://community.ca.com/blogs/itil/archive/2007/10/26/promoting-the-cmdb-to-cms.aspxhttp://community.ca.com/blogs/itil/archive/2007/10/26/promoting-the-cmdb-to-cms.aspxhttp://community.ca.com/blogs/itil/archive/2007/10/26/promoting-the-cmdb-to-cms.aspxhttp://community.ca.com/blogs/itil/archive/2007/10/26/promoting-the-cmdb-to-cms.aspx


17/32



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 organizaci n

es para todos igual (sistema operativo Windows, drivers, codecs, etc.) y dependiendo del rea donde trabaje se le instalanotras aplicaciones.

Gestin de ConfiguracinPor 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,


18/32



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 seralmacenada, 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 (RDMRelease 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


19/32



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

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 pasadopor desarrollo y pruebas.

Tipos de versiones:

Versin delta: slo se testean e instalan los elementos modificados. Esta opcin tiene como ventaja su mayor simplicidadpero 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 esobviamente 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 deversiones, 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.


20/32



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


21/32



ITIL V3: SERVICE OPERATION (OPERACIN 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 s istema 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 serviciosestables, 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 a l 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.


22/32



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 estecorreo, 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)


23/32



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.


24/32



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 estamoshablando 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 inicialLa imagen superior muestra un ejemplo de clasif icacin, 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.


25/32



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.


26/32



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 esmenor; 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 (KEError 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)


27/32



.

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.


28/32



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.


29/32



ITIL V3: SERVICE OPERATION (OPERACIN DEL SERVICIO)PARTEII

Es evidente que para poder entender todo este tema en su totalidad, les recomiendo antes haber ledo los captulos anteriores. 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 este laborioso 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.


30/32



Service Desk adems cumple un ROL importante, Service Desk es el nico punto de contacto para atender servicio s, 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 elService 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) t iene 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:


31/32



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


32/32


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.

Resumen Personal ITIL V3

Documents

Transcript of Resumen Personal ITIL V3