Source: http://docplayer.es/486418-Metricas-de-la-gestion-de-los-servicios-de-ti-como-empezar.html
Timestamp: 2017-09-22 20:49:09+00:00

Document:
Métricas de la Gestión de los Servicios de TI: Cómo Empezar - PDF
Download "Métricas de la Gestión de los Servicios de TI: Cómo Empezar"
Óscar Aranda Ramos
1 Métricas de la Gestión de los Servicios de TI: Cómo Empezar Por George Ritchie, Serio Ltd george-dot-ritchie-at-seriosoft.com Copyright Serio Ltd
3 Page 3 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é
4 Page 4 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. Este Libro Blanco es traído a usted por Serio Prueba hoy tu sistema SerioPlus un Sistema de Gestión y Soporte a Servicios de TI de clase empresarial. Visitenos en para la prueba gratuita.
5 Page 5 Clasificación de los Datos de Rendimiento La mayoría de las herramientas ITSM proporcionan diferentes tipos de informes que ofrecen datos de rendimiento. Estos informes pueden ser clasificados en diferentes grupos. Lo que sigue a continuación no es una lista completa pero esperamos que le proporcione los elementos necesarios para saber cómo agrupar datos y los tipos de datos que están normalmente disponibles. Datos de Entrada (Inputs) Con el término de Datos de Entrada me refiero a los datos tales como Incidentes registrados o Cambios solicitados. Por supuesto hay muchas maneras de enfocar esto. Por ejemplo: Incidentes registrados semana a semana Incidentes registrados mes a mes Incidentes registrados por departamentos Incidentes registrados según prioridad, etc. Sin embargo, todo esto es lo que clasifico como Datos de Entrada y mide hasta cierto punto el trabajo que entra en el Centro de Servicio al Usuario. Una cosa que he observado tratando con clientes que acaban de empezar con la Gestión de los Servicios de TI es que, en términos de informes de gestión, hay una tendencia a centrarse en los datos de entrada excluyendo casi por completo otros datos de rendimiento. De algún modo no es sorprendente: Las organizaciones que tienen un servicio de soporte reactivo, lo que hacen es registrar incidentes y solucionar incidentes. Mientras que como veremos, un Centro de Servicio al Cliente hace bastante más y mirará más ampliamente a los datos de rendimiento. Dónde encontrar esto en Serio: En SerioReports, agrupados bajo Logged (Registrados), Logged of which resolved (Registrados de los cuales resueltos) y Logged vs Resolved (Registrados frente a resueltos). En SerioClient, examinando el gráfico Incidents Logged and Resolved (26 Weeks) (Incidentes registrados y resueltos (26 semanas) en Performance Graphs (Gráficos de Rendimiento). Datos de Salida (Outputs) Con el término Datos de Salida, me refiero a datos tales como Incidentes resueltos, o Cambios completados, durante un período de informe determinado. De nuevo a veces estos datos se usan (junto con los Datos de Entrada) excluyendo otros datos porque el servicio de soporte considera que su trabajo consiste en resolver incidentes. Los ejemplos de Datos de Salida podrían incluir: Incidentes registrados y resueltos semana a semana Incidentes registrados según prioridad o compañía, etc.
6 Page 6 Dónde encontrar esto en Serio: En SerioReports, puede usar los informes agrupados en SLA Analysis (Análisis SLA ). Todos estos informes están basados en Incidentes, Problemas y Cambios resueltos. También los informes agrupados en Logged (of which Resolved now) (Registrados de los cuales ya resueltos) y muchos de los informes bajo Agent Performance (Rendimiento de los Agentes). En SerioClient, puede utilizar el gráfico Incidents Logged and Resolved (26 Weeks) (Incidentes registrados y resueltos (26 semanas)) en Performance Graphs (Gráficos de Rendimiento). Datos estadísticos del teléfono Aunque vivamos en la era multimedia de soporte de TI a través de , acceso de web, voz a través de Internet y un amplio abanico de tecnologías emergentes, el teléfono es todavía muy importante. Siempre me sorprende, por lo tanto, que muchos Centros de Servicio al Usuario descuiden o ignoren las estadísticas de teléfono del todo. Sin embargo esto es algo que realmente importa al cliente; si no consiguen una contestación cuando llaman no se sentirán bien servidos por parte del servicio de soporte. Las estadísticas de teléfono son proporcionadas generalmente por el sistema telefónico, o a través de su sistema ITSM, el cual interface con el sistema telefónico. Por ejemplo: Tiempo medio que tarda en contestar el teléfono, desglosado en la hora del día. El índice de llamadas perdidas, otra vez desglosado en la hora del día Llamadas contestadas por cada agente Llamadas salientes realizadas, según la hora del día Información de estado La información de estado es una foto instantánea de los datos dinámicos que están siendo tratados por el Centro de Servicio al Usuario en un momento del tiempo. Por ejemplo: El número de Incidentes, Problemas y Cambios activos El estado de los Incidentes Activos (como Esperando reacción del cliente, Esperando Componentes, En Espera, Investigando ). Bastante a menudo se representa mediante un gráfico circular. El número de Incidentes actualmente asignados a proveedores externos. El número actual de Incidentes Graves activos. Cómo los Incidentes, Problemas y Cambios activos están en ese momento repartidos entre Agentes y Equipos. Dónde encontrar esto en Serio: Tiene disponible mucha información de estado en Performance (Rendimiento) en el menú de SerioClient. Como por ejemplo, Agent Status A & B Distribution (Distribución de estados A &B), SLA Dashboard (Panel de rendimiento SLA), Incident Assignment Status (Estado de
7 Page 7 Asignación de Incidentes), Incident Owership Status (Estado de Propiedad de Incidentes), Days Logged for Active Incidents (Días contados desde el registro de cada Incidente activo). En SerioReports, vea los informes agrupados bajo Assignment Status (Estado de asignación). Datos sobre la puntualidad de la Respuesta y Resolución Este tipo de datos son denominados a veces como datos del Acuerdo de Nivel de Servicio (Service Level Agreement SLA). Generalmente compara los tiempos y porcentajes de respuesta y resolución acordados (con el negocio) con aquellos realmente logrados. Ejemplos: Porcentaje de respuestas logradas a tiempo (y hasta una hora tarde, hasta cuatro horas tarde, etc.) comparado con el objetivo. Porcentaje de resoluciones logradas a tiempo (posiblemente desglosado según prioridad) comparado con el objetivo. Tiempos de resolución desglosados en compañía, prioridad o impacto. Dónde encontrar esto en Serio: En SerioReports, encontrará informes que se centran en esto, agrupados bajo SLA Performance Rendimiento SLA). En SerioClient, echa una mirada a Average Resolution Times by Issue Type/Priority (Tiempos medios de resolución según tipo/prioridad) y los gráficos de Average Resolution Times by Priority (Tiempos medios de resolución según prioridad) representados en Performance (Rendimento). Datos sobre la encuesta de satisfacción del cliente Muchas herramientas (incluyendo Serio) permiten recoger datos de encuestas de satisfacción del cliente, por ejemplo, de los procesos de Resolución de Incidentes. Ésto es un recurso de información bastante importante si se usa y se interpreta correctamente, ya que nos dice cómo la gente a la cual estamos sirviendo ve y valora el servicio que estamos ofreciendo. A veces es tentador suponer que si alcanzamos nuestros objetivos SLA el cliente automáticamente lo valorará, pero la experiencia nos muestra que no siempre es así. El uso de los datos sobre la encuesta de satisfacción del cliente (en conjunción con otros datos) es un indicador muy útil del rendimiento de su Centro de Servicio al Cliente. Dónde encontrar esto en Serio: En SerioReports, agrupado en Customer Surveys (Encuestas al cliente). En SerioClient, en Performance (Rendimiento). Los gráficos de Customer Satisfaction Survey Results (Resultados de las encuestas de satisfacción del cliente) proporcionan un dibujo útil y conveniente de cómo la satisfacción del cliente ha cambiado durante los últimos tres meses.
8 Page 8 Datos de Causa Una de las metas de la Gestión de los Servicio de TI es, en primer lugar, detener (o al menos reducir) el número de Incidentes que ocurren, de modo que se reduzca el impacto en el negocio y los costes asociados a los Incidentes. Los datos de causa nos ofrecen una vía efectiva, fácilmente entendible y simple de lograr esto junto con otras disciplinas ITIL como Gestión del Cambio y del Problema. Los datos de causa se derivan de los Incidentes que resolvemos colocando un código de causa en el momento de la resolución, el cual representa la mejor descripción o clasificación de porqué ocurrió el Incidente en primer lugar. Podemos utilizar ésto para ayudar a reducir el número de Incidentes que ocurren. Por ejemplo: Causas expresadas mediante un gráfico circular de Incidentes resueltos. Mostrar las causas desglosadas por compañía. Informes que unen la categoría de Incidentes a la causa para ayudar a identificar tendencias. Dónde encontrar ésto en Serio: En SerioReports, agrupados en Cause Analysis (Análisis de la Causa). Datos de Rendimiento de Equipos y de Agentes Este tipo de datos es bastante introspectivo, pero muy útil. Incluye los Acuerdos del Nivel de Operación (Operational Level Agreements OLAs) y los Contratos de Soporte (Underpinning Contracts UCs), acuerdos de rendimiento que podría tener con equipos especializados que son parte de la provisión de servicio TI en general. Este tipo de datos es útil para identificar equipos y agentes con un bajo rendimiento. Este tipo de datos pueden producir simples pero poderosos Datos Claves de Rendimiento. Por ejemplo: Incidentes resueltos según Equipo o Agente Incidentes resueltos a tiempo según Equipo o Agente Porcentaje de resolución en el primer nivel (trataremos este punto en mayor profundidad más adelante en este Libro Blanco). Incidentes resueltos por los grupos de soporte de primera, segunda o tercera línea. Dónde encontrar ésto en Serio: En SerioReports, agrupados en Agent Peformance (Rendimiento de los Agentes). En SerioClient, vea Incident Resolution by Agent (Resolución de Incidentes según Agente). Datos de Rendimiento de los Suministradores La mayoría de los Centros de Servicio al Cliente usan suministradores externos para la provisión de servicios especializados, por ejemplo para reparar hardware defectuoso o
9 Page 9 proporcionar servicios de soporte para sistemas de software especializados. En algunos casos los contratos que existen para el suministro de estos servicios pueden costar cientos de miles de euros al año por lo que asegurar la obtención de la mejor relación calidad-precio es una consideración importante. Herramientas como Serio permiten gestionar sus relaciones con estos suministradores, y recoger informaciones estadísticas sobre los servicios que éstos proporcionan. Ejemplos: Incidentes resueltos por cada suministrador Puntualidad de las respuestas de los suministradores Resoluciones del suministrador logradas a tiempo Satisfacción del cliente con las acciones de los suministradores Dónde encontrar ésto en Serio: En SerioReports, agrupados en Supplier Reports (Informes de Suministradores). Datos de Incidentes Graves Un Incidente Grave es simplemente un Incidente con un impacto muy significativo en el negocio, y por supuesto la eliminación de Incidentes Graves es una de las metas de la Gestión de los Servicios de TI. Los datos de Incidentes Graves podrían incluir el número de tales Incidentes, las partes del negocio afectadas, y una discusión de la causa, el remedio y las acciones futuras que surgen tras cada Incidente. Datos de Disponibilidad y de Tiempo de Caída Para muchas organizaciones, hay ciertos sistemas y servicios que son esenciales (nosotros los llamaremos Servicios Críticos). Sus informes pueden incluir información sobre la Disponibilidad y el Tiempo de Caída de Sistemas Críticos. Ambos se expresan en términos del horario del Acuerdo de Nivel de Servicio (SLA). Con ésto quiero decir que consideramos Tiempo de Caída sólo el tiempo sin servicio que pasa durante las horas de operación acordadas. Los datos de Tiempo de Caída expresan la cantidad de horas que cada Sistema Crítico estaba no disponible, expresados directamente en horas y minutos, o como una figura que muestra las horas de producción perdidas. La Disponibilidad recoge los mismos datos, pero los expresa de manera diferente. Lo que podría expresarse como cuatro horas de Tiempo de Caída en un determinado mes se podría comparar al 99,8% de Disponibilidad. Dónde encontrar estos datos en Serio: Los informes de Disponibilidad y Tiempo de Caída se encuentran principalmente en SerioClient en Performance (Rendimiento). Véase los informes de Downtime (Tiempo de Caída) y de Availability (Disponibilidad). Puede leer más sobre estos informes en la ayuda de SerioClient.
10 Page 10 Indicadores Claves de Rendimiento importantes Los siguientes indicadores son algunos de los Indicadores Claves de Rendimiento estándares, ampliamente usados en la Gestión de los Servicios de TI. Ésto está incluido como definición y como recurso adicional de ideas para su repertorio de informes. Resolución en el Primer Nivel Si una de las metas de la Gestión de los Servicio de TI es prevenir que ocurran los Incidentes en primer lugar, la Resolución en el Primer Nivel es la rapidez con que se resuelven estos Incidentes cuando ocurren. La idea es simple. Un cliente tiene un problema y llama para notificar un Incidente. El agente del Centro de Servicio al Usuario toma los detalles y resuelve el problema inmediatamente antes de que la llamada finalice. La dificultad está en cómo medir ésto con exactitud y seguridad, y estará, hasta cierto punto, determinado por la herramienta ITSM que tenga, y cómo esté configurada. Algunas herramientas ITSM requieren que los Agentes indiquen una Resolución en el Primer Nivel. Serio, por ejemplo, permite este tipo de indicación pero también puede producir estadísticas de Resolución en el Primer Nivel por deducción mediante el recuento de Incidentes que cumplan estos criterios: Tiempo Medio Entre Fallos Registrado y resuelto por el mismo Agente, sin haber sido encargado a nadie más, y resuelto dentro de 30 minutos. Ésto se aplica más útilmente a clases de Elementos de Configuración (CI ), por ejemplo a un tipo específico de conmutador o servidor. Ésto es una medida de fiabilidad de un producto específico, aunque en mi carrera lo he visto aplicado a Elementos individuales. Tiempo Medio Entre Fallos (MTBF ) no es un término restringido a la Gestión de los Servicio de TI. También se usa en industrias como automoción y aviación para obtener una figura que represente el tiempo medio entre fallos de un componente determinado. El supuesto en el que se basa el cálculo es que un componente es reparado inmediatamente y restaurado al servicio. El cálculo de MTBF es simple. Seleccione una clase de Elementos de Configuración, elija una unidad de tiempo adecuada (por ejemplo, horas, días, o semanas) y calcule el tiempo medio entre fallos en esa unidad. No hace falta decir que debe tener claro qué significa fallo. Para MTBF ésto es normalmente un fallo crítico. Mi consejo en ésto es úselo con cuidado. Necesita tener un número de fallos significativos antes de llegar a una estadística representativa de MTBF. Recuerde que una media sin suficientes datos podría ser seriamente tergiversado por uno o dos datos de su muestra. La industria de la aviación, por ejemplo, está actualmente explorando otros caminos para medir la fiabilidad de sus componentes.
11 Page 11 Tiempo Medio de Reparación El Tiempo Medio de Reparación (MTTR ) es simplemente el tiempo medio necesario para reparar un Elemento de Configuración desde el fallo hasta su reparación, pero no necesariamente restaurado al servicio. Hay otra medida llamada Tiempo Medio de Caída. En esta figura está incluido todo el tiempo tomado para reparar, desplegar y restaurar al servicio el Elemento de Configuración. Otra vez mi consejo es usarlo con precaución, ya que se necesita recoger un gran número de muestras para llegar a una cifra significativa.
12 Page 12 Los Datos de Rendimiento y sus procesos de Gestión de Servicios TI están enlazados Vale la pena afirmar en esta ocasión lo que puede ser obvio: Los Datos Claves de Rendimiento que obtiene de su herramienta de Gestión de Servicios TI dependen de sus procesos de Gestión de Servicios TI. Como ejemplo, si no registra ningún Incidente no podrá producir informes que usen los datos de Incidentes, tales como informes de Datos de Entrada y Salida mencionados anteriormente. Si no tiene un proceso para gestionar a los suministradores a través de su herramienta ITSM, entonces la información sobre la Gestión de Suministradores podría ser difícil de obtener. El hecho inevitable es que todos los informes que saca de su herramienta ITSM se basan en los datos que se encuentran ahí, y dependen de la integridad de esos datos. Debido a que los Datos de Rendimiento y los procesos de la Gestión de los Servicios de TI están ligados, debería revisar sus informes periódicamente mientras que sus procesos ITSM evolucionan y maduran. Es casi cierto que su habilidad para extraer y usar significativamente los datos de rendimiento habrá mejorado. Ésta es una de las muchas razones por las que debería estar continuamente examinando, mejorando y refinando sus procesos de la Gestión de los Servicios de TI. Creando su primer Informe de Gestión de Servicios TI Si está creando un Informe de Gestión por primera vez (y particularmente si este informe circulará en su organización, por ejemplo a su supervisor/ director) permítame decir que es lo que su informe no debería ser: no debería ser unas páginas de gráficos y cifras de su herramienta ITSM grapadas y enviadas por correo interno. Por supuesto puede incluir este material, pero inclúyalo como apéndices y refiérase a él cuando lo necesite desde la parte principal de su informe. Su informe debería ser una interpretación, análisis y plan de acción (si está requerido) basados en los gráficos y cifras de su herramienta ITSM. Empiece por considerar quién será su audiencia. Para quién está escribiendo el informe? Asegúrese que lo expone en su informe, y téngalo en cuenta cuando lo escriba. Para qué es este informe? Existen necesidades específicas o temas urgentes a que el informe se deba dirigir? Define el intervalo entre informes. Va a crear el informe semanalmente o mensualmente? Es un informe extraordinario? Es bastante común realizar un informe ITSM semanal más corto y otro mensual más largo. Tras esto hay que considerar cuáles de los Datos de Rendimiento disponibles quiere utilizar. Haga una lista. Ésta luego se usará para escribir el informe. Si nunca antes ha escrito un Informe de Gestión, considere incluir los siguientes Datos Claves de Rendimiento.
13 Page 13 Datos de Entrada Datos sobre el número de Incidentes registrados. Considere expresar esto con algún tipo de gráfico, quizás con el número de resoluciones de Incidentes (véase más abajo). Quizás puede comentar la tendencia: las cifras crecen (malo) o decrecen (bueno)? Datos de Salida A veces es útil comparar éstos con los Datos de Entrada, y considerar si se está formando una acumulación de Incidentes no resueltos. Serio ofrece informes que comparan el número de Incidentes registrados cada semana con el número de Incidentes resueltos. Éstos pueden ser maneras efectivas de mostrar estos datos. Incidentes Graves Si tiene un procedimiento para Incidentes Graves, incluya un resumen de los Incidentes Graves relevantes Incluya al menos el número de Incidentes activos en el momento de escribir el informe Datos sobre la Puntualidad de la Respuesta y Resolución Si va a usar este tipo de datos, realmente debería estar activamente involucrado en la Gestión del Nivel de Servicio. Lo que quiere mostrar aquí es el rendimiento con respecto al objetivo por cada SLA que tiene. Serio tiene tanto los informes de gráfico como los informes de texto desglosados en diferentes caminos que muestran exactamente ésto. Datos sobre la encuesta de satisfacción del cliente En particular, comente la tendencia de los datos: está mejorando la percepción de los clientes? Incidentes Graves Si tiene un procedimiento para Incidentes Graves, incluya un resumen de los Incidentes Graves relevantes Por supuesto, mientras maduran sus procesos de la Gestión de los Servicios de TI, puede extender significativamente sus Datos Claves de Rendimiento a áreas tales como el informes sobre la Disponibilidad y el Tiempo de Caída. Como estructurar su informe de Gestión de Servicios TI: Ejemplo Hasta el momento hemos: Analizado porqué escribimos Informes de Gestión de Servicios TI Intentado clasificar y sugerir diferentes tipos de datos que se pueden usar como base para crear un informe Examinado la unión entre sus procesos de la Gestión de los Servicios de TI y procedimientos, y los datos que tiene disponibles para producir Informes de Gestión. Comentado qué es lo que necesita considerar cuando escribe un Informe de Gestión. Ahora podemos buscar una posible estructura para su informe. El ejemplo que sigue está basado en en el siguiente escenario:
14 Page 14 Es un informe mensual Es un resumen de Gestión de Servicios para altos ejecutivos de negocios Como previamente se ha comentado, su informe debería ser algo que usted escriba, con los datos y gráficos extraídos de la herramienta ITSM incluidos como apéndices y referidos en el informe. Titulo del Informe: Realizado para: Puntos claves: Revision mensual de la Service Desk Vicepresidente de Tecnología, Vicepresidente de Operaciones { En Puntos claves se incluye un resumen de 3 o 4 líneas con la información más importante del informe. Por ejemplo, si ha ocurrido un Incidente muy grave, o que no se ha perdido ninguna hora de producción en los Sistemas Críticos } Revisión del Servicio TI: Asuntos a tratar: Acciones futuras: Apéndice A: {En la revisión es donde se utiliza y se hace referencia a Los Datos Claves de Rendimiento incluidos en los apéndices, ayudando al lector a entender los detalles que contienen. Por ejemplo, podría decir que durante el mes se registraron 256 Incidentes, de los cuales 230 se resolvieron o el rendimiento con respecto al Acuerdo de Nivel de Servicio está por debajo de las expectativas, con la puntualidad de resoluciones en particular como motivo de preocupación como se muestra en el Apéndice B. } {Aquí es donde se extiende acerca de su Revisión, destacando los motivos de preocupación o elementos que requieran una investigación adicional.} {Aquí es donde se comenta cualquier acción correctiva a tomar que surja de los temas de la sección anterior Asuntos de tratar. Por ejemplo: El análisis de los datos de Causa identifica un número significativo de problemas de facilidad para acceder al sistema de cuentas comerciales. Una acción correctiva podría ser realizar cursos de formación adicional para los usuarios de esta aplicación. } {En este y en los otros Apéndices es donde los datos, gráficos e informes extraídos de la herramienta ITSM se pueden usar. Ya que se está haciendo referencia a ellos durante el texto, deberán ser más fáciles de entender por parte de la audiencia a la que van dirigidos.}
15 Page 15 Preguntas frecuentes P: Quién es la persona adecuada para realizar informes? R: La idea central de este Libro Blanco ha sido la de recoger los datos de su herramienta ITSM, considerar qué le dicen sobre los servicios y la infraestructura que está proporcionando, y realizar los ajustes necesarios como corresponde. Por lo tanto la mejor persona o personas para realizar estos informes son aquellos que tengan la habilidad de efectuar estas tareas: lo que significa los gestores de provisión de servicio TI. Podría ser que sus informes sean una colaboración, con secciones producidas por diferentes gestores; por ejemplo, el Gestor de Nivel de Servicio, el Gestor de Incidentes, el Gestor de Cambios y el Gestor de Provisión de Servicio. P: Mis equipos están demasiado ocupados para registrar cada Incidente de 60 segundos con los que tienen que tratar. Debo que preocuparme por el efecto que esto podría tener en mis informes? R: Sí, debe preocuparse. Sus informes no reflejarán la realidad, particularmente si hay un número significativo de tales Incidentes que están siendo manejados pero no registrados. Debería de registrar todos aquellos Incidentes. La mayoría de las herramientas ITSM permiten registrar Incidentes de manera rápida. En Serio, por ejemplo, puede usar Serio Alerts para registrar incidentes rápidamente. P: Mis empleados no están acostumbrados a tener informes sobre su rendimiento. Cómo puedo hacer esto menos controvertido? R: Mi consejo es dejar claro al personal qué se está midiendo. Por ejemplo, crear informes de muestra (con nombres ficticios) y mostrar a sus empleados qué es lo que usted verá. Considere hacer algunos o todos los informes disponibles para el personal, de manera que puedan revisar su propio rendimiento. En SerioClient, pueden revisar mucha información mirando en Performance (Rendimiento). Lo más importante es asegurarles que usted es suficientemente inteligente como para tomar en cuenta otros factores cuando mira a los datos brutos o no procesados de la herramienta ITSM. P: Los altos cargos de mi empresa, los cuales no trabajan directamente en TI, han especificado los datos que quieren ver en los informes. Sin embargo, no creo que estén preguntando por la información apropiada. Me puede dar un consejo? R: Negócielo con ellos, sin entrar en confrontación o ser condescendiente. Lo importante es que les dé un ejemplo de qué es lo que quiere proporcionarles, explicando porqué esto aumenta la información que pueden utilizar para tomar decisiones. P: Cómo puedo utilizar mis informes mejor para convencer a mis directores de que, como gestor implicado en la Gestión de los Servicios de TI, necesito más personal? Estamos sufriendo un bombardeo de problemas todo el tiempo. R: He estado tentado a decir por dónde empiezo! Una respuesta detallada va más allá del ámbito e intención de este documento, pero mi mejor consejo es el siguiente. Creo que debería empezar por examinar los datos que tiene, y decidir si realmente necesita más gente.
16 Page 16 En otras palabras, está usando eficazmente los recursos que ahora tiene? Hay problemas con la infraestructura TI que, una vez reparados, reduciría de golpe el número de Incidentes y Cambios con los que su personal tiene que hacer frente? Examine sus datos de Causa y Problema, y mire si hay algún indicio que sugiera cosas que usted pueda hacer, las cuales reducirán el número de Incidentes con los que tiene que tratar. Ésto podría suponer una inversión en tecnología más que en personal. A menudo es bastante sencillo conseguir una rentabilidad económica de la investigación cuando se están buscando soluciones desde esta perspectiva. Si no puede encontrar ningún modo de reducir el número de Incidentes, considere si está utilizando eficazmente a la gente que tiene. Eche un vistazo a la Resolución de Incidentes por Agente y por Equipo. Parece que hay algunos empleados trabajando por debajo de sus posibilidades? Tiene falta de algunas habilidades especializadas que causan el cuello de botella en la resolución de Incidentes? Esta falta de habilidades podría ser superada mediante formación adicional? Y lo más importante: están bien desarrollados sus procesos ITIL? Usa Gestión de Problemas para reducir pro-activamente Incidentes? Tiene un procedimiento de Gestión de Cambio, basado en un CMDB correcto? En conclusión: asegúrese de que necesita personal adicional antes de solicitarlo.

References: Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 Resolución 
 Resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución