Recursos ITIL®/Gestión de Servicios TI (ITSM) en Español

Un amigo mío y cliente de Serio de hace muchos años (quien permanecerá anónimo) me ha comentado: “Me han pedido que escriba unas pautas para nuestro manual de operaciones sobre cómo tratar con los clientes difíciles que llaman a nuestro centro de soporte técnico. Estoy pasando apuros así que ¡pensé en preguntarte a ti!” Lo que motivó esto fue un intercambio verbal entre un operador de primera línea y un cliente con un problema de impresión que parece haber resultado muy mal.

Siempre me alegra ayudar. Sin embargo, después de haber leído la siguiente anécdota (por la que pido disculpas volver a contarla) puede que prefiera no pedirme ayuda otra vez.

Después de licenciarme, a finales de los ‘80, trabajé en un banco en Londres, mi primer buen trabajo. No era un banco minorista sino un banco que hacía dinero por el intercambio de monedas extranjeras, acciones, el riesgo, cualquier cosa que pudiera ser objeto de comercio. Siendo recién licenciado, me encontré en el centro de soporte técnico atendiendo a llamadas de (entre otros) los comerciantes. La formación consistió en mostrarme cómo usar el software helpdesk (que tenía sólo una página), y decirme, “Gritan, pero mucho. Me voy”. Y dicho eso después de 10 minutos, estaba solo.

Mis primeras 10 llamadas fueron fáciles. Luego ocurrió lo siguiente:

Cliente: «Mi monitor está borroso. Quiero uno nuevo.»
Yo: «Ha comprobado que el cable de vídeo no esté cerca de una fuente de alimentación de CA?»
Cliente: «¿Qué?»
Yo: «Ha comprobado que el cable de vídeo no esté cerca de una fuente de alimentación de CA?»
Cliente, muy despacio esta vez: «Mi .. monitor .. está .. borroso .. quiero .. uno .. nuevo.»
Yo: «Eh…» (Empezaba a tener pánico) «Podría ser que la fuente de alimentación de CA esté interfiriendo con …»
Cliente: «¡Qué*****! ¿Es esto una **** lección de física, **** de ****?» Luego, dirigiéndose a un colega, «Tienen **** Johnny Ball trabajando en el **** soporte y me ésta dando una **** lección de física.»
Yo: «Es sólo que si…»
Cliente: «Tiene 5 segundos para decirme las palabras mágicas o terminamos. 5-4-3-2-1 adiós.» Y me cortó violentamente.

Diez minutos después estaban a punto de echarme y no permitirme volver a trabajar en soporte técnico.

Entonces, ¿cómo puede evitar cometer mis errores?

1. Simulaciones. Aunque mi amigo me pidió específicamente un texto para un manual de operaciones, no creo que esto sea lo que debiera pedir. Los procedimientos escritos en un manual de operaciones no le ayudarán en el momento que los necesita, es decir, cuando esté hablando por teléfono con un cliente enfadado. En cambio, debería diseñar unas simulaciones o juegos de rol para que pueda practicar su personal. Asegúrese que estas actividades se desempeñen en un entorno privado (con sólo el equipo de primera linea) y que los guiones que siguen sean realistas. Si quiere, báselos en situaciones o clientes verdaderos. A continuación, consolide estas simulaciones con unas pautas escritas. Asegúrese de que cada nuevo empleado tenga la oportunidad de practicar con las simulaciones. Es casi seguro que si no lo hace, serán ellos los que hablarán con los clientes enfadados.

2. Asegúrese de que el personal, especialmente los nuevos, entienda lo que los clientes pueden esperar razonablemente. En mi anécdota de más arriba, no sabía que los comerciantes recibían cualquier cosa que pidieran, y rápido. De hecho, la empresa guardaba siempre equipos de repuesto, ya configurados y preparados para usar. Tenían una reserva para competir con la de la tienda local de ordenadores.

