Sistema para la gestión de incidencias de cómputo en una universidad pública

System for managing computing incidents in a public university

Serrano Preciado, Oscar Alberto; Valencia Moreno, José Manuel; Osorio Cayetano, Oscar Ricardo; Wagner Gutiérrez, Juan Manuel

Oscar Alberto Serrano Preciado

oserrano@uabc.edu.mx

Universidad Autónoma de Baja California México

José Manuel Valencia Moreno

jova@uabc.edu.mx

Universidad Autónoma de Baja California México

Oscar Ricardo Osorio Cayetano

oosorio@uabc.edu.mx

Universidad Autónoma de Baja California México

Juan Manuel Wagner Gutiérrez

jwagner@uabc.edu.mx

Universidad Autónoma de Baja California México

Revista de Investigación en Tecnologías de la Información

Universitat Politècnica de Catalunya, España

ISSN-e: 2387-0893

Periodicidad: Bianual

vol. 12, núm. 26, 2024

editorial@riti.es

Recepción: octubre 11, 2024

Aprobación: diciembre 16, 2024

URL: https://portal.amelica.org/ameli/journal/368/36851903685190014/

DOI: https://doi.org/10.36825/RITI.12.26.014

© Revista de Investigación en Tecnologías de la Información (RITI) 2024

License Creative Commons
Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial 4.0 Internacional.

Modelo de publicación sin fines de lucro para conservar la naturaleza académica y abierta de la comunicación científica

ePub generado a partir de XML JATS4R

Resumen: La gestión de incidencias de cómputo es un proceso que aún se realiza de manera manual en una diversidad de organizaciones, lo que ralentiza la atención a los usuarios. Esta situación se acentúa en organizaciones públicas que no cuentan con el presupuesto necesario en equipo y personal especializado para esta tarea. Este trabajo aborda tal desafío en el contexto de una universidad pública en México, proponiendo un sistema para la gestión de incidencias de cómputo, reportadas por el personal administrativo al área de soporte técnico. Se utilizó la metodología de Design Thinking con un fuerte énfasis en la participación de usuarios finales desde la fase inicial. Los resultados obtenidos a través de la evaluación de los prototipos del sistema muestran una gran aceptación por parte de los usuarios participantes, en cuanto a la facilidad de uso (6.67/7) y percepción de utilidad (6.42/7). El desarrollo del sistema web de mesa de ayuda promete ser una solución efectiva para mejorar el proceso de gestión de incidencias de cómputo en la universidad, contribuyendo a un servicio más eficiente y transparente.

Palabras clave: Mesa de Ayuda, Soporte Técnico, Gestión de Incidentes, Pensamiento de Diseño.

Abstract: Nowadays, computer incident management is a manual process in several organizations, which can negatively affect the provided user attention. Public organizations have a more challenging situation as they usually need a budget for technical equipment and specialized staff to provide incident management services. This paper addresses the incident management service challenge in a public university in Mexico through a system that supports the computer incident management service reported to technical support by administrative personnel. We used the Design Thinking methodology to design a help desk system, which empathizes with the need to have end users involved in the design process from the initial phase. We evaluated the possible technology acceptance of the system through the Technology Acceptance Model (TAM), obtaining promising results regarding ease of use (6.67/7.0) and perceived usefulness (6.42/7.0). The evaluation results show that our help desk system is a potential tool for improving the computer incident management process in the public university, contributing to a more transparent and efficient service.

Keywords: Help Desk, Technical Support, Incident Management, Design Thinking.

1. Introducción

Con su incorporación como herramientas de trabajo en prácticamente todo tipo de organización, se ha creado una dependencia en las computadoras e internet para la realización de las actividades diarias, por lo que el cuidado del funcionamiento ininterrumpido de estas herramientas es vital. Una interrupción en los servicios informáticos puede afectar la productividad, la toma de decisiones e incluso causar pérdida de datos importantes para la organización. A cualquier interrupción de servicios de tecnología de la información que afecta desde un solo usuario hasta toda la empresa, se le conoce como “incidencia de cómputo” [1].

La gestión de los recursos tecnológicos de las organizaciones y de sus incidencias se lleva a cabo a través de los sistemas de mesa de ayuda (Help Desk), los cuales se definen como un centro de atención para los usuarios de una organización, proporcionando soporte administrativo y técnico con el fin de resolver los problemas que estos encuentran lo antes posible [2]. Los sistemas de mesa de ayuda pueden estar conformados por una persona o un grupo de personas que utilizan un sistema o aplicación de software para dar un seguimiento al estado de las incidencias y entregar soluciones que satisfagan a los usuarios [3]. El área de mesa de ayuda también es conocida como soporte técnico. Inicialmente, los reportes de incidencias los manejaban por medio de correos electrónicos, llamadas telefónicas o el usuario va personalmente a hacer el reporte [4].

Dependiendo del tamaño de la organización y de la cantidad de equipo tecnológico utilizado, la gestión de este equipo, así como de las incidencias que surgen en su uso diario, se vuelve más complicada. En las organizaciones públicas se acentúa más, ya que el presupuesto para esta función es muy limitado. Actualmente, es imposible brindar un servicio de calidad sin la presencia de las TIC [5]. La atención ineficiente de las incidencias de cómputo puede deteriorar la productividad de uno o varios usuarios y generar un sentimiento de insatisfacción hacia la mesa de ayuda.

La presente investigación propone una solución a esta problemática que se suscita en una importante universidad pública de México. La Universidad se encuentra distribuida en tres unidades físicamente dispersas, en donde se atienden a más de 68 mil estudiantes, 7595 profesores y un total de 1860 trabajadores administrativos, los cuales realizan sus labores por medio de más de 2000 equipos de cómputo. Este estudio se enfoca en una unidad que cuenta con 10 departamentos conformados por 294 usuarios administrativos, los cuales se encargan de llevar a cabo las tareas administrativas de la universidad. No se consideran los usuarios académicos, conformado por alrededor de 1400 profesores, ni los usuarios estudiantes.

El Departamento de Informática (DI) de la Universidad se encarga de asesorar y apoyar a las dependencias administrativas en el uso y optimización de los recursos tecnológicos, así como de facilitar el acceso al acervo bibliográficos, a través de la investigación, incorporación, capacitación y buscando siempre la mejora continua del personal del DI en beneficio de los usuarios universitarios. Este departamento cuenta con 5 áreas principales, las cuales son: soporte técnico, telecomunicaciones, sistemas administrativos, salas de cómputo y seguridad y redes. El área de soporte técnico es el encargado de mantener en óptimas condiciones los equipos de cómputo de los 294 usuarios administrativos, esta es una tarea difícil y laboriosa, ya que el funcionamiento administrativo de la universidad depende totalmente del buen funcionamiento de los equipos de cómputo, debido a que la gran mayoría de los procesos administrativos se realizan a través de sistemas Web. Cuando sucede una incidencia de cómputo, el personal administrativo debe reportarlo al área de soporte técnico.

Actualmente, el proceso de gestión de incidencias de cómputo no está automatizado. Las solicitudes se hacen de manera informal y por distintos medios. Por lo que ni el personal de soporte, ni los usuarios pueden llevar un seguimiento de las solicitudes. Debido a la problemática anterior, el proceso de gestión de incidencias de cómputo es tardado, lo cual conlleva un retraso en las actividades administrativas y como consecuencias una insatisfacción por parte de los usuarios administrativos. Además, al no contar con un registro de las incidencias atendidas, el DI no tiene datos suficientes para generar informes solicitados por instancias superiores. Considerando lo anterior, este artículo presenta una solución a la problemática anteriormente descrita, con la propuesta de un sistema Web de mesa de ayuda que apoye a la gestión del proceso de incidencias de cómputo reportadas al área de soporte técnico por parte de los usuarios administrativos de la universidad.

El resto del documento está organizado de la siguiente manera: en la sección de estado del arte se describe el mapeo sistemático realizado acerca investigaciones previas relacionadas con el tema, en la sección de materiales y métodos se describe la metodología utilizada y los métodos de recolección de datos, en la sección de resultados se describen los resultados obtenidos en cada una de las etapas de la metodología utilizada, en la sección de conclusiones y trabajo futuro se describe la interpretación de los resultados obtenidos en la investigación y posibles direcciones para investigaciones futuras, en la sección de agradecimientos se da el reconocimiento a los autores y a la institución que contribuyó al desarrollo de esta investigación, por último en la sección de referencias se citan las fuentes bibliográficas utilizadas en la investigación.

2. Estado del arte

Para conocer el estado del arte sobre este tema, se realizó un mapeo sistemático de la literatura con el objetivo de identificar las características de diseño, implementación y evaluación que han sido empleadas en el desarrollo de los sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI.

2.1. Metodología del mapeo sistemático

El método empleado para llevar a cabo el mapeo sistemático de la literatura comprende tres fases: planeación, ejecución y reporte [6]. Además, se utilizó la metodología PRISMA con el objetivo de mejorar la calidad y transparencia del mapeo sistemático [7].

2.1.1. Planeación

En esta etapa se plantearon las siguientes preguntas de investigación:

1. ¿Qué tipos de sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI, se han desarrollado y en qué contextos o ámbitos?

2. ¿Cuáles son las principales características de los sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI, que se han desarrollado?

3. ¿Qué técnicas y metodologías se han utilizado en el diseño y desarrollo de sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI?

4. ¿Cuáles son los métodos de evaluación que se han utilizado y qué aspectos se han evaluado en los sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI?

5. ¿Cuáles son los principales hallazgos de los sistemas de mesa de ayuda, soporte y mantenimiento de TI que se han desarrollado?

Posteriormente, se definieron palabras claves basados basadas en las preguntas de investigación para crear la cadena de búsqueda:

((“Web system” OR “Web platform” OR “System design”) AND (“Help desk” OR “Service desk” OR “IT service management” OR “IT support” OR Maintenance))

Se consultaron los motores de la IEEE, ACM y Springer para la búsqueda de artículos. En estos sitios la búsqueda se realizó considerando las palabras claves únicamente en el título (Title) y resumen (Abstract).

Se establecieron como criterios de inclusión: el artículo se encuentra disponible para público en su versión completa para su lectura; es un artículo de revista o de conferencia; el artículo hace uso de tecnologías de la información; y el artículo describe el desarrollo, implementación o evaluación de un sistema de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI. Por otro lado, el criterio de exclusión fue en caso de que el artículo se haya publicado en un idioma diferente al inglés.

2.1.2. Ejecución

En la Figura 1 se muestra el proceso de ejecución con la metodología PRISMA con sus tres etapas. En la fase de Identificación, el total de resultados obtenidos de los motores de búsqueda fueron 323 (ACM = 57; IEEE = 199; Springer = 59). Posterior a la eliminación de duplicados se obtuvo un total de 257 artículos.

En la etapa siguiente “Elegibilidad”, se aplicaron los criterios de inclusión y exclusión, considerando únicamente el título y el resumen. Se analizaron los 257 artículos, de los cuales se excluyeron 159, quedando 98 artículos en esta etapa, después se leyeron las introducciones y conclusiones de los 98 artículos. A los cuales se les aplicaron de nueva cuenta los criterios de inclusión y exclusión, obteniendo 55 artículos, los cuales se consideraron para la etapa de lectura completa. Durante la etapa “Incluidos”, se descartaron 15 artículos, debido a que su lectura completa no se encuentra disponible con suscripción gratuita, por lo tanto, al final tenemos 40 artículos para su lectura completa y poder responder nuestras preguntas de investigación.

Figura 1.
Proceso de ejecución de metodología PRISMA.

Elaboración propia, basada en la metodología PRISMA [7].

2.1.3. Reporte

Los resultados obtenidos del mapeo sistemático realizado por cada una de las preguntas de investigación son las siguientes:

1. ¿Qué tipos de sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI, se han desarrollado y en qué contextos o ámbitos?

Los tipos de sistemas reportados en los artículos considerados en el mapeo sistemático fueron: sistemas web, sistemas de escritorio y modificaciones a sistemas ya existentes. Los contextos o ámbitos de desarrollo abarcan áreas: empresarial, educativa, gubernamental y privada.

El desarrollo de sistemas web se realiza en el entorno empresarial en un 30.30%, en el ámbito educativo en un 10% y en el ámbito privado con el 9.09%. El 18.18% del total de artículos considerados, reportan la modificación a sistemas existentes en el ámbito empresarial, mientras que el 2.5% en el ámbito gubernamental. Por otro lado, los sistemas de escritorio se han desarrollado en un 15% para el ambiente empresarial y 5% en el académico. Un ejemplo de sistema Web en el ámbito empresarial es el desarrollado en la organización Ihsan Solusi Informatika, el cual demostró agilizar el proceso y aumentar la satisfacción de los usuarios finales [8].

2. ¿Cuáles son las principales características de los sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI, que se han desarrollado?

Se identificaron varias características con diferentes enfoques y funcionalidades. La principal característica de uso de las mesas de ayuda, con un 25% de los artículos analizados, fue el seguimiento de tickets de servicio. Esta característica muestra la importancia de la gestión de solicitudes por parte de los usuarios y la mesa de ayuda. Se observaron tres características más, cada una con un 7.5%: generación de informes, la inclusión de un sistema de chat multimedia y el uso de sesiones colaborativas para discutir problemas. La generación de informes muestra la necesidad de reportar las actividades realizadas a instancias superiores; el chat multimedia refleja el interés en mejorar la comunicación y la interacción usuario-mesa de ayuda; y la característica de uso de sesiones colaborativas que es útil para discutir los problemas con los usuarios.

De las cuatro características identificadas, sobresale el seguimiento de tickets o de órdenes de servicios de ayuda, parte esencial de las mesas de ayuda. De esta manera se transparenta el proceso de servicio tanto para los usuarios como para los administradores y encargados de la gestión de la mesa de ayuda. Un ejemplo de los resultados obtenidos es el artículo de Shae et al. [9], en donde analizaron 115 sesiones de soporte técnico con los usuarios. Consideraron la duración de la sesión y las imágenes verbales, dividiendo las sesiones en dos categorías: sesiones con imágenes verbales y sesiones sin imágenes verbales. Observaron una gran diferencia en la duración entre ambas. El uso de imágenes verbales fue relacionado con una mayor duración de la sesión, a diferencia de la ausencia de estas en la cual la duración de la sesión disminuye a menos de la mitad. Identificaron que aproximadamente el 25% de la duración de las sesiones con imágenes visuales se dedicó a describir algún tipo de imágenes verbales y que el 75% de tiempo de sesión del agente de soporte se utiliza para describir imágenes verbales de lo que el cliente debería estar visualizando en su pantalla.

3. ¿Qué técnicas y metodologías se han utilizado en el diseño y desarrollo de sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI?

Fueron identificadas diversas técnicas y metodologías. La técnica basada en casos fue utilizada por el 25% de los artículos analizados. Después, metodologías propias fue usada en un 12.5%, seguidas por la metodología ITIL (Information Technology Infrastructure Library) con el 10%, con un 5% las metodologías CRB (Cascade, Review, Block), la simulación y aprendizaje automático, así como la implementación de bases de datos de preguntas frecuentes. Con el 2.5% las metodologías de SCRUM con enfoque ágil, COBIT (Control Objectives for Information and Related Technologies), la metodología estructurada y la gamificación.

Un ejemplo es el desarrollado por Richard et al. [10] el cual se centra en la importancia que tienen los laboratorios de cómputo en la universidad de nivel superior y como se propone la implementación de un marco de trabajo basado en ITIL como solución para mejorar la calidad del servicio de laboratorio de cómputo.

4. ¿Cuáles son los métodos de evaluación que se han utilizado y qué aspectos se han evaluado en los sistemas de mesa de ayuda, incluyendo sistemas para soporte, mantenimiento o servicios de TI?

Los métodos de evaluación y aspectos evaluados en los sistemas de mesa de ayuda reportados en los artículos analizados, se destaca como principal aspecto de evaluación la satisfacción del cliente (10%). El 5% utilizó la simulación para medir la efectividad de los sistemas. En un 2.5% fueron utilizados los métodos cualitativos, como encuestas y observación para medir la efectividad del sistema. Pruebas de caja negra fueron utilizadas en un 2.5% para evaluar la categorización de tickets. Un ejemplo de evaluación por medio de pruebas de caja negra es el desarrollado por Harun et al. [11], el cual demostró un aumento en el tiempo promedio de resolución de un problema.

5. ¿Cuáles son los principales hallazgos de los sistemas de mesa de ayuda, soporte y mantenimiento de TI que se han desarrollado?

Mejorar la calidad del servicio de una mesa de ayuda fue el principal hallazgo en el 30% de los artículos analizados, mientras que para el 27.5% de los artículos fue la satisfacción del cliente. El 17.5% reportaron la reducción en el tiempo de resolución de una incidencia, el 7.5% la mejora con respecto a los métodos manuales previamente utilizados, y para el 5% el principal hallazgo fue la reducción de carga laboral para el personal de soporte. El 7.5% sugiere trabajos a futuro para proporcionar hallazgos concluyentes. Por ejemplo, el sistema de gestión de sistemas de servicios de TI implementado en una universidad pública de Jordania, el cual demostró reducir el tiempo de resolución de los problemas reportados y mejorar la satisfacción de los clientes [12].

El mapeo sistemático de la literatura ayudó a conocer el estado del arte sobre las mesas de ayuda desarrolladas por otros investigadores, identificando sus principales características de diseño, implementación y formas de evaluación, entre las que destacan: son implementadas como sistemas web tanto en empresas como en instituciones educativas; la principal funcionalidad es el seguimiento de órdenes de servicios; y las métricas más importantes son la satisfacción de los usuarios y la reducción en la atención de las incidencias. Así mismo, se identificaron problemas, como en algunas organizaciones en donde los reportes de soporte técnico se hacían mediante correos electrónicos, llamadas telefónicas o el usuario debe trasladarse personalmente a solicitar la ayuda técnica, haciendo que el tiempo de atención fuera extenso.

Además del mapeo sistemático de la literatura realizado, se realizó un análisis de los principales sistemas de mesa de ayuda comerciales y de software libre. Aunque en el mercado existen numerosas soluciones de mesa de ayuda, los desarrolladores continuamente añaden nuevas funcionalidades, lo que conlleva ciertos inconvenientes: los programas se vuelven más complejos, requieren mayores recursos y hardware más costoso, además, presentan una curva de aprendizaje prolongada para los usuarios finales. Como menciona Ismaili et al. [4], desarrollar un sistema propio de mesa de ayuda no garantiza necesariamente una solución superior a las existentes en el mercado, pero permite incorporar características únicas y adaptadas a las necesidades específicas de la institución. Con esta información y para solucionar los problemas detectados en la Universidad, se propone el desarrollo de un sistema web para la atención de las incidencias de cómputo.

3. Materiales y métodos

Para el desarrollo de la mesa de ayuda, se utilizó la metodología de Design Thinking que se define como “un proceso analítico y creativo que involucra a una persona en oportunidades de experimentar, crear y prototipar modelos, recabar opiniones y rediseñar” [13]. Se eligió esta metodología debido a que le da un gran valor y participación a los usuarios, tomando en cuenta sus comentarios y sugerencias. Esta agrupada en cinco etapas generalmente aceptadas: empatizar, definir, idear, prototipar y evaluar, como se muestran en la Figura 2 [14].

Figura 2.
Etapas de la metodología Design Thinking.

Elaboración propia basada en la metodología Design Thinking [14].

3.1. Empatizar

Consiste en comprender de manera empática todas las necesidades de los usuarios y generar soluciones para sus problemas. Para lograrlo se utilizan métodos para la recopilación de información como la observación informal del proceso y entrevistas semiestructuradas. En forma especialmente útil, la entrevista semi-estructurada, no solamente permite recopilar datos, sino que además permite una libre expresión del entrevistado, para entenderlo desde su interior [15]. El análisis de los datos recolectados por la observación y la entrevista semi-estructurada, se analizó mediante técnicas de codificación abierta y axial, que es el proceso de abordar el texto, con el fin de desnudar conceptos, ideas, identificar patrones, relaciones y categorías más amplias [16]. Con la información recolectada se generó un mapa de empatía, una herramienta utilizada para comprender las necesidades de los usuarios fue desarrollado por Dave Gray y apareció por primera vez en el libro Game Storming [17].

3.2. Definir

En esta etapa se realiza una exhaustiva evaluación de los problemas detectados en la etapa anterior y proponer soluciones adecuadas. Para lograrlo se utilizó información recabada en la etapa de empatizar y se utilizaron técnicas de reingeniería de procesos como la gráfica rica [18], diagrama IDEF0 [19] y RAD [20] para mostrar de una manera gráfica el proceso de gestión de incidencias de cómputo.

3.3. Idear

Tiene el propósito de generar la mayor cantidad de ideas posibles con el objetivo de encontrar decenas de soluciones a un problema, eliminando los juicios de valor. Una vez encontrados los problemas en el proceso actual, se propuso una solución junto con sus requerimientos, para posteriormente realizar una sesión de validación con los usuarios, utilizando la técnica de validación de requerimientos [21], la cual se utiliza para mapear cada uno de los requerimientos propuestos, detectar problemas, aciertos y registrar los comentarios mencionados por los participantes.

3.4. Prototipar

Aquí se les dan forma a las ideas, creando versiones de muestra en poco tiempo y que no sean costosas. Se intenta mejorar, refinar o cambiar elementos importantes antes de llegar al resultado final. Se realizaron prototipos con ayuda de la herramienta de diseño Figma (https://www.figma.com/es-la/), posteriormente se realizó una sesión la cual fue grabada en audio, además, se utilizaron cuestionarios de cuatro preguntas después de realizar cada tarea asignada, los datos obtenidos fueron analizados posteriormente. Se utilizó una metodología de desarrollo basada en SCRUM, debido a que se utilizó un marco de trabajo iterativo e incremental.

3.5. Evaluar

Consiste en evaluar los prototipos junto con los usuarios finales para identificar mejoras significativas, fallos a resolver y posibles carencias. En nuestro caso, las técnicas y materiales utilizados en la sesión de validación de prototipos con los usuarios fueron: observación; grabación de audio de los comentarios que expresaban los usuarios después de concluir cada una de las tareas y la retroalimentación general del sistema, y la aplicación de un cuestionario de 4 preguntas a los participantes sobre su experiencia al realizar la tarea asignada. Además, a cada participante se le proporcionó una hoja guía con las tareas a realizar.

Para evaluar el nivel de aceptación, se aplicó el cuestionario del “Modelo de Aceptación de Tecnología” (Technology Acceptance Model, TAM) [22]. El TAM fue diseñado a finales de los años 80, es una de las formas más seguras y estables para recoger información que permita conocer cómo los usuarios aceptan y utilizan una herramienta tecnológica. Obtiene información acerca de dos categorías claves, la utilidad percibida y la facilidad de uso percibida. Cada pregunta utiliza una escala de 7 puntos Likert, que van desde completamente desacuerdo (1) a completamente de acuerdo (7).

4. Resultados

A continuación, se describen los resultados obtenidos en cada etapa de la metodología Design Thinking utilizada en el desarrollo de este trabajo.

4.1. Etapa Empatizar

A través de entrevistas semi-estructuradas al personal involucrado en el proceso de gestión de incidencias de cómputo, se logró recabar la información. Primero se entrevistaron a 3 trabajadores del personal administrativo de la Universidad, quienes brindaron información con base a su experiencia en el subproceso de reportar equipo de cómputo, posteriormente se entrevistó a un trabajador del área de soporte técnico del DI con el propósito de saber cómo se lleva el proceso de solución a incidencias de cómputo y si existe alguna bitácora o registro de todas las incidencias atendidas. Por último, se entrevistó al jefe del DI para conocer los servicios que brinda el departamento y las necesidades que tiene.

Las entrevistas realizadas al personal se transcribieron para su análisis. Con la codificación axial se establecieron las conexiones entre los códigos identificados durante la codificación abierta, logrando como resultado un diagrama de afinidad con ocho categorías principales:

1. Acerca del DI.

2. Área de soporte técnico

3. Tipos de incidencias

4. Medios de comunicación para reportes de incidencias

5. Problemáticas actuales

6. Ventajas y desventajas de los sistemas existentes

7. Funcionalidades deseadas del nuevo sistema

8. Sugerencias y comentarios de usuarios

El diagrama de afinidad completo se encuentra disponible en el Anexo 1. El resultado del análisis de las entrevistas permitió generar un mapa de empatía (Figura 3), el cual se divide en cuatro bloques con las preguntas: ¿qué piensa y siente?, ¿qué ve?, ¿qué oye?, ¿qué dice y hace?, el mapa nos ayuda a comprender mejor a los usuarios y su propósito principal es profundizar en las experiencias, necesidades, emociones y comportamientos. Basándonos en las respuestas generadas, podemos diseñar soluciones alineadas con sus necesidades.

Figura 3.
Mapa de empatía del personal administrativo

Elaboración propia.

4.2. Etapa Definir

En la etapa de definir de la metodología se utilizaron técnicas de reingeniería de procesos para poder identificar a los actores, actividades y herramientas involucradas en el proceso de gestión de incidencias de cómputo. Para ello se construyeron diagramas de gráfica rica, IDEF0 y RAD, los cuales fueron validados con el jefe del departamento de informática. En la Figura 4 se observa el diagrama IDEF- A0 del proceso de gestión de incidencias de cómputo, el proceso se desglosa en 3 etapas principales: Reportar equipo de cómputo; Analizar equipo en la ubicación física; y Reparar el equipo de cómputo.

Además, se muestra cada una de las entradas y salidas de los procesos, así como los controles y mecanismos involucrados en el proceso.

Figura 4.
IDEF A0 Proceso actual de gestión de incidencias de cómputo.

Elaboración propia.

Los actores involucrados en el proceso fueron: personal administrativo, personal de soporte técnico, jefe del DI, secretaria del DI, jefes de departamentos administrativos, y secretarias de departamentos administrativos. Se identificaron los siguientes problemas del proceso de gestión de incidencias de cómputo:

No siempre se reportan las incidencias directamente al área de soporte técnico.

Se utilizan diversos medios de comunicación para realizar el reporte.

Arribar al sitio de la incidencia sin saber exactamente el problema.

Falta de registro de las incidencias de cómputo.

Falta de datos para la generación de informes trimestrales, semestrales y anuales.

Estos problemas generan una insatisfacción de los usuarios por el tiempo de reparación de su equipo de cómputo, por otro lado, contribuyen a la falta de visibilidad del trabajo que se realiza en el departamento de informática en el área de soporte técnico. Con los problemas identificados, se procede a proponer soluciones que se abordan en la siguiente etapa de la metodología Design Thinking.

4.3. Etapa Idear

Con la información obtenida y problemática identificada en las etapas anteriores, se propone como una solución, la implementación de un sistema Web de mesa de ayuda para corregir con 15 requerimientos funcionales (Tabla 1).

Tabla 1.

Requerimientos funcionales para el sistema Web de mesa de ayuda.

Requerimiento funcional |
RF-01 Solicitar registro |
RF-02 Iniciar sesión RF-03 Crear solicitud de incidencia de cómputo |
RF-04 Consultar solicitud
RF-05 Modificar solicitud
RF-06 Cancelar solicitud
RF-07 Revisar solicitud inicial
RF-08 Revisar solicitud asignada
RF-09 Revisar equipo con incidencia
RF-10 Cerrar la solicitud
RF-11 Finalizar solicitud y calificar experiencia del servicio.
RF-12 Generar Informes de Solicitudes.
RF-13 Gestionar catálogos |
RF-15 Finalizar Mantenimiento preventivo |

Elaboración propia.

Se realizó una sesión de validación de requerimientos funcionales, en donde participaron 4 personas del departamento de informática (Tabla 2). Como resultado de la sesión se obtuvo una tabla con los aciertos, errores y observaciones mencionados para cada requerimiento utilizando la técnica de validación de requerimientos [17].

Tabla 2.

Participantes de la sesión de validación de requerimientos.

ID | Puesto
P1 | Jefe DI
P2 | Jefe de Oficina de telemática
P3 | Encargado de seguridad en cómputo
P4 | Personal área de soporte técnico

Elaboración propia.

En esa misma sesión de evaluación de requerimientos funcionales, también se recolectaron los comentarios vertidos por los participantes, como, por ejemplo: “Considerar agregar un llenado automático en las solicitudes de cómputo” (P1 y P2), que serán incorporados posteriormente.

4.4. Etapa Prototipar

Como primera versión de los prototipos, se desarrollaron esquemas en papel (Figura 5), como una forma rápida y económica de explorar diferentes ideas de diseño y recibir retroalimentación de los usuarios. Se representaron los principales módulos del sistema: Autenticación, Gestión de Incidencias, Informes, Catálogo de Estatus y Mantenimiento preventivo.

Figura 5.
Ejemplo del prototipo en papel. (a) Pantalla de inicio; (b) Pantalla del menú de solicitudes.

Elaboración propia.

Al concluir los prototipos de papel, se realizó una sesión de evaluación en donde participaron dos personas con conocimientos en el diseño de interfaces. Se les solicitó realizar tareas específicas en los prototipos del sistema, como, por ejemplo: Solicitar registro (RF-01) e iniciar sesión (RF-02), crear una solicitud de incidencia (RF-03), consultar una solicitud (RF-04), modificar una solicitud (RF-05), cancelar una solicitud (RF-06), y finalizar una solicitud y calificar experiencia del servicio (RF-11). Los comentarios generales de la evaluación de prototipos de papel fueron que el sistema es fácil de utilizar, es sencillo y amigable con el usuario, el tiempo en realizar cada tarea les pareció corto y no tuvieron ningún problema mayor con las tareas a realizar.

Con base en la retroalimentación obtenida, se crearon prototipos digitales (media fidelidad) con la ayuda de la interfaz de diseño Figma. Los prototipos fueron enlazados entre sí para simular funcionalidad. Algunos de los prototipos realizados se muestran en la Figura 6.

Figura 6.
Ejemplos de prototipos digitales. (a) Pantalla de inicio del sistema de mesa de ayuda (RF-02 Iniciar sesión). (b) Pantalla del menú solicitudes del sistema de mesa de ayuda (RF-03 Crear solicitud de incidencia de cómputo).

4.5. Etapa Evaluar

Con los prototipos de media fidelidad terminados, se planeó una sesión de validación con los roles principales del sistema. Se definieron los prototipos a evaluar (Tabla 3), las tareas asignadas a cada rol (Tabla 4), los participantes (Tabla 5), los materiales de recolección que se utilizarán y los métodos de análisis para la información recabada.

Tabla 3.

Prototipos a evaluar en la sesión de validación.

Prototipos a evaluar
Pantalla de inicio. Pantalla de registro. Pantalla de inicio del sistema. Pantalla principal del sistema. Pantallas del menú solicitudes. Pantallas de creación de solicitudes. | Pantallas de consulta y confirmación de visita técnica. Pantallas de solicitudes a modificar por técnico. Pantallas de modificación de estatus. Pantallas de cierre de solicitud. Pantallas de finalización y calificación del servicio. Pantallas de generación de informes.
Pantallas de consulta de solicitudes. | Pantallas de catálogos de equipo.
Pantallas de modificación de solicitudes. | Pantallas de mantenimiento preventivo.
Pantallas de cancelación de solicitudes. | Pantallas de finalización de mantenimiento preventivo.
Pantallas de solicitudes recibidas. | Pantallas de consulta y asignación de técnico.

Elaboración propia.

La lista de tareas seleccionadas para ser realizadas por los usuarios en la sesión de validación de los prototipos se muestra en la Tabla 4.

Tabla 4.

Tareas a realizar por los participantes de la sesión de evaluación.

Tareas a realizar
T1. Registrar e ingresar al sistema. | T8. Consultar solicitud asignada y agendar visita técnica.
T2. Crear solicitud de incidencia de cómputo. | T9. Modificar estatus.
T3. Consultar solicitud. | T10. Cerrar solicitud.
T4. Modificar solicitud. | T11. Generar Informe.
T5. Cancelar solicitud. | T12. Programar mantenimiento preventivo.
T7. Consultar solicitud recibida y asignar prioridad y técnico. | T13. Catálogo de equipos.

Elaboración propia.

Tabla 5.

Participantes y tareas asignadas de la sesión de evaluación de prototipos digitales.

ID | Rol | Tareas a realizar | Sesión
P1 | Administrativo | T1, T2, T3, T4, T5 y T6 | Primera
P2 | Administrativo | T1, T2, T3, T4, T5 y T6 | Primera
P3 | Administrativo | T1, T2, T3, T4, T5 y T6 | Primera
P4 | Jefe departamento | T1, T2, T3, T4, T5, T6, T7, T11, T12 Y T13 | Segunda
P5 | Jefe DI | T1, T2, T3, T4, T5, T6, T7, T11, T12 Y T13 | Segunda
P6 | Soporte técnico | T7, T8, T9, T10, T11, T12 Y T13 | Tercera

Elaboración propia.

La sesión de evaluación de prototipos digitales se dividió en tres sesiones para su aplicación. En la primera sesión asistieron los tres participantes administrativos, dos con el puesto de secretaria y el otro es analista. La sesión de validación tuvo una duración aproximada de 1 hora 30 minutos. En la segunda sesión asistieron dos participantes administrativos, jefes de departamento de la Universidad. La sesión tuvo una duración aproximada de 1 hora con 20 minutos. En la tercera sesión de validación participó uno de los dos técnicos del área de soporte técnico del campus en donde se desarrolló este proyecto, el otro es el autor. Esta última sesión tuvo una duración aproximada de 1 hora 15 minutos.

En cada una de las sesiones, los participantes realizaron las tareas asignadas y dieron retroalimentación general y de cada tarea realizada acerca de su percepción en las áreas de usabilidad y funcionalidad. Los materiales utilizados en la sesión de validación de los prototipos digitales fueron: grabadora de audio, cuestionarios cortos, cuestionario TAM, lápices y hoja guías con las tareas a realizar.

Los resultados obtenidos a partir del cuestionario TAM se dividieron en dos categorías, utilidad percibida y facilidad de uso. Utilidad percibida: se obtuvo un promedio de utilidad percibida de 6.42 (Figura 7). Esta puntuación sugiere que los participantes ven el sistema de mesa de ayuda como una herramienta valiosa y que les traerá beneficios al realizar su trabajo y tareas relacionadas con el soporte y la resolución de incidencias de cómputo.

Figura 7.
Gráfica de resultados cuestionario TAM - Utilidad percibida.

Los resultados de la encuesta TAM en la categoría de facilidad de uso muestran un promedio general de 6.67 (Figura 8). Esta puntuación sugiere que la mayoría de los participantes calificaron el sistema de mesa de ayuda con una puntuación alta, además los participantes mencionaron que encontraron el sistema intuitivo y fácil de utilizar. Varios de los participantes externaron que el sistema tiene una interfaz clara y amigable, por lo cual, pueden realizar las tareas sin dificultades.

Figura 8.
Gráfica de resultados cuestionario TAM - Facilidad de uso.

En general las tareas realizadas por los usuarios tuvieron comentarios positivos, los usuarios mencionaron que no tuvieron problemas para realizar las tareas asignadas, el tiempo de realización les pareció muy corto, las interfaces son muy fáciles de usar y califican su experiencia como positiva. La mayoría de los participantes concuerdan en que el sistema propuesto sería de gran ayuda para todos los usuarios, tanto al personal administrativo, jefes o área de soporte técnico. El sistema permitirá agilizar y llevar un seguimiento del proceso de gestión de incidencias de cómputo, así como poder extraer información valiosa para la creación de informes solicitada por instancias superiores.

Aunque la mayoría de los comentarios fueron positivos, también detectaron algunos problemas como: especificar tipo de información que se solicita, reubicar y eliminar campos de formularios, agregar un botón para regresar a la pantalla anterior, la opción de exportar información en distintos formatos, entre otros. Además, sugirieron algunos cambios a los prototipos, como, por ejemplo: poner listado de departamentos para que el usuario lo elija; eliminar el campo de priorización al momento de crear la solicitud; y que el campo de fecha se agregue automáticamente.

Todos los comentarios, sugerencias y problemas encontrados mediante las sesiones llevadas a cabo con los usuarios, fueron consideradas en la implementación del sistema propuesto, con el objetivo de tener un sistema de calidad y orientado al usuario.

5. Conclusiones y trabajo futuro

El presente trabajo muestra el desarrollo del sistema web de mesa de ayuda para el proceso de gestión de solicitudes de incidencias de cómputo en el departamento de informática de una universidad pública de México. El cual es congruente con las características reportadas en la literatura y que incorporó la participación de los usuarios desde el inicio hasta la evaluación del desarrollo a través de la metodología Design Thinking empatizando con sus necesidades y sugerencias, por lo que evaluaron el sistema favorablemente.

El mapeo sistemático de la literatura permitió identificar las características de diseño, implementación y evaluación que han sido empleadas en estudios anteriores. Las mesas de ayuda reportadas fueron implementadas como sistemas web, con la principal funcionalidad de dar seguimiento a las órdenes de ayuda y se evaluaron de acuerdo con la satisfacción de los usuarios. Todas estas características también están presentes en nuestro sistema.

La evaluación de los prototipos en papel y digitales realizadas por los usuarios fue muy favorable, obteniendo calificaciones de 6.67 de 7 puntos en la facilidad de uso y 6.42 en la utilidad percibida. La evaluación sugiere que el sistema podría tener una aceptación exitosa en todos los usuarios.

La continuación inmediata de este trabajo incluye el desarrollo completo del sistema, incluyendo las ideas de mejora y los problemas detectados externados por los usuarios participantes en la evaluación. Con este nuevo sistema se pretende mejorar el proceso de gestión de incidencias de cómputo al reducir los tiempos de atención y permitir que los usuarios puedan monitorear el estado de su petición, lo cual redundará en una mayor satisfacción para ellos. Además, con la información recolectada por el sistema, permitirá al departamento de informática mantener un registro detallado de las solicitudes, generar informes al instante, incrementar la satisfacción del personal administrativo, y fortalecer la capacidad de respuesta y control del área de soporte técnico. Con ello se podría contribuir al mejor funcionamiento del campus y de toda la comunidad universitaria.

6. Agradecimientos

Los autores agradecen a cada uno de los usuarios participantes por su gran contribución en cada una de las etapas del desarrollo del sistema Web de mesa de ayuda. Este trabajo se realizó gracias al apoyo del Consejo Nacional de Humanidades, Ciencias y Tecnología (CONAHCYT) de México, otorgado al primer autor.

7. Referencias

[1] Haider, R. (2019). ITIL Foundation v4. Axelos.

[2] Chanchad, Y., Kanade, S., Singh, R. (2023). HelpDesk Ticketing System. International Journal of Innovative Research in Technology (IJIRT), 9 (19), 557-560. https://ijirt.org/Article?manuscript=158803

[3] Sheehan, M. (2008). The help desk as a pivot point for IT agility. EDUCAUSE Midwest Regional Conference, Chicago, Illinois.

[4] Ismaili, F., Bulku, A., Caushi, B. A. (2018). Analysis, design, and implementation of a helpdesk management system: Case study "Albanian Radio Television". 41st International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), Opatija, Croatia. https://doi.org/10.23919/MIPRO.2018.8400092

