UNIVERSIDAD NACIONAL DEL ALTIPLANO FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA, ELÉCTRONICA Y SISTEMAS ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

Transcripción

1 UNIVERSIDAD NACIONAL DEL ALTIPLANO FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA, ELÉCTRONICA Y SISTEMAS ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS MODELO DE GESTIÓN DE INCIDENCIAS BASADO EN ITIL PARA REDUCIR EL TIEMPO DE DIAGNÓSTICO DE INCIDENTES DEL SERVICIO DE SOPORTE TÉCNICO EN LA UNIVERSIDAD NACIONAL DEL ALTIPLANO PUNO TESIS PRESENTADO POR: VILMA CRIST PALLI APAZA PARA OPTAR EL TÍTULO PROFESIONAL DE: INGENIERO DE SISTEMAS PUNO PERÚ 2014

2 UNIVERSIDAD NACIONAL DEL ALTIPLANO FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA, ELECTRÓNICA Y SISTEMAS ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS MODELO DE GESTIÓN DE INCIDENCIAS BASADO EN ITIL PARA REDUCIR EL TIEMPO DE DIAGNÓSTICO DE INCIDENTES DEL SERVICIO DE SOPORTE TÉCNICO EN LA UNIVERSIDAD NACIONAL DEL ALTIPLANO PUNO TESIS PRESENTADA POR: VILMA CRIST PALLI APAZA PARA OPTAR EL TÍTULO PROFESIONAL DE: INGENIERO DE SISTEMAS APROBADA POR EL JURADO REVISOR CONFORMADO POR: PRESIDENTE : M.Sc. Hugo Yosef Gómez Quispe PRIMER MIEMBRO : Ing. Milder Zanabria Ortega SEGUNDO MIEMBRO : Ing. Pablo Tapia Catacora DIRECTOR DE TESIS : Dr. Henry Iván Condori Alejo 1

3 DEDICATORIA A mis padres Felix y Francisca, por su cariño, sus enseñanzas y consejos, por guiarme por el buen camino y hacer de mí una persona de bien. A mis hermanos Ever y Yesica, porque su bienestar y su felicidad me impulsan a seguir adelante y ser mejor cada día. Al Dr. German Yabar Pilco, al Dr. Henry Iván Condori Alejo, al Ing. Olger Alejandrino Ortega Achata, al Ing. Hugo Yosef Gómez Quispe y al Ing. Fredy Collanqui Martinez; por su incansable exortación a concluir mí paso por mi alma mater. Cuando algo está hecho, no puede ser de otro modo Troya Crist 2

4 AGRADECIMIENTOS A Dios por mostrarme día a día que con humildad, paciencia y esfuerzo todo es posible. A mis padres y hermanos, por su apoyo incondicional, su comprensión y su fe en mí, a ellos mi gratitud eterna por estar siempre a mi lado. A Remigia, Thania, Otilia, Alodia, Veronica, Anita y Luis Miguel, por su ejemplo y por siempre exhortarme a culminar cada tarea iniciada en la vida, como lo es esta investigación. A los ingenieros miembros del comité de jurados, M.Sc. Hugo Yosef Gómez Quispe, Ing. Milder Zanabria Ortega e Ing. Pablo Catacora Tapia, por sus observaciones, sugerencias, consejo en la realización de la presente investigación. Al director de tesis, Dr. Henry Iván Condori Alejo, por todos sus consejos, sugerencias, por su apoyo incondicional y por su dirección en la presente investigación. A toda la familia de la Oficina de Tecnología Informática de la Universidad Nacional del Altiplano Puno, en especial al Ing. Fredy Collanqui Martinez a él, por sus consejos y apoyo incondicional, en el desarrollo de este trabajo de investigación. A todos, muchas gracias 3

5 ÍNDICE ÍNDICE DE FIGURAS... 6 ÍNDICE DE TABLAS... 8 RESUMEN INTRODUCCIÓN CAPÍTULO I. PLANTEAMIENTO DE LA INVESTIGACIÓN PLANTEAMIENTO DEL PROBLEMA DEFINICIÓN DEL PROBLEMA JUSTIFICACIÓN OBJETIVOS DE LA INVESTIGACIÓN OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS HIPÓTESIS LIMITACIONES CAPÍTULO II. MARCO TEÓRICO ANTECEDENTES MARCO TEÓRICO MODELO DE GESTIÓN DEL SERVICIO ITIL (Information Technology Infrastructure Library) GESTIÓN DE INCIDENCIAS MÉTRICAS DE LA GESTIÓN DE INCIDENCIAS SOPORTE TÉCNICO SOPORTE TÉCNOLÓGICO PARA LA GESTION DE SERVICIO DEFINICIÓN DE TÉRMINOS BÁSICOS CAPÍTULO III. MATERIALES Y MÉTODOS TRABAJO EXPERIMENTAL TIPO Y DISEÑO DE LA INVESTIGACIÓN POBLACIÓN Y MUESTRA SISTEMA DE VARIABLES DEFINICIÓN DE VARIABLES OPERACIONALIZACIÓN DE VARIABLES MATERIAL EXPERIMENTAL MÉTODOS DE RECOPILACIÓN DE DATOS MÉTODO DE TRATAMIENTO Y ANÁLISIS DE DATOS MATERIAL APLICATIVO METODOLOGÍA DE DESARROLLO DEL MODELO HARDWARE Y SOFTWARE DE DESARROLLO CAPÍTULO IV. RESULTADOS Y DISCUSIÓN DIAGNÓSTICO Y DEFINICIÓN DE LOS REQUISITOS DEL MODELO DE GESTIÓN DE INCIDENCIAS DESCRIPCIÓN DE LA OFICINA DE TÉCNOLOGÍA INFORMÁTICA SITUACIÓN ACTUAL DE LA GESTIÓN DE INCIDENTES ANÁLISIS DE LA SITUACIÓN ACTUAL MEDICIÓN DEL GRADO DE MADUREZ DE LA SITUACIÓN ACTUAL REQUISITOS DEL MODELO DE GESTIÓN DE INCIDENCIAS DISEÑO DEL MODELO DE GESTIÓN DE INCIDENCIAS BASADO EN ITIL ENTRADA, ACTIVIDADES Y SALIDA DEL MODELO DE GESTIÓN DE INCIDENCIAS CICLO DE VIDA DEL INCIDENTE

6 DESCRIPCIÓN DEL PROCESO PROCESOS DEL MODELO DE GESTIÓN DE INCIDENCIAS ROLES Y RESPONDABILIDADES DEL MODELO MÉTRICAS DEL PROCESO POLÍTICAS PARA EL MODELO DE GESTIÓN DE INCIDENCIAS IMPLEMENTAR MODELO DE GESTIÓN DE INCIDENCIAS ARQUITECTURA DE LA HERRAMIENTA ANÁLISIS Y DISEÑO DE LA HERRAMIENTA IMPLEMENTACIÓN DE LA HERRAMIENTA EVALUACIÓN DEL MODELO DE GESTIÓN DE INCIDENCIAS RESULTADOS DE LAS FICHAS DE OBSERVACIÓN SIN MODELO CON MODELO PRUEBA DE HIPOTESIS CONCLUSIONES RECOMENDACIONES Y SUGERENCIAS BIBLIOGRAFÍA ANEXOS ANEXO 1: ENCUESTA DE DIAGNÓSTICO DE SITUACIÓN ACTUAL ANEXO 2: FICHA DE OBSERVACIÓN ANEXO 3: ESPECIFICACIÓN DE CASOS DE USO ANEXO 4: CODIGO FUENTE DE BASE DE DATOS ANEXO 5: MODELO DE GESTIÓN DE INCIDENCIAS ANEXO 6: REGISTRO DE INCIDENTES CON Y SIN MODELO

7 ÍNDICE DE FIGURAS Figura 1: Ciclo de vida del servicio según ITIL Figura 2: Proceso de Gestión de incidencias Figura 3: Modelo de gestión de calidad Figura 4: Organigrama de la Oficina de Tecnología Informática Figura 5: Diagrama de flujo de la situación actual Figura 6: Entradas y salidas del proceso de gestión de incidencias Figura 7: Estados del incidente Figura 8: Diagrama de flujo del proceso de gestión de incidencias Figura 9: Diagrama de flujo del proceso registro de incidentes Figura 10: Diagrama de flujo del proceso clasificación y soporte inicial Figura 11: Diagrama de flujo proceso asignación y escalado Figura 12: Diagrama de flujo del proceso cierre del incidente Figura 13: Diagrama de flujo del proceso asignación y escalado Figura 14: Arquitectura de la herramienta para la gestión de incidencias Figura 15: Caso de uso para la gestión de usuario Figura 16: Caso de uso para la gestión de CMDB Figura 17: Caso de uso para la gestión de ticket Figura 18: Caso de uso para la gestión de ticket Figura 19: Diagrama de secuencia para identificar usuario Figura 20: Diagrama de secuencia para registro de elemento de CMDB Figura 21: Diagrama de secuencia para registro ticket Figura 22: Diagrama de actividades del proceso de registro de usuario Figura 23: Diagrama de actividades del proceso de registro de usuario Figura 24: Diagrama de actividades del proceso de registro de usuario

8 Figura 25: Diagrama de actividades para la atención de incidente Figura 26: Diagrama de clases Figura 27: Modelo ER de la base de datos Figura 28: Modelo ER de la base de datos Figura 29: Interfaz de inicio Figura 30: Interfaz principal Figura 31: Interfaz para la gestión de usuario Figura 32: Interfaz para la gestión de activo Figura 33: Interfaz para la gestión de incidentes Figura 34: Interfaz para la visualizar reportes

9 ÍNDICE DE TABLAS Tabla 1: Operacionalización de variables Tabla 2: Catálogo de servicios de la Oficina de Tecnología Informática Tabla 3: Cuadro comparativo Tabla 4: Nivel de madurez visión y dirección Tabla 5: Nivel de madurez personas respecto al proceso Tabla 6: Nivel de madurez procesos respecto al proceso Tabla 7: Nivel de madurez tecnología respecto al proceso Tabla 8: Nivel de madurez cultural respecto al proceso Tabla 9: Nivel de madurez general respecto al proceso Tabla 10: Descripción del proceso de gestión de incidencias Tabla 11: Proceso registro de incidentes Tabla 12: Proceso clasificación y soporte inicial Tabla 13: Proceso asignación y escalado Tabla 14: Proceso Reparación y recuperación Tabla 15: Proceso cierre del incidente Tabla 16: Roles para el modelo de gestión de incidencias Tabla 17: Tabla usuario Tabla 18: Tabla rol Tabla 19: Tabla oficina Tabla 20: Tabla sede Tabla 21: Activo CMDB Tabla 22: Tabla tipo activo CMDB Tabla 23: Tabla ticket Tabla 24: Tabla descargo

10 Tabla 25: Tabla de resultados de diagnóstico de incidentes (sin modelo) Tabla 26: Tabla resultados tipo de incidentes (sin modelo) Tabla 27: Tabla resultados por prioridad (sin modelo) Tabla 28: Tabla de resultados de incidentes (con modelo) Tabla 29: Tabla resultados por tipo de incidente (con modelo) Tabla 30: Tabla resultados por prioridad (con modelo) Tabla 31: Estadística de grupo Tabla 32: Resultados de muestras independientes

11 RESUMEN El presente trabajo de investigación titulado Modelo de gestión de incidencias basado en ITIL para reducir el tiempo de diagnóstico de incidentes del servicio de soporte técnico en la Universidad Nacional del Altiplano Puno 2014, tiene por objetivo general desarrollar un modelo de gestión de incidencias basado en ITIL para reducir el tiempo de diagnóstico de incidentes. El manejo inadecuado de la gestión de incidencias ocasiona tiempos largos para su diagnóstico, según registro de trámite documentario. Es necesario mejorar el actual proceso de gestión de incidencias estandarizándolo según el modelo propuesto por ITIL, para lograr la reducción del tiempo de diagnóstico de incidencias, se realizaron las pruebas correspondientes, y teniendo ya los datos recopilados a través de fichas de observación, se aplicó una prueba de entrada (Pre-test) y una prueba de salida (Pos-test), para comprobar la hipótesis declarada; Constituyendo un diseño de investigación pre-experimental. Los resultados obtenidos fueron claros al mostrar una reducción de minutos de tiempo promedio de diagnóstico de incidentes sin modelo a 457 minutos de tiempo promedio de diagnóstico de incidentes con modelo. Finalmente, una vez realizada la prueba de hipótesis, a través de los resultados de las fichas de observación, se demuestra empírica y estadísticamente, que el desarrollo de un Modelo de gestión de incidencias basado en ITIL reduce en un 77% el tiempo de diagnóstico de incidencias del servicio de soporte técnico en la Universidad Nacional de Altiplano. PALABRAS CLAVE: ITIL, gestión de incidencias, soporte técnico, gestión del servicio. 10

12 ABSTRACT This research work entitled "Management Model based on ITIL to reduce diagnostic time incident support service at the National University of the Altiplano Puno 2014 incidents", general objective is to develop a model based incident management ITIL to reduce diagnostic time incident. Improper handling of the incident management brings long times for diagnosis, as documentary record of proceedings. It is necessary to improve the current process standardizing incident management as proposed by ITIL model to achieve a reduction in time to diagnosis of incidents, the corresponding tests were performed, taking and data collected through observation sheets was applied an entrance test (Pre-test) and an output test (Post-test) to check the stated hypothesis; Forming a pre-experimental design research. The results were clear in showing a reduction of 59,198 minutes of average time for diagnosis model without incident at 457 minutes average time incidents diagnostic model. Finally, once the hypothesis testing, through the results of observation forms, empirical and statistically demonstrated that the development of an "incident management model based on ITIL reduces by 77% the time of diagnosis incident support service at the National University of Altiplano". KEYWORDS: ITIL, incident management, technical support, service management. 11