3. No discuta. No es su trabajo defender la posición del centro de soporte. Si el cliente se queja de algo malo que usted ha hecho, no pida disculpas sino que reconozca sus quejas y enfatice que va a intentar resolverlo. Si no hace esto, entonces la situación se puede intensificar, como hemos visto. En las simulaciones, preste atención a los empleados que suenen condescendientes o falsos y hable con ellos sobre esto. Sin embargo, evite el servilismo; para algunas personas enfadadas esto es como echar leña al fuego.

En el ejemplo anterior, estaba discutiendo con el cliente. Dejó claro que no iba a probar nada con su monitor, pero yo persistía. Aunque no discrepara con él, esto es igual que discutir.

Evite admitir que el cliente tiene razón si empieza a insinuar que todo el servicio ofrecido por el centro de soporte es basura. Ocúpese solamente de los problemas específicos por los que está enfadado el cliente.

5. Fíjese bien en lo que ha molestado o enfadado al cliente. Déjeselo claro al cliente repitiendo lo que quiere o lo que le ha disgustado.

6. No se enfade como represalia. Siempre me resulta de ayuda ponerme de pie durante una llamada difícil, ya que me ayuda respirar más fácil y relajarme.

7. Opcionalmente puede tener un procedimiento para las reclamaciones, y preguntar al cliente si quiere presentar una queja. Esté preparado para explicar el procedimiento de reclamaciones.

8. Mientras escucha la queja del cliente, aprenda ignorar la grosería.

A quién está destinado

El Libro Blanco está destinado a todas las personas involucradas en la Gestión de Servicio TI, que han tenido contacto con ITIL y que desean averiguar más acerca de la Gestión de la Disponibilidad.

Propósito de este Libro Blanco

Explicar algunos puntos básicos de la Gestión de Disponibilidad, proporcionando ayuda y ejemplos prácticos siempre que sea posible. Al final de este Libro Blanco, encontrará gráficos de muestra, y una plantilla para realizar informes de gestión.

Lectura adicional

Puedo recomendar el siguiente libro como recurso definitivo de la Gestión de Disponibilidad: ‘Service Delivery’ publicado por TSO, ISBN 0 11 330015 8. He citado textualmente de este libro en el Libro Blanco en algunas partes. Donde así lo he hecho está claramente marcado.

También puedo recomendar otro Libro Blanco de Serio del mismo autor titulado ‘Métricas de la Gestión de los Servicio de TI: Cómo Empezar’.

Resumen de la Gestión de Disponibilidad

En resumen, la Gestión de Disponibilidad es:

•Identificar los sistemas y servicios TI claves de su organización.
•Determinar los requisitos de disponibilidad para estos sistemas y servicios.
•Trabajar para asegurar que estos requisitos se cumplan de una manera rentable.
•Realizar informes sobre la Disponibilidad TI, monitorizarla y mejorarla.

¿Por qué las organizaciones necesitan la Gestión de Disponibilidad?

Cuando me licencié a mediados de los ´80 y empecé a trabajar en varios puestos de soporte TI, los sistemas con los que trabajaba se necesitaban normalmente durante lo que llamaría ‘horario de oficina’ (de 8.00 a 18.00) o en ‘horario de oficina ampliado’ (de 8.00 a 20.00). Era bastante normal apagar los sistemas al final de la jornada laboral con el fin de hacer copias de seguridad, según la conveniencia del departamento de TI.

Por entonces, aquí en Reino Unido los negocios de venta al público cerraban a las 17.30, los bancos cerraban a las 15.00 y era casi imposible comprar nada los domingos. Los cajeros automáticos que operaban los bancos estaban frecuentemente no disponibles por la noche debido al ‘mantenimiento programado’.

Si saltamos 20 años hasta nuestros días, todo ha cambiado. Por supuesto Internet ha causado un profundo cambio en cuanto a cómo y cuándo esperamos acceder a los servicio TI, pero este cambio es algo más que cuestión tecnológica o de Internet.

Las expectativas de empresarios y consumidores sobre la disponibilidad de bienes y servicios han cambiado totalmente. Ahora los consumidores esperan poder hacer cosas que no podían hace 20 años, como contactar con su banco o compañía de tarjeta de crédito en cualquier momento, o realizar una compra a través de un catálogo o página web a la cualquier hora de la tarde.