[5] Díaz Rosabal, E. M., Díaz Vidal, J. M., Gorgoso Vázquez, A. E., Sánchez Martínez, Y., Riverón Rodríguez, G., Santiesteban Reyes, D. de la C. (2020). La dimensión didáctica de las tecnologías de la información y las comunicaciones. Revista de Investigación en Tecnologías de la Información (RITI), 8 (15), 8–15. https://doi.org/10.36825/RITI.08.15.002

[6] Kitchenham, B., Charters, S. (2007). Guidelines for performing systematic literature reviews in software engineering. EBSE Technical Report EBSE-2007-01. Keele University/University of Durham. https://www.elsevier.com/__data/promis_misc/525444systematicreviewsguide.pdf

[7] PRISMA (2020). PRISMA Flow Diagram. https://www.prisma-statement.org/prisma-2020-flow-diagram

[8] Prasetio, R. T., Ramdhani, Y., Alamsyah, D. P. (2021). Scrum method in help-desk ticketing and project management system. 3rd International Conference on Cybernetics and Intelligent System (ICORIS), Makasar, Indonesia. https://doi.org/10.1109/ICORIS52787.2021.9649626

[9] Shae, Z.-Y., Bergstrom, T., Pinhanez, C., Podlaseck, M. (2008). Multimedia chat for helpdesks: A practical SOA architecture. IEEE Congress on Services - Part I, Honolulu, HI, USA. https://doi.org/10.1109/SERVICES-1.2008.34