13 INTRODUCCIÓN El presente trabajo de investigación muestra en qué medida el modelo de gestión de incidencias basado en ITIL (Biblioteca de la Infraestructura de las tecnologías de Información), reduce el tiempo de diagnóstico de incidencias. El actual manejo de incidencias se inicia con una solicitud o notificación del incidente por parte del usuario a secretaria de la Oficina de Tecnología Informática o directamente al personal de soporte técnico luego de ello el personal técnico diagnóstica el incidente; Los diferentes medios para el reporte de los incidentes ocasiona tiempos largos de respuesta para su diagnóstico, en el presente trabajo de investigación se desarrolla un modelo de gestión de incidencias basado en ITIL que estandariza el manejo de incidentes en la Universidad Nacional del Altiplano Puno para reducir el tiempo de diagnóstico de incidencias del servicio de soporte técnico. Esta tesis se encuentra constituida por cuatro capítulos, todos ellos relacionados de manera que haya una coherencia entre las distintas partes y sea fácil su comprensión para los lectores de la presente investigación. CAPÍTULO I: Planteamiento y formulación del problema, justificación de la investigación, objetivos de la investigación, limitaciones de la investigación. Estos puntos sitúan al lector dentro de la problemática de la investigación; así como de la hipótesis que será demostrada y de la operacionalización de variables. CAPÍTULO II: El marco teórico compuesto de tres partes: antecedentes de la investigación, donde se consideró investigaciones anteriores que sirvieron de base para la presente investigación; el marco teórico, donde reside toda la teoría necesaria para el mejor entendimiento del presente trabajo de investigación; y finalmente el marco conceptual, necesario para comprender los términos básicos más utilizados a lo largo de la investigación. 12

14 CAPÍTULO III: El método de investigación constituido por el trabajo experimental realizado; así como también de la metodología de desarrollo; las herramientas y técnicas empleadas para la recolección de datos y su posterior análisis estadístico empleadas durante la investigación. CAPÍTULO IV: Exposición y análisis de los resultados constituido por el diagnóstico de la situación actual; el diseño del modelo basado en ITIL; como también el análisis, diseño y la implementación de la herramienta propuesta, finalmente la evaluación del modelo de gestión de incidencias. Conclusiones a las que se ha llegado como resultado de la implantación y puesta en marcha del modelo de gestión de incidencias basado en ITIL. Recomendaciones y sugerencias para seguir investigando e implementando trabajos relacionados a la gestión de incidencias y al marco de referencia que propone ITIL para la gestión del servicio. 13

15 CAPÍTULO I. PLANTEAMIENTO DE LA INVESTIGACIÓN 14

16 1.1. PLANTEAMIENTO DEL PROBLEMA La incorporación de las tecnologías de la información en los procesos fundamentales de las organizaciones crea la necesidad de incorporar departamentos de tecnologías de la información que tengan implantado procesos para resolver incidencias de los servicios prestados, cuya finalidad es dar una efectiva y rápida respuesta a los incidentes que puedan ocurrir (Carozo Blumsztein, 2013). La Universidad Nacional del Altiplano, cuenta con una infraestructura de red que permite la interconexión de las diferentes unidades académicas y unidades administrativas a través de fibra óptica y enlaces de cobre e inalámbrico, extendiéndose por todo el campus universitario y sedes remotas cuyo crecimiento la hace compleja, a esta infraestructura de red se integran equipos de cómputo como equipos principales que permiten el acceso a la red de esta forma acceder a los servicios ofrecidos a través de esta. Durante el normal desempeño de las actividades surgen incidentes relacionados con equipos informáticos, acceso a los sistemas de información y servicios como telefonía IP, Internet, etc. La oficina de Tecnología Informática cuenta con 02 personas que forman parte del equipo técnico cuya función es diagnosticar las incidencias respecto el servicio de soporte técnico. La gestión de incidencias del servicio de soporte técnico, a la fecha es deficiente según percepción de los usuarios, donde los incidentes son reportados a través de documentos dirigidos al jefe de la Oficina de Tecnología Informática o de manera verbal directamente al personal técnico, los incidentes no se resuelven siempre de la misma forma, se desconoce el tiempo exacto de resolución de incidencias, se carece de un mecanismo de control para mejorar la gestión de incidencias, los incidentes no se canalizan debidamente puesto que no existe un único punto de contacto. De esta forma el tiempo de diagnóstico de incidencias se prolonga. 15

17 Los usuarios de los servicios de tecnologías de información que proporciona la Universidad Nacional del Altiplano a través de la Oficina de Tecnología Informática, requieren que los incidentes que se presentan en el día a día durante el desarrollo de sus funciones se diagnostiquen tan rápido como sea posible para restaurarlos a su operación normal. Los incidentes que se presentan son relacionados con los equipos de cómputo, así como en las aplicaciones que utilizan, dichos incidentes se refieren a descomposturas y/o fallas en el hardware, software y aplicaciones utilizadas. El diagnóstico implica la participación del personal de soporte técnico en computadoras, sistemas operativos, paquetería de oficina, herramientas de colaboración y mensajería instantánea, aplicaciones administrativas de propósito específico, servidores, bases de datos, redes locales, internet, intranet, antivirus y otras herramientas que utiliza la organización, por tanto es necesario que dichos incidentes se gestionen adecuadamente de manera que se permita darle seguimiento durante todo su ciclo de vida, además de que se genere información suficiente que permita medir y evaluar el desempeño y la calidad de incidentes a los usuarios, aplicando en donde se requiera acciones preventivas, correctivas y de mejora. Debido a lo mencionado se formula el siguiente problema de investigación: 1.2. DEFINICIÓN DEL PROBLEMA En qué medida el modelo de gestión de incidencias basado en ITIL reduce el tiempo de diagnóstico de incidentes del servicio de soporte técnico en la Universidad Nacional del Altiplano Puno ? 1.3. JUSTIFICACIÓN El desarrollo de la presente investigación permitió estandarizar la gestión de incidencias basado en ITIL (Biblioteca de la infraestructura de tecnología de información) en la Universidad Nacional del Altiplano. Estableciendo procesos con un 16

18 flujo de actividades acorde a las necesidades de la entidad, ofreciendo una descripción detallada de los procesos necesarios que requiere la entidad para la gestión de incidencias, el valor de implementar la gestión de incidencias basado en ITIL reside en la posibilidad de controlar, diagnosticar incidencias y mejorar el proceso, lo que significa menor tiempo de parada del servicio. Lo que permite mejorar la gestión de incidencias, reduciendo los tiempos de diagnóstico de incidencias, siendo este un factor clave, ya que influye directamente en la eficiencia y la disponibilidad de los servicios proporcionados por la Oficina de Tecnología Informática. La industria ya ha normalizado gran parte del conjunto de actividades necesarias para que los servicios proporcionados sean fiables, eficientes y se encuentren siempre disponibles, estas normas cubren desde las actividades del día a día inmediato, como es la atención de los incidentes, hasta la mejora continua de proceso (Telefonica, 2009). Con el presente trabajo de investigación se pretende dar a conocer la importancia del marco de referencia que plantea ITIL, para la gestión del servicio proporcionado por las tecnologías de la información, por lo que se propone una alternativa de solución al problema planteado OBJETIVOS DE LA INVESTIGACIÓN OBJETIVO GENERAL Desarrollar un modelo de gestión de incidencias basado en ITIL para reducir el tiempo de diagnóstico de incidentes del servicio de soporte técnico en la Universidad Nacional Del Altiplano OBJETIVOS ESPECÍFICOS Diagnosticar y definir los requisitos del modelo de gestión de incidencias. Diseñar el modelo de gestión de incidencias basado en ITIL. Implementar el modelo de gestión de incidencias basado en ITIL 17

19 Evaluar el modelo de gestión de incidencias basado en ITIL HIPÓTESIS El modelo de gestión de incidencias basado en ITIL reduce el tiempo de diagnóstico de incidentes del servicio de soporte técnico en la Universidad Nacional del Altiplano Puno LIMITACIONES Para la elaboración del presente trabajo de investigación, se tomó en cuenta las siguientes limitaciones: La investigación se realizó en la Oficina de Tecnología Informática de la Universidad Nacional del Altiplano Puno. De tal forma que se desarrolló el modelo de gestión de incidencias acorde a los requerimientos de la entidad alineados a ITIL. El modelo de gestión propuesto abarca sólo incidencias respecto a los servicios de tecnologías de la información brindados por la Oficina de Tecnología Informática. El presente trabajo de investigación, trata de la operación del servicio de ITIL, específicamente solo del proceso de gestión de incidencias. La base de conocimientos de errores conocidos se alimentará de las incidencias conforme se de en producción. Para las pruebas se consideró los incidentes presentado en el mes de mayo y junio del año Para el desarrollo del modelo de gestión de incidencias basado en ITIL se emplearon criterios para la atención de incidentes de los servicios de TI de los usuarios (personal administrativo) de la Universidad Nacional del Altiplano. 18

20 CAPÍTULO II. MARCO TEÓRICO 19

21 2.1. ANTECEDENTES Las investigaciones realizadas, las cuales tienen referencia por su cercanía con la presente investigación son las siguientes: Implantación de los procesos de gestión de incidentes y gestión de problemas según ITIL V3 en el área de tecnologías de la información de una entidad financiera: Elaborado por Jesús Rafael Gómez Álvarez en el año Quien se ha planteado como objetivo: Implantar y consolidar la organización y procesos planificados de operación y transición de servicio en operaciones de TI, cuyas acciones estratégicas fueron: a). Implementar el proceso ITIL de gestión de incidencias en operaciones de TI, b). Implementar el proceso ITIL de gestión de problemas en operaciones TI, c). Implementar el proceso ITIL de gestión de disponibilidad de servicios en operaciones TI. Luego de concluir el trabajo se observó lo siguiente: Es necesario recordar a todas las áreas de operaciones que cualquier incidente o problema que estén atendiendo, por más pro actividad o criticidad que tenga, siempre se debe exigir el registro en la herramienta, pues esto ayudará a tener un control sobre lo que acontece en las operaciones diarias, Se observa que es necesario tener un plan de comunicación verbal presencial, como reuniones internas o externas, pues no siempre el portal o s son leídos por el personal de sistemas o, si lo leen, no le dan la importancia respectiva. Es importante revisar periódicamente los SLA para poder determinar si es necesario subir o disminuir los tiempos según la categoría del incidente o del problema. Conclusiones: Con la implementación de ITIL, se alienta el cambio cultural hacia la provisión de servicios. Asimismo, se mejora la relación con los clientes y usuarios pues existen acuerdos de calidad. 20

22 A través de la implementación de procesos ITIL, se desarrollan procedimientos estandarizados y fáciles de entender que apoyan la agilidad en la atención, logrando de esta forma visualizar el cumplimiento de objetivos corporativos. Con los procesos de gestión de incidentes y la gestión de problemas ya maduros, se reducen los tiempos de indisponibilidad de los sistemas. Recomendaciones: Es necesario seguir implementando el resto de procesos ITIL tales como gestión de cambios y gestión de la configuración. Es importante que la parte gerencial de TI apoye a sus equipos en cuanto al cumplimiento de las directivas de ITIL y no dar preferencias en atención a incidentes o problemas de igual o mayor rango gerencial que ellos. Es necesario recordar que si la oficina de TI no cumple o hace cumplir sus directivas, no puede esperar que el resto de áreas si cumplan (Gomez Alvarez, 2012) Modelo de gestión para la atención de incidentes a usuarios de servicios de tecnologías de información: Elaborado por Christian Zempoaltecatl Ibarra, Jacobo Mendoza Ríos. En el año 2010, quienes se han planteado como objetivo principal: Diseñar un modelo de gestión para la atención de incidentes a usuarios de servicios de tecnologías de información en las mejores prácticas y normas de calidad aceptadas internacionalmente, que este estructurado en módulos para que se facilité su implementación por etapas, que pueda ser fácilmente configurado a las necesidades particulares de las organizaciones, teniendo como finalidad que las descomposturas o fallas en los equipos o dispositivos de cómputo, en el software, en las herramientas de cómputo y/o en las aplicaciones que utilizan los usuarios de la organización, sean reparados tan pronto como sea posible para restaurarlo a su operación normal, y de esta manera propiciar que el desempeño 21

23 personal y de los procesos sustantivos de la organización sean más eficientes, eficaces, efectivos y con altos niveles de calidad. Cuyos objetivos específicos fueron: a). Conocer al detalle el proceso de administración de incidentes en ITIL versión 3 (marco de referencia de las mejores prácticas aceptadas internacionalmente, para la gestión de servicios de tecnologías de la información) y aplicar estos conceptos en el modelo de gestión para la atención de incidentes a usuarios de servicios de tecnologías de la información, b). Incorporar en el modelo de gestión que se desarrollara, conceptos de la norma internacionales ISO 9000 que se refieren a sistemas de gestión de la calidad, que tiene una orientación a satisfacer los requerimientos de sus usuarios, a medir y mejorar continuamente el desempeño y la calidad de sus servicios, mediante la medición y evaluación de sus procesos y servicios y la aplicación de las operaciones preventivas, correctivas y de mejora que sean necesarias, c). Desarrollar un modelo de gestión estructurado en módulos que pueda implementarse en etapas y que fácilmente pueda ser configurado e implementado en una organización, d). Diseñar un mapa estratégico que permita a los responsables de la atención de incidente a usuarios de servicios de tecnologías de la información, administrarlo en base a estrategias previamente definidas en una relación causa-efecto (Balance Scorecard) y complementarlo con un tablero de control que genere semáforos y alarmas ejecutivas como apoyo a la toma de decisiones y a la mejora continua de los servicios. Conclusiones: ITIL que nos ayudó a tener un contexto más amplio en cuanto a una de las mejores prácticas aceptadas internacionalmente en la gestión de servicios de tecnologías de la información, encontrando que nuestro proyecto solo utilizaría 9 de los

24 procesos que componen ITIL y con ellos se cubre la totalidad de los procesos de tecnologías de la información, siendo esto un reto a mediano plazo para conocerlo a mayor detalle y aplicarlos en nuestra vida profesional. La norma internacional ISO 9000 nos permitió conocer a mayor detalle conceptos de sistemas de gestión de calidad y los grandes beneficios que se tienen al implementarlos en la prestaciones de los servicios de tecnología de la información, para lograr constantemente una mejora continua en cuanto a mejora del desempeño, calidad y satisfacción del cliente. Algo muy valioso que encontramos es que nuestro modelo de gestión para la atención de incidentes usuarios de servicios de tecnologías de la información, puede tomarse como un marco de referencia confiable para adaptarlo a la atención de incidentes a usuarios de otras especialidades, ya que en cualquier organización se gestionan incidentes y requerimientos de servicio de todo tipo, solo imaginemos un hospital donde se atienden los requerimientos del personal médico para la atención de los pacientes (solicitudes de medicamentos en horarios específicos, programar el uso de un quirófano, integración del equipo de cirugía, programación de interconsultas con expertos de otros hospitales, egresos hospitalarios, entre otros) o bien los incidentes en el equipo e instrumental médico que reduzcan las posibilidades de falla o descompostura para propiciar un mejor funcionamiento con mayor eficacia, eficiencia y efectividad, lo cual también es un nicho de oportunidades que puede aprovecharse. (Zempoaltecatl Ibarra & Mendoza Rios, 2010) 23

25 Sistema de gestión de gestión de servicios basado en ITIL para optimizar el servicios informático en la municipalidad provincial de San Román Juliaca Presentado por Ana Luisa Paricahua Gutierrez y Larisa Quispe Mamani: En Quienes se han planteado como objetivo principal: Implementar un sistema de gestión de servicios basado en ITIL para optimizar el servicio informático en la Municipalidad Provincial de San Román Juliaca, cuyos objetivos específicos son: a.) Utilizar ITIL para la gestión de servicios informáticos, b.) Analizar y diseñar el sistema de gestión de servicios informáticos, c.) Implementar el sistema utilizando herramientas de entorno Web. Conclusiones: Una vez realizado el análisis, diseño, implementación e implantación del sistema de gestión de servicios se concluye que: 1. El sistema de gestión de servicios basado en ITIL optimiza el servicio informático en la Municipalidad Provincial de San Román Juliaca, con respecto a la calidad, procesos y tiempos de respuesta en el servicio informático, a la vez se optimiza la relación entre el área de informática y los usuarios de la institución. 2. Se ha utilizado ITIL (Information Technology Infraestructure Library) para definir los procesos de gestión de servicios informáticos utilizando la gestión de incidencias como eje de la mejora en el servicio informático y optimizando el tiempo de ejecución de procesos generados, según el marco de buenas prácticas ITIL. 3. Se ha analizado la factibilidad técnica como la económica para aprobar la realización del sistema, a la vez se identificaron los actores involucrados y se definieron las funciones y los procesos del sistema, obteniéndose una mejor abstracción de la problemática para luego ser implementada. En cuanto en el proceso de diseño, se tuvo apoyo fundamental del modelado UML, que permitió la ayuda en la eficiencia y calidad en el diseño. 4. Se ha implementado el sistema de gestión de 24

26 servicios utilizando el marco de trabajo Kohana, que facilita la labor del desarrollador separando claramente la lógica del sistema de la vista (interfaz) y del modelo (Base de datos) además de su sencillez. Además se recomienda: Que el área de informática realice un cronograma de capacitaciones para el mejor uso de las soluciones planteadas que se encuentran registradas en el sistema de gestión de servicios, haciendo que las incidencias no se eleven al segundo nivel de soporte. Para la implementación de ITIL se recomienda que el área de informática cuente con todo el respaldo de sus superiores, porque esta genera cambios en los procesos internos de la institución, a la vez que el tiempo que se requiere es elevado considerando, el compromiso de los usuarios para esta adaptación desde el análisis hasta la puesta en marcha del sistema, también se recomienda que se implemente los demás módulos de ITIL para una optimización total de la gestión de servicios. Para el análisis y diseño del sistema de gestión de servicios se recomienda que el área de informática documente todos sus procesos informáticos para su posterior uso utilizando como marco de referencia ITIL, siendo este importante para la implantación de procesos que no se adaptaron en esta investigación. Para la implementación del sistema de gestión de servicios se recomienda comprender que el proceso de desarrollo de un sistema es dinámico y no acaba con la implantación de sistema porque necesita constantes adaptaciones de acuerdo a las solicitudes del usuario. (Paricahua Gutierrez & Quispe Mamani, 2011) 25

27 2.2. MARCO TEÓRICO MODELO DE GESTIÓN DEL SERVICIO Los servicios de tecnologías de la información son cada vez más complejos, se incrementan sus niveles regulatorios, se producen frecuentes desviaciones en tiempo o en costes en su ciclo de vida, continuos avances tecnológicos (Bauset Carbonell & Rodenes Adam, 2013). Actualmente las organizaciones proveedoras de servicios de Tecnologías de la Información necesitan disponer de una gestión de servicios efectiva para cumplir las demandas de sus clientes. Para estas organizaciones ya no es suficiente apostar por la mejor tecnología, una orientación a procesos en el desarrollo de sus productos y en su propia organización interna, sino que también deben considerar la calidad de los servicios que proporcionan a sus clientes. El interés que la calidad de los servicios ofrecidos ha despertado en las organizaciones ha propiciado el nacimiento de una nueva disciplina, la gestión de servicios de tecnologías de la información (o ITSM del inglés Information Technology Service Management), que se centra en la perspectiva del cliente como principal aportación al negocio. La gestión de servicios de tecnologías de la información es una disciplina orientada a procesos que combina la gestión de procesos y las mejores prácticas de la industria en una aproximación estandarizada con el objetivo de optimizar los servicios de tecnología de información. También se puede definir como el conjunto de capacidades organizacionales especializadas en proporcionar valor a los clientes en forma de servicios. Para proveer y gestionar de forma eficaz los servicios ofrecidos a lo largo de todo su ciclo de vida, resulta imprescindible definir y adoptar un conjunto de buenas prácticas. Si estas prácticas se agrupan y estructuran en procesos, este conjunto de procesos del área de provisión y gestión 26

28 de servicios, puede utilizarse para ampliar el concepto de ciclo de vida de procesos de software hacia un ciclo de vida de producto completo, que abarque también todos los aspectos relacionados con la provisión y gestión de los servicios. Con el objetivo de crear un marco único que agrupara todos los procesos relacionados con la gestión de los servicios han ido surgiendo diferentes iniciativas que se analizan en esta sección. Estas iniciativas se pueden clasificar en dos categorías bien distintas: Por una parte, algunas de estas iniciativas se han centrado en la creación y desarrollo de nuevos modelos, normas o estándares específicos de calidad de servicios. Dentro de este grupo, las más destacadas son ITIL (Information Technology Infrastructure Library) e ISO/IEC Por otra parte, dada la orientación a procesos en la gestión de servicios de tecnología de la información, otros proyectos se han basado en la ampliación de los modelos de evaluación y mejora de procesos, como CMMI e ISO/IEC (SPICE), para cubrir los procesos de gestión de servicios. (Inform-IT, 2008) ITIL (Information Technology Infrastructure Library) InformationTechnology Infrastructure Library ( Biblioteca de Infraestructura de Tecnologías de Información ), frecuentemente abreviada como ITIL, Es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para 27

29 servir de guía para que abarque toda infraestructura, desarrollo y operaciones de TI. ITIL, es una colección de las mejores prácticas observadas en la industria de TI. Es un conjunto de libros en los cuales se encuentran documentados todos los procesos referentes a la provisión de servicios de tecnología de información hacia las organizaciones. ITIL por medio de procedimientos, roles, tareas, y responsabilidades se pueden adaptar a cualquier organización de TI, genera una descripción detallada de mejores prácticas, que permitirán tener mejor comunicación y administración en la organización de TI. Proporciona los elementos necesarios para determinar objetivos de mejora y metas que ayuden a la organización a madurar y crecer. (GST, 2011) Figura 1: Ciclo de vida del servicio según ITIL Fuente: (Bon, 2008) 28

30 En la Figura 1, se muestra el ciclo de vida del servicio según ITIL, la cual consta de cinco fases que son: Estrategia del servicio, esto permite tratar la gestión de servicio no solo como una capacidad sino como un activo estratégico. Diseño del servicio, cubre el proceso de transición para la implementación de nuevos servicios o su mejora. Transición del servicio, cubre el proceso de transición para la implementación de nuevos servicios o su mejora. Operación del servicio, cubre las mejores prácticas para la gestión del día a día en la operación del servicio y mejora continua del servicio, proporciona una guía para la creación y mantenimiento del valor ofrecido a los clientes a través de un diseño, transición y operación del servicio optimizado. A. OPERACIÓN DEL SERVICIO: La fase de operación del servicio es, sin duda, la más crítica entre todas, la percepción que los clientes y usuarios tengan de la calidad de los servicios prestados depende en última instancia de una correcta organización y coordinación de todos los agentes involucrados. Todas las otras fases del ciclo de vida del servicio tienen como objetivo último que los servicios sean correctamente prestados aportando el valor y la utilidad requerida por el cliente con los niveles de calidad acordados. Es evidente que de nada sirve una correcta estrategia, diseño y transición del servicio si falla la entrega. Los principales objetivos de la fase de operación del servicio incluyen: Coordinar e implementar todos los procesos, actividades y funciones necesarias para la prestación de los servicios acordados con los niveles de calidad aprobados. Dar soporte a todos los usuarios del servicio. Gestionar la infraestructura tecnológica necesaria para la prestación del servicio. 29

31 Uno de los aspectos esenciales en la operación del servicio es la búsqueda de un equilibrio entre estabilidad y la capacidad de respuesta. La organización de TI no debe comprometerse en la prestación de servicios para los que carezca de capacidad tecnológica o los necesarios recursos humanos ni tampoco caer en el exceso de la infraestructura TI encareciendo innecesariamente el coste de los servicios prestados. Los principales procesos asociados directamente a la fase de operación del servicio son: Gestión de Eventos: Responsable de monitorizar todos los eventos que acontezcan en la infraestructura TI con el objetivo de asegurar su correcto funcionamiento y ayudar a prever incidencias futuras. Gestión de Incidencias: Responsable de registrar todas las incidencias que afecten a la calidad del servicio y restaurarlo a los niveles acordados de calidad en el más breve plazo posible. Petición de Servicios TI: Responsable de gestionar las peticiones de usuarios y clientes que habitualmente requieren pequeños cambios en la prestación del servicio. Gestión de Problemas: Responsable de analizar y ofrecer soluciones a aquellos incidentes que por su frecuencia o impacto degradan la calidad del servicio Gestión de Acceso a los Servicios TI: Responsable de garantizar que sólo las personas con los permisos adecuados pueda acceder a la información de carácter restringido. (OverTI, ) 30

32 GESTIÓN DE INCIDENCIAS El proceso de gestión de incidencias cubre todo tipo de incidencias, ya sean fallos, preguntas o consultas planteadas por usuarios al personal técnico o bien detectado automáticamente por herramientas de monitorización. ITIL, define una incidencia como: Una incidencia es una interrupción no planificada o una reducción de calidad de un servicio de TI. El fallo de un elemento de configuración que no haya afectado todavía al servicio también se considera una incidencia. (Bon, 2008) El principal objetivo del proceso de gestión de incidencias es volver a la situación normal lo antes posible y minimizar el impacto sobre los procesos del negocio. A. Ámbito de gestión de incidencias: La gestión de incidencias cubre cualquier evento que interrumpa o pueda interrumpir un servicio. Esto significa que incluye eventos comunicados directamente por los usuarios, ya sea a través del centro de servicio al usuario o con las diversas herramientas posibles. También el personal técnico puede comunicar o registrar incidencias. B. Valor para el negocio: El valor de la Gestión de Incidencias reside en: La posibilidad de controlar y resolver incidencias, lo que significa menor tiempo de parada para el negocio y mayor disponibilidad del servicio. La posibilidad de alinear las operaciones de TI con las prioridades del negocio, ya que la Gestión de Incidencias puede identificar prioridades de negocio y distribuir recursos de forma dinámica. La posibilidad de identificar mejoras potenciales de servicios. La gestión de incidencias tiene efectos muy visibles para el negocio, lo que significa que su valor es más fácil de demostrar que el de otros campos de la 31

33 Operación del Servicio. Esto hace que sea uno de los procesos que antes se implementan en proyectos de Gestión del Servicio. C. Elementos básicos referidos a la gestión de incidencias En la gestión de incidencias hay que tener en cuenta los siguientes elementos: Límites de tiempo: Se deben definir límites de tiempo para todas las fases y emplearlos como objetivos en contratos de soporte. Incidencias graves: Las incidencias graves requieren un procedimiento distinto, con plazos más cortos y mayor nivel de urgencia. Hay que definir que es una incidencia grave y describir todo el sistema de prioridades para incidencias. En ocasiones se confunde una incidencia grave con un problema, pero una incidencia siempre será una incidencia; es posible que aumente su impacto o su prioridad, pero nunca llegará a ser un problema. Un problema es la causa que subyace a una o más incidencias y siempre será una entidad diferenciada. D. Actividades, métodos y técnicas: El proceso de Gestión de Incidencias consta de los siguientes pasos (Ver Figura 2): 1. Identificación 2. Registro 3. Clasificación 4. Priorización 5. Diagnóstico (inicial) 6. Escalado 7. Investigación y diagnóstico 8. Resolución y recuperación 9. Cierre 32

34 Desde Gestión de Eventos Llamada Telefónica del Usuario Correo Electrónico al Personal técnico Identificación del incidente Registro del incidente Categorización del incidente Petición de servicio Gestión de peticiones Priorización del incidente Procedimientos para incidentes graves Incidente grave Diagnóstico inicial Se necesita escalado inicial Investigación y diagnóstico Resolución y recuperación Cierre de la incidencia FIN Figura 2: Proceso de Gestión de incidencias. Fuente: Elaboración propia 33 Nivel 2/3 de escalado funcional