Incluso el gobierno ha respondido. El acceso a servicios de formación, consejos de salud, etc. puede llevarse a cabo a cualquier hora tanto por teléfono como online vía Internet.

Toda esta actividad requiere de TI con el fin de proporcionar el servicio que las personas y empresas quieren y esperan, y así le da una importancia creciente a la Disponibilidad. Simplemente, los clientes verán la organización con desdén si los sistemas que desean usar no están disponibles, bien porque el servicio no está operativo cuando la organización advirtió que estaría disponible, bien porque está no disponible cuando el cliente siente que debería estar disponible.

La Gestión de Disponibilidad nos aporta un marco donde se pueda entender en primer lugar las necesidades de Disponibilidad de las empresas, para que después puedan ser proporcionadas.

En este punto recalcaría que la Gestión de Disponibilidad es mucho más que simplemente añadir componentes redundantes en su infraestructura TI, y es más que las últimas generaciones de hardware tolerante a fallos (aunque tales cosas indudablemente desempeñan un papel importante). La Gestión de Disponibilidad es un proceso, y, si se usa inteligentemente y sistemáticamente, puede producir beneficios sin tener que recurrir a un desembolso de capital significativo.

A quién está destinado

Este Libro Blanco está destinado a los gestores de centros de soporte que están planeando implementar un Centro de Servicio al Usuario basado en los principios de ITIL®.

Acerca de este Libro Blanco

Esperamos que este Libro Blanco sea muy útil para todos aquellos que quieran establecer un nuevo Centro de Servicio al Usuario basado en los principios ITIL®, o convertir su centro de soporte en un servicio ITIL® como único punto de contacto para sus clientes. Aquí encontrará ideas y sugerencias prácticas. Las sugerencias y observaciones que contiene este artículo provienen de la experiencia personal que hemos obtenido tras un gran número de implementaciones de ITIL®.

Qué hacer- Empezar por medir el estado actual de su Centro de Servicio al Usuario

Si usted no sabe por dónde ha empezado, es imposible saber si ha mejorado.

Una de las medidas más importantes que puede tomar antes de la implementación del Centro de Servicio al Usuario ITIL® es hacer una encuesta de satisfacción del cliente (vea nuestro Libro Blanco de Métricas de la Gestión de Servicio TI para más información).