[10] Richard, Gaol, F. L., Warnars, H. L. H. S., Abdurachman, E., Soewito, B. (2019). Development of web application based on ITIL – incident management framework in computer laboratory. International Conference on Information Management and Technology (ICIMTech), Jakarta/Bali, Indonesia. https://doi.org/10.1109/ICIMTech.2019.8843799

[11] Harun, N. A., Huspi, S. H., Iahad, N. A. (2021). Question classification framework for helpdesk ticketing support system using machine learning. 7th International Conference on Research and Innovation in Information Systems (ICRIIS), Johor Bahru, Malaysia. https://doi.org/10.1109/ICRIIS53035.2021.9617077

[12]Al-Hawari, F., Barham, H. (2019). A machine learning based help desk system for IT service management. Journal of King Saud University - Computer and Information Sciences, 33 (4) 702-718. https://doi.org/10.1016/j.jksuci.2019.04.001

[13] Razzouk, R., Shute, V. (2012). What is design thinking and why is it important? Review of Educational Research, 82 (3), 330–348. https://doi.org/10.3102/0034654312457429

[14] Corral, L., Fronza, I. (2018). Design thinking and agile practices for software engineering: An opportunity for innovation. 19th Annual SIG Conference on Information Technology Education. Fort Lauderdale Florida, USA. https://doi.org/10.1145/3241815.3241864