35 Una incidencia no se empieza a gestionar hasta que se sabe que existe. A esto se le llama identificación de la incidencia. Desde el punto de vista del negocio, la práctica generalmente aceptada consiste en esperar con el Centro de Servicio al Usuario. La organización tiene que intentar monitorizar todos los componentes importantes, de manera que los fallos reales o potenciales se puedan detectar lo antes posible y se pueda iniciar el proceso de Gestión de incidencias. En el caso ideal, las incidencias se resuelven antes de que tengan un impacto sobre los usuarios. Todas las incidencias deben quedar registradas con todos sus datos, incluyendo fecha y hora. Es lo que se llama registro de incidencia y afecta tanto a las incidencias recibidas a través del Centro de Servicio al Usuario como a las que se detectan automáticamente con un sistema de monitorización de eventos. Para disponer de un registro histórico completo hay que registrar toda la información sobre la naturaleza de la incidencia. Si la incidencia se traslada a otros grupos de soporte, estos tendrán a su disposición toda la información que necesiten. Se debe registrar, como mínimo: Un número de referencia exclusivo. La categoría de la incidencia. La prioridad de la incidencia. El nombre/identificador de la persona y/o grupo que registró la incidencia. Una descripción de síntomas. Las actividades realizadas para resolver la incidencia. Se deben utilizar los códigos apropiados de clasificación de incidencias para documentar los distintos tipos de llamadas. Esto tendrá importancia más adelante, cuando se analicen los tipos y frecuencias de incidencias para identificar 34

36 tendencias que se pueden usar en Gestión de Problemas, Gestión de Proveedores y otras actividades de la Gestión de servicios de TI. Cuando se registra una incidencia, es posible que los datos de los que se dispone estén incompletos o sean incorrectos. Por ello conviene comprobar la clasificación de la incidencia y actualizarla para que se cierre la llamada. Un ejemplo de incidencia categorizada es el siguiente: software, aplicación, seguridad, redes. Otro aspecto importante en el registro de incidencia es la asignación del código de prioridad correcto. Los agentes y herramientas de soporte utilizan este código para determinar cómo deben tratar la incidencia. Por lo general, la prioridad de una incidencia se puede determinar a partir de su urgencia e impacto (indicado por el número de usuarios a los que afecta). Cuando un usuario comunica una incidencia al centro de servicio al usuario, el agente del centro debe intentar registrar el mayor número posible de síntomas de la incidencia a modo de un primer diagnóstico. También tiene que intentar determinar qué es lo que ha fallado y cómo se podría corregir. En este contexto pueden resultar muy útiles los guiones de diagnóstico y la información sobre errores conocidos. Si es posible, el agente del centro de atención al usuario resuelve la incidencia inmediatamente y la cierra. Si resulta imposible, el agente debe escalar la incidencia. Esto puede hacer de dos maneras: 1) Escalado funcional: Si está claro que el centro de servicio al cliente no puede resolver (con la rapidez suficiente) la incidencia, ésta debe ser escalada inmediatamente para recibir un nivel de soporte más alto. Si la organización tiene un grupo de segunda línea de soporte y el centro de servicio al cliente 35

37 cree que ese grupo puede resolver la incidencia, se envía la incidencia a la segunda línea de soporte no puede resolverla, tiene que ser escalada al grupo de tercera línea de soporte. 2) Escalado jerárquico: Los correspondientes gestores de TI deben ser avisados en el caso de las incidencias más serias (de prioridad 1, por ejemplo). También se utiliza el escalado jerárquico si no se cuenta con los recursos adecuados para resolver la incidencia. El escalado jerárquico consiste en ir ascendiendo niveles en la cadena de mando de la organización para que los altos responsables conozcan la incidencia y puedan adoptar las medidas oportunas, como asignar más recursos o acudir a suministradores. Investiga qué es lo que ha fallado y realiza un diagnóstico. Todas estas actividades deben quedar documentadas en un registro de incidencias para disponer de una imagen completa de las actividades realizadas. En el caso de incidencias en las que el usuario solo esté buscando información, en el centro de servicio al cliente debe ser capaz de responder rápidamente y resolver la petición de servicio. Si se ha determinado una posible solución, lo siguiente que hay que hacer es implementarla y probarla. En eso consiste la resolución y recuperación. Se pueden llevar las siguientes acciones: Pedir al usuario efectúe determinadas operaciones en su ordenador. El centro de servicio al usuario puede ejecutar la solución de forma centralizada o utilizar software remoto para controlar el ordenador del usuario e implementar una solución. Pedir a un suministrador que resuelva el error. 36

38 El grupo de soporte devuelve la incidencia al centro de servicio al usuario y este procede a cerrar la incidencia, comprobando antes que ha sido resuelta y que los usuarios estén satisfechos con la solución. También tiene que cerrar la clasificación, comprobar que el usuario está satisfecho, actualizar la documentación de la incidencia, determinar si se podría volver a producirla misma incidencia y decidir si hay que adoptar alguna medida para evitarlo. Una vez hecho todo esto, la incidencia se puede cerrar formalmente MÉTRICAS DE LA GESTIÓN DE INCIDENCIAS Las métricas hacen posible evaluar la eficacia, la eficiencia y la operación del proceso de gestión de incidencias. Los siguientes son ejemplos de incidencias: El número total de incidencias. Tiempo de resolución de incidencias. Tiempo de diagnóstico de incidencias. Número y porcentaje de incidencias graves. El porcentaje de incidencias gestionadas en el tiempo acordado. La gestión de incidencias debe hacer frente a las siguientes dificultades: Detectar incidencias lo más rápidamente posible. Convencer a todo el personal (Tanto usuarios como equipo técnico) de que se deben registrar todas las incidencias y animarles a usar herramientas para resolver incidencias por sí mismos. Disponibilidad de información sobre problemas y errores conocidos para que el personal de gestión de incidencias puede aprender de incidencias anteriores y conocer el estado de las soluciones 37

39 Integración con el sistema de gestión de configuración para determinar la relación entre elementos de configuración y hacer que la primera línea de soporte pueda consultar datos históricos de estos elementos. Integración en el proceso de gestión de nivel de servicio para que la gestión de incidencias pueda determinar correctamente el impacto y la prioridad de incidencias así como definir y ejecutar procedimientos de escalado. Los siguientes factores críticos de éxito son básicos para una buena gestión de incidencias: Un buen centro de servicios. Objetivos claramente definidos en el SLA. Personal de soporte orientado hacia el usuario, con buena formación técnica y con las competencias adecuadas a todos los niveles del proceso. Herramientas de soporte integradas para controlar y gestionar el proceso Acuerdos de nivel operativo y contratos de soporte para definir la manera en que se debe comportar todo el personal de soporte. Los riesgos para la gestión de incidencias son: Un número de incidencias tan elevado que no se puede gestionar en los plazos previstos debido a la falta de recursos con la formación necesaria. Incidencias que no se resuelvan debido al uso de herramientas de soporte inadecuadas. Ausencia de buenas fuentes de información por falta de integración o herramientas adecuadas. Falta de coincidencia entre los objetivos y acciones debido a acuerdos de nivel operativo y contratos de soporte no alineados o inexistentes. 38

40 SOPORTE TÉCNICO El soporte técnico es un rango de servicios que proporcionan asistencia con el hardware o software de los equipos de cómputo (Computadora, laptop, impresora, scanner, fotocopiadora, etc.). En general los servicios de soporte técnico tratan de ayudar al usuario a resolver determinados problemas con alguno de sus equipos de cómputo. El soporte técnico se puede dar por distintos tipos de medio, incluyendo el correo electrónico, chat, software de aplicación, faxes. El más común es por teléfono. Niveles de soporte: Cuando el soporte está debidamente organizado, se puede dar varios niveles de soporte, donde el soporte nivel 1 es el que está en contacto directo con el usuario y que soluciona las incidencias triviales, soporte nivel 2, daría soporte al nivel que está por debajo y a este nivel llega la información algo filtrada y así sucesivamente. El soporte o asistencia técnica está a menudo subdividido en capas, o niveles, para que así pueda atender de una forma más eficaz y eficiente a una base de negocio o clientes. El número de niveles en los que una empresa organiza su grupo de soporte depende fundamentalmente de las necesidades del negocio, de los objetivos o de la voluntad ya que conllevara la habilidad para servir de forma suficiente a sus clientes o usuarios. A. Soporte de Nivel (L1) Este es el nivel de soporte inicial, responsable de las incidencias básicas del cliente, es sinónimo de soporte de primera línea, soporte de nivel uno, línea 1 de soporte y otras múltiples denominaciones referentes a las funciones de soporte de nivel técnico básico. El principal trabajo de un especialista de nivel 1, es reunir toda la información del cliente y determinar la incidencia mediante el análisis de 39

41 los síntomas y la determinación del problema subyacente cuando se analizan los síntomas, es importante para el técnico de soporte identificar qué es lo que el cliente está intentando llevar a cabo de forma que no se pierda tiempo intentando resolver un síntoma en lugar de un problema una vez que se ha logrado identificar el problema subyacente, el especialista puede comenzar a prestar la verdadera asistencia iterando de forma ordenada sobre el catálogo de posibles soluciones disponibles. Los especialistas de soporte técnico en este grupo habitualmente manejan problemas simples de resolución sencilla, El personal a este nivel tiene un conocimiento entre básico y general del producto o servicio y no siempre ha de tener la competencia necesaria para resolver problemas complejos. No en vano, el objetivo de este grupo es manejar entre el 70%-80% del de los problemas del usuario antes de concluir en la necesidad de escalar la incidencia a un nivel superior. B. Soporte de Nivel (L2) Está basado especialmente en el grupo donde sus integrantes hacen soporte técnico teniendo en cuentas áreas del conocimiento más especializadas en el área computacional. De esta manera, se deduce que el soporte de segundo nivel lo realizan personas especializadas en redes de comunicación, sistemas de información, sistemas operativos, bases de datos, entre otras. Este nivel tiene por lo menos 1 año en el área de soporte y cuenta con los conocimientos de nivel 1 y con conocimientos de recuperación de información nivel software, manejo de paquetería de oficina a nivel básico y configuración de redes inalámbricas y cableadas en grupos de trabajo. Actualmente se usan manuales o guías donde se muestran los pasos que el usuario debe seguir para resolver, dicho problema, en caso de no llegar a la solución. Se pasara a un soporte en sitio. 40

42 C. Soporte de Nivel (L3) Habitualmente los sistemas de mantenimiento se gestionan con un máximo de tres niveles, siendo el tercer nivel, el de mayor capacidad para resolver problemas, llegando a este nivel, los problemas técnicos de mayor calado o de resolución más avanzada. Es sinónimo de nivel 3, soporte de back-end, la línea de apoyo 3, el apoyo de alto nivel, y varias otras denominaciones que denotan los métodos de solución de problemas a nivel de expertos y de análisis avanzado. Los individuos asignados a este nivel, son expertos en sus campos y son responsables, no solo para ayudar tanto al personal de nivel 1 y nivel 2, sino también para la investigación y desarrollo de soluciones a los problemas nuevos o desconocidos. Tenga en cuenta que los técnicos de nivel 3 tienen la misma responsabilidad que los técnico de nivel 2 en la revisión de la orden de trabajo y evaluar el tiempo ya cumplido con el cliente para que se dé prioridad a la gestión del tiempo y se utiliza lo suficiente para resolver dicha incidencia. Si es posible, el técnico trabajara para resolver el problema con el cliente, ya que puede llegar a ser evidente que el nivel 1 y / o técnicos de nivel 2 simplemente no descubrieron la solución correcta. Al encontrarse con nuevos problemas, sin embargo, el personal de nivel 3 debe determinar primero, si puede o no resolver el problema y si para resolver el problema, necesita requerir información de contacto del cliente para que el técnico pueda disponer de tiempo suficiente para analizar el problema y encontrar una solución. En algunos casos, un tema puede ser tan problemático hasta el punto donde el producto no se puede salvar y debe ser reemplazado. (Cuadros Gómez, 2011) 41

43 SOPORTE TÉCNOLÓGICO PARA LA GESTION DE SERVICIO La gestión de servicio es una disciplina basada en procesos, enfocada a alinear los servicios de TI proporcionados, con las necesidades de la organización, poniendo énfasis en los beneficios que puede obtener el cliente final. Supone dejar de centrarse en el aspecto tecnológico del negocio para dar un mayor pero a la calidad de los servicios ofrecidos y la relación con los clientes. Los retos de la gestión de TI son coordinar y trabajar en alianza con el ámbito del negocio para poder ofrecer servicios TI de alta calidad. Para ello debe adoptarse una posición más orientada al cliente y al negocio en la entrega de los servicios junto a una mayor optimización de costes. Es importante tener claro que cuando los procesos de la organización se encuentren bien definidos, también la selección, implementación y uso de la herramienta seleccionada será más fácil y más rápido. Las organizaciones deben prestar atención a sus procesos y asegurarse de que simplemente no están adquiriendo una herramienta para solucionar los problemas de gestión. A. Requisitos tecnológicos para la gestión de servicios: Como hemos descrito previamente, las herramientas permiten a los procesos trabajar con más eficacia, así como aumentar la eficiencia en la organización. Con la ayuda de las herramientas, el diseño de la gestión de la información de vuelve más eficiente y los puntos débiles son más fácilmente identificados. Esto conduce a ahorros de costes y aumento de la productividad, que a su vez puede conducir a una mayor calidad de los servicios de TI. Los beneficios de la utilización de herramientas son la centralización, automatización e integración de los procesos clave en la gestión de servicios. Los 42

44 datos pueden ser analizados, lo que proporciona la capacidad de identificar tendencias y permite la aplicación de medidas preventivas. B. Tecnologías aplicables en la gestión de incidencias Los procesos incluidos en la fase de operación del servicio se refieren a la operativa del día a día en la gestión de los servicios, la tecnología juega un papel importante en el funcionamiento del mismo. Las herramientas relacionadas a la fase operación de servicio: 1. Autoayuda: Es la funcionalidad que permite a los usuarios ayuda para resolver sus propias dificultades, de una manera rentable. Puede estar compuesta por una interfaz web que incluye elementos tales como preguntas frecuentes (FAQ) How-Tos, con capacidades de búsqueda para guiar a los usuarios a través de la información disponible en el sistema. 2. Gestión de worflows: Es necesario disponer de un motor de flujos de trabajo que permita definir y controlar los procesos, tales como por ejemplo el ciclo de vida de las incidencias. Esto permite establecer la secuencia de las actividades que forma un proceso y acciones a realizar: de alerta, de escala, actividades, etc. Las cuales son controladas automáticamente. Con ello permitimos ser preventivos ante cualquier incidencia, bien por que esta sea pasada por alto o se retrase. 3. Sistema de gestión de la configuración integrado (CMS): El sistema de gestión de la configuración almacena los activos de infraestructura de TI, componentes, servicios y otros elementos de configuración: cualquier cosa que las organizaciones de TI consideran que deben tener información acerca de su estado y de su trazabilidad en el sistema. Debe estar relacionado con incidentes, problemas, errores conocidos y bases de datos de cambios. 43

45 4. Utilidad de diagnóstico: Los servicios de diagnóstico son útiles para los grupos de apoyo en el centro de servicios, será necesario contar con grupos de especialistas de apoyo y los proveedores, que pueden especificar detalles sobre los fallos que pueden ocurrir, así como podrán responder a las preguntas claves para identificar que salió mal y los detalles de las acciones que ayuden a la resolución. 5. Bases de datos de errores conocidos: Una base de datos error conocido debe almacenar todos los detalles de los incidentes anteriores, los problemas y soluciones para apoyar un rápido diagnóstico y resolución de incidentes y problemas futuros. (Terreno Cárdenas, 2012) ENFOQUE BASADO EN PROCESOS Como primer paso para plantear la manera de abordar el enfoque basado en procesos en un modelo de gestión de calidad, convierte hacer una reflexión acerca de cómo las normas de gestión de calidad establecen las estructuras para llevarlas a cabo. Los pasos que establece la metodología enfocada en procesos constan de los siguientes pasos: a. Comprender y cumplir con los requisitos del proceso. b. Considerar los procesos en términos que aporten valor. c. Obtener los resultados del desempeño y eficacia del proceso. d. Mejorar continuamente los procesos con base en mediciones objetivas. El énfasis del enfoque basado en procesos por estos aspectos sirve de punto de partida para justificar la estructura de la propia norma y para trasladar este enfoque a los requisitos de manera particular. De hecho, la trascendencia del enfoque basado en procesos es tan evidente que los propios contenidos se 44

46 estructuran con este enfoque, lo que permite a su vez concebir y entender los requisitos del modelo. Como muestra de lo anterior, en la siguiente Figura 3 se recogen gráficamente los vínculos entre los procesos que se introducen en los capítulos del modelo de gestión de incidencias. Figura 3: Modelo de gestión de calidad. Fuente: (Instituto de Andaluz de Tecnología, 2012) 45

47 2.3. DEFINICIÓN DE TÉRMINOS BÁSICOS Acuerdo de nivel de servicio (SLA): Es un acuerdo entre un proveedor de servicios de TI y un cliente. El SLA describe el servicio de TI, documenta las metas de niveles de servicio y especifica las responsabilidades del proveedor de servicios de TI y del cliente. (ITIL - Office of Government Commerce, 2009) Arquitectura: La estructura de un sistema o servicio de TI, incluyendo las relaciones entre los componentes y de estos con el ambiente en el que están. La arquitectura también incluye las normas y directrices que guían el diseño y evolución del sistema. (ITIL - Office of Government Commerce, 2009) Base de datos de errores conocidos: Contiene todos los registros de errores conocidos, además forma parte del sistema de gestión de conocimientos de servicios. (ITIL - Office of Government Commerce, 2009) Clasificación: El acto de asignarle una categoría a algo. La clasificación se usa para asegurar una gestión y el uso de informes consistentes. (ITIL - Office of Government Commerce, 2009) Cliente: Alguien que compra bienes o servicios. El cliente de un proveedor de servicios de TI es la persona o el grupo que define y se muestra de acuerdo con las metas de niveles de servicio. El termino cliente se usa a veces de modo informal para referirse a los usuarios. (ITIL - Office of Government Commerce, 2009) CMDB: Base de datos de la gestión de configuración, La CMDB es un repositorio de información donde se relacionan todos los componentes de un sistema de información, ya sean hardware, software, documentación (ITIL Office of Government Commerce, 2009). 46

48 Diagnóstico: Identificar una alternativa de solución para un incidente o causa raíz de un problema. (ITIL - Office of Government Commerce, 2009) Escalado: Una actividad que obtiene recursos adicionales cuando se necesitan estos para satisfacer las metas de niveles de servicio o las expectativas de los clientes. (ITIL - Office of Government Commerce, 2009) Error Conocido: Es un problema del que se tiene una causa raíz documentada y una solución provisional. (ITIL - Office of Government Commerce, 2009) Gestión: Conjunto de trámites que se llevan a cabo para resolver un asunto Incidencia: Es una interrupción no planificada o una reducción de calidad de un servicio de TI. El fallo de un elemento de configuración que no haya afectado todavía al servicio también se considera una incidencia. (Inform-IT, 2008) ITIL: Conjunto de mejores prácticas para la gestión de servicios de TI, consiste en una serie de publicaciones que aconsejan sobre la provisión de servicios de TI de calidad, y sobre los procesos y las instalaciones necesarias para soportarlos. (Inform-IT, 2008) Modelos de incidencia: Un modelo de incidencia es una manera de determinar los pasos necesarios para ejecutar correctamente un proceso (en este caso, el procesamiento de ciertos tipos de incidencias), lo que significa que las incidencias estándar se gestionarán de forma correcta y en el tiempo establecido Proceso: Se denomina proceso al conjunto de acciones o actividades sistematizadas que se realizan o tienen lugar con un fin. (ITIL - Office of Government Commerce, 2009) 47

49 Servicio: Medio para entregar valor a los clientes facilitando resultados que clientes quieren lograr sin la propiedad de costes y riesgos específicos. (ITAA, 2013) Solución provisional: Reducción o eliminación del impacto de una incidencia o problema para la que aún no existe una solución completa (ITIL Office of Government Commerce, 2009) Soporte técnico: Asistencia que brinda el personal de TI, para que los usuarios puedan hacer uso de los servicios que brinda el área de TI (ITIL - Office of Government Commerce, 2009) Tecnología de la Información: Según lo definido por la asociación de la tecnología de información de América (ITAA) es el estudio, diseño, desarrollo, implementación, soporte o dirección de los sistemas de información computarizados, en particular de software de aplicación y hardware de computadoras. (ITAA, 2013) 48

50 CAPÍTULO III. MATERIALES Y MÉTODOS 49

51 3.1. TRABAJO EXPERIMENTAL TIPO Y DISEÑO DE LA INVESTIGACIÓN La presente investigación, de acuerdo a las características del problema, los objetivos y la hipótesis, se enmarcó dentro del tipo experimental, donde el diseño de la investigación es pre-experimental con pre-test y post-test. Los diseños preexperimentales no presentan grupo de control. El grupo experimental estuvo conformado por los incidentes diagnosticados del servicio de soporte técnico en la Universidad Nacional del Altiplano - Puno. La representación gráfica es la siguiente: G1 : O1 X O2 Donde: G1 : Grupo experimental. X: Tratamiento con el modelo de gestión de incidencias basado en ITIL O1 : Test antes del experimento. O2 : Test después del experimento. Este diseño con grupo experimental permitió la comparación de resultados Pretest y Post-test, con un alto grado de probabilidad, ante la situación con modelo de gestión de incidencias basado en ITIL y sin modelo (variable independiente), ha sido factor determinante en la reducción del tiempo de diagnóstico de incidentes del servicio de soporte técnico en la Universidad Nacional del Altiplano (variable dependiente). 50

52 POBLACIÓN Y MUESTRA Población La población objeto de estudio está constituida por los incidentes reportados por los usuarios del servicio de soporte técnico ofrecido por la Universidad Nacional del Altiplano a través de la Oficina de Tecnología de la Universidad Nacional del Altiplano Puno Muestra Para la prueba de hipótesis, el número de la muestra se determinó a criterio no probabilístico, siendo objeto de estudio los 54 incidentes reportados durante el periodo mayo y junio del año SISTEMA DE VARIABLES DEFINICIÓN DE VARIABLES Independiente: Situación sin modelo : 0 Situación con modelo : 1 Dependiente: Tiempo de diagnóstico de incidencias del servicio de soporte técnico. 51

53 OPERACIONALIZACIÓN DE VARIABLES Tabla 1: Operacionalización de variables. de incidencias basado en ITIL DIMENSIONES INDICADORES ESCALA - Con modelo Sin modelo Fecha y hora de reporte del - Tiempo Situación servicio de soporte técnico diagnóstico de incidencias del Variable dependiente: Tiempo de Variable Independiente: Modelo de Gestión VARIABLES Tiempo: Fecha y hora de reportado incidente. el incidente, Fecha y hora de expresado - Fecha y hora de diagnosticado diagnóstico del incidente minutos del incidencia. Fuente: Elaboración propia MATERIAL EXPERIMENTAL MÉTODOS DE RECOPILACIÓN DE DATOS Para la recopilación de datos se tomó las siguientes consideraciones específicas, según la metodología de la investigación científica: Identificar la información que se requiere para hacer la investigación. Señalar la clase de información que se requiere. Especificar los requerimientos que se tiene que emplear para conseguir la información. 52 en

54 Señalar las fuentes de información (dónde se obtendrá la información). Estos procedimientos sistemáticos y estandarizados usados en la investigación contribuyeron a obtener medidas variables y de esta manera se pudo proporcionar evidencias empíricas a la investigación. Luego se procedió a obtener las fuentes de información primarias mediante: - Encuestas: Se ha utilizado una encuesta dirigida al personal encargado de soporte técnico del actual manejo de incidencias, en la que se ha planteado preguntas (Ver Anexo N 1), considerando los atributos del modelo de gestión de incidencias basado en ITIL, que han posibilitado respuestas cualitativas y valorativas referentes al proyecto, dichas respuestas han sido sistematizadas con el fin de establecer cuáles son las necesidades y/o requerimientos de los usuarios en relación al nuevo modelo y sus funcionalidades. - Registro de observación: Se ha utilizado el registro de observación (Ver Anexo N 2) para obtener datos del actual modelo de gestión de incidencias. Este registro de observación se realizó en tiempo real con el propósito de determinar el tiempo de diagnóstico de incidencias y las cualidades del actual manejo de gestión de incidencias MÉTODO DE TRATAMIENTO Y ANÁLISIS DE DATOS Para el tratamiento de los datos se realizó con el programa estadístico SPSS versión 22, tomando en cuenta el siguiente procedimiento: - Recolección y evaluación de datos. - Codificación de datos. - Tabulación de datos. - Presentación de los resultados en cuadros y tablas estadísticas. 53

55 - Interpretación de los resultados en medida y desviación estándar. Se realizó el análisis y la explicación de los resultados de la investigación con modelo y sin modelo en contraste con la hipótesis de la investigación y el sustento teórico, para así extraer las conclusiones respectivas MATERIAL APLICATIVO METODOLOGÍA DE DESARROLLO DEL MODELO La metodología empleada para el desarrollo de la tesis fue orientada a procesos la cual consta de los siguientes pasos: Definir de manera sistemática las actividades que componen el proceso de gestión de incidencias. Identificar las interrelaciones entre los subprocesos. Definir los roles respecto al proceso de gestión de incidencias. Analizar y medir los resultados de la capacidad y eficacia del proceso. Mejora continua del proceso HARDWARE Y SOFTWARE DE DESARROLLO Hardware El hardware utilizado en el desarrollo de la investigación, es el siguiente: - 01 Portátil Computadora de escritorio - 01 Impresora: HP Software El software utilizado en el desarrollo de la investigación, es el siguiente: Sistema operativo: Windows 7 Professional y Ultimate. - Lenguaje de programación PHP. - Gestor de Base de Datos: MySQL. 54

56 - Modelador de Base de Datos: MySQL Workbench 5.2 CE. - Framework: Codeigniter v Entorno de desarrollo Web: Apache v2 - Entorno de programación: SublimeText2 55

57 CAPÍTULO IV. RESULTADOS Y DISCUSIÓN 56

58 4.1. DIAGNÓSTICO Y DEFINICIÓN DE LOS REQUISITOS DEL MODELO DE GESTIÓN DE INCIDENCIAS Para recopilar la información requerida del actual manejo de incidentes se utilizaron las siguientes herramientas: Entrevistas personales y grupales como fuente primaria a las personas involucradas en las actividades actuales relacionadas con el proceso de manejo de incidentes y los responsables del proceso (personal responsable de soporte técnico), de acuerdo a la ficha de entrevista ver Anexo N 1. La observación para registrar lo que ocurre directamente en el lugar de trabajo, para ello se utilizó la ficha de observación del Anexo N 2. Análisis de información de fuentes secundarias de propiedad de la Oficina de Tecnología Informática que fueron autorizados para efectos del presente trabajo de investigación, dentro de las fuentes secundarias se tiene: documentos remitidos solicitando atención de incidentes. En general, el diagnóstico incluye la recolección y el análisis de toda documentación útil, la elaboración del cuestionario y el análisis de los resultados. El diagnostico se basó en la determinación del grado de madurez de la situación actual del manejo de incidentes, para ello se utilizó el modelo que permite calcular el nivel de madurez del proceso, de acuerdo a los criterios propuesto por la OGC (Office of Government Comerce de UK), que gobierna la práctica de ITIL a nivel mundial. Esto permite validar el nivel de madurez de la organización, acotados al proceso de gestión de incidencias. También garantiza a la entidad un modelo universal reconocido que puede ser evaluado por cualquier ente certificador reconocido. 57

