ITIL V3: Service Operation (Operación del Servicio)

Abril 22, 2010 18 comments ITIL

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

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

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

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

Habíamos dejado la “acción” en la implementación del servicio (Transición del Servicio

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

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

Definición, metas y objetivos

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

Cuando hablamos de gente que esta constantemente monitoreando los servicios,

atendiendo llamadas y dando soluciones temporales, hablamos de nuevos conceptos
como: impacto, urgencia y prioridad. Imaginemos….. llama un usuario de logística
indicando que no puede abrir un archivo PDF y llama el director general indicando que
no le funciona el outlook, ¿a quien se atiende primero? ¿al que llamo primero?, pues….
eso depende de muchos factores como la cantidad de gente con la que se cuente, la
cantidad de recursos y de tiempo.

Terminología: En este tema existen muchos términos nuevos y definiciones muy

técnicas así que me gustaría explicarlo mejor con un ejemplo para que quede bien claro:

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

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

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

A partir de este punto se crean nuevos paradigmas: Calidad del Servicio Vs. Costo del
servicio. Es que nosotros como TI podríamos decirle al cliente que el tiempo de
respuesta frente a la caída de un servicio será de solo 10 minutos pero necesitamos:

- Herramientas costosas de monitoreo, con un valor aprox de 30 mil dólares anuales

- 25 personas dedicadas al área de TI, con un valor de 100 mil dólares anuales
- ETC

¿Es esto posible? la mejor idea es siempre buscar un equilibrio entre la calidad del
servicio y el costo de modo que se pueda cumplir con los requerimientos del negocio.
Los procesos en la Operación del servicio son:

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

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

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

- Escalamiento funcional (horizontal): Cuando se involucra a otra persona con mayores

conocimientos en el tema.
- Escalamiento jerárquico (vertical): Cuando se necesita de autoridad para realizar una
acción.

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

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

Detección, comunicación y registro

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

Entonces la “detección” debería ser automatizada en primera instancia, recibida por el

personal del centro de servicios, reportada por el mismo personal de TI o directamente
reportada por el usuario final; cualquiera que sea el mecanismo de detección TODO
INCIDENTE DEBE SER REGISTRADO Y DEBE SER ASIGNADO UN NUMERO.

¿Absolutamente todo debe ser registrado?

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

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

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

Numero de identificación, clasificación, fecha, quien detecto el incidente, síntomas,

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

¿A quién comunico el incidente?

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

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

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

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

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

Cierre del incidente

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

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

Otro tema muy importante es el MAL ESCALAMIENTO, muchas veces se abusa del
escalamiento y cualquier problema es ESCALADO rápidamente distrayendo a los
especialista en temas que no son importantes. (ESTA ES PREGUNTA DE
CERTIFICACION ITIL).
Y por ultimo y quizás el mayor problema que presenta la gestión de incidentes es la
falta de un SLA y Catalogo de servicios, cuando estos documentos no están presentes
cualquier problema relación con tecnología va ser automáticamente asignado al área de
TI sin importar temas como tiempo y recursos.

No olvidar que ITIL cuantifica todo, por ello nosotros debemos ser capaces de tener
reportes de la gestión de incidentes que respondan a las siguientes preguntas:

- ¿Cuántos incidentes se han presentado en un periodo de tiempo?

- ¿Cuántos incidentes de software hemos tenido?
- ¿Cuántos incidentes han sido escalados hasta los especialistas?
- ¿Cual es el tiempo de respuesta ante un incidente? ¿Cumplo con el SLA?
- ¿Qué área presenta mayores incidentes?
- Etc

GESTION DE EVENTOS

La principal diferencia entre evento e incidente radica en que TODO INCIDENTE es un

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

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

- ITIL v3 no se puede implementar sin herramientas que monitoreen los eventos,

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

CUMPLIMIENTO DE SOLICITUDES

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

GESTION DE PROBLEMAS

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

Algunos conceptos:

KnowError (KE – Error conocido): ITIL apunta a que todo problema debe ser resuelto y
dar como resultado un KE, un KE es entender la causa de la falla y no necesariamente
conocer la solución, es decir ITIL recomienda tener registrado todos los errores en una
BD, Base de Datos de Errores conocidos (KEDB).

ITIL v3 lo ve de la siguiente manera, todo comienza en la Gestión de incidentes, el

incidente es repetitivo (se convierte en un problema) y por ende pasa a la Gestión de
problemas, se investiga las causas del problema hasta dar con el origen del mismo,
cuando se tiene el conocimiento necesario de las causas del problema se genera un
Workaround (solución temporal) y el problema sufre un cambio, una mutación!!; pasa
de ser un problema a un Know Error (KE).
Por ultimo KE debe generar un RFC para hacer el cambio correspondiente y solucionar
el problema, La Gestión del Cambio se encargara de este proceso.

Como habremos notado la Gestión de Incidentes y la Gestión de Problemas van de la

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

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

proporcionándole soluciones temporales (workarounds).

La Gestión de Problemas tiene los siguientes procesos:

Control de problemas
- Define e investiga los problemas y su principal función es transformar los problemas
en KE.
- La principal fuente de información para el registro de problemas es la BD del registro
de incidentes.
Control de Errores
- Se ocupa de resolver Errores Conocidos (KE) mediante la Gestión de Cambios, la
Gestión de problemas se encarga de todo el ciclo de vida del problema lo que quiere
decir que debe estar monitoreando el cambio que sera realizado por la Gestión de
Cambios.
Como en todos los procesos de ITIL con la BD de los Errores Conocidos nosotros
debemos poder sacar informes de gestión: cantidad de problemas resueltos, tiempo
tomado para resolver problemas, costos asociados con los problemas, etc.

GESTION DE ACCESO

Hablar de seguridad de la información es un tema demasiado relevante en la actualidad

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

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

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

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

Procesamiento de Solicitudes de Acceso al Usuario

Procesar pedidos para agregar, cambiar o revocar derechos de acceso, y asegurar que
sólo los usuarios autorizados tengan derecho a usar determinados servicios.
ITIL V3: Service Operation (Operación del Servicio) –
Parte II
Abril 28, 2010 11 comments ITIL

Voy a tratar de ser breve

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

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

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

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

¿Service Desk o Help Desk?

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

¿Donde trabaja Service Desk?

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

Service Desk es un punto rápido de contacto donde se resuelven incidentes de la

manera mas rápida posible, esto nunca lo olviden!!! (lo voy a poner en negrita y de
rojo).

Entonces…. ¿Qué hace Service Desk?

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

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

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

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

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

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

herramientas debidas.

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

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

Tipos de Service Desk

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

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

Service Desk Virtual de Servicios Centralizados: Aquí el ejemplo son las grandes
empresas de Internet, por ejemplo MySQL Support (La versión Enterprise de MySQL
brinda este servicio) tiene diferentes centros de Servicio: uno para Latinoamérica, otro
para China, etc etc pero todos son contactados por un único medio, mediante la creación
de un ticket mediante su pagina web.
La imagen superior explica las maneras en como Service Desk recibe solicitudes de
atención: correo, vía telefónica, vía web, etc y además no olvidemos que cualquier tipo
de servicio, CUALQUIER!!! debe ser recibido por Service Desk.

IMPLEMENTAR UN SERVICE DESK

La implementación no es tan simple como parece, requiere una dedicada planificación y

debe responderse las siguientes preguntas:

- ¿Cuáles son las necesidades?

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

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

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

comunicación desde el saludo hasta las preguntas de rutina a realizar.
- Informar a los clientes de los beneficios del Service Desk.

Estructura lógica del Service Desk

- Conocer los protocolos de comunicación con el cliente, conoces los cheklists

(preguntas de rutina a realizar para determinar la causa del incidente).
- Disponer y conocer las herramientas de software para el registro e interacción con el
usuario.
- Conocer cuando hacer un escalado a instancias superiores.
- Tener rápido acceso a la base del conocimiento para ofrecer un mejor servicio a los
usuarios.
Indicadores Claves de Rendimiento
La manera de saber si mi Service Desk esta funcionando adecuadamente para por
responder las siguientes preguntas:

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

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

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

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

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

Factores Críticos de Éxito

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

- Difícil manera de contactar a Service Desk, si los usuarios encuentran complicado

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

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

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

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