.[15] Corbetta, P. (2003). Metodología y técnicas de investigación social. McGraw Hill

[16] Strauss, A., Corbin, J. (2002). Bases de la investigación cualitativa. Técnicas y procedimientos para desarrollar la Teoría Fundamentada. Universidad de Antioquia.

[17] Gray, D., Brown, S., Macanufo, J., Benítez, B. (2013). Gamestorming: A playbook for innovators, rulebreakers, and changemakers. O'Reilly Media.

[18] Macintyre, R. (2020). Rich pictures: Non visual use of visual tools. International Journal of Management and Applied Research, 7 (3), 360–369. https://doi.org/10.18646/2056.73.20-026

[19] Hurenko, O., Bohdanov, I., Tsybuliak, N., Lopatina, H., Suchikova, Y., Popova, A. (2023). Development of an inclusive educational environment in higher education institutions: A project approach using IDEF0. 18th International Conference on Computer Science and Information Technologies (CSIT), Lviv, Ukraine. https://doi.org/10.1109/CSIT61576.2023.10324022

[20] Huckvale, T., Ould, M. (1995). Process modeling – who, what and how: Role activity diagramming. En V. Grover, W. Kettinger (Eds.) Business process change: Reengineering, concepts, methods and technologies (pp. 330–349). Idea Group Publishing.

[21] Santana, S., Antonelli, R., Thomas, P. (2021). Evaluación de metodologías para la validación de requerimientos. XXVII Congreso Argentino de Ciencias de la Computación (CACIC). https://sedici.unlp.edu.ar/handle/10915/130429

[22] Davis, F. (1993). User acceptance of information technology: System characteristics, user perceptions and behavioral impacts. International Journal of Man-Machine Studies, 38 (3), 475–487. https://doi.org/10.1006/imms.1993.1022