59 DESCRIPCIÓN DE LA OFICINA DE TÉCNOLOGÍA INFORMÁTICA. La Oficina de Tecnología Informática es un órgano de apoyo en las tareas que cumple Rectorado, cuyo propósito es lograr una gestión administrativa moderna, desconcentrada, eficiente y eficaz, siendo soporte de la actividad académica, investigativa y de proyección social. Siendo sus funciones: Normar el funcionamiento adecuado y eficiente uso de las redes en la institución. Mantener el soporte técnico y los estándares de seguridad en el manejo de la información. Desarrollar sistemas de información en el proceso de automatización dentro de la gestión administrativa y académica. Facilitar con servicios informáticos a los estudiantes, docentes y personal administrativo de la institución. Organización: JEFATURA UNIDAD DE ADMINISTRACIÓN DE REDES Y SISTEMAS INFORMÁTICOS UNIDAD DE DESARROLLO Y MANTENIMIENTO DE SISTEMAS UNIDAD DE SOPORTE TÉCNICO Y CAPACITACIÓN Figura 4: Organigrama de la Oficina de Tecnología Informática. Fuente: Elaboración propia 58

60 Servicios brindados: Los servicio ofrecidos por la Universidad Nacional del Altiplano a través de la oficina de Tecnología informática es de acuerdo a la Tabla N 2. Tabla 2: Catálogo de servicios de la Oficina de Tecnología Informática Prioridad Alta Media - Baja - Servicio Sistema módulo matriculas Sistema modulo impresión de actas Módulo pagos Módulo registro de comensales Modulo registro de proyectos de investigación. Internet Telefonía IP - - Usuarios Coordinadores académicos Personal de registro académico. Personal de caja Personal de Bienestar universitario Coordinador de investigación - Centros de cómputo de las escuelas profesionales - Personal administrativo Fuente: Elaboración propia SITUACIÓN ACTUAL DE LA GESTIÓN DE INCIDENTES El actual manejo de la gestión de incidencias, no se encuentra estandarizado por lo que existen cinco puntos de contacto para reportar los incidentes. Tal como se puede apreciar en la Figura 5, el usuario puede comunicar por escrito o de manera verbal, al Jefe directamente o al personal del área de soporte, del área de desarrollo o del área de redes. 59

61 SITUACIÓN ACTUAL Incidente Responsable de soporte técnico Jefe de OTI Incidente Incidente El usuario a través de documento solicitando la soluciòn del incidente Responsable de la administración de sistemas Incidente Usuario El usuario pone de conocimiento de manera directa al personal técnico acerca del incidente Responsable de redes Figura 5: Diagrama de flujo de la situación actual. Fuente: Elaboración propia En el actual manejo de incidencias, se observa que no existe un criterio para categorizar las incidencias, siendo el usuario quien determina con qué área debe de contactarse para el diagnóstico de las incidencias ocurridas. Asimismo, no se documentan el registro ni la solución de los mismos; Todos las incidencias son atendidos de acuerdo al orden de reporte o de acuerdo al criterio que toma el personal encargado de su diagnóstico, el diagnóstico de las incidencias se tratan en un solo nivel. 60

62 ANÁLISIS DE LA SITUACIÓN ACTUAL En este apartado se muestra una comparación de las actividades del proceso de gestión de incidencias, propuesto por ITIL; Con el actual manejo de la gestión de incidencias, a fin de establecer las diferencias y semejanzas. Tabla 3: Cuadro comparativo Actividades del proceso de gestión de incidencias propuesto por ITIL Registro de incidencias Todas las incidencias deben quedar registradas incluyendo fecha y hora. Es lo que se llama registro de incidencias recibidas a través del centro de servicio al usuario como a las que se detectan automáticamente con un sistema de monitorización de eventos. Si la incidencia se traslada a grupos de soporte, estos tendrán la disposición toda la información que necesite se debe registrar como mínimo: - Número de referencia exclusivo - La categoría de la incidencia - La urgencia - Prioridad - El nombre /identificados de la persona y/o grupo que registro la incidencia. - Una descripción de síntomas. - Las actividades realizadas para resolver la incidencia. Clasificación de los incidentes Tiene como objetivo principal recopilar toda la información que pueda ser utilizada para la resolución del mismo. El proceso de clasificación debe implementar, al menos, los siguientes pasos: - Categorización: se asigna una categoría dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. - Establecimiento de prioridad. - Asignación de recursos: si el centro de servicios no puede resolver el incidente en primera instancia, designara al personal de soporte técnico responsable de su resolución (segundo nivel o tercer nivel). 61 Actual manejo de gestión de incidencias llevado a cabo por la Oficina de Tecnología Informática No se registran las incidencias ocurridas, si el usuario desea solicitar el servicio de soporte técnico, es a través de un oficio dirigido al jefe de la oficina o comunicación de manera directa al personal que labora en la Oficina de Tecnología Informática. No se clasifican los incidentes, se atienden de acuerdo a la fecha de envió de oficios o de acuerdo al criterio de cada persona que labora en la Oficina de Tecnología Informática.

63 - Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente. Análisis, resolución y cierre En primera instancia, se examina el incidente con No existe base de conocimientos ya que ayuda de la base de conocimientos para determinar la solución de incidentes no es si se puede identificar con alguna incidencia ya documentada. resulta y aplicar el procedimiento asignado. Si la resolución del incidente se escapa de las posibilidades del centro de servicios este se re direcciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente, se seguirán los protocolos de escalado predeterminados, Cuando se haya solucionado el incidente se: - Confirma con los usuarios la solución satisfactoria del mismo. - Incorpora el proceso de resolución al sistema de gestión de conocimiento del servicio. - Reclasifica el incidente si fuera necesario - Actualiza la información en base de datos de gestión de configuraciones (CMDB) sobre los elementos de configuración (CIs) implica en el incidente. Fuente: Elaboración propia 62

64 MEDICIÓN DEL GRADO DE MADUREZ DE LA SITUACIÓN ACTUAL Con el fin de calcular el nivel de madurez en el que se encuentra el actual manejo de incidencias en la Universidad Nacional del Altiplano, se utilizó el instrumento propuesto por la OGC (Office of Government Comerce de UK), donde se tuvo en cuenta los aspectos considerados en el modelo de madurez propuesto, tal como se puede apreciar en las Tabla 4, Tabla 5, Tabla 6, Tabla 7 y Tabla 8, donde se establece una puntuación para cada criterio a fin de determinar el nivel en que se encuentra el proceso. Los aspectos evaluados son: Visión y Dirección, Personas, Procesos, Tecnología y Cultura. o Visión y dirección: Tabla 4: Nivel de madurez visión y dirección Puntuación Aspecto Nivel de madurez 0 No existe una estrategia de implantación para Inicial la gestión de incidentes 1 Existen actividades planificadas Gestionado 2 Existe una estrategia concreta Definido 3 Objetivos y metas formales documentados y Gestionado acordados. cuantitativamente Planes formalmente publicados, monitoreados y revisados. Bien financiados y con los recursos adecuados Regular, informes planificados y comentarios 4 Planes estratégicos integrados, vinculados con Optimizado los planes del negocio, metas y objetivos. Monitorización continua, medición, presentación de informes y alertas Opiniones vinculadas a un proceso continúo de mejora. Revisiones y / o auditorías periódicas para la eficacia, la eficiencia y la conformidad. Fuente: (Office of Government Commerce, 2011) 63

65 o Personas Tabla 5: Nivel de madurez personas respecto al proceso Puntuación Aspecto 0 Las personas de la entidad no conocen las herramientas que permiten documentar, notificar o registrar incidentes. Las personas de la entidad conocen algunas de las herramientas y servicios pero no tienen una idea clara ni son conscientes de su importancia. Las personas están formalmente capacitados en todos los aspectos de la gestión de incidentes. Roles y responsabilidades claramente definidos y acordados. Objetivos y metas formales. Planes de formación proceso formalizado. Objetivos de negocios alineados y metas formales activamente supervisados como parte de la actividad cotidiana. Roles y responsabilidades de parte de una cultura corporativa global. Fuente: (Office of Government Commerce, 2011) Nivel de madurez Inicial Gestionado Definido Gestionado cuantitativamente Optimizado o Procesos: Tabla 6: Nivel de madurez procesos respecto al proceso Puntuación Aspecto Nivel de madurez No se han creado procedimientos y documentos Inicial estandarizado conocidos por todos. Se tiene procedimientos más o menos Gestionado sistematizados pero no se ha precisado ni comunicado oficialmente. Existen un manual de calidad donde se reflejan los Definido pasos para documentar y seguir procedimientos de forma clara, formalmente notificada por la entidad. Procesos claramente definidos y bien Gestionado publicitados. cuantitativamente Procedimientos, actividades reguladas y programadas. Una buena documentación. Ocasionalmente proceso proactivo. Procesos y procedimientos bien definidos por Optimizado parte de la cultura corporativa. Proceso proactivo y preventivo. Fuente: (Office of Government Commerce, 2011) 64

66 o Tecnología: Tabla 7: Nivel de madurez tecnología respecto al proceso Puntuación Aspecto Nivel de madurez Los sistemas de información están Inicial enfocados hacia la oferta, es decir el departamento de TI ofrece los elementos que considera necesario Los sistemas de información tratan de Gestionado adecuarse a la exigencias de los clientes Las decisiones tecnológicas se toman Definido considerando las variables de beneficio costo y riesgo La recopilación de datos comprende un Gestionado adecuado monitoreo cuantitativamente Datos consolidados retenidos y utilizados para la planificación formal. Arquitectura de herramientas en general Optimizado bien documentado con total integración en todas las áreas de personas, procesos y tecnología Fuente: (Office of Government Commerce, 2011) o Cultura: Tabla 8: Nivel de madurez cultural respecto al proceso Puntuación Aspecto Nivel de madurez La innovación y adecuación al medio no Inicial está presente en los intereses de la entidad. Existen algunas iniciativas para tratar de Gestionado realizar el cambio cultural. Hay una visión planteada que trata de Definido promover la cultura de la innovación con incentivos y apoyo para fomentar el compromiso personal y grupal de los involucrados. Servicio al usuario y orientada a un enfoque Gestionado formal. cuantitativamente Una actitud mejora continua, junto con un Optimizado estratégico enfoque de negocios. La comprensión del valor de las TI a la entidad. Fuente: (Office of Government Commerce, 2011) 65

67 Los niveles estarían entre 0 y 20 puntos, donde cada rango corresponde a un nivel, así: N1 = Entre 0 y 5 puntos N2 = Entre 6 y 10 puntos N3 = Entre 11 y 15 puntos N4 = Entre 15 y 19 puntos N5 = 20 puntos De acuerdo a lo anterior obtenemos la siguiente tabla de medición del grado de madurez del actual manejo incidentes, así: Tabla 9: Nivel de madurez general respecto al proceso. Proceso Gestión de incidentes Visión y Procesos Personas Tecnología Cultura Ptos Nivel dirección Fuente: Elaboración propia. Los resultados obtenidos en la Tabla 9, indica que la entidad se encuentra en un nivel 1 en la gestión de incidente, según cálculo realizado. Lo que significa que: El proceso de gestión de incidentes existe, pero no hay actividad de gestión que la determine, por tanto no se le asigna una importancia notable respecto de los recursos y la intención de la entidad para mejorar este proceso, que carece de fundamento. Este nivel describe que la gestión de incidentes, no se ha iniciado de manera formal. 66

68 REQUISITOS DEL MODELO DE GESTIÓN DE INCIDENCIAS Luego de conocer la situación actual del manejo de incidencias, de realizar el análisis en relación al modelo propuesto por ITIL y del cálculo del grado de madurez de la situación actual, se determinaron lo siguientes requisitos para el modelo de gestión de incidencias: Definir y documentar los procesos, definir las actividades que determinaron el alcance del modelo de gestión de incidencias basado en ITIL, esto de acuerdo a las necesidades de la entidad respecto a la gestión de incidencias. Documentar los roles y responsabilidades, para cada proceso y actividades que comprende el modelo. Proponer las políticas de aplicación del modelo de gestión de incidencias. Implementar una herramienta que permite gestionar las incidencias, de acuerdo al diseño del modelo. 67

69 4.2. DISEÑO DEL MODELO DE GESTIÓN DE INCIDENCIAS BASADO EN ITIL Para el diseño del modelo de gestión de incidencias se tomó en cuenta los requisitos citados en el punto 4.1 del presente documento ENTRADA, ACTIVIDADES Y SALIDA DEL MODELO DE GESTIÓN DE INCIDENCIAS. El modelo de gestión de incidencias, se encuentra comprendido por las actividades de los procesos de este. ENTRADA ACTIVIDADES SALIDA Ciclo de vida del incidente: INCIDENTE REPORTADO - Registro del incidente - Clasificación y soporte inicial - Asignación y escalado - Reparación y recuperación - Cierre de incidente INCIDENTE DIAGNOSTICADO Figura 6: Entradas y salidas del proceso de gestión de incidencias. Fuente: Elaboración propia Según Figura 6, como entrada del proceso de gestión de incidencias se tiene un incidente reportado, cuya salida es el incidente diagnosticado, los procesos definidos forman parte del ciclo de vida del incidente que son: Registro del incidente, Clasificación y soporte inicial, Asignación y escalado, Reparación y recuperación y Cierre del incidente. 68

70 CICLO DE VIDA DEL INCIDENTE Para el proceso de gestión de incidencias se definen los siguientes procesos: o GI01: Registro del incidente. o GI02: Clasificación y soporte inicial. o GI03: Asignación y escalado. o GI04: Reparación y recuperación. o GI05: Cierre de incidente. En la Figura 8, el proceso se inicia con el reporte del incidente por parte del usuario, seguidamente se inicia el proceso del registro del incidente. Una vez concluido se da inicio al proceso de clasificación y soporte inicial; si el incidente es diagnosticado con el soporte inicial se continua con el proceso de cierre de incidentes, de lo contrario se inicia el proceso de asignación y escalado; el procesos clasificación y soporte inicial y el proceso del cierre del incidente son ejecutados por el gestor de incidentes. Y el proceso reparación y recuperación se encuentra a cargo del soporte de nivel 2 y 3. Así mismo a lo largo del ciclo de la vida de incidencias, el incidente pasa por los estados ilustrados en la Figura 7. Cabe indicar que la documentación completa de la gestión de incidencias se encuentra en el Anexo N 4. Cerrado Abierto Incidente Solucionado Escalado Figura 7: Estados del incidente Fuente: Elaboración propia 69

