Source: http://docplayer.es/487033-Universidad-simon-bolivar-decanato-de-estudios-profesionales-coordinacion-de-ingenieria-de-produccion-y-organizacion-empresarial.html
Timestamp: 2018-07-21 10:44:53+00:00

Document:
Gerardo Mora Cáceres
1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE PRODUCCIÓN Y ORGANIZACIÓN EMPRESARIAL ANÁLISIS Y PROPUESTA DE MEJORA DEL PROCESO DE GESTIÓN DE INCIDENTES DEL SERVICE DESK DE MERCANTIL SEGUROS Por: Gabriela Carolina Tueti Silva INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Producción Sartenejas, enero de 2010
2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE PRODUCCIÓN Y ORGANIZACIÓN EMPRESARIAL ANÁLISIS Y PROPUESTA DE MEJORA DEL PROCESO DE GESTIÓN DE INCIDENTES DEL SERVICE DESK DE MERCANTIL SEGUROS Por: Gabriela Carolina Tueti Silva Realizado con la asesoría de: Tutor Académico: Prof. Fernando Torre Tutor Industrial: Ing. Robert Díaz INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Producción Sartenejas, enero de 2010
4 ANÁLISIS Y PROPUESTA DE MEJORA DEL PROCESO DE GESTIÓN DE INCIDENTES DEL SERVICE DESK DE MERCANTIL SEGUROS Realizado por: Gabriela Carolina Tueti Silva RESUMEN Este informe presenta el estudio del proceso de Gestión de Incidentes del Service Desk (SD) o Escritorio de Servicios de Mercantil Seguros. El objetivo principal del proyecto fue elaborar una propuesta de mejora de este proceso, orientada a minimizar los tiempos de respuesta y aumentar la eficiencia y rentabilidad del mismo, así como los niveles de satisfacción de los usuarios. Para llevar a cabo este trabajo fue necesario en primer lugar hacer el levantamiento de información del proceso, en donde se definieron que las actividades realizadas en la Gestión de Incidentes del SD son: asignación, registro, solución, escalado y cierre de incidentes. Así mismo se midieron las variables vitales para determinar su rendimiento, identificando que las actividades críticas en donde se generan demoras y cuellos de botella son: registro, escalado y cierre. Se llevaron a cabo una serie de entrevistas a los analistas y especialistas del departamento, que permitieron determinar que las causas de estas demoras son: el volumen de solicitudes recibidas vía correo electrónico, la falta de definición de los acuerdos de nivel de servicio (SLA s) y acuerdos de nivel de operación (OLA s) con otras unidades que intervienen el proceso, así como la falta de compromiso del personal para hacer seguimiento a los incidentes escalados a otras unidades, entre otros. También se realizaron encuestas a los usuarios para determinar sus niveles de satisfacción con el servicio ofrecido por el SD, las cuales arrojaron resultados negativos debido a los altos niveles de negación del servicio y a los largos tiempo de respuesta en la solución de incidentes. Finalmente para solventar los problemas encontrados se propone el autoregistro de requerimientos, el cierre automático de incidentes y la definición de OLA s y SLA s; también se define un modelo mejorado para el proceso de Gestión de Incidentes del SD de Mercantil Seguros, así como un conjunto de métricas e indicadores que permiten evaluar el funcionamiento del mismo. Palabras Claves: incidente, solicitud de servicio, usuario, proceso, Service Desk. iv
5 AGRADECIMIENTOS A Dios por la vida, familia, salud, oportunidades y personas que colocó en mi camino, los cuales contribuyeron significativamente en la culminación de mis estudios de pregrado. A mis padres y hermano quienes me han brindado su apoyo incondicional a lo largo de toda mi vida. A la Universidad Simón Bolívar, la casa de estudios donde tuve la oportunidad de formarme como profesional y crecer como persona. A mi tutor académico Prof. Fernando Torre quien contribuyó y me guió en la elaboración de este trabajo. A mi tutor industrial Ing. Robert Díaz por la oportunidad, asesoría y conocimientos compartidos durante la elaboración del proyecto. A la Lic. Andrea Rosas quien contribuyó significativamente en el trabajo realizado y me apoyó durante toda su ejecución. Al equipo de trabajo del Service Desk de Mercantil Seguros por su apoyo en la elaboración del proyecto. Al grupo de profesores de la Universidad Simón Bolívar quienes contribuyeron en mi formación profesional y personal. A todos los buenos amigos que he tenido la oportunidad de conocer y cultivar a lo largo de la vida universitaria, quienes han sido y siguen siendo un gran apoyo y compañía en mi vida v
6 ÍNDICE GENERAL RESUMEN... IV AGRADECIMIENTOS... V ÍNDICE DE TABLAS... IX ÍNDICE DE FIGURAS... X LISTA DE ABREVIATURAS... XII GLOSARIO... XIII INTRODUCCIÓN... 1 CAPÍTULO 1. DESCRIPCIÓN DE LA EMPRESA DESCRIPCIÓN DE MERCANTIL SEGUROS MISIÓN Y VISIÓN DE MERCANTIL SEGUROS ESTRUCTURA ORGANIZACIONAL DE MERCANTIL SEGUROS GERENCIA DE CANALES VIRTUALES Y SOPORTE A USUARIOS UNIDAD DE CANALES VIRTUALES DEPARTAMENTO DE SERVICE DESK... 5 CAPÍTULO 2.MARCO TEÓRICO TECNOLOGÍA DE LA INFORMACIÓN CONCEPTO DE HELP DESK Y SERVICE DESK HELP DESK (HD) SERVICE DESK (SD) ESTRUCTURA ORGANIZACIONAL DEL SERVICE DESK SERVICE DESK CENTRALIZADO SERVICE DESK LOCAL O DISTRIBUIDO SERVICE DESK VIRTUAL ITIL vi
7 2.4.1 GESTIÓN DE PROBLEMAS GESTIÓN DE CONFIGURACIONES GESTIÓN DE CAMBIOS GESTIÓN DE ENTREGA GESTIÓN DE NIVELES DE SERVICIO GESTIÓN DE INCIDENTES Escalado Impacto, urgencia y prioridad CAPÍTULO 3. METODOLOGÍA FASE DE DEFINICIÓN FASE DE ANÁLISIS FASE DE MEJORAS FASE DE CONTROL CAPÍTULO 4 RESULTADOS FASE DE DEFINICIÓN CANALES PARA REPORTAR REQUERIMIENTOS REGISTRO RESOLUCIÓN DE INCIDENTE ESCALADO CIERRE DE TICKET REABRIR TICKET FASE DE MEDICIÓN ACTIVIDADES DEL PROCESO DE GESTIÓN DE INCIDENTES ENCUESTA FASE DE ANÁLISIS FASE DE MEJORAS PROPUESTAS DE MEJORAS Propuesta para disminuir volumen de llamadas y correos electrónicos vii
8 Propuesta para mejorar el registro de requerimientos Propuesta para mejorar el tiempo de cierre de ticket Propuesta para mejorar el tiempo de cierre de órdenes de servicio MODELO PROPUESTO DEL PROCESO DE GESTIÓN DE INCIDENTES Proceso de Gestión de Incidentes del SD Sub-proceso de escalado FASE DE CONTROL CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES REFERENCIAS BIBLIOGRÁFICAS APÉNDICE A. ENCUESTA DE SATISFACCIÓN APÉNDICE B. HERRAMIENTA UTILIZADA POR EL SERVICE DESK (SDTOOL) APÉNDICE C. CUADRO RESUMEN DE PROBLEMAS Y SOLUCIONES APÉNDICE D. TIEMPO DE CIERRE POR UNIDAD SOLUCIONADORA APÉNDICE E. FORMATO PARA EL LEVANTAMIENTO DE INFORMACIÓN APÉNDICE F. MANUALES viii
9 ÍNDICE DE TABLAS Tabla 2.1 Ejemplo de un sistema de codificación de prioridades.18 Tabla 3.1. Formato de medición de tiempo de asignación de correos..23 Tabla 3.2. Formato de medición de tiempo de registro de correos...23 Tabla 4.1 Requerimientos registrados por los diferentes canales.26 Tabla 4.2. Casos resueltos en los diferentes niveles de soporte 31 Tabla 4.3. Propuesta de indicadores..54 Tabla D.1 Tiempo de cierre por unidad solucionadora...70 ix
10 ÍNDICE DE FIGURAS Figura 1.1. Síntesis de estructura organizacional de Mercantil Seguros Figura 1.2. Síntesis de estructura organizacional de la Gerencia de Tecnología, Sistemas y Procesos Figura 2.1. Service Desk Centralizado Figura 2.3. Service Desk Virtual Figura 2.4. Marco de Publicaciones ITIL. Versión Figura 2.5. Escalado funcional de Incidente Figura 2.6. Proceso de Gestión de Incidente Figura 3.1. Metodología DMAMC Figura 4.1. Gráfico de volumen de arribos por los diferentes canales Figura 4.2. Distribución de llegada de correos durante el día Figura 4.3. Gráfico del promedio diario de Incidentes registrados de enero a octubre de Figura 4.4. Gráfico de promedio diario de Solicitudes de Servicio registradas de enero a octubre de Figura 4.5. Diagrama de flujo del proceso de Gestión de Incidentes Figura 4.6. Correos asignados a especialistas y analistas Figura 4.7. Tiempo de registro Analistas Figura 4.8 Tiempo de registro especialistas Figura 4.9 Tiempo para generar orden de servicio Figura Tiempo de solución de Incidentes y solicitudes de servicio Figura Pregunta 1 de encuesta Figura Pregunta 2 de encuesta Figura 4.13 Pregunta 3 de encuesta Figura Pregunta 4 de encuesta Figura Diagrama Causa y Efecto Figura Modelo de Service Desk Figura Diagrama de flujo del proceso propuesto de Gestión de Incidentes Figura Diagrama de flujo del proceso propuesto de escalado x
11 Figura A.1. Escritorio de trabajo SDTool Figura A.2. Apertura de Reporte SDTool Figura A.3. Consulta de Reporte SDTool Figura F.1 Diagrama de proceso para la reimpresión de cuadros póliza anulados Figura F.2 Ruta para ingresar a SQL Navegator Figura F. 3. Ventana de Oracle Logon Figura F.4 Nueva edición de SQL Figura F.5 Modificar status de cuadro póliza de anulado a vigente Figura F.6 Fecha de exclusión de la póliza Figura F.7 Borrar fecha de exclusión de la póliza Figura F.8 Ruta para ingresar a Rector Certificación Figura F.9 Ruta para reimpresión de cuadro póliza individual o colectiva que facture por certificado Figura F10. Seleccionar destinatario para impresión Figura F11. Ruta para la reimpresión de cuadro póliza colectiva que facture por póliza Figura F12. Seleccionar destinatario para impresión Figura F13. Ruta para verificar que cuadro póliza se encuentra en proceso Figura F14. Ruta para verificar que cuadro póliza se envió a la impresora indicada xi
12 LISTA DE ABREVIATURAS ACD HD Sistema de distribución automática de llamadas Help Desk o Escritorio de ayuda ITIL Information Technology Infrastructure Library o Biblioteca de Infraestructura de Tecnología de la Información OLA Operation Level Agreement o Acuerdo de Nivel de Operación SD Service Desk o Escritorio de Servicios SDTool Herramienta utilizada por el Service Desk SLA Service Level Agreement o Acuerdo de Nivel de Servicio TI Tecnología de la Información xii
13 GLOSARIO Acuerdo de Nivel de Operación (OLA por sus siglas en inglés Operation Level Agreement ): es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio. Acuerdo de Nivel de Servicio (SLA por sus siglas en inglés Service Level Agreement ): es un acuerdo suscrito entre cliente y proveedor donde se especifican los detalles de los servicios brindados. Debe tener definidos los siguientes aspectos: descripción, disponibilidad, niveles de calidad, tiempo, etc. Error: es un incidente o problema para el cual la causa raíz es conocida y para el cual se ha identificado una solución permanente o temporal. Escalado: cuando el SD no es capaz de resolver en primera instancia un incidente o una solicitud de servicio y debe recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad Impacto: es el grado de desviación sobre la operativa normal, en términos de número de usuarios o de procesos del negocio afectados por un incidente. Incidente: es un evento que no es parte de la operación estándar de un servicio y que causa, o puede causar una interrupción al servicio o una reducción en la calidad del mismo. Problema: es una condición identificada en múltiples incidentes que exhiben síntomas comunes, o de un solo Incidente importante del que se desconoce la causa raíz. Es una causa no conocida de uno o más incidentes. Solicitud de servicio: es una petición de un usuario que necesita soporte, suministro, información, asesoramiento o documentación, sin que sea un fallo de la infraestructura TI. Urgencia: es la demora aceptable para el usuario o el proceso del negocio, para resolver un incidente xiii
14 INTRODUCCIÓN Las Tecnologías de Información (TI) han cambiado la forma en la cual operan las organizaciones actuales. A través de su uso se logran importantes mejoras, pues automatizan los procesos operativos y suministran una plataforma de información necesaria para la toma de decisiones, pero lo más importante es que su implementación logra ventajas competitivas. El impacto creciente de la tecnología en los procesos de negocios obliga a las organizaciones a ofrecer un servicio de soporte de alta calidad tanto para la infraestructura de cómputo como para los usuarios. En este sentido el Service Desk (SD) es de mucha utilidad, pues su objetivo es constituirse como el punto único de contacto entre los usuarios y la organización TI. El SD de Mercantil Seguros tiene como propósito recibir y resolver incidentes que puedan causar una interrupción o reducción de la calidad de los servicios informáticos, tanto de usuarios internos como externos a nivel nacional de forma rápida y efectiva, además de hacer seguimiento a todas las solicitudes y mantener a los usuarios informados del estado de las mismas. Sin embargo se ha observado que en este departamento los tiempos de respuesta de solución de incidentes no son satisfactorios, por lo que se hace necesaria una revisión del proceso realizado. El presente proyecto tiene como objetivo estudiar, documentar, identificar y analizar los factores que influyen en el proceso de Gestión de Incidentes del SD de Mercantil Seguros, con la finalidad de optimizarlo, específicamente disminuyendo los tiempos de respuesta de la solución de incidentes y de esta forma aumentar los niveles de satisfacción de los usuarios. En el siguiente informe se describe brevemente la empresa y el departamento donde se realizó el proyecto de pasantía, así como los fundamentos teóricos de los temas relacionados con el proceso de Gestión de Incidentes del SD. También se presenta la metodología seguida
15 2 durante la elaboración del trabajo y finalmente se presenta el diagrama de flujo donde se definen todas las etapas del proceso, se analizan los resultados obtenidos de las variables medidas y las oportunidades de mejoras para solventar los problemas encontrados en el mismo, también se propone un modelo mejorado del proceso y un conjunto de métricas e indicadores que permiten evaluar su funcionamiento.
16 CAPÍTULO 1 DESCRIPCIÓN DE LA EMPRESA A continuación se presenta una breve descripción de la empresa, Mercantil Seguros, C.A., en la cual fue realizado este proyecto de pasantía. Se describirá la gerencia de Canales Virtuales y Soporte a Usuarios, en especial el departamento de Service Desk (SD) o Escritorio de Servicios. 1.1 Descripción de Mercantil Seguros Mercantil Seguros se describe como una empresa de seguros venezolana constituida en 1988, subsidiaria de Mercantil Servicios Financieros, la primera y más completa proveedora de servicios financieros en Venezuela, con un patrimonio de BsF millones (US$ millones), y presencia en diez países de América y Europa. [1] En el año 2002, Mercantil Seguros, se integra con Seguros Orinoco, empresa con más de 44 años de experiencia en el mercado de seguros, incrementando su capital a BsF. 15 millones 796 mil, reforzando su red de sucursales y agencias conformada por más de 35 puntos de atención en todo el territorio nacional. [1] Su sede principal se encuentra en el Edificio Mercantil Seguros en la Avenida Libertador con calle Isaías Látigo Chávez de Caracas, Venezuela. La empresa ofrece pólizas de seguros individuales y colectivos en los ramos de Vida, Accidentes Personales, Automóviles, bienes Patrimoniales y Salud Misión y visión de Mercantil Seguros La misión de Mercantil Seguros, es la siguiente: Ser la mejor aseguradora del país, y ofrecerle una gran variedad de productos y
17 4 servicios de alta calidad al mejor costo, así como la más eficiente respuesta. La empresa está orientada al crecimiento de sus servicios, enfocado principalmente al mercado masivo de productos específicos de Salud, Vida y Propiedades, así como también a la atención de las necesidades de seguros de las grandes corporaciones donde tiene una destacada trayectoria. Es una aseguradora que se distingue por tener un personal comprometido con todos sus valores dentro de la más elevada ética y responsabilidad. [1] Estructura organizacional de Mercantil Seguros Mercantil Seguros presenta un organigrama de varios niveles. En la Figura 1.1 se observa una síntesis del organigrama general de la empresa. Figura 1.1. Síntesis de estructura organizacional de Mercantil Seguros. [2] Dentro de la estructura organizacional de la Gerencia de Tecnología, Sistemas y Procesos se encuentra la Gerencia de Canales Virtuales y Soporte a Usuarios, donde se realizó el proyecto de pasantía. En la figura 1.2 se observa el organigrama de la Gerencia de Tecnología, Sistemas y Procesos.
18 5 Figura 1.2. Síntesis de estructura organizacional de la Gerencia de Tecnología, Sistemas y Procesos. [2] 1.2 Gerencia de Canales Virtuales y Soporte a Usuarios La Gerencia de Canales Virtuales y Soporte a Usuarios está conformada por la Unidad de Canales Virtuales y el Departamento de Service Desk (SD). [2] Unidad de Canales Virtuales Esta unidad tiene como misión la planificación y desarrollo de modelos de negocio basados en funciones y servicios factibles a través de los canales virtuales; con énfasis en el canal Internet. La Unidad de Canales Virtuales es la encargada de, vía Internet: consolidar la oferta de servicios, planificar y priorizar la construcción de servicios, vigilar la construcción de los servicios, coordinar los aspectos relativos al lanzamiento de los servicios, así como monitorear y generar cifras de desempeño de los servicios (objetivos de propagación, volumen de operaciones, impacto financiero, entre otros). [2] Departamento de Service Desk El presente proyecto se desarrolla específicamente en el departamento de Service Desk (SD) de Mercantil Seguros, que tiene como misión canalizar de manera efectiva y eficiente la solución de incidentes y problemas, según los acuerdos de servicios establecidos, prestando un servicio de
19 6 calidad. [3] Los objetivos del departamento de Service Desk son: [3] Registrar todos los detalles de incidentes y requerimiento de servicios, así como su categorización y priorización. Proveer una primera línea de investigación y diagnóstico. Resolver el mayor porcentaje de incidentes y requerimientos de servicios. Escalar incidentes y requerimientos de servicios. Mantener al usuario informado del progreso de su solicitud. Cerrar todos los incidentes resueltos, requerimientos de servicio y otras llamadas. Determinar niveles de satisfacción de los usuarios con los servicios prestados por el SD. El departamento de SD está conformado por un jefe de departamento, 5 analistas y 5 especialistas de Soporte Usuarios, a continuación se describen sus funciones: Jefe de departamento Es responsable de la operación del grupo de SD. Supervisa a los integrantes del SD, identificando los recursos necesarios y participando en la resolución de conflictos. Se asegura que el personal asignado disponga de las habilidades necesarias, reconociendo los requerimientos de formación del personal y propio en caso necesario. Entre sus responsabilidades se encuentran: asignación de turnos, distribución de casos, manejo de ausencias programadas (vacaciones, permisos) y no programadas (notificación de ausencias), desarrollo de competencias (cursos), manejo de relación con agentes solucionadores, medición de desempeño y atención entre otros. [3] Analistas: Atienden las llamadas de los usuarios y registran incidentes, peticiones y consultas que llegan por los canales establecidos. Resuelven consultas sencillas, tramitan peticiones y mantienen informado al usuario. En el caso de disponer de la capacidad necesaria, solucionan incidentes en primer nivel. [3]
20 7 Especialistas Registran incidentes que llegan al SD vía correo electrónico y son los responsables de diagnosticarlo, resolverlo o escalarlo, comprobarlo con el usuario y documentarlo. Constituyen la unidad solucionadora de Soporte a Usuarios. [3]
21 CAPÍTULO 2 MARCO TEÓRICO En este capítulo se explican los fundamentos teóricos de los temas relacionados con el proceso de Gestión de Incidentes del Service Desk (SD) o Escritorio de Servicios, para ello se empieza con la definición de la Tecnología de la Información (TI), se sigue explicando los conceptos de Help Desk (HD) o Escritorio de Ayuda y SD, objetivos y diferencias. Y por último se presentan las diferentes estructuras organizacionales que este último pueda tener. Adicionalmente se hace un breve resumen de ITIL ( Information Technology Infrastructure Library o Biblioteca de Infraestructura de Tecnología de la Información), haciendo énfasis en su libro de Soporte del Servicio y dado que el tema a tratar en el informe es el proceso de Gestión de Incidentes, se explica en detalle como ITIL lo describe. 2.1 Tecnología de la Información La información son los datos organizados en el contexto de un negocio. Se conoce como tecnología de información (TI) a la utilización de tecnología (específicamente computadoras) para el manejo y procesamiento de información, es decir la captura, transformación, almacenamiento, protección, y recuperación de ésta. [4] El departamento o equipo que dentro de una organización ejerce las funciones de TI se encarga de estudiar, diseñar, desarrollar, implementar y administrar los sistemas de información utilizados para el manejo de datos de toda la organización. Estos sistemas a su vez, comprenden aplicaciones (software) y equipos (hardware). [4] Los objetivos de una buena gestión de servicios TI son: proporcionar un servicio de calidad, aumentar la eficiencia, alinear los procesos de negocio y la infraestructura TI y reducir los riesgos [4] asociados a estos servicios.
22 9 2.2 Concepto de Help Desk y Service Desk Help Desk (HD) Un HD es un área en cualquier organización que ayuda a sus usuarios a encontrar respuesta a sus preguntas o soluciones a sus problemas. Estos usuarios son empleados de la misma organización que necesitan ayuda con respecto al software de sus computadoras, acceso a la red, problemas de impresión o cualquier otro problema técnico. [5] Los objetivos de HD son los siguientes: [6] Recibir los reportes realizados por los usuarios que solicitan un servicio de TI cuando: se interrumpe la operación normal de su trabajo, requieran soporte sobre el hardware y/o software instalado, requieran nuevos productos de hardware y/o software y necesiten asesoramiento sobre el funcionamiento y/o utilización de los recursos informáticos disponibles Escalar incidentes a los grupos especializados. Corroborar que la soluciones brindadas a los usuarios sean las más adecuadas Realizar estadísticas de los servicios proporcionados por el HD. Las mismas tienen como objetivo poder realizar un análisis de la actividad del área de informática que ayudará al mejoramiento del servicio. Planes de contingencia en caso de que un servicio así lo requiera. Control de los inventarios de software y hardware de la organización. Control de la base de datos de los usuarios. Administración de las licencias de software. Desarrollo de manuales de normas y procedimientos.
23 Service Desk (SD) El SD es el único punto de contacto entre los usuarios de la organización y la oficina de servicios de TI (también denominada comúnmente como gestión de servicios de TI). En su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio y adicionalmente, debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes. [4] Los principales objetivos del SD son: [6] Ser el único punto de contacto entre los usuarios y el departamento de TI. Facilitar la restauración normal del servicio dentro de los niveles y prioridades establecidas, minimizando el impacto al negocio. Identificar mejoras en los servicios prestados por el departamento de TI. Optimizar procesos y procedimientos que permitan reducir los tiempos de solución y el correcto escalado de los mismos. Detectar problemas y buscar la solución de éstos. Tener un control de los elementos de que sean parte de la infraestructura para detectar cualquier cambio que se haya generado. Implementar procedimientos de monitoreo y escalado relacionados con SLA s. Proporcionar a la administración, información y recomendaciones para la mejora del servicio. Analizando los conceptos y objetivos tanto de HD como de SD se puede establecer la siguiente diferencia: la operación del primero se limita a asegurarse de que se dispongan de los recursos humanos y tecnológicos que permitan satisfacer la demanda de los requerimientos reportados por los usuarios; mientras que las actividades del SD mas allá de satisfacer única y exclusivamente la demanda debe alinear los objetivos de los departamentos TI con los objetivos de la organización. [5]
24 Estructura organizacional del Service Desk Los modelos más comunes de estructuras de SD son: centralizados, locales o distribuidos y virtuales Service Desk centralizado En el SD centralizado todo el contacto con los usuarios se canaliza a través de una sola estructura central. Este tipo de estructura permite reducir costos, optimizar recursos y simplificar la gestión, sin embargo surgen importantes inconvenientes cuando los usuarios se encuentran en diversos emplazamientos geográficos: diferentes idiomas, productos y servicio; así como cuando se necesita dar servicios de mantenimiento "en sitio" (on-site). Un ejemplo de esta estructura se muestra en la figura 2.1. [8] Figura 2.1. Service Desk Centralizado [8] Service Desk local o distribuido El SD se divide en distintas ubicaciones, es por ello que esta es la estructura tradicional cuando se trata de empresas que ofrecen servicios en diferentes emplazamientos geográficos (ya sean ciudades, países o continentes). La deslocalización de los diferentes SD conlleva grandes problemas, tales como: mayor costo de inversión y mantenimiento; se complica la gestión y monitorización del servicio y se dificulta el flujo de datos y conocimiento entre las instancias, sin
25 12 embargo da al usuario una percepción más próxima del soporte recibido. Un ejemplo de esta estructura se muestra en la figura 2.2. [8] Figura 2.2. Service Desk Local o Distribuído [8] Service Desk virtual La ubicación del SD es inmaterial, ya que se usa tecnología de comunicación que hace que el usuario no note la localización remota del soporte. El principal objetivo del SD virtual es aprovechar las ventajas de su versión centralizada y distribuida. En un centro de servicios virtual el "conocimiento" está centralizado; se evitan duplicidades innecesarias con el consiguiente ahorro de costos y se puede ofrecer un "servicio local" sin incurrir en costos adicionales y la calidad del servicio es homogénea y consistente. Un ejemplo de esta estructura se muestra en la figura 2.3. [8]
26 13 Figura 2.3. Service Desk Virtual [8] La estructura de SD empleada por Mercantil Seguros es una combinación entre el modelo centralizado y el distribuido o local, debido a que la empresa cuenta con sucursales regionales en todo el territorio nacional poco a poco ha ido delegando responsabilidades del SD en los coordinadores regionales de cada una de las sucursales, sin embargo la mayoría de los incidentes y requerimientos de servicios son gestionados a través del SD ubicado en la sede principal de la empresa. 2.4 ITIL Existen muchos estándares y mejores prácticas para la gestión de servicios de TI, entre los que se encuentra el servicio de soporte ofrecido por el SD. Uno de los estándares más utilizados en el mundo es la Biblioteca de Infraestructura de Tecnología de la Información ITIL. [5]. La estructura básica de ITIL se ilustra en la Figura 2.4.
27 14 Figura 2.4. Marco de Publicaciones ITIL. Versión 2 [7] En la figura 2.4 se observan los siete libros que conforman la biblioteca de ITIL versión 2. Cada uno de estos libros se conecta con los otros seis, y hasta cierto punto se superponen. [5] El libro ITIL sobre Soporte del Servicio describe cómo los usuarios pueden tener acceso a los servicios adecuados para contribuir a su negocio. Este libro cubre los siguientes temas: [5] Escritorio de Servicios (Service Desk) Gestión de Incidentes Gestión de Problemas Gestión de Configuraciones Gestión de Cambios Gestión de Entrega ITIL también define los términos de incidente, problema, error conocido y solicitud de servicio según se indica a continuación: Un incidente es un evento que no es parte de la operación estándar de un servicio y que causa, o puede causar una interrupción al servicio o una reducción en la calidad del mismo.
28 15 Un problema es una condición identificada en múltiples incidentes que exhiben síntomas comunes, o de un solo Incidente importante del que se desconoce la causa raíz. Es una causa no conocida de uno o más incidentes. Un error conocido es un incidente o problema para el cual la causa raíz es conocida y para el cual se ha identificado una solución permanente o temporal. Una solicitud de servicio es una petición de un usuario que necesita soporte, suministro, información, asesoramiento o documentación, sin que sea un fallo de la infraestructura TI. A continuación se explica los temas tratados en el libro de ITIL de Soporte del Servicio, haciendo énfasis en la Gestión de Incidentes que es el tema a tratar en este informe Gestión de Problemas La Gestión de Problema investiga la infraestructura y toda la información disponible para identificar las causas de los incidentes que suceden con más frecuencia, para prevenirlos. Una vez que se identificaron las causas (errores conocidos), se decide si es necesario realizar mejoras permanentes en la infraestructura TI para prevenir nuevos incidentes. Esta mejora se hace emitiendo una Petición de Cambio. [5] Gestión de Configuraciones La Gestión de Configuraciones se encarga de realizar los cambios de infraestructura (estandarización y verificación del estado), de identificar los elementos de configuración (inventario, vínculos respectivos, verificación y registro), de reunir y gestionar la documentación de la infraestructura TI y de proporcionar esta información a todos los otros procesos. [5] Gestión de Cambios La Gestión de Cambios asume la tarea de implementar los cambios en la infraestructura TI de manera controlada. El objetivo del proceso es determinar los cambios necesarios y cómo deben implementarse para que produzcan el menor efecto adverso sobre los servicios TI, al mismo tiempo garantizar la correcta identificación de los cambios a través de una eficaz coordinación en toda la organización. Los cambios se realizan a partir del estado de las actividades monitorizadas por la Gestión de Configuraciones, a petición de la organización del cliente, de la Gestión de
29 16 Problemas entre otros. Los cambios se implementan siguiendo unos pasos específicos de definición, planificación, construcción y pruebas, aceptación, implementación y evaluación. [5] Gestión de Entrega Una entrega es un grupo de elementos de configuración que son probados e introducidos conjuntamente en el entorno en producción. El objetivo de la gestión de entrega es asegurar el correcto despliegue de las entregas, incluyendo integración, pruebas y almacenamiento. [5] Gestión de Niveles de Servicio Es el proceso de negociar, definir, medir, manejar y mejorar la calidad de los servicios TI a un coste aceptable. Esto se formaliza mediante: Acuerdo de Nivel de Servicio (SLA por sus siglas en inglés Service Level Agreement ): es un acuerdo suscrito entre cliente y proveedor donde se especifican los detalles de los servicios brindados. Debe tener definidos los siguientes aspectos: descripción, disponibilidad, niveles de calidad, tiempo, etc. [8] Acuerdo de Nivel de Operación (OLA por sus siglas en inglés Operation Level Agreement ): es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio. [6] Contratos de soporte (UC por sus siglas en inglés Underpinning Contract ): es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización TI. [8] Gestión de Incidentes El objetivo primordial del proceso de Gestión de Incidentes es restaurar el funcionamiento normal del servicio tan rápido como sea posible y minimizar el impacto negativo sobre la actividad del usuario, garantizando de este modo que se mantiene el más alto nivel de calidad y disponibilidad del servicio. [5] La terminología utilizada en la Gestión de Incidentes se explica a continuación:
30 Escalado Cuando el SD no es capaz de resolver en primera instancia un incidente o una solicitud de servicio y debe recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado. Existen dos tipos de escalado: Escalado funcional: cuando se requiere a un especialista de más alto nivel, a causa de la necesidad de un mayor conocimiento para solventar un incidente o prestar un servicio. [8] En la figura 2.5 se muestra el proceso de escalado funcional Figura 2.5. Escalado funcional de Incidente [6]
31 18 Escalado jerárquico: cuando se debe acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel. [8] Impacto, urgencia y prioridad Cuando se atienden muchos incidentes al mismo tiempo, se deben establecer prioridades. El SD debe asignar la prioridad consultando con el usuario y de acuerdo con las disposiciones del SLA se determina el orden en que deben tratarse los incidentes. Para hacer una evaluación objetiva se deben considerar los siguientes criterios: Impacto del incidente: es el grado de desviación sobre la operativa normal, en términos de número de usuarios o de procesos del negocio afectados. [6] Urgencia del incidente: es la demora aceptable para el usuario o el proceso del negocio, para resolver un incidente. [6] El impacto y la urgencia pueden combinarse en una matriz como la que se muestra en la tabla 2.1, para determinar la prioridad del incidente. Tabla 2.1 Ejemplo de un sistema de codificación de prioridades. [5] Proceso de Gestión de Incidentes Las actividades del proceso de Gestión de Incidentes propuestas por ITIL son: [5]
32 19 Admisión y registro del incidente: cuando el incidente es detectado o informado por el usuario se crea un registro del mismo. Clasificación y soporte inicial: el incidente se codifica por tipo, estado, impacto, urgencia, prioridad, SLA, etc. Si es una petición de servicio, se inicia el proceso correspondiente. Comparación: se investiga si el incidente es conocido, y si se relaciona con un incidente existente, un problema o error conocido, y si existe una solución o trabajo relacionado en curso. Investigación y diagnóstico: si no hay una solución conocida, se investiga el incidente. Resolución y recuperación: una vez que se encuentre una solución, se resuelve el incidente. Cierre: se pregunta al usuario si está satisfecho con la solución y se cierra el incidente. Monitorización y seguimiento del progreso: se monitoriza el ciclo entero del incidente, y si el SD considera que no puede resolver el incidente se continúa con el escalado. En la figura 2.6 se muestra el diagrama de flujo del proceso de Gestión de Incidentes propuesto por ITIL.
33 Figura 2.6. Proceso de Gestión de Incidente [5] 20
34 CAPÍTULO 3 METODOLOGÍA El estudio y elaboración de todo proyecto requiere una organización previa de las fases o etapas necesarias para cumplir con el objetivo final. Para llevar a cabo las propuestas de mejoras del proceso de Gestión de Incidentes del Service Desk (SD) o Escritorio de Servicios de Mercantil Seguros, se siguió la metodología llamada DMAMC, la cual consta de cinco fases. Las fases que comprende la metodología DMAMC son: definición, medición, análisis, mejora y control, las cuales se muestran en la figura 3.1. Figura 3.1. Metodología DMAMC [8] 3.1 Fase de definición Durante esta primera etapa se identificaron los fundamentos y objetivos planteados en el proyecto, además de conocer el área, procesos y personal con el que está relacionado. Se recopiló toda la información y documentos involucrados con el proceso en estudio y en este caso se realizó la investigación referente al tema de SD, específicamente al marco de referencia ITIL (Biblioteca de Infraestructura de Tecnología de la Información). Se realizaron entrevistas al personal del SD y se analizaron documentos disponibles en la empresa referentes al tema en estudio, entre estos se encuentran: documentos que describen las funciones y objetivos del departamento, informes de auditorías y trabajos relacionados con el proceso de Gestión de Incidentes. También con la información obtenida, se hace una descripción detallada de las actividades
35 22 realizadas en el proceso de Gestión de Incidentes, así como se define su diagrama de flujo. 3.2 Fase de medición Luego de tener un conocimiento general del proceso, del funcionamiento del SD y tener noción de los posibles problemas del mismo, se procedió a definir las variables y recolectar la información que permitieron medirlas. Para determinar las actividades críticas del proceso en donde se generan las mayores demoras de tiempo, se midieron los tiempos de respuesta de cada una de las actividades del mismo. A fin de medir estos tiempos se seleccionaron las siguientes muestras: Todos los casos registrados en el mes de agosto, que representa una muestra de 2017 casos. Una muestra de 400 correos, que representa aproximadamente un 27% de los correos que recibe el SD mensualmente. Una muestra de 60 usuarios, que representa un 10% de los usuarios del SD, a los cuales se le realizó una encuesta de satisfacción (ver apéndice A). Los tiempos después de que los casos son registrados en el sistema quedan grabados en el SDTool, que es la herramienta utilizada por el SD para la Gestión de Incidentes (ver apéndice B), es por ello que esos datos fueron extraídos de las matrices de detalle órdenes de servicios y detalle casos registrados del mes de agosto, arrojadas por dicha herramienta. El tiempo desde que los usuarios envían un requerimiento vía correo electrónico hasta que éstos son cargados en el sistemas no quedan registrados, por esta razón para lo obtención de estos datos se diseñaron dos formatos uno para determinar el tiempo de asignación de correo y otro para determinar el tiempo de registro de correos. El primero de ellos fue entregado al analista encargado de la asignación (tabla 3.1) y el segundo fue entregado a todos los analistas y especialistas del SD (tabla 3.2), los cuales llenaron dicho formato por un tiempo de una semana.
36 23 Fecha de llegada Tabla 3.1. Formato de medición de tiempo de asignación de correos. Hora de Fecha de Hora de llegada asignación asignación Analista/especialista Nuevo/seguimiento Tabla 3.2. Formato de medición de tiempo de registro de correos. Fecha de Hora de Fecha de Hora de Ticket asignación asignación Registro Registro En el proceso de atención de llamadas el departamento no cuenta con un Sistema de Distribución Automática de llamadas (ACD), que permita evaluar el comportamiento y distribución de las llamadas telefónicas, midiendo la cantidad de llamadas entrantes, salientes, desbordadas y abandonadas, así como el tiempo de conversación y la efectividad del servicio. Por esta razón para evaluar el comportamiento de este proceso se realizó una encuesta a los usuarios del SD, la cual busca determinar: Nivel de satisfacción de los usuarios con el servicio de atención telefónica que brinda el SD. Cuántas veces los usuarios intentan llamar antes de ser atendidos por un especialista del SD. Tiempos de espera para ser atendidos por un analista del SD. Si la información suministrada por los analistas del SD es de utilidad para el usuario. Con los resultados de los tiempos medidos se identificaron las actividades en donde se generan las mayores demoras en el proceso. 3.3 Fase de análisis Luego de identificar las actividades críticas del proceso en donde se generan las mayores demoras se procedió a determinar las causas de las mismas, para lo cual se realizaron reuniones con el personal de SD, en donde se presentaron los resultados de la etapa anterior y se utilizó la
37 24 técnica de los cinco por qué, en la que se define un problema como una cadena de causas y efecto preguntando por qué, idealmente cinco veces [9]. Posteriormente con la información obtenida en estas reuniones se elaboró un diagrama causa- efecto que sirvió como base para la elaboración de las propuestas de mejoras ya que permitió ubicar, visualizar y estructurar las causas de los problemas. 3.4 Fase de mejoras Al finalizar el análisis se procedió a buscar las posibles soluciones de las demoras detectadas en el proceso. Para ello se utilizó la técnica de una lluvia de ideas donde se evaluaron diversos planteamientos que buscaran solucionar los problemas más importantes encontrados y con ellos sus causas raíces. Paralelamente se iba realizando la matriz de posibles soluciones, que reuniría y consolidaría las mismas (ver apéndice C). Por último se evaluaron y seleccionaron las mejores soluciones, las cuales se explican en los resultados. También se realizó la redefinición del proceso de Gestión de Incidentes basada en el proceso que recomienda ITIL, describiendo las entradas y salidas de cada una de las actividades del mismo. 3.5 Fase de control En esta fase se diseñaron un conjunto de indicadores que permitirán evaluar el desempeño del proceso. El departamento de SD será el encargado de hacer el seguimiento pertinente a los indicadores propuestos, garantizando la culminación del ciclo DMAMC.
38 CAPÍTULO 4 RESULTADOS En este capítulo se presentan los resultados obtenidos, se comienza definiendo el proceso de Gestión de Incidentes del Service Desk (SD) o Centro de Servicios de Mercantil Seguros estableciendo la definición de sus actividades y su diagrama de flujo. Después se presentan las mediciones de los tiempos de respuesta de cada una de ellas. Y por último en base al análisis de los resultados obtenidos se elaboran las propuestas de mejoras, un modelo optimizado del proceso de Gestión de Incidentes, así como un conjunto de indicadores que permiten evaluar su funcionamiento. 4.1 Fase de definición Al iniciar el proyecto se encontró que los analistas y especialista manejan diversas definiciones de las actividades del proceso y de la secuencia en que estas deben realizase, por lo que fue necesario el levantamiento de la información requerida para unificar criterios en relación a dichos conceptos y a partir de allí estructurar su diagrama de flujo. A continuación se presenta la descripción de las actividades y diagrama de flujo del proceso de Gestión de Incidentes recibidos por correo electrónico y vía telefónica Canales para reportar requerimientos Los canales por los que llegan los requerimientos de los usuarios al SD de Mercantil Seguros son: Correos electrónico personal: los usuarios envían requerimientos directamente a correo personal de los analistas y especialistas del SD Correo electrónico del SD: usuarios envían requerimientos al correo genérico de SD.
39 26 Personal: usuarios que realizan requerimiento personalmente en el SD. Vía telefónica: el SD cuenta con dos extensiones telefónicas. Una extensión de atención inmediata para todos los usuarios y una de atención exclusiva para las unidades críticas Para medir el volumen de arribos de requerimientos por los distintos canales se tomó como muestra los meses de enero hasta octubre de 2009 de la matriz de detalle de casos registrados arrojada por la herramienta SDTool. En la figura 4.1 y tabla 4.1 se observan estos resultados. Tabla 4.1 Requerimientos registrados por los diferentes canales de enero a octubre de 2009 Canales Solicitudes registradas Correo electrónico personal 397 Correo electrónico del SD Personal 197 Teléfono Figura 4.1. Gráfico de volumen de arribos por los diferentes canales En el gráfico de la figura 4.1 se observa que del total de los requerimientos el 44% llega vía correo electrónico del SD, el 54% llega vía telefónica y que el porcentaje de requerimientos recibidos vía personal y correo electrónico personal, tanto de analistas como de especialistas, no son significativos, por lo que no se consideran en el estudio realizado.
40 27 Recepción de solicitudes vía correo electrónico. Los correos electrónicos enviados por los usuarios llegan a una bandeja de entrada genérica del departamento de SD, en donde un analista lee y analiza cada uno de estos y dependiendo de la solicitud del usuario lo asigna a otro analista o especialista. Si el correo es para solicitar información acerca de un ticket ya abierto, éste se asignará al analista o especialista responsable. En la figura 4.2 se observa cómo se distribuye la llegada de correos electrónicos durante el día % mas Horas Figura 4.2. Distribución de llegada de correos durante el día Las horas del día en la que el volumen de arribos de correos es mayor son: en la mañana: de 9 a 11 y en la tarde de 2 a 4. Estas son las horas en las que el personal del SD debe estar más atento para el registro y solución de incidentes y solicitudes de servicio. En esta etapa del proceso también se hizo una primera clasificación de los correos para conocer el porcentaje que son para hacer seguimiento a un requerimiento ya hecho y el porcentaje de correos para hacer nuevos requerimientos, dando como resultado que el 40% de los correos que llegan a la bandeja de entrada del SD corresponden al primer grupo. Recepción de solicitudes vía telefónica. Las solicitudes recibidas vía telefónica son registradas por los analistas inmediatamente mientras están en línea con el usuario.
41 Registro El analista o especialista analiza la solicitud hecha por el usuario y procede a registrarla en la herramienta utilizada por el departamento (llenando la información necesaria para el registro, ver apéndice B), generando un número de ticket. Automáticamente el sistema envía al usuario un correo electrónico con el número de ticket de su solicitud, para que éste le pueda hacer seguimiento. A continuación se hace una breve descripción de la clasificación de los incidentes y solicitudes de servicio según su fuente, realizada en la actividad de registro. Aplicaciones de negocio: son aquellos programas propietarios utilizados por los empleados puedan realizar sus operaciones diarias y de esta manera cumplir con los diferentes servicios que ofrece la compañía de seguros Aplicaciones de oficina: son los diferentes programas utilitarios que son utilizados por los empleados para el procesamiento de datos (Word, Access, Excel, Sql, etc) Aplicaciones web: diferentes aplicaciones web que han sido desarrolladas para el uso de productores, proveedores y clientes. Equipos periféricos: se refiere a todos los equipos accesorios a los equipos de computación, (Pc, impresoras, video beam, scanner, etc). Redes: se refiere a todas las Incidentes y solicitudes de servicio relacionadas con fallas de conexión e inconvenientes generales con la red. Seguridad: es todo lo relacionado a seguridad de la información, como cambio de contraseña, acceso a aplicaciones, autorizaciones, políticas a nivel de equipos, entre otros. Servicios: se refiere a servicios especiales como mudanzas de equipos, respaldo y recuperación de archivos entre otros. Telefónica: es todo lo relacionado con líneas telefónicas y claves de teléfono. El número de casos registrados mensualmente por el SD de Mercantil Seguros es
42 29 aproximadamente de 3192, de los cuales 1434 son recibidos vía correo electrónico y 1758 vía telefónica, estos datos fueron obtenidos de las estadísticas arrojadas por la herramienta SDTool de los meses de enero hasta agosto de Otro dato importante para el estudio de esta actividad es el promedio diario de incidentes y solicitudes de servicio registrados por los analistas y especialistas del SD. Los valores obtenidos corresponden a los meses de enero a octubre del año 2009, de la matriz de detalle de casos registrados arrojada por la herramienta SDTool. En la figura 4.3 y 4.4 se muestran estos resultados. Figura 4.3. Gráfico del promedio diario de Incidentes registrados de enero a octubre de 2009 En el gráfico de la figura 4.3, se observa que el promedio diario de incidentes registrado es de 62 casos.
43 30 Figura 4.4. Gráfico de promedio diario de Solicitudes de servicio registradas de enero a octubre de 2009 En el gráfico de la figura 4.4, se observa que el promedio diario de solicitudes de servicio registradas es de 118 casos, que es aproximadamente el doble de los incidentes reportados en el mismo período de tiempo. El aumento, tanto en el registro de incidentes como en el de solicitudes de servicio a partir del mes de agosto se debe a un evento excepcional específico que es la migración del sistema rector, una de las aplicaciones más usadas por la empresa, a una nueva plataforma tecnológica Resolución de incidente El analista o especialista genera bitácoras, en donde quedan registradas las acciones realizadas para llegar a la solución del incidente o la prestación del servicio solicitado Escalado En este punto es necesario definir los diferentes participantes en el proceso de Gestión de Incidentes, los cuales se describen a continuación: Usuario: reporta incidente o solicitud de servicio. Primer nivel de soporte: primer punto de contacto del usuario al momento de reportar algún incidente o solicitud de servicio. En este caso son los analistas del SD.
44 31 Segundo nivel de soporte: está conformado por la unidad solucionadora de Soporte a Usuario. En este caso son los especialistas del SD. Tercer nivel de soporte: está conformado por el resto de unidades solucionadoras. Cuarto nivel de soporte: conformado por proveedores externos. Si el analista o primer nivel de soporte no puede solucionar el incidente o prestar el servicio que solicita el usuario, se escala el ticket a otra unidad que lo pueda hacer. Para escalar un ticket del SD a otro nivel de soporte se debe generar una orden de servicio a la unidad requerida, enviando automáticamente un correo electrónico con el número de ticket y número de orden asociada al mismo. Dado que uno de los objetivos del SD explicados en el marco teórico es tratar de resolver el mayor porcentaje de incidentes y solicitudes de servicio sin tener que escalarlos a otras unidades, en la tabla 4.2 se muestra el porcentaje de casos que: son atendidos y resueltos por los analistas (primer nivel de soporte), los que son escalados a la unidad solucionadora de Soporte a Usuario que forma parte del SD (segundo nivel de soporte) y los que son escalados a otras unidades solucionadoras y proveedores externos (tercer y cuarto nivel de soporte). Los datos fueron obtenidos de las estadísticas arrojadas por la herramienta SDTool de los meses de enero a octubre del año Tabla 4.2. Casos resueltos en los diferentes niveles de soporte % de casos Nivel de soporte resueltos Analistas (primer nivel de soporte) 55 Especialistas (segundo nivel de soporte) 14 Unidades solucionadoras (tercer y cuarto nivel de soporte) 31 En la tabla anterior se observa que 69% de los incidentes y solicitudes de servicio son atendidos y resueltos por el SD, el resto se escalan a otros niveles de soporte, ya que técnicamente el departamento no puede atender estos casos, en consecuencia esta cifra es aceptable aunque se puede mejorar.
45 Cierre de Ticket Al resolverse el incidente en cualquier nivel de soporte, el especialista y analista de SD debe cerrar el ticket asociado al incidente. Al cerrar el ticket se envía automáticamente un correo al usuario indicándole que su solicitud fue atendida y resuelta Reabrir ticket El analista o especialista del SD verifica que la solicitud no tenga un ticket asociado. Si tiene ticket abierto se genera una bitácora con la información del correo, y si el ticket está cerrado se reapertura y se genera bitácora. A continuación en la figura 4.5 se muestra el diagrama de flujo del Proceso de Gestión de Incidentes elaborado según los conceptos definidos anteriormente.
46 Figura 4.5. Diagrama de flujo del proceso de Gestión de Incidentes. 33
47 Fase de medición Actividades del proceso de Gestión de Incidentes Para determinar las actividades críticas del proceso en donde se generan las mayores demoras, se midieron los tiempos de respuesta de cada una de las mismas. A continuación se explican los resultados obtenidos. Asignación de correos En la figura 4.6 se muestra el porcentaje de correos que son asignados a especialistas y a analistas. Figura 4.6. Correos asignados a especialistas y analistas El 47% de los correos son asignados a los analistas (primer nivel de soporte), y el resto son asignados a los especialistas (segundo nivel de soporte). Al medir el tiempo de asignación de correo, es decir el tiempo desde que llega el correo a la bandeja de entrada del SD hasta que es asignado a un especialista o analista, se obtuvo que el 61% de los correos son asignados en menos de 20 minutos después de haber llegado a la bandeja de entrada del SD, con un tiempo promedio de asignación de 22 minutos. Registro Para el estudio del tiempo de respuesta de esta actividad, el registro de requerimientos se dividió en dos: registro analistas y registro especialistas.
48 35 o Registro analistas De los correos asignados a los analistas el 70% son registrados y escalados por el analista destinado para ello y el 30% restante es atendido por los otros analistas. Al medir el tiempo de registro, es decir el tiempo desde que se asigna el correo hasta que es registrado en el SDTool se obtiene los resultados mostrados en la figura 4.7. % Más de 4 Días Figura 4.7. Tiempo de registro Analistas En la figura 4.7 se observa que el 82% de los correos asignados al primer nivel de soporte se registran el mismo día que se asignan, al hacer el estudio de estos correos, se tiene que son registrados con un tiempo promedio de 1,8 horas. El registro de solicitudes recibidas por el SD vía telefónica se debe hacer inmediatamente en línea con el usuario, sin embargo como se explicó anteriormente no se cuenta con un Sistema de Distribución Automática de llamadas (ACD) que permita medir el porcentaje de éstas que son registradas en el SDTool y se observa que el registro de solicitudes recibidas por esta vía no se realiza de forma ordenada y consistente. Los analistas no registran todos los casos que atienden por este canal, y debido a que estas llamadas no quedan registradas en ningún sistema es imposible hacer una evaluación cuantitativa de esta inconsistencia, sin embargo como producto de la observación realizada con los analistas se determina que el orden de llamadas no registradas es de aproximadamente 20% que representan 352 llamadas mensuales. o Registro especialistas En la figura 4.8 se observa que de los correos asignados a los especialistas solo el 39% son
49 36 registrados el mismo día que se asignan % Más de 4 Días 3 Figura 4.8 Tiempo de registro especialistas Una de las mayores demoras del proceso se encuentra en esta actividad, ya que el 61% de los correos asignados al segundo nivel de soporte son registrados en un lapso de tiempo de dos a cuatro días. Escalado En esta actividad se midió el tiempo desde que se registra la solicitud y se le asigna un número de ticket hasta que se le genera una orden de servicio (a aquellas solicitudes que requieren ser escaladas), a este tiempo se le llamó tiempo para generar orden de servicio. La figura 4.9 muestra los tiempos medidos en el proceso para generar una orden de servicio % más de 4 Día Figura 4.9 Tiempo para generar orden de servicio El 86% de los tickets registrados que requieren ser escalos se le genera inmediatamente una orden de servicio.
50 37 También se midió el tiempo de cierre de orden de servicio, que es el tiempo desde que se genera la orden hasta que la unidad solucionadora la cierra y que en teoría debería ser el tiempo empleado por la unidad solucionadora en solucionar el incidente. Este tiempo fue medido por separado para cada unidad y los resultados se pueden observar en el apéndice D. El tiempo promedio de cierre de orden de servicio de todas las unidades solucionadoras es de 140 horas hábiles o aproximadamente 18 días, lo que indica que en esta actividad ocurre la segunda demora del proceso. Cierre El tiempo de cierre de ticket se definió como el tiempo desde que se cierran todas las órdenes de servicio asociadas a un ticket hasta que el analista o especialista cierra el ticket asociado al incidente. Para el estudio de este tiempo, esta variable se dividió en dos: o Tiempo de cierre de tickets escalados a la unidad solucionadora de Soporte a Usuarios (segundo nivel de soporte): el 70% de los tickets escalados a la unidad de Soporte a Usuarios son cerrados inmediatamente después que son cerradas todas las órdenes de servicio asociadas al ticket, con un tiempo promedio de 14 horas hábiles, es decir aproximadamente 2 días hábiles. o Tiempo de cierre de tickets escalados a otras unidades solucionadoras (tercer y cuarto nivel de soporte): el 64% de los tickets escalados a un tercer y cuarto nivel de soporte son cerrados dos o más días después que son cerradas todas las órdenes de servicio asociadas al ticket, con un tiempo promedio de 49 horas hábiles, es decir aproximadamente 6 días. Debido a este retraso en esta actividad se encuentra la tercera demora significativa del proceso. En la figura 4.10 están representados los tiempos promedio de solución (tiempo desde que es registrado el requerimiento y generado número de ticket hasta que es cerrado el ticket), de incidentes y solicitudes de servicio de acuerdo a su clasificación según su fuente. Los tiempos están representados en horas hábiles, es decir un día tiene ocho horas, por lo que 24 horas representan 3 días.
51 Aplicaciones del negocio Aplicaciones de oficina Aplicaciones Web Equipos periféricos Redes Seguridad Servicios Telefónica Incidentes Solicitudes de Servicio Figura Tiempo de solución de Incidentes y solicitudes de servicio Debido a las demoras encontradas en las actividades de escalado y cierre, en la figura 4.10 se observa que los tiempos de solución de incidentes y solicitudes de servicios son muy largos Encuesta Para conocer los niveles de satisfacción de los usuarios con respecto al proceso de Gestión de Incidentes reportados vía telefónica se realizó una encuesta. Los resultados de ésta se muestran a continuación. Número de veces que usuarios intentan llamar al SD antes de ser atendidos. En la figura 4.11 se observa que de los usuarios encuestados, 54% tienen que llamar entre dos y tres veces antes de ser atendidos por un analista de SD, 22% tienen que llamar más de cuatro veces antes de ser atendidos y solo un 14% es atendido en la primera llamada.
52 39 Figura Pregunta 1 de encuesta Es importante destacar que el 61% de las personas encuestadas tienen que llamar más de tres veces para ser atendidas por un analista, lo que indica altos niveles de negación de este servicio a los usuarios. Tiempo de espera en línea antes de ser atendido por analista de SD En la figura 4.12 se observa que de los usuarios encuestados 64% tienen que esperar entre uno y cinco minutos en línea antes de ser atendidos por un analista de SD % min2-5 min 5-10 min min 6 Más de 15 min Figura Pregunta 2 de encuesta Percepción del usuario sobre el servicio de soporte ofrecido por SD.
53 40 En la figura 4.13 se observa que de los usuarios encuestados 68% piensan que el servicio prestado por la extensión telefónica de SD es bueno o muy bueno, mientras que solo un 25% piensa que es deficiente % Excelente Muy Bueno 0 Bueno Deficiente Muy deficiente Figura 4.13 Pregunta 3 de encuesta Si la información suministrada por el analista de SD es de utilidad para solventar el requerimiento planteado. En la figura 4.14 se observa que de los usuarios encuestados al 80% siempre o casi siempre la información suministrada por los analistas de SD les ayuda a solventar su requerimiento.
54 % Siempre Casi siempre A veces 0 Nunca Figura Pregunta 4 de encuesta 4.3 Fase de análisis El análisis de los resultados se lleva a cabo con la participación del personal del departamento de SD mediante la realización de reuniones en donde se le presentaron a los analistas y especialistas los resultados obtenidos de la fase anterior y ellos expresaron sus ideas sobre cuáles podrían ser las posibles causas de las demoras de tiempo y problemas encontrados en el proceso de Gestión de Incidentes. Basado en esta sesión se construyó un diagrama causa y efecto que se muestra en la figura 4.15
55 Figura Diagrama Causa y Efecto 42
56 43 A continuación se explican los problemas encontrados en las actividades críticas del proceso derivadas de la fase anterior, así como las posibles causas que generan estos problemas y las demoras de tiempo en dichas actividades. Registro o Demora de entre dos a cuatro días en el registro de requerimientos recibidos vía correo electrónico debido al gran volumen de requerimientos que llegan por esta vía. o No se registran de forma ordenada y consistente las solicitudes recibidas vía telefónica. Se encontró que aún cuando los analistas cuentan con los mecanismos para realizar el registro de requerimientos en línea con el usuario no tienen el compromiso para realizar esta actividad. o No se cuenta con un sistema de Distribución Automática de Llamadas (ACD) que permita llevar un control del número de llamadas entrantes, atendidas y abandonadas, así como comparar el número de las atendidas con las registradas por los analistas. Escalado o Demoras en el cierre de órdenes de servicio por parte de las unidades solucionadoras de aproximadamente 18 días, esto se debe a que no están definidos los acuerdos de nivel de servicio (SLA s) y los acuerdos de nivel de operación (OLA s) para los servicios prestados por estas unidades, por lo que éstas no están obligadas a cerrar las órdenes de servicio en un lapso de tiempo establecido. o Otra causa de la demora en el cierre de órdenes de servicio es la falta de seguimiento a los tickets escalado por parte de los analistas y especialistas del SD. Cierre de tickets o Después de que se cierran todas las órdenes de servicio asociadas a un ticket, existe una demora de aproximadamente 6 días en el cierre de éste, esto se debe a la falta de seguimiento a los tickets escalado por parte de los analistas y especialistas del SD. Además de las actividades críticas, también se identificaron otros problemas:
57 44 Los usuarios se sienten desinformados acerca del estado de su solicitud, por lo que gran porcentaje de las llamadas y correos recibidos por el SD son para hacerle seguimiento a una solicitud ya hecha. Inexistencia en el área operativa de un proceso formal a nivel de Gestión de Incidentes. No se generan reportes formales del proceso de Gestión de Incidentes. Inexistencia de métricas que permitan analizar la Gestión de Incidentes y el impacto en el negocio. 4.4 Fase de mejoras Después de identificar las actividades críticas en donde se producen las mayores demoras de tiempo del proceso y sus posibles causas, se procede a especificar las propuestas de mejora y cambios en el proceso en general que permitan optimizar el tiempo de solución de incidentes del SD. Es de resaltar que este es uno de los aportes más importantes de este trabajo para la empresa, ya que se plantean una serie de modificaciones que de ser implementadas mejoraran sustancialmente el funcionamiento de la Gestión de Incidencias Propuestas de mejoras Propuesta para disminuir volumen de llamadas y correos electrónicos. Para disminuir el volumen de llamadas y correos electrónicos se propone identificar las causas raíces de los incidentes reportados con más frecuencia, para realizar los cambios necesarios en los sistemas e infraestructura de Tecnología de Información (TI) que permitan prevenir la ocurrencia de los mismos, así como implementar un sistema de monitorización de hardware y software que informe al SD mediante alertas los incidentes antes de que sean reportadas por los usuarios. En este sentido se define una alerta como una situación detectada por los sistemas de monitoreo, que no forme parte de la operación estándar de servicio y que cause o pueda causar una interrupción o reducción de la calidad del mismo. De esta forma el SD seguirá un patrón más proactivo ante los incidentes que van surgiendo.
58 Propuesta para mejorar el registro de requerimientos. 45 Se propone un nuevo canal para el reporte de incidentes y solicitudes de servicio (autoregistro), en el cual sean los usuarios los que registren y hagan una clasificación inicial de su solicitud, generando ellos mismos el número de ticket asociado a la misma, de esta manera los analistas y especialistas del SD no tienen la necesidad de registrar las solicitudes. Y se podrá llevar un mejor control de las solicitudes registradas, ya que todos los incidentes reportados por los usuarios serán registrados en la herramienta SDTool. Por esta vía el usuario también podría hacer seguimiento del estado de sus reportes, disminuyendo el volumen de correos electrónico recibidos por el departamento para este fin, que según el estudio realizado representa un 40% de los correos recibidos Propuesta para mejorar el tiempo de cierre de ticket. Se propone el cierre automático del ticket después de que las unidades solucionadoras cierren todas las órdenes de servicio asociadas al mismo. Para comprobar con el usuario que el incidente fue solucionado correctamente se le enviará por correo electrónico de forma automática una encuesta de evaluación de calidad, si el usuario no está conforme con la solución se procede a la reapertura del ticket. Se debe crear una nueva categoría en la clasificación de incidentes llamada no conformidad la cual permitirá medir el porcentaje de incidentes solucionados correctamente. Con el cierre automático de ticket se elimina la demora de 6 días producida en la actividad de cierre, mejorando los tiempos de respuestas. A continuación en la figura 4.16 se observa el modelo de SD con las propuestas antes mencionadas.
59 46 Usuarios Incidentes, requerimiento de servicios y seguimiento de solicitudes. Auto registro SERVICE DESK Atención y solución de incidentes y prestación de servicios. Escalado Llamadas y Correos Unidad de Soporte a Usuario Centro de Monitoreo Alarmas I N F R A E S T R U C T U R A UNIDADES SOLUCIONADORAS Figura Modelo de Service Desk Propuesta para mejorar el tiempo de cierre de órdenes de servicio. De acuerdo a los resultados obtenidos y las entrevistas realizadas al personal de SD se hace suponer el desconocimiento de los SLA s y OLA s para los servicios ofrecidos por el SD y para las unidades solucionadoras, es por ello que se propone la construcción de un portal que contenga los documentos relativos a los SLA s y OLA s tanto para los servicios ofrecidos por SD como para los servicios ofrecidos por las unidades solucionadoras. En función de la creación de dicho portal se diseñó un formato para el levantamiento de información (ver apéndice E) y se elaboraron los manuales de procedimiento de los servicios ofrecidos por el primer nivel de soporte del departamento de SD, lo cuales contienen: descripción y procedimiento a seguir para prestar el servicio y la definición de OLA s y SLA s (ver apéndice F). De esta forma los usuarios estarán informados del tiempo en que su incidente será solventado, o
60 47 en que se le prestará el servicio requerido, además de obligar a las unidades solucionadoras a cumplir con los tiempos establecidos en los SLA s y OLA s Modelo propuesto del proceso de Gestión de Incidentes. En esta sección se propone un modelo mejorado del proceso para la Gestión de Incidentes, con una descripción detallada de los procedimientos a realizar por los analistas y especialistas en cada una de las actividades del mismo. El modelo propuesto está basado en el proceso de Gestión de Incidentes que describe ITIL y fue adaptado a las necesidades del SD de Mercantil Seguros Proceso de Gestión de Incidentes del SD. Asignación. El analista responsable de esta actividad debe leer y analizar cada solicitud, ya sea recibida vía correo electrónico o vía auto registro y dependiendo del requerimiento asignarla al primer, segundo o tercer nivel de soporte. Registro Se registra el incidente o solicitud de servicio mediante la apertura de un ticket, para ello se graba los datos relativos en la Base de Datos de Incidentes. Si se trata de un incidente se verifica que si ya existe, en cuyo caso se asocia con el incidente existente, en caso contrario se graba como nuevo incidente. Para después pasar a la actividad de Clasificación y Soporte Inicial Entradas o Contacto de usuario para informar incidente. o Registro de incidente o solicitud de servicio hechos por el usuario en auto registro. o Entradas desde los servicios de monitorización de hardware y software, que habitualmente se transforman en incidentes. Salidas o Base de Datos de Incidentes con la siguiente información: Asignación automática de un número de registro (número de ticket) Fecha y hora real del momento de la detección. Modo de entrada del contacto (correo electrónico, llamada o auto registro). Descripción detallada del caso detectado. Datos de la persona que realiza el registro.
61 48 Clasificación y Soporte Inicial. El SD realiza una clasificación preliminar del incidente para asignarle una prioridad y una categoría basada en el análisis del registro del incidente creado en la actividad anterior. La prioridad debe asignarse según los parámetros de impacto y urgencia (definidos en el marco teórico). La categoría permite identificar inicialmente el tipo de elemento y la razón o síntoma causante del incidente, facilitando la identificación de la correspondiente acción resolutiva a realizar. Adicionalmente en este proceso también se asigna el estado del incidente. Este estado es un indicador del progreso realizado en la resolución de un incidente abierto y permite definir y extraer ciertas métricas con el fin de evaluar el Proceso de Gestión de Incidentes. Entradas o El registro del incidente. o Incidentes que guardan relación con incidentes anteriores. o SLA s y OLA s Salidas o Incidente clasificado. o Detalles del incidente actualizados. o En caso de resolución del incidente se obtendrían los detalles de su resolución. Escalado Se asigna el incidente al siguiente nivel de soporte especializado (escalado funcional), mediante la creación de una orden de servicio. Resolución del incidente Normalmente se resuelve el incidente mediante un arreglo temporal, y se llevan a cabo las acciones oportunas para restaurar el servicio. Las actividades de restauración del servicio se pueden llevar a cabo por personal de cualquier nivel de soporte. Todas las acciones realizadas
62 49 en esta actividad se colocan en el registro de incidentes mediante la creación de bitácoras, ya sea por la unidad que restauró el servicio o por el SD. Entradas o Detalle del incidente actualizado. o Cualquier arreglo provisional. Salidas o Detalles del incidente actualizados. o Incidente resuelto con los detalles relativos a la restauración del servicio. Comprobación con el Usuario. Se contacta al usuario mediante una encuesta de evaluación de calidad enviada vía correo electrónico automáticamente después de cerrar el ticket, para comprobar la resolución del incidente y el restablecimiento normal del servicio. Entradas o Incidente resuelto. o Restablecimiento del servicio. Salidas o Conformidad o no del usuario. Reabrir incidente En caso de disconformidad del usuario con la resolución del incidente, se registra en la Base de Datos de Incidentes el por qué de la no conformidad del usuario, se cambia el estado del incidente a reabierta y se regresa a la actividad de clasificación y soporte inicial. Entradas o Detalles del incidente actualizados. o Disconformidad del usuario. Salidas o Detalles del incidente actualizados.
63 o Incidente reabierto. 50 Cierre de contacto Después de que se cierran todas las órdenes de servicio asociadas al ticket, éste se cierra automáticamente y se envía al usuario una encuesta de evaluación de calidad del servicio prestado. Entradas o Detalles del incidente actualizados. o Incidente resuelto. o Servicio restaurado. Salidas o Detalles del incidente actualizados. o Conformidad del usuario. o Incidente cerrado. Solicitud de servicio Cuando la entrada es una solicitud de servicio, se resuelve mediante la aplicación del procedimiento asociado al servicio solicitado. Seguimiento de la Gestión de Incidentes. En esta actividad se realiza la monitorización periódica de los incidentes que son escalados a las unidades solucionadoras mediante la generación de bitácoras de seguimiento, con el fin de verificar el cumplimiento de OLA s y SLA s. Entradas o Detalle de los incidentes actualizados. o Arreglos provisionales. Salidas o Comunicación con unidades solucionadoras
64 Sub-proceso de escalado 51 Investigación y diagnóstico Se evalúan los detalles del incidente, se recopila y analiza toda la información relacionada con la resolución y se amplían los detalles del incidente con los datos resultantes. Entradas o Orden de servicio. o Base de Datos de Incidente, con detalles del mismo actualizados. o Cualquier arreglo provisional hecho por el primer nivel de soporte. Salidas o Solución del incidente. Resolución del incidente Se resuelve el incidente mediante un arreglo temporal y se llevan a cabo las acciones oportunas para restaurar el servicio. Las actividades de restauración del servicio se pueden llevar a cabo por personal de cualquier línea de soporte. Todas las acciones realizadas en esta actividad se colocan en el registro de incidentes mediante la creación de bitácoras, ya sea por la unidad que restauró el servicio o por el SD. Entradas o Detalles del incidente actualizados. o Cualquier arreglo provisional. Salidas o Detalles del incidente actualizados. o Incidente resuelto con los detalles relativos a la restauración del servicio. Cierre de orden de servicio. Al resolver el incidente, la unidad solucionadora debe verificar que la documentación del incidente esté completa, llenar el registro del incidente con la información relativa al cierre de orden y cerrar orden de servicio. Entradas
65 o Detalles del incidente actualizados. o Incidente resuelto. o Servicio restaurado. 52 Salidas o Detalles del incidente actualizados. A continuación en las figuras 4.17 y 4.18 se observa el diagrama de flujo del proceso propuestos para la Gestión de Incidentes y de escalado.
66 Figura Diagrama de flujo del proceso propuesto de Gestión de Incidentes 53
67 54 Escalado Segundo Nivel Tercer Nivel Cuarto Nivel Orden de Servicio Investigar/ Diagnosticar Solución? No Investigar/ Diagnosticar Si Solucionar incidencia Solución? Si No Investigar/ Diagnosticar Solucionar incidencia Solucionar incidencia Cierre de orden de servicio Figura Diagrama de flujo del proceso propuesto de escalado
68 55 Luego de haber definido el nuevo proceso para la Gestión de Incidentes también se propone la creación de los siguientes cargos adicionales a los ya existentes: o Administrador de soporte de Incidentes: es responsable de la administración en el ámbito técnico (herramienta SDTool) del proceso de Gestión de Incidentes. Se ocupa de proporcionar y mantener los medios técnicos necesarios para una gestión eficiente del proceso. o Gestor de nivel de servicios: es el encargado de garantizar el cumplimiento de los niveles de servicio acordados con el usuario respecto al servicio ofrecido y formalizados en los SLA s y OLA s. o Gestor de Incidentes: es el responsable de la operación del proceso de Gestión de Incidentes, supervisa a los miembros de las diferentes líneas de Soporte que intervienen directamente en el proceso, identificando los recursos necesarios y participando en la resolución de conflictos. 4.5 Fase de control Es necesario establecer medidas que permitan evaluar el funcionamiento de los procesos para poder tomar acciones correctivas y/o proactivas, al objeto de hacerlos más eficientes, eficaces y adaptables, es por ello que en esta sección se describen un conjunto de métricas e indicadores que permitirán llevar un mejor control del proceso de Gestión de Incidentes. En la siguiente tabla se describen los indicadores según los objetivos planteados que son: la restauración del servicio en el menor tiempo posible minimizando el impacto en el negocio, la atención y resolución de solicitudes de servicio e incidentes dentro de los SLA s y OLA s definidos, la mejora continua del proceso y el aumento de los niveles de satisfacción de los usuarios.
69 Tabla 4.3. Propuesta de indicadores Objetivos Indicador Métricas Atención y solución de incidentes y solicitudes de servicio dentro de los SLA s y OLA s definidos. Cumplimiento de OLA s y SLA s Uso de catálogo de servicios % de solicitudes de servicio gestionadas en el marco de los acuerdos de servicios % de incidentes gestionados en el marco de los acuerdos de servicio % de órdenes de servicio no cerradas por unidad solucionadora % de servicios que están dentro del catálogo de servicios Frecuencia de reporte Mensual Mensual Mensual Mensual 56 Tiempo de registro Tiempo medio de registro de solicitudes recibidas por correo Mensual Mejorar tiempos de respuesta Mejora continua del proceso Tiempo solución Tiempo escalado de de Tiempo medio total de respuesta Incidentes categorizadas correctamente Incidentes priorizadas correctamente Incidentes y solicitudes de servicio escalados Casos atendidos y cerrados por SD Tiempo medio de solución Tiempo medio de escalado Tiempo medio total de respuesta de solicitudes de servicio Tiempo medio total de respuesta de incidentes % de incidentes categorizadas correctamente % de incidentes priorizadas correctamente % de incidentes y solicitudes de servicio escalados % de incidentes y órdenes de servicio atendidos y resueltos por analistas % de incidentes y órdenes de servicio atendidos y resueltos por especialistas Mensual Mensual Mensual Mensual Mensual Mensual Mensual Mensual Mensual Incidentes reabiertos % de incidentes reabiertos por inconformidad del usuario Mensual Aumentar niveles de satisfacción de los usuarios Satisfacción de los usuarios % de encuestas contestadas por los usuarios Mensual
70 57 Objetivos Indicador Métricas Resultados de encuesta Frecuencia de reporte Mensual A continuación se explica cómo calcular los indicadores descritos en la tabla 4.3: Cumplimiento de SLA s y OLA s: se refiere al porcentaje de incidentes y solicitudes de servicio gestionadas en el marco de los acuerdos de nivel de servicio y de operación. Se obtiene a partir de la cantidad de incidentes y solicitudes de servicios gestionadas dentro de los SLA s y OLA s vs la cantidad de incidentes y solicitudes de servicio registradas. Porcentaje de órdenes de servicios no cerradas por unidades solucionadoras: se refiere al porcentaje de órdenes de servicio no cerradas por las unidades solucionadoras y se obtiene a partir de la cantidad de órdenes no cerradas en un período de tiempo vs la cantidad de órdenes generadas. Utilización del catálogo de servicios: se refiere al porcentaje de solicitudes de servicios que se encuentran dentro del catálogo de servicios. Tiempo de registro canal correo electrónico: es el tiempo transcurrido desde que un incidente o solicitud de servicio es reportada a través del correo electrónico hasta que un analista o especialista lo registra en el SDTool. Se obtiene de la diferencia entre la hora de registro y la hora en que el usuario envió el correo electrónico, la cual queda registrada en el correo. Tiempo medio de escalado: tiempo transcurrido desde que se genera orden de servicio a unidad solucionadora hasta que ésta cierra la orden de servicio. Tiempo medio de solución: tiempo en el que el analista o especialista del SD resuelve el incidente o solicitud de servicio. Tiempo medio total de respuesta: tiempo promedio desde que el incidente o solicitud de servicio es reportada por el usuario hasta que el ticket es cerrado por el analista o especialista del SD. Permite medir el tiempo transcurrido durante el ciclo de vida del incidente. Incidentes priorizados correctamente: se refiere al porcentaje de incidentes priorizados correctamente según el impacto y la urgencia y tomando en cuenta los OLA s y SLA s. Incidentes categorizados correctamente: se refiere al porcentaje de incidentes categorizados correctamente, según las categorías definidas por el SD. Se obtiene a partir
71 58 de la cantidad de incidentes registrados y categorizados correctamente vs la cantidad de incidentes registrados. Incidentes y solicitudes de servicio escaladas: se refiere a los incidentes escalados a las unidades solucionadoras. Permite identificar las unidades solucionadoras que están recibiendo mayor cantidad de Incidentes. Porcentaje de incidentes y solicitudes de servicio solucionadas por analistas: se refiere al porcentaje de incidentes o solicitudes de servicio resueltas por los analistas (primer nivel de soporte). Permite medir la efectividad del primer nivel de soporte. Se obtiene a partir de la cantidad de Incidentes o solicitudes de servicios resueltas o atendidas por el primer nivel de soporte vs la cantidad de Incidentes y solicitudes de servicios registradas. Porcentaje de incidentes y solicitudes de servicio solucionadas por especialistas: se refiere al porcentaje de incidentes resueltos por los especialistas (segundo nivel de soporte). Permite medir la efectividad del segundo nivel de soporte. Se obtiene a partir de la cantidad de incidentes resueltas por el segundo nivel de soporte vs la cantidad de Incidentes registradas. Incidentes reabiertos: se refiere al porcentaje de incidentes reabiertos por disconformidad del usuario. Se obtiene a partir de la cantidad de incidentes reabiertos por disconformidad del usuario vs la cantidad de Incidentes solucionadas. Porcentaje de encuestas respondidas: se refiere al porcentaje de encuestas respondidas por los usuarios luego de la prestación de un servicio o la solución de un incidente sobre el total de encuestas enviadas. Satisfacción global del usuario: se refiere al porcentaje de satisfacción de los usuarios y se obtiene de los resultados de las encuestas.
72 CONCLUSIONES Y RECOMENDACIONES 5.1 Conclusiones A partir del estudio del proceso de Gestión de Incidentes del SD de Mercantil Seguros se identificaron los principales problemas que afectan el desarrollo del mismo, entre los que destacan los siguientes: demoras en registro de solicitudes recibidas vía correo electrónico, retraso en el cierre de órdenes de servicio por parte de las unidades solucionadoras y falta de seguimiento por parte de los analistas a los incidentes escalados, así como también deficiencias en el servicio de atención telefónica a los usuarios. No existía uniformidad de criterios en relación a las actividades del proceso en estudio y el orden en que éstas se debían realizar, es por esto que uno de los mayores aportes de este trabajo fue el levantamiento de información de estas actividades que permitió la definición del proceso de Gestión de Incidentes y su diagrama de flujo. La elaboración de manuales de procedimiento de los servicios ofrecidos por el primer nivel de soporte del SD, que incluyen descripción del servicio prestado, SLA s, OLA s, procedimiento y diagrama de flujo del proceso, constituyen un apoyo y guía informativa fundamental para la adecuada prestación de los servicios. Otro aspecto importante en este proyecto fue el proponer un modelo del proceso de Gestión de Incidentes basado en ITIL. Se pudo apreciar que para las organizaciones actuales, la gestión de servicios de Tecnologías de Información (TI) es un aspecto muy importante dentro sus actividades y que ITIL, que constituye una guía de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI, cuenta con la versatilidad necesaria para que su implantación y ajuste a las necesidades particulares de la empresa sean sencillos. Específicamente, para las propuestas sugeridas, se hizo base en una sección la sección titulada Soporte del Servicio, que se enfoca principalmente en la descripción
73 60 de procesos del SD. Las propuestas de mejoras planteadas en este trabajo fueron aprobadas por la gerencia de Canales Virtuales y Soporte a Usuarios, en algunas de ellas, como la aplicación del proceso de Gestión de Problemas para identificar las causas de los incidentes más comunes y el autoregistro, ya se está trabajando, y las otras forman parte del plan de acción de mejoras del SD para el año Además como resultado de las mediciones realizadas, se deja a la empresa una base para la gestión de procesos y búsqueda de soluciones en función de cifras. 5.2 Recomendaciones Involucrar al personal del SD en la búsqueda de soluciones tendientes a mejorar los procesos que se lleven a cabo, ya que de esta manera se logra que ellos tengan una mejor disposición en la aplicación de éstas. Mantener actualizados los manuales de los servicios ofrecidos por el primer nivel de soporte del SD e incentivar su utilización por el personal. Adiestrar y orientar al personal acerca de la importancia que tiene la aplicación utilizada por el departamento (SDTool), para la Gestión de Incidentes. Realizar informes periódicos de indicadores que permitan llevar un mejor control del proceso en estudio. Adquisición de un Sistema de Distribución Automática de llamadas (ACD), que permita llevar el control del número de llamadas entrantes, atendidas y abandonadas y de esta forma poder disponer de datos numéricos para comparar la cantidad de llamadas entrantes con las registradas. Implementar las propuestas de mejora planteadas en este trabajo.
74 61 REFERENCIAS BIBLIOGRÁFICAS [1] Portal de Mercantil Seguros, C. A, [2] Mercantil Seguros. Gerencia de Tecnología, Sistemas y Procesos. Ajuste Organizacional, 26(2), (2009). [3] Mercantil Seguro. Gerencia de Canales y Soporte a Usuarios. Transformando el Help Desk en Service Desk. (2009). [4] Jan Van Bon (2008). Fundamentos de Gestión de Servicios TI, basado en ITIL. 2da edición. itsmf Internacional. [5] Auxilor, Inc. (N/K). Implementing Your Help Desk. A Practical Guide. Auxilor, Inc. [6] Soporte Remoto de México (2008). Diferencia entre operación de un Help Desk y administración de Service Desk. Disponible en Internet consultado el 20 de diciembre de [7] David Cannon y David Wheeldon (2007). ITIL Version 3 Service Operation [8] OSIATIS. (2007). ITIL, Gestión de Servicios de TI. Disponible en Internet consultado el 22 de diciembre de [9] James R. Evans, William M. Lindsay (2005). Administración y Control de la Calidad. Sexta edición. Internacional Thomson Editores, S. A, México. Capítulos 10 y 12
75 62 APÉNDICE A ENCUESTA DE SATISFACCIÓN Responda marcando con una (X) la opción con la que este de acuerdo. 1. El servicio de soporte prestado por Help Desk a través de la extensión 2222 es: 1 Excelente 2 Muy bueno 3 Bueno 4 Deficiente 5 Muy Deficiente 2. Usualmente de ser atendido por un analista de Help Desk, Cuántas veces ha intentado llamar a la extensión 2222?: 1 Una vez 2 Dos veces 3 Tres veces 4 Cuatro veces 5 Más de cuatro veces 3. Normalmente cuanto tiempo tiene que esperar en linea para ser atendido? min min min min 5 Más de 15 min
76 63 4. La información suministrada por analista de help desk es de utilidad para solventar el requerimiento planteado. 1 Siempre 2 Casi siempre 3 A veces 4 Nunca 5. Tiene usted algún comentario adicional o alguna sugerencia que nos ayude a mejorar.
77 64 APÉNDICE B HERRAMIENTA UTILIZADA POR EL SERVICE DESK (SDTOOL) En esta sección del informe se describirá la herramienta de software utilizada por el SD y unidades solucionadoras para el proceso de Gestión de Incidentes. Escritorio de trabajo Posee un menú principal (figura A1.1) que ofrece las siguientes opciones: nuevo reporte, estadísticas, asignación, parámetros, cambio de clave, filtro y salir. El objetivo del escritorio de trabajo es mostrar el número de ticket, fecha, solicitante descripción y estatus (figura A.1.3) de los casos con los cuales está trabajando cada uno de los analistas y especialistas que conforman el SD. Mediante la opción ver (figura A.1.2) se pueden escoger los casos que se desean filtrar, las opciones son: Propios en proceso: son los casos sobre los cuales el analista o especialista tiene total responsabilidad. Propios cerrados: son los casos asignados al analista o especialista los cuales ya se encuentran cerrados. Del departamento en proceso: son los casos que el SD está manejando y que actualmente están en vías de ser solucionados. Del departamento cerrados: son los casos que el SD ya ha cerrado. Listos para cerrar: son los casos que se encuentran listos para ser cerrados ya que no tienen órdenes de servicio pendientes. Anulados: son los casos que se encuentran anulados dentro del rango de fechas establecidas por el filtro de búsqueda, el cual será comparado con la fecha de anulación de caso. Las últimas columnas de este escritorio (figura A.1.4 y A.1.5) permiten saber si un caso se encuentra dentro del tiempo esperado de solución (SLA s) y si posee ordenes de servicio
78 65 y el status de estas (OLA s). Los indicadores son mostrados mediante los colores verde, amarillo y rojo. Para el caso de los niveles de acuerdo de servicio (SLA s) el color verde significa que el caso se encuentra cerrado dentro del tiempo acordado, el color amarillo significa que el caso se encuentra en proceso dentro del lapso de tiempo acordado y el color rojo significa que la solución del caso se encuentra fuera del lapso de tiempo acordado. Para el caso de los acuerdos de niveles operativos (OLA s), el color rojo significa que existen órdenes de servicio no terminadas y que el tiempo dado para ser entregadas se ha vencido, el color amarillo significa que las ordenes de servicio aun no se han entregado pero aun el tiempo dado para ser resueltas no se ha vencido y el color rojo significa que las ordenes de servicio no se han resuelto y el tiempo acordado para la solución ya se ha alcanzado (vencido). La etiqueta Reportes no asignados (figura A.1.6) indica si existen casos recibidos por el SD que no han sido asignados a un analista. La condición no asignado significa que el caso no posee un analista responsable y el jefe del departamento de SD deberá asignarlo a uno de sus analistas. El campo Buscar (figura A.1.7), permite realizar la búsqueda de casos, se puede buscar por el nombre del solicitante, el alias del analista o especialista de SD responsable, por el número de ticket o por la descripción del reporte
79 66 Figura A.1. Escritorio de trabajo SDTool Nuevo reporte Para registrar un nuevo incidente de debe seleccionar la opción de nuevo reporte en el menú principal (1) y llenar los datos necesarios para su registro. Nombre del solicitante, carnet y ubicación del usuario solicitante. Número de ticket (generado automáticamente del sistema) Hora y fecha cuando se realiza el registro (se registra de forma automática por el sistema). Descripción del problema. Fuente del problema. Prioridad (normal, media, baja, alta, urgente, ASAP) Forma del reporte ( , SD, teléfono, personal, fax) Teléfono e de contacto del usuario. Analista de SD asignado. Acción realizada. A continuación en la figura A.2 se muestra la pantalla de apertura de reporte
80 67 Figura A.2. Apertura de Reporte SDTool Solución de Incidentes La herramienta SDTool permite al analista o especialista de SD registrar las acciones realizadas para la solución de un incidente, ya sea con el registro de bitácoras (BI), correos electrónicos (CO) u órdenes de servicio (OS) cuando se escalan las Incidentes a las unidades solucionadoras. En la figura A.3 se observa como la herramienta muestra las BI, CO y OS.
81 68 Figura A.3. Consulta de Reporte SDTool Estadísticas La herramienta SDTool también genera las estadísticas de atención y tiempos de resolución de Incidentes, tanto para los analistas y especialistas del SD como para las unidades solucionadoras. Es de destacar que las estadísticas de tiempo generadas por el SDTool empiezan a contarse después de que los casos son registrados en el sistema, antes no se lleva ningún registro.

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