Otra medida inicial importante es hacer una evaluación del nivel de madurez de ITIL® de su Centro de Servicio al Usuario y del proceso de Gestión de Incidentes. Las herramientas para realizar la autoevalución las puede encontrar en la página web de ITSMF (http://www.itsmf.com/bestpractice/selfassessment.asp). Esta autoevaluación, si es contestada honestamente y por alguien de su organización que tenga un entendimiento y conocimientos suficientes de los actuales procesos y políticas, le dará una línea de referencia con la que puede medir el progreso futuro.

Qué hacer- Involucrar al equipo del Centro de Servicio al Usuario en la planificación del proceso de Gestión de Incidentes

Muy poca gente recibe el cambio con los brazos abiertos. ¡Los cambios pueden dar miedo! Si da a su equipo cierto protagonismo en el cambio de un centro de soporte a un Centro de Servicio al Usuario basado en ITIL®, les resultará la transición mucho más fácil.

Celebre unas sesiones de “lluvia de ideas” con su equipo, ya que ellos contestan y registran llamadas cada día, ellos saben qué tipos de llamadas van a recibir. Involúcrelos en las pruebas del nuevo proceso y tenga en cuenta sus sugerencias. Estas son las personas que tendrán que trabajar con este proceso diariamente; será mucho más fácil si están contentos con ello.

Qué hacer- asegurar que la persona encargada de la Gestión de Incidentes tenga suficiente autoridad.

Un error bastante común que he detectado en las implementaciones ITIL® es que a menudo se asigna el puesto de la Gestión de Incidentes a alguien del Centro de Servicio al Usuario pero no se le da la autoridad necesaria para asegurar que el proceso de Gestión de Incidentes acordado se mantenga.

El Gestor de Incidentes se encargará de comprobar la calidad de los datos registrados y la información de la resolución enviada a los clientes. El Gestor necesita tener autoridad para reabrir llamadas cuando la información es inadecuada o inapropiada y hacer un seguimiento con los agentes involucrados.

Es muy importante que el Gestor de Incidentes sea capaz de dirigir a los agentes del Centro de Servicio al Usuario para que tomen medidas para resolver cualquier asunto con las llamadas en las que han estado trabajando. Si los agentes lo consideran sólo como miembro del equipo, sin la autoridad adicional necesaria, esta tarea será muy difícil.

En esta entrada, quiero hablar de la formación del personal de primera línea del Centro de Servicio al Usuario; en particular de cómo preparar al personal nuevo para atender Incidentes nuevos de los clientes.

Primero, asegúrese de que saben usar el software de Soporte Técnico. No siempre tiene que llamar al suministrador del software para llevar a cabo la formación, simplemente asegúrese de darle un enfoque estructurado cuando lo realice dentro de su empresa.

Formación sobre el software ITSM: Qué hacer y qué no

• No: no siente al nuevo miembro del personal al lado de un empleado con experiencia, esperando que así sea formado.
• Sí: Crée una lista de cosas que el nuevo empleado debería de ser capaz de hacer durante el registro de una llamada. Por ejemplo, si fuese un usuario de Serio, esperaría que la lista contuviera lo siguiente:

• Seleccionar al cliente en el sistema usando algún detalle más aparte del apellido.
• Entender (y ser capaz de explicar) que significan cada uno los campos usados para clasificar el Incidente (como “Tipo”, “Área”, “Prioridad”, “Impacto”, etc).
• Cómo activar la Revisión Ortográfica
• Cómo seleccionar un Elemento de Configuración (CI) dentro de la Base de Datos de Gestión de la Configuración (CMDB)
• Cómo cambiar cualquiera de las opciones por defecto
• Cómo usar Acciones para registrar las medidas que ha tomado para resolver el incidente
• Cómo adjuntar documentos o archivos al Incidente
• Cómo registrar Incidentes nuevos que han llegado por email al buzón de entrada de Serio
• Cómo registrar rápidamente los incidentes usando Alertas.

• Sí: Prepare una serie de tareas de formación para los nuevos empleados.
• Sí: Proporcione un sistema de formación para que lo use el nuevo empleado. No le pida que use el sistema real. En Serio aconsejamos a nuestros propios clientes que hagan una copia de su sistema de producción para usar durante la formación.
• Sí: Proporcione un entorno para la formación separado fisicamente del Centro de Servicio al Usuario.

Formación de cómo atender llamadas

Para mi, esta es la parte más importante. La primera llamada que atienda el nuevo empleado del Centro de Servicio al Usuario no debe ser de un cliente verdadero.

Debería preparar una serie de llamadas de prueba y simulacros y vea cómo el empleado las atiende. Haga que sus llamadas de prueba sean realistas y cada vez más complejas. Registre usted previamente los Incidentes de cada llamada.

Pida a un colega del mismo nivel del nuevo empleado que realice las llamadas de prueba. Si las hace un jefe la gente se puede poner a veces demasiado nerviosa.

Será bastante obvio si se necesita hacer más trabajo, pero puede tener en cuenta lo siguiente cuando examine los resultados:

• ¿Cuánta confianza en sí mismo parecía tener el empleado?
• ¿Controlaba la llamada?
• ¿Captó todos los detalles que usted esperaba que captase?
• ¿Cómo eran los registros de las llamadas de prueba en comparación con las que usted había previamente registrado? Explíquele cuidadosamente y con paciencia cualquier diferencia que encuentre.

Este artículo ha sido sugerido por alguien que conozco hace mucho tiempo que es ingeniera especializada en Gestión de Servicios TI (la llamaré Linda). Ha asumido recientemente un nuevo rol como Gestor de Provisión de Servicio en una empresa nueva (es decir, que tiene que ocuparse de un nuevo papel y una nueva organización). La primera cosa que notó el primer día era que, aunque su empresa (la llamaré Widgetco) tiene sólo 600 usuarios y 8 de personal informático, había más de 600 Incidentes activos, algunos de ellos abiertos hacía 6 meses.

WidgetCo no utiliza ITIL ni tiene ningún conocimiento de Gestión de Servicios TI, aunque sin duda ésto cambiará. La pregunta que me hizo mi amiga era: “¿Qué tipo de medidas puedo tomar para reducir el número de Incidentes atrasados a un nivel más razonable?”

Aquí tiene algunas de las cosas que haría yo, sin un orden especial.

1. Avise a los altos cargos, a los directores y a los patrocinadores del proyecto de lo que ha descubierto. Deles un resumen rápido del problema, señale lo que va a hacer y cuánto tiempo tardará, y prometa presentarles un informe al final de este plazo. Si crea informes de
gestión que muestra el rendimiento frente a un Acuerdo de Nivel de Servicio (SLA), avíseles que éstos y posiblemente otras estadísticas podrían verse afectados mientras pone al día el trabajo.

2. Considere avisar a los clientes o usuarios de lo que está haciendo, especialmente si afectará negativamente a corto plazo la calidad del servicio.

3. Dé a su personal unas pautas sobre la calidad (Linda me comentó que no se registra cada Incidente). Éstas deben incluir:

Registre cada Incidente
Si resuelve un Incidente, póngalo como resuelto en el sistema dentro de tres horas
Establezca unas reglas de calidad básicas, tales como proveer descripciones de Incidente y de resolución adecuadas.

4. Averigüe si algunos de los Incidentes atrasados son en realidad Solicitudes de Cambio. Hay que distinguir entre Incidentes (en los que ha ocurrido un fallo en un servicio del usuario) y situaciones en que los clientes solicitan cambio en los servicios (aunque éstos sean importantes).

5. Examine uno por uno los Incidentes más antiguos (por ejemplo de abril a julio). Puede necesitar que alguien le ayude con ésto. La mayoría de las herramientas ITSM como Serio permiten que se adjunten ‘valores de estado’ personalizados a los Incidentes (en Serio, Agent Status A & B (Estado de Agente A y B) son ejemplos de ésto). Crée unos valores de estado para adjuntar a sus Incidentes que aclaren lo que significan. Ésto también puede ayudarle a recordar cuáles han sido examinados.

Por ejemplo,

“Pendiente” (ya lo ha examinado y requiere todavía actuación)
“Cambio registrado” (este Incidente es realmente un Cambio)
“No requiere acción” (según mi experiencia, puede encontrar algunos Incidentes que o bien ya están resueltos pero todavía no se ha actualizado el sistema, o bien las circunstancias han cambiado y ya no se necesita continuar).
“En espera” (el estado no estará claro hasta otra revisión. Naturalmente, es deseable mantener este número bajo).

6. Revise sus estadísticas para ver quién está resolviendo realmente los Incidentes, a fin de ver si alguno de los empleados está trabajando por debajo de sus posibilidades. Use estos datos con cuidado: puede que los que resuelven menos se encarguen de Incidentes más complejos.

Haga hincapié a su personal de la importancia de resolver Incidentes, y considere publicar diariamente una lista de Incidentes pendientes en el tablón de anuncios o en otra posición destacada.

Considere formar un equipo especial dedicado a resolver los Incidentes “pendientes” que ha identificado. En el caso de Linda, es poco probable que el equipo sea de más de dos personas. Aquí pongo énfasis en la palabra “considere”, ya que también podría decidir dejar los Incidentes a los ingenieros que actualmente se encargan de ellos.

9. Los Incidentes se asignarán a equipos y a agentes. Examine el reparto de Incidentes entre ellos (un gráfico de barras puede ser útil para ésto). Si nota cuellos de botella (por ejemplo, 300 Incidentes asignados a un individuo) tome medidas para redistribuir Incidentes como sea
necesario.

Algunas de estas sugerencias pueden dejar ver otros problemas. De ésos volveré a escribir en otro artículo.

Alguien que ha asumido recientemente el papel de Gestor de Incidentes me ha pedido escribir esta entrada. Para ayudar a alguien a empezar, ¿qué tipo de cosas hacen los Gestores de Incidentes?

Por supuesto, lo ideal sería haber trabajado antes para un Gestor de Incidentes efectivo, en una operación ITSM efectiva. Si no, y particularmente si ha ascendido inesperadamente en su trabajo, puede parecer un poco intimidante.

Primero, vuelva hasta el principio. Los Gestores de Incidentes son, en última instancia, responsables del proceso de Gestión de Incidentes. Si luego se amplia esta definición para incluir todo el ciclo de vida del incidente tendrá una mejor idea.

Mi objetivo con este blog es centrarme en detalles y aspectos prácticos. Por eso, lo que haré es tratar de dar una idea de algunas de las cosas que usted esperaría hacer, poniendo el énfasis en los aspectos prácticos. No es exhaustivo pero espero que le de una idea.

1. Propiedad del proceso de la Gestión de Incidentes.

Si usted es Gestor de Incidentes, intentará describir cómo los agentes de su equipo atenderán los Incidentes, cómo trabajarán juntos, y qué espera de ellos. Los mejores Gestores de Incidentes con quienes he tenido la suerte de trabajar han sido suficientemente listos como para producir documentos fáciles de entender y utilizables. Estos documentos describen cosas tales como cómo escalar un Incidente, quién tiene la responsabilidad por los incidentes en cada fase de su ciclo, definen unos roles y los asignan a personas específicas … espero que entienda el concepto.

Lo que intenta definir es “¿Cómo podemos garantizar que, cuando se registra un Incidente, lo atendamos de manera profesional y con plena satisfacción del cliente?”.

En ésto se distinguen los Gestores de Incidentes efectivos de los demás. Los efectivos se toman tiempo para explicar el proceso al equipo de Incidentes; es decir, para convencerles de sus ventajas. No sólo les mandan un email que dice “Estimados compañeros: Ésto es lo que quiero que ustedes hagan, me voy a jugar una vuelta de golf”. En cambio, montan presentaciones, reuniones, etc.; cualquier cosa que pueda hacerles llegar mejor su mensaje.

2. Asegurar que el proceso de Gestión de Incidentes sea seguido

Es algo que veo demasiado a menudo. Alguien ha escrito unas pautas, o un documento de Incidentes, lo ha mandado al personal, y esa es la última vez que alguien lo mira. El documento (es decir, el proceso de Gestión de Incidentes) se ignora por completo.

Los Gestores de Incidentes efectivos actúan como policías. Por ejemplo, si piden que la información de la resolución de cada Incidente sea completa y correcta (de modo que pueda ser útil más tarde para búsquedas en la Base de Conocimiento), entonces intentarán asegurar que:

1. Haya alguna manera de verificar ésto, como parte del propio proceso de la Gestión de Incidentes.
2. De vez en cuando ellos mismos examinan los registros de Incidentes. Por ejemplo, si usan Serio, podrían mirar los Incidentes resueltos durante la última semana y examinar por sí mismos la información de resolución, volviendo a abrir Incidentes que no den la talla (y posiblemente ajustando el mismo proceso de Gestión de Incidentes).

Los Gestores de Incidentes efectivos se dan cuenta de que alertas y avisos generados por un sistema ITSM tienen su valor, pero que muchos del personal pueden ignorar éstos al principio (de hecho, si configura su herramienta ITSM para que genere muchas alertas, es cierto que pasa ésto). Así que, busque señales de que la gente no está utilizando efectivamente el sistema. Hay muchas maneras sutiles de que se puede tratar este tipo de cosa, empezando con una conversación en privado, y un poco de formación extra.

3. Preguntar, “¿Es efectivo el proceso de Gestión de Incidentes?”

Ésto no es la misma cosa que para el punto 2. En general, el Gestor de Incidentes usará un amplio abanico de estadísticas para ésto, y ajustará el proceso de Gestión de Incidentes cuando sea necesario. Puede encontrar unos ejemplos de los KPIs de la Gestión de Incidentes y de la Gestión de Problemas en nuestro Libro Blanco (link ‘Libro Blanco’ to metrics whitepaper). Tome nota por favor que (como he descrito muchas veces antes) ésto no es lo mismo que sacar unas métricas de su sistema ITSM y darlas a su jefe. (Si un Gestor de Incidentes me hiciera eso, se las devolvería directamente.) Quiere decir sentarse y decidir que datos van a examinar, sacando conclusiones, y haciendo sugerencias para cómo mejorar.

4. Gestionar el trabajo y las cargas de trabajo de los equipos de la Gestión de Incidentes

Lo que quiere decir ésto es que de vez en cuando aparecen cuellos de botella. Por ejemplo, puede tener una situación en que cien incidentes están asignados a su equipo unipersonal de redes, y casi ningún incidente siendo atendido por los otros.

Los Gestores de Incidentes se mantienen a corriente de estos problemas, y toman las medidas correctivas que sean necesarias; por ejemplo, volver a asignar trabajo, contratar a personal temporal, volver a programar tareas no urgentes. Para los usuarios de Serio, ésto puede ser tan simple como usar efectivamente los gráficos de rendimiento de asignación y de propiedad.

Para muchos usuarios de Serio, el Gestor de Incidentes es de hecho el supervisor del equipo del primer nivel del Centro de Servicio al Usuario, una solución que generalmente funciona muy bien.

Por último, recomendaría que nuestro nuevo Gestor de Incidentes consulte el libro ‘Best Practice for Service Support’. Es una fuente excelente de información, y lo puede comprar de amazon.com.

A quién está destinado

El Libro Blanco está destinado a los gestores de Centros de Servicio al Usuario que pretenden convertir datos crudos recogidos de la Gestión de los Servicios de TI en información sobre la cual puedan basarse las decisiones de la gestión.

Acerca del Libro Blanco

Esperamos que este Libro Blanco sea de utilidad para aquellos que quieran realizar un informe de gestión por primera vez, ofreciendo ideas y sugerencias prácticas.

Al final de este Libro Blanco encontrará una plantilla de ejemplo que puede usar.

Nuevo: Hemos producido una hoja de cálculo ‘Métricas Serio’ para acompañar este Libro Blanco, la cual contiene varios gráficos en los que puede añadir sus propios datos. Puede descargar la hoja de cálculo aquí.

¿Por qué realizar informes de gestión desde los datos de del Centro de Servicio al Usuario?

Por encima de todo, recuerde porqué realizamos informes de gestión. Las razones podrían ser:

“Permitir a los gestores involucrados en la Gestión de los Servicios de TI tomar decisiones racionales y bien fundamentadas sobre los servicios de TI y la infraestructura ofrecidos al cliente.”

Por otro lado, también podría realizar informes para clientes, en cuyo caso:

“Mostrar al cliente que paga el servicio de TI (o a otros grupos interesados) el nivel de servicio que provee el Centro de Servicio al Usuario y su rendimiento. Permitir que la conformidad con los estándares de rendimiento acordados sean examinados.”

Comenzando por esta premisa, resulta claro que mirando entre todos los datos que tenemos disponibles, algunos de ellos van a ser para nosotros más importantes que otros. Me referiré a los datos que nos importan como Datos Claves de Rendimiento.

Su propia elección de cuáles son los Datos Claves de Rendimiento debería estar influenciada por:

• Los retos a los que se enfrenta en la entrega de los servicios de TI a los clientes
• Las demandas en la función de la Gestión de los Servicios de TI realizadas por el negocio.
• El uso previsto de los informes y su audiencia.

Por ejemplo, puede proporcionar un sistema CRM y su organización requiere un elevado tiempo de disponibilidad (en torno al 99,8%). En este caso, sería razonable incluir datos de la disponibilidad y del tiempo de caída como parte de los Datos Claves de Rendimiento.

A primera vista, podría parecer que identificar sus Datos Claves de Rendimiento es una tarea muy difícil, particularmente cuando la mayoría de las herramientas disponibles (incluyendo Serio) ofrecen muchos tipos diferentes de datos a su elección. Sin embargo, realizando las cosas poco a poco, encontrará que en general es bastante sencillo.

Un método sería clasificar los datos de rendimiento en diferentes grupos, y después decidir qué grupo se considera más importante. Para cada uno, necesita tener una idea muy clara sobre qué podrían indicar los datos sobre los servicios que proporciona a los clientes.