71 USUARIO GESTOR DEL INCIDENTE SOPORTE DE 1/2/N NIVEL INICIO GI01 Registro del incidente 1 Reportar incidente GI02 Clasificación y soporte inicial 2 Incidente solucionado? No GI03 Asignación y escalado GI04 Reparación y recuperación Si GI05 Cierre del incidente FIN Figura 8: Diagrama de flujo del proceso de gestión de incidencias Fuente: Elaboración propia DESCRIPCIÓN DEL PROCESO A continuación en la Tabla 10, se describe el flujo de actividades del proceso de gestión de incidencias. 70

72 Tabla 10: Descripción del proceso de gestión de incidencias ID Actividad Entrada Descripción de la Actividad 1 GI01 GI02 2 Salida Rol Incidente reportado Usuario Incidente registrado Incidente registrado Gestor de incidente Gestor de incidente Actividad Reportar incidencia Incidente detectado Registro del incidente Clasificación y soporte inicial Incidente registrado Incidente registrado Incidente solucionado? Incidente registrado GI03 Asignación escalado y Incidente registrado GI04 Reparación recuperación y Incidente diagnosticado GI05 Cierre incidente del Incidente solucionado Conformidad del usuario Se reporta incidente a por: Teléfono, por intranet, personalmente al centro de servicios. Se registra incidente Se clasifica y determina grado de severidad del incidente, Se busca en la base de datos la solución, si no se encuentra se escala el incidente. SI: Continúa con proceso Gestor de GI03. incidentes NO: Continúa con proceso Soporte de GI Nivel Se asigna o escala el Incidente Gestor del incidente que no es diagnosticado incidente solucionado con el soporte inicial. Se investiga y diagnostica. Incidente Soporte de Se efectúan cambios para diagnosticado 2-3 Nivel implementar la solución, de ser necesario. Si el usuario da su Incidente Gestor de conformidad a la solución cerrado incidentes del incidente, se procede a cerrar el ticket Fuente: Elaboración propia 71

73 PROCESOS DEL MODELO DE GESTIÓN DE INCIDENCIAS En este apartado se muestra en las Figura 8, Figura 9, Figura 10, Figura 11 y Figura 12, se detallan las actividades de los procesos del modelo de gestión de incidencias. - Proceso de registro de incidentes GESTOR DEL INCIDENTE INICIO 1 Registrar el user ID de quien reporta el incidente 2 Registrar Nombre, fecha y hora del incidente 3 Obtener detalles del incidente 4 Tipificar o clasificar incidente 5 Registrar el estado del incidente 6 Comunicar el número de Ticket del incidente FIN Figura 9: Diagrama de flujo del proceso registro de incidentes. Fuente: Elaboración propia 72

74 - Descripción del proceso Tabla 11: Proceso registro de incidentes ID Actividad Actividad 1 Registrar el user ID de quien reporta el incidente 2 Registrar Nombre, Fecha y hora del incidente 3 Obtener detalles del incidente 4 Tipificar Clasificar incidente o 5 Registrar estado incidente el del 6 Comunicar el número de Ticket Entrada Descripción de la Actividad Salida Rol Incidente Registrar el user ID de la Incidente en Gestor de reportado persona que comunica el registro incidentes incidente. Incidente Verificar el registro de la en fecha y hora en que se registro presentó el incidente y asignar prioridad (Alta, Media o Baja). Incidente Registra detalles del en incidente, tales como registro Software/hardware afectado, tiempo de inactividad, personas afectadas. Incidente Tipificar y Clasificar el en incidente reportado. registro (Hardware, Software o Redes) Incidente Registrar el incidente en en estado ABIERTO y generar el registro número de ticket en el registro de incidentes. Número Comunicar al usuario el de Ticket número de ticket de la siguiente manera: -Si el reporte del incidente es por teléfono el Agente le indica el número del ticket. -Si el reporte es por la intranet la asignación del número de ticket es inmediato asignado por la herramienta de registro de incidentes. Fuente: Elaboración propia 73 Incidente en Gestor de registro incidentes Incidente en Gestor de registro incidentes Incidente en Gestor de registro incidentes Incidente registrado Gestor de incidentes Número de Gestor de ticket incidentes comunicado

75 - Proceso de clasificación y soporte inicial. GESTOR DEL INCIDENTE INICIO 1 Buscar solución en la base de datos 2 Existe solución en la base de datos? No 3 Investigar y diagnosticar Si 4 Ejecutar solución FIN Figura 10: Diagrama de flujo del proceso clasificación y soporte inicial. Fuente: Elaboración propia - Descripción del proceso Tabla 12: Proceso clasificación y soporte inicial ID Actividad Actividad 1 Buscar solución 2 3 Entrada Descripción de la actividad Salida Rol Incidente registrado Buscar en la base de datos si Resultado de Gestor existe una solución temporal la búsqueda de de o definitiva para el incidente. soluciones en incident la base de es datos Existe Resultado de la Si: Continúa con actividad 4 Gestor solución en búsqueda de No: Continúa con actividad 3 de la base de soluciones en la incident datos? base de datos es Investigar y Incidente diagnosticar registrado Comparar el incidente en el Incidente Gestor registro. Diagnosticar luego diagnosticado de 74

76 ID Actividad 4 Actividad Ejecutar solución Entrada Incidente diagnosticado Ejecutar solución Descripción de la actividad Salida de revisar, investigar y analizar la información obtenida a través de la data histórica del incidente Comunicar al usuario para Incidente seguimiento de su solucionado aprobación. Fuente: Elaboración propia - Proceso de asignación y escalado GESTOR DEL INCIDENTE INICIO 1 Diagnosticar incidente 2 Solución en base a documentos de la base de datos de incidentes? NO SI 3 La solución requiere documentación? SI 4 Adjuntar documento al incidente y calificarlo 5 Documentar la solución en la base de datos de incidentes FIN Figura 11: Diagrama de flujo proceso asignación y escalado. Fuente: Elaboración propia 75 NO Rol incident es Gestor de incident es

77 - Descripción del proceso Tabla 13: Proceso asignación y escalado ID Actividad Entrada Activid ad 1 Diagnostica Incidente r diagnosticado Solución propuesta 2 Solución Incidente en base de asignado. datos? La solución requiere documenta ción? Adjuntar documento al incidente Incidente solucionado Incidente solucionado Documento en la base de datos Documenta Incidente r solución solucionado Descripción de la Actividad Salida Rol Resolver el incidente Servicio Soporte de ejecutando las recupera 2-3 Nivel soluciones temporales o do definitivas Si: Continúa con Soporte de actividad Nivel No: Continúa con actividad 3 Si: Continúa con Soporte de actividad Nivel No: Fin del proceso Se adjunta el documento Incident Soporte de al incidente. e 2-3 Nivel solucion ado Se documentan las soluciones de los incidentes en la base de datos no solo como un sustento de la solución, si no como un repositorio de conocimiento. Fuente: Elaboración propia 76 Incident Soporte de e 2-3 Nivel docume ntado

78 - Reparación y recuperación SOPORTE DE 2-3/ Nivel INICIO 1 Revisar y validar datos de categorización 2 Documentar diagnóstico FIN Figura 12: Diagrama de flujo del proceso cierre del incidente. Fuente: Elaboración propia - Descripción del proceso Tabla 14: Proceso Reparación y recuperación ID Actividad Entrada Actividad 1 Revisar Incidente validez de solucionado datos finales y categorización 2 Solucionar incidente Incidente solucionado Descripción de la Actividad Se verifican los datos y la categorización para poder dar por concluido el caso. Se soluciona el incidente. Fuente: Elaboración propia 77 Salida Rol Incidente solucionado Soporte de 2-3 Nivel Incidente solucionado Soporte de 2-3 Nivel

79 - Proceso cierre del incidente SOPORTE DE 2-3/ Nivel INICIO 1 Monitorear estado y progreso de los incidentes 2 Monitorear a los grupos diagnosticadores 3 Monitorear incidentes según la prioridad asociada 4 Adjuntar documento al incidente FIN Figura 13: Diagrama de flujo del proceso asignación y escalado. Fuente: Elaboración propia - Descripción del proceso Tabla 15: Proceso cierre del incidente ID Actividad Actividad 1 Monitorear estado y progreso de los incidentes escalados 2 Monitorear a los grupos resoluto res (Agentes) 3 Monitorear incidentes según la prioridad asociada. Entrada Descripción de la Salida Actividad Incidente Cerrar incidentes cuyos Incidente solucionado estados se encuentran en cerrado SOLUCIONADO. Rol Gestor de Incidentes Incidente Obtener la conformidad Incidente solucionado del usuario. cerrado Gestor de Incidentes Incidentes asignado, Gestor de Incidentes 78 Cambiar la prioridad de Incidentes atención en forma re inmediata si ya se priorizado encuentra asignado y aún no ha sido diagnosticado.

80 ID Actividad Entrada Descripción de la Salida Actividad Actividad 4 Adjuntar Incidente Generar reporte técnico Incidente documentación solucionado de conformidad de la cerrado. del incidente. atención Rol Gestor de Incidentes Fuente: Elaboración propia ROLES Y RESPONDABILIDADES DEL MODELO Los roles para los procesos definidos para el modelo de gestión es de acuerdo a la Tabla 16. Tabla 16: Roles para el modelo de gestión de incidencias. Rol Usuario / Cliente Responsabilidad Reportar incidentes Gestor de Incidentes / El Gestor de Incidentes es responsable de la implementación efectiva del proceso de Gestión de Administrador Incidentes y prepara los informes correspondientes. Ofrece representación durante la primera fase de escalado de incidentes, cuando no se pueden solucionar en el marco de los niveles de servicio acordados. Soporte de 1er nivel = La responsabilidad del Soporte de primera línea o soporte inicial es registrar y clasificar los Incidentes reportados y soporte inicial de llevar a cabo esfuerzos inmediatos para restaurar lo antes posible un servicio de TI que ha fallado. incidentes / Si no se encuentra una solución adecuada a estos fines, el Administrador Soporte de Primera Línea refiere el incidente a grupos de apoyo técnico especializado (Soporte de Segunda Línea). El Soporte de Primera Línea también mantiene informados a los usuarios acerca del estatus de los Incidentes cada cierto tiempo. Soporte de 2-3 Nivel de Se hace cargo de los Incidentes que no pueden ser resueltos con los recursos del Soporte de Primera Línea. Incidentes /Agentes De ser necesario, requerirá apoyo externo como son la unidad de desarrollo, redes, y soporte técnico. La meta es restaurar un servicio de TI fallido en el menor tiempo posible. Fuente: Elaboración propia 79

81 Descripción de roles: Usuario/cliente: Persona o grupo de personas que usa o utiliza algún servicio ofrecido por la Oficina de Tecnología Informática. Gestor de Incidentes / Administrador: Es el rol dueño del proceso, se encarga de vigilar el correcto cumplimiento del proceso de gestión de incidentes y la obtención de las métricas del proceso. Soporte de 1er nivel/ Administrador: Personal de Centro de Servicios quien recibe el incidente. Soporte de 2 niveles de incidentes / Agentes: Personal de mayor experiencia que se encarga de solucionar incidentes que no pudieron ser resueltos por el 1er nivel, puede ser proveedor, fabricante o experto. Puede ser 2do o 3er nivel MÉTRICAS DEL PROCESO Con el objetivo de poder medir el cumplimiento progresivo del proceso de gestión de incidentes, se ha considerado las siguientes métricas por cada período mensual: 1. Tiempo de diagnosticado de incidentes 2. Tiempo de resolución de incidentes. 3. Número total de incidentes clasificados por tipo de prioridad reportados. 4. Número de incidentes asignados a grupos de soporte clasificados por tipo de prioridad. 80

82 Estas métricas permitirán ver el desempeño de la gestión de incidentes y determinar los SLAs de los servicios brindados por la Oficina de Tecnología Informática. Respecto de las diferencias con el proceso estándar de ITIL, se puede indicar que: Las vías para reportar los incidentes serán de forma presencial, por auto registro, por teléfono. ITIL propone más formas. Aún no se ha incluido un proceso exclusivo de gestión del escalamiento de los incidentes. En el proceso estándar, si existe el proceso. Se ha considerado dentro del proceso una actividad específica de validación de la resolución del incidente con el usuario. En el proceso estándar, existe dentro de su proceso de cierre del incidente. Aún no se ha incluido un proceso exclusivo de gestión de requerimientos. En el proceso estándar si existe el proceso POLÍTICAS PARA EL MODELO DE GESTIÓN DE INCIDENCIAS. Las políticas sugeridas para la puesta en marcha del modelo de gestión de incidencias basado en ITIL para la Oficina de Tecnología Informática. a. El centro de servicios (Oficina de Tecnología Informática) será el único punto de contacto con los usuarios para el reporte de incidentes. b. Todo incidente debe ser documentado desde su registro hasta su diagnóstico. c. Los agentes debidamente acreditados por la Oficina de Tecnología Informática deben son los únicos autorizados para diagnóstico de incidencias en la Universidad Nacional del Altiplano. 81

83 4.3. IMPLEMENTAR MODELO DE GESTIÓN DE INCIDENCIAS ARQUITECTURA DE LA HERRAMIENTA La arquitectura de la herramienta propuesta es de acuerdo a la Figura 14. CMDB Reportes Sistema de Gestión de Incidencias Jefes WebBrowser Administrador Acuerdos de nivel de servicio V1.0 Catalogo de servicio V1.0 Incidente ++ Cliente Agentes Solicitud de cambio Figura 14: Arquitectura de la herramienta para la gestión de incidencias Fuente: Elaboración propia 82

84 ANÁLISIS Y DISEÑO DE LA HERRAMIENTA Esta parte describe lo que la herramienta debe hacer según la especificación de requerimientos, este análisis consiste en describir lo que la herramienta, proporcionará en términos de funcionalidad, el cual define requisitos funcionales y operativos del sistema. Se han utilizado los diagramas de Casos de Uso (CU) para describir la relación entre los actores y actividades, los cuales nos permite definir los requerimientos de la herramienta ANÁLISIS DE LA HERRAMIENTA Actores de la herramienta Los actores de la herramienta son: Actor Cliente: Este actor representa al grupo de usuarios de los servicios de TI en la Universidad Nacional del Altiplano. Actor Agente: Este actor representa al personal técnico que labora en la Oficina de Tecnología Informática encargado del soporte técnico. Actor Administrador: Este actor representa al administrador de la herramienta que soporta la gestión de incidencias Casos de uso de la herramienta Los casos de uso obtenidos como resultado en la etapa de análisis se divide en: Gestión de usuarios, Gestión de CMDB (Base de datos de gestión de configuración), Gestión de tickets y gestión de reportes. 83

85 Figura 15: Caso de uso para la gestión de usuario Fuente: Elaboración propia Figura 16: Caso de uso para la gestión de CMDB Fuente: Elaboración propia 84

86 Figura 17: Caso de uso para la gestión de ticket Fuente: Elaboración propia Figura 18: Caso de uso para la gestión de ticket Fuente: Elaboración propia 85

87 Especificaciones de caso de uso de la herramienta Los casos de uso fueron basados en actividades que realizan los actores. En la especificación de casos de uso se describen esas actividades. Anexo N Diagramas de secuencia Los siguientes diagramas de secuencia permiten visualizar como los objetos identificados de la herramienta se comunican entre sí para generar un evento en el flujo de control a lo largo del tiempo. Figura 19: Diagrama de secuencia para identificar usuario Fuente: Elaboración propia 86

88 Figura 20: Diagrama de secuencia para registro de elemento de CMDB Fuente: Elaboración propia Figura 21: Diagrama de secuencia para registro ticket Fuente: Elaboración propia 87

89 Diagramas de Actividades El diagrama de actividades proporcionó una vista del comportamiento centrada en la tarea, ya que su propósito es capturar acciones (trabajo y actividades que serán realizadas) y sus resultados en términos de cambios de estado. Figura 22: Diagrama de actividades del proceso de registro de usuario Fuente: Elaboración propia Figura 23: Diagrama de actividades del proceso de registro de usuario Fuente: Elaboración propia 88

90 Figura 24: Diagrama de actividades del proceso de registro de usuario Fuente: Elaboración propia Figura 25: Diagrama de actividades para la atención de incidente Fuente: Elaboración propia 89

91 Diagramas de clases El siguiente diagrama de clases analizado describe la estructura del sistema desde el punto de vista de clases y objetos. A continuación se muestra las clases que se han identificado y las abstracciones genéricas de sus atributos y comportamiento del conjunto de objetos. Figura 26: Diagrama de clases Fuente: Elaboración propia 90

92 DISEÑO DE LA HERRAMIENTA En este espacio se muestra el modelo conceptual (Esquema Entidad-Relación), lógico (Esquema Relacional) y físico de la base de datos Modelo Conceptual E-R El modelo conceptual fue el punto de partida para el diseño de la base de datos, donde la primera representación está basada en el modelo EntidadRelación (Atributos, relaciones e interrelaciones entre objetos). usuario id id nombre password codigo cargo ES OFICINA TIENE USUARIO id nombres apellidos nro_celular PERTENECE ROL id_emite GENERA SEDE rol id_recibe TIENE DESCARGO sede id id caracteristicas tipo_activo detalle id TIENE TICKET fecha_registro fecha_diagnostico descripcion escalado estado ACTIVO_CMDB cod_patrimonial modelo activo caracteristicas Figura 27: Modelo ER de la base de datos Fuente: Elaboración propia 91

93 Modelo Lógico El modelo lógico de la base de datos es el siguiente: Figura 28: Modelo ER de la base de datos Fuente: Elaboración propia Modelo Físico Para esta investigación se ha modelado una base de datos relacional la cual está compuesta por 12 tablas que almacenan información de los datos de los usuarios (Administrador, Agente, Clientes), de los elementos de CMDB, tickets generados, atendidos y cerrados, así como los reportes. En el Anexo N 5 se puede ver el esquema físico de la base de datos (Código fuente). 92

94 Tamaño de la BD: El tamaño de la BD no depende de un dimensionamiento fijo que se realice al momento del diseño, sino del motor de BD que se utilice y de la capacidad de almacenamiento en disco y de procesamiento que se tenga en el servidor de producción. Los límites en el número de bases de datos y tablas: MySQL no tiene límite en el número de bases de datos. Sin embargo, el sistema de archivos puede tener un límite en el número de directorios. Motores de almacenamiento individuales pueden imponer limitaciones específicas del motor. InnoDB (que es el motor que utilizamos) permite hasta 4 mil millones de tablas. Diccionario de Datos: El diccionario de datos especifica con mayor detalle las tablas correspondientes a la base de datos, y se observan en las siguientes tablas: Tabla 17: Tabla usuario. Nombre Descripción usuario Contiene la información del usuario. Clave Primaria Id Campo Tipo int(11) Id Código trabajador VARCHAR(8) Descripción Id usuario Código del trabajador Usuario VARCHAR(60) Nombre de usuario password VARCHAR(255) Contraseña del usuarios Cargo VARCHAR(45) VARCHAR(255) Correo del usuario Nombres VARCHAR(80) Nombres del usuario Apellidos VARCHAR(80) Apellidos del usuario Nro_celular VARCHAR(9) Numero de celular Nro_anexo VARCHAR(9) Numero de anexo IP Área_oti ENUM(1,2,3) Nombre de área Cargo del usuario Fuente: Elaboración propia. 93

95 Tabla 18: Tabla rol. Nombre Descripción rol Contiene la información del rol del usuario. Clave Primaria Id Campo Tipo Descripción Id del rol Id TINYINT rol VARCHAR(255) Nombre del rol Fuente: Elaboración propia. Tabla 19: Tabla oficina. Nombre Descripción oficina Contiene la información de las principales oficinas. Clave Primaria Id Campo Tipo Descripción Id de oficina Id TINYINT Nombre VARCHAR(80) Nombre de oficina Código VARCHAR(12) Código de oficina Fuente: Elaboración propia. Tabla 20: Tabla sede Nombre Descripción sede Contiene la información de la sede. Clave Primaria Id Campo Tipo Descripción Id de la sede Id TINYINT sede VARCHAR(255) Nombre de la sede Fuente: Elaboración propia. Tabla 21: Activo CMDB. Nombre Descripción Activo_CMDB Contiene la información a cerca de cada elemento de CMDB. Clave Primaria Id Campo Id Tipo Descripción Id del elemento de CMDB TINYINT Código_patrimonial VARCHAR(45) Código patrimonial del equipo características TEXT Características del equipo modelo VARCHAR(255) Nombre del modelo del equipo Fuente: Elaboración propia 94

96 Tabla 22: Tabla tipo activo CMDB Nombre Descripción Tipo_activo_cmdb Contiene la información del tipo de CMDB Clave Primaria Id Campo Tipo Descripción Id del CMDB Id TINYINT tipo VARCHAR(50) Nombre del activo CMDB Fuente: Elaboración propia. Tabla 23: Tabla ticket Nombre Descripción Ticket Contiene la información del ticket generado por el usuario Clave Primaria Id Campo Tipo Descripción Id BIGINT Id del ticket Fecha_hora_registro DATETIME Fecha y hora de registro del incidente Descripción TEXT Descripción del incidente Estado TINYINT Estado del incidente Fecha_hora_diagnòstico DATETIME Fecha y hora del diagnóstico del incidente Tiempo_solucion TIME Tiempo de diagnóstico del incidente Código VARCHAR(10) Código del ticket generado Fuente: Elaboración propia. Tabla 24: Tabla descargo Nombre Descripción Descargo Contiene la información de la atención del ticket Clave Primaria Id Campo Tipo Descripción Id BIGINT Id de la atención del ticket Detalle TEXT Detalle de la atención Fecha_hora_asignacion DATETIME Fecha y hora de la asignación Estado TINYINT Estado del ticket Fuente: Elaboración propia. 95

97 IMPLEMENTACIÓN DE LA HERRAMIENTA FRAMEWORK UTILIZADO: El framework de desarrollo fue el CodeIgniter en su versión 2.1.4, así que se utilizó a éste como el core del sistema desarrollado. Esta herramienta permitió diseñar la aplicación bajo un esquema MVC (Modelo Vista Controlador) muy utilizado para la producción de sistemas. Las clases utilizadas para cada uno de los elementos del MVC fueron: CI_Controller: Un controlador es simplemente un archivo de clase que se denomina de manera que se puede asociar con un URI. Las clases heredadas de CI_Controller incluyen funciones que son utilizadas como rutas de ejecución desde el lado cliente que invocan un determinado módulo. Estas funciones son los encargados de coordinar el acceso a datos a través de los modelos y la consecuente generación de vistas de acuerdo a su ejecución. CI_Model: La clase CI_Model es la encargada de realizar la conexión con la Base de Datos y gestionar la información para su procesamiento. Los modelos son clases PHP que están diseñados para trabajar con la información en la base de datos COMPONENTES UTILIZADOS - AdminLTE AdminLTE es una plantilla con características que le permiten adaptarse a cualquier dispositivo (está optimizada para tabletas y dispositivos celulares) que se utiliza para paneles de administración. Está basado en bootstrap y JQuery UI que incluye elementos válidos de HTML y CSS3. 96

98 - Bootstrap y otros componentes cliente Para el lado cliente, se utilizaron varios componentes de desarrollo ágil: Bootstrap 3.0, JQuery y JQuery UI INTERFACES PRINCIPALES DE LA HERRAMIENTA Para el diseño de interfaces se utilizó Bootstrap 2.0 y una plantilla de distribución libre denominada AdminLTE, la misma que cuenta con diseño adaptativo (responsive design), es decir se adapta a cualquier dispositivo, también basado en Bootstrap. Las principales interfaces del sistema Web son: Interfaz de logueo: El acceso al sistema Web se realiza a través de un explorador web, el usuario debe ingresar la URL del sistema para obtener la ventana de logueo tal como se puede apreciar en la Figura 29, donde en la página inicial el usuario registrado, tiene que autenticarse para iniciar sesión y así poder ingresar a la interfaz principal. Figura 29: Interfaz de inicio Fuente: Elaboración propia 97

99 Interfaz de inicio del sistema Web: Una vez realizada la identificación se accede a la interfaz principal del sistema Web, la cual muestra las principales funciones que realiza el usuario ver Figura 30, y se presentan los accesos directos a las secciones principales del sistema Web (Usuarios, Activos tecnológicos, Ticket y reportes). Sección USUARIOS, donde se registran los datos del usuario así como el rol que cumple ya sea administrador, cliente o agente. Sección ACTIVOS TECNOLÓGICOS, donde se los datos del activo relacionado al incidente. Sección de TICKETS donde se registran, listar, escalar y atender el ticket relacionado con la incidencia. Sección de REPORTES, donde se obtienen el reporte por agente, por oficina y por incidentes. Figura 30: Interfaz principal Fuente: Elaboración propia 98

100 Interfaz con las opciones gestionar los datos del usuario: En la Figura 31 se muestra la interfaz para la gestión de usuario, las diferentes opciones de registro que puede realizarse respecto al usuario, entre ellas se encuentran las siguientes opciones: DETALLES, permite ver al detalle los datos del usuario como: Código, Usuario, Nombres y Apellidos, Cargo, Nro. Celular, Anexo, , Rol, Oficina, Sede. EDITAR, permite editar los datos del usuario HABILITAR/DESHABILITAR, para deshabilitar al usuario, al momento de registrar el usuario el estado por defecto es habilitado. Figura 31: Interfaz para la gestión de usuario Fuente: Elaboración propia Interfaz con las opciones gestionar activo tecnológico: En la Figura 32, se muestra la interfaz que permite la gestión de los activos de tecnología. Las diferentes opciones de registro que puede realizarse respecto a los elementos de CMDB, entre ellas se encuentran: LISTAR, permite listar los activos según se van agregando a la base de datos. 99

101 AGREGAR ACTIVO, permite editar los datos del usuario, a su vez presenta las siguientes opciones: o Detalles, permite ver al detalle los datos del activo como: Código patrimonial, Activo, Características, Modelo, Servicio, Tipo activo o Habilitar/Deshabilitar, para dar de baja el activo (deshabilitar) de TI, al momento de registrar el activo el estado por defecto es habilitado. Figura 32: Interfaz para la gestión de activo Fuente: Elaboración propia Interfaz con las opciones gestionar incidencia (Ticket): En la Figura 32, se muestra la interfaz donde se observa las diferentes opciones de registro que puede realizarse respecto a los incidentes, entre ellas se encuentran: REGISTRAR INCIDENCIAS, permite registrar incidencias, el usuario debe proporcionar datos del servicio, descripción detallada del incidente, asociar a un activo de tecnológico. ESCALADO, permite escalar (derivar) el incidente para su diagnóstico al agente correspondiente. TICKET ASIGNADO, permite listar los incidentes mostrando el estado del incidente, si el estado es solucionado el administrador puede cambiar el estado del incidente de solucionado a cerrado. 100

102 Figura 33: Interfaz para la gestión de incidentes Fuente: Elaboración propia Interfaz con las opciones para generar reportes En la Figura 34, se muestra la interfaz donde se observa las diferentes opciones para generar reportes, entre ellas se encuentran: LISTA DE INCIDENCIAS, permite listar los activos por incidencias de forma general. POR OFICINAS, permite listar los incidentes registrados por oficinas. POR AGENTE, permite listar los incidentes por agente. Figura 34: Interfaz para la visualizar reportes Fuente: Elaboración propia 101