1. INTRODUCCIÓN Y ENCUADRE DEL SERVICIO

ayudaDIGITAL es el servicio de soporte integral de tecnologías de la información y las comunicaciones puesto por el Servicio Andaluz de Salud a disposición de sus profesionales. Su función no consiste únicamente en responder llamadas o reparar equipos: organiza la relación operativa entre quienes utilizan los servicios digitales y los equipos, proveedores y unidades responsables de mantenerlos. En una organización sanitaria distribuida, con actividad asistencial continuada y con numerosos sistemas corporativos, disponer de un punto de contacto reconocible evita que cada profesional tenga que averiguar qué proveedor, área técnica o responsable funcional debe atender cada necesidad.

Desde la perspectiva de gestión de servicios, ayudaDIGITAL actúa como punto único de contacto o single point of contact. El usuario comunica una necesidad mediante alguno de los canales disponibles; la solicitud queda registrada, identificada, clasificada y vinculada al servicio o elemento afectado; posteriormente se resuelve en el propio centro de servicios o se escala al grupo resolutor competente. La trazabilidad del registro permite conocer qué se pidió, cuándo se pidió, qué diagnóstico se efectuó, quién intervino y cuál fue la solución aplicada.

ayudaDIGITAL es el Centro de Servicios al Usuario de Informática del Servicio Andaluz de Salud, el punto único de contacto (SPOC – Single Point of Contact) que canaliza, registra, gestiona y resuelve todas las incidencias, peticiones y consultas relacionadas con los activos y servicios TIC del sistema sanitario público andaluz.

1.1. Relevancia para el TFA-STI

Como futuro Técnico de Función Administrativa en Sistemas y Tecnología de la Información, tu relación con ayudaDIGITAL será dual:

• Como usuario: Registrarás incidencias y peticiones para tu entorno de trabajo.
• Como técnico de soporte: Dependiendo de tu asignación, podrías formar parte del equipo que da servicio a través de ayudaDIGITAL, resolviendo tickets, gestionando activos o participando en el modelo de priorización.

1.2. Marco Normativo y Conceptual

2. MODELO DE SERVICIO, ALCANCE Y ORGANIZACIÓN

El modelo de ayudaDIGITAL se integra en la gestión de los servicios TIC del SAS. La documentación contractual vigente describe una línea de atención y ayuda digital TIC en la que se encuadra el service desk, anteriormente denominado CSU. Sus cometidos centrales son proporcionar un punto único de contacto ante cualquier necesidad relacionada con los servicios de la organización TIC y coordinar grupos de trabajo, proveedores y suministradores para cubrir las necesidades de los usuarios y cumplir los niveles de servicio acordados.

La existencia de un punto único no implica que un solo equipo resuelva todas las solicitudes. El centro de servicios ejerce funciones de recepción, validación, registro, diagnóstico inicial, resolución de primer contacto cuando es posible, comunicación, seguimiento y escalado. La resolución especializada puede corresponder a soporte provincial, administradores de sistemas, equipos de aplicaciones, seguridad, redes, bases de datos, responsables funcionales o empresas proveedoras. El valor del modelo está precisamente en ocultar al usuario esa complejidad organizativa sin perder la trazabilidad interna.

La organización por niveles facilita que cada solicitud sea tratada con el grado de especialización necesario. El primer nivel concentra la atención inicial y la resolución de casos conocidos o estandarizados. Los niveles superiores atienden situaciones de mayor complejidad, especialización o impacto. El escalado puede ser funcional, cuando se remite a un equipo con conocimientos o permisos superiores, o jerárquico, cuando la gravedad, el incumplimiento potencial o la necesidad de coordinación exige informar a responsables con autoridad de supervisión.

La documentación del SAS contempla además gestores de procesos, responsables de operación, gestores provinciales y mecanismos de coordinación con terceros resolutores. Estos roles no sustituyen al técnico que resuelve; aseguran que el conjunto del proceso funciona, que los datos son de calidad, que las solicitudes críticas reciben seguimiento y que se analizan tendencias, demoras y oportunidades de mejora.

3. CANALES DISPONIBLES Y OMNICANALIDAD

El portal oficial de ayudaDIGITAL presenta un servicio disponible de manera ininterrumpida durante las veinticuatro horas de todos los días del año y enumera varios canales de relación. La multiplicidad de canales persigue que el profesional pueda contactar desde el puesto de trabajo, desde un dispositivo móvil o mediante un canal asistido cuando la situación impida utilizar el autoservicio. La omnicanalidad exige que el cambio de canal no rompa la continuidad: una solicitud registrada por web debe poder ser consultada y atendida por los equipos de soporte con la misma información básica que una solicitud iniciada por teléfono.

Uno de los pilares de un Service Desk moderno es la omnicanalidad: ofrecer múltiples vías de contacto manteniendo la coherencia de la información y el servicio. ayudaDIGITAL implementa este principio con tres canales principales.

3.1. ayudaDIGITAL Área Personal (Web)

3.1.1. Funcionalidades Principales

• Registro de Incidencias: Cuando algo no funciona correctamente (ej: «No puedo acceder a Diraya», «Mi impresora no imprime», «El ordenador se reinicia solo»).
• Registro de Peticiones: Cuando se solicita algo nuevo (ej: «Necesito acceso a la aplicación BPS», «Solicitud de instalación de software», «Alta de cuenta de correo»).
• Seguimiento de Solicitudes: Visualización del estado en tiempo real (Registrada, En Proceso, Resuelta, Cerrada).
• Buscador de Incidencias y Peticiones: Permite localizar solicitudes previas por diferentes criterios.
• Favoritos: Personalización de las solicitudes más frecuentes para acceso rápido.
• Aprobaciones: Gestión de solicitudes que requieren validación jerárquica (ej: accesos a sistemas con datos sensibles).
• «Busca tu Solución»: Base de conocimiento con artículos de autoresolución (knowledge base – KB).

3.1.2. Catálogo de Servicios en el Área Personal

El catálogo está estructurado jerárquicamente:

3.2. ayudaDIGITAL Escritorio (Cliente Desktop)

3.2.1. Funcionalidades Específicas

• Información Técnica Automática del Equipo: Cuando se abre un ticket desde el cliente de escritorio, este captura y envía automáticamente datos técnicos del equipo (hostname, IP, versión de SO, memoria RAM, software instalado). Esto acelera el diagnóstico y evita preguntas redundantes al usuario.
• Ubicación Detallada del Equipo: Permite al usuario rellenar la ubicación física exacta del equipo (Planta, Unidad, Número de habitación), fundamental para el soporte presencial.
• Avisos de Caducidad de Contraseña DMSAS: El cliente notifica cuando se aproxima la fecha de renovación obligatoria de la contraseña del dominio DMSAS (Directorio Microsoft Active Directory del SAS).
• Conversor de Teléfonos de Red Corporativa: Herramienta integrada para convertir extensiones internas a formato externo y viceversa.
• Notificaciones Push: Alertas informativas sobre mantenimientos programados, actualizaciones críticas, avisos de seguridad.

3.3. App Móvil ayudaDIGITAL

3.3.1. Funcionalidades Móviles

• Registro de Incidencias/Peticiones: Interfaz táctil optimizada para smartphones.
• Consulta de Solicitudes: Visualización del estado y detalles.
• Notificaciones Push: Alertas en tiempo real sobre actualizaciones de tickets.
• «Busca tu Solución»: Acceso a la KB desde dispositivos móviles.

La app es especialmente útil para profesionales en movilidad (médicos/as de urgencias domiciliarias, enfermeras de distrito) que necesitan soporte sin estar físicamente en su puesto de trabajo habitual.

3.4. Otros Canales Complementarios

Aunque el canal digital es el principal, ayudaDIGITAL mantiene canales tradicionales para situaciones específicas:

• Teléfono 24×7: Línea directa para incidencias críticas que impidan el acceso a los canales digitales.
• Correo Electrónico: Para consultas que no requieren registro formal de ticket.
• Soporte Presencial: Técnicos de campo para intervenciones in situ (reparaciones hardware, instalaciones).

3.5. Área Personal y portal web

El Área Personal permite registrar y gestionar solicitudes, consultar su evolución, acceder a soluciones de autoservicio y configurar notificaciones. El registro estructurado obliga a identificar el tipo de demanda, el servicio o aplicación, el síntoma y otros datos necesarios. Esta estructuración mejora la asignación automática y reduce el tiempo empleado en solicitar información adicional.

3.6. ayudaDIGITAL Escritorio

La aplicación de escritorio acerca el soporte al equipo corporativo. Permite crear y seguir peticiones e incidencias, consultar información del puesto y su ubicación, revisar datos del usuario DMSAS, recibir avisos, acceder a soluciones y utilizar determinadas utilidades. La página oficial señala que puede proporcionar información técnica del equipo cuando el personal de informática la requiera y avisar cuando se aproxima el cambio de contraseña.

3.7. App, WhatsApp, Zoom, teléfono y correo

La app móvil se localiza como «ayudaDIGITAL» en las tiendas de aplicaciones y facilita el acceso al soporte desde movilidad. El portal oficial también ofrece WhatsApp, Zoom como herramienta corporativa de comunicación, el canal telefónico —con numeración corta 31 70 00 desde la red corporativa y 955 01 70 00— y el correo corporativo del servicio. Estos datos son operativos y pueden evolucionar, por lo que en un tema de larga duración conviene presentar el concepto y remitir a la página oficial para la verificación del dato concreto.

La elección del canal depende del contexto. El Área Personal es idónea para registrar una solicitud con detalle y adjuntar información; el escritorio permite contextualizar el puesto; el canal móvil resulta útil fuera del equipo habitual; el teléfono facilita la comunicación síncrona cuando el profesional necesita atención asistida. Ningún canal debe utilizarse para incluir datos clínicos innecesarios, contraseñas o información sensible que no sea imprescindible para diagnosticar la necesidad TIC.

La disponibilidad permanente del servicio no significa que todas las peticiones se ejecuten inmediatamente ni que todos los resolutores trabajen con el mismo horario. Significa que el profesional dispone de canales para trasladar la necesidad y que el modelo aplica el tratamiento correspondiente según el tipo, prioridad, servicio y acuerdo vigente.

La aplicación móvil permite gestionar solicitudes desde movilidad. WhatsApp, Zoom, teléfono y correo ofrecen atención asistida o comunicación alternativa. El teléfono resulta especialmente útil cuando el profesional no puede acceder a los canales digitales o necesita explicar una situación compleja. El correo puede servir para comunicaciones corporativas, pero no debe utilizarse como sustituto informal del registro cuando la necesidad requiere trazabilidad.

ayudaDIGITAL Escritorio aporta contexto del puesto corporativo. La documentación oficial menciona información del equipo y su ubicación, datos del usuario DMSAS, creación y gestión de solicitudes, avisos, «Busca tu Solución», utilidades y una opción de modificación de contraseña. Debe evitarse memorizar materiales antiguos sobre funciones que hayan podido cambiar: la fuente de referencia es el portal oficial actualizado.

El Área Personal es el canal con mayor capacidad de autoservicio. Su estructura facilita escoger el elemento del catálogo, completar campos obligatorios y consultar solicitudes previas. También permite acceder a soluciones publicadas y configurar notificaciones. Esta forma de registro es especialmente adecuada para peticiones que requieren datos estructurados o aprobación.

Los canales no son servicios independientes: son puertas de entrada al mismo modelo de soporte. El identificador de la solicitud y el repositorio común permiten que el usuario consulte la evolución sin depender del operador que atendió el primer contacto. La trazabilidad requiere registrar las comunicaciones relevantes, conservar la categoría y evitar que una conversación en un canal asistido quede fuera de la herramienta de gestión.

3.8. Canal, función y trazabilidad

4. LA SOLICITUD: REGISTRO, DATOS Y CICLO DE VIDA

La unidad operativa que permite gestionar la demanda es la solicitud. Bajo esta denominación general pueden registrarse incidencias, peticiones, consultas y otros tipos de actividad definidos en el catálogo. Un registro de calidad debe expresar con claridad quién solicita, qué servicio o elemento está afectado, dónde se produce, qué síntoma se observa, desde cuándo ocurre, a cuántos usuarios afecta, si existe alternativa de trabajo y qué evidencias pueden ayudar al diagnóstico.

La información inicial condiciona la clasificación, la prioridad y la asignación. Un texto como «no funciona» obliga al operador a reconstruir el contexto mediante preguntas. En cambio, «al iniciar Estación Clínica aparece un error de autenticación en tres puestos de la consulta, desde las 08:10, mientras otras aplicaciones corporativas funcionan» permite discriminar entre un problema de identidad, de aplicación, de red o de equipo. La calidad del registro no sustituye al diagnóstico, pero reduce la ambigüedad.

El ciclo de vida habitual comprende registro, categorización, priorización, diagnóstico, asignación, investigación, resolución, validación y cierre. No todas las solicitudes recorren idéntico camino: una petición estándar puede resolverse mediante un flujo automatizado de aprobación; una incidencia conocida puede cerrarse en primer contacto; una incidencia compleja puede escalarse a varios equipos; un problema puede permanecer abierto mientras se implanta el cambio que elimina su causa.

Los estados deben representar la situación real. «Asignada» no significa «resuelta»; «pendiente de usuario» requiere que exista una interacción necesaria; «resuelta» indica que se ha aplicado una solución, pero el cierre puede exigir confirmación o validación. Los procedimientos deben evitar cierres en falso y registrar los pasos de investigación y las comunicaciones relevantes.

El cierre debe incluir una descripción comprensible de la resolución. Cuando la solución es reutilizable, conviene transformarla en conocimiento para futuras solicitudes. Cuando se detecta una causa común o una repetición significativa, la información alimenta la gestión de problemas. Cuando se modifica una configuración, el proceso debe mantener la coherencia con la información de activos y elementos de configuración.

5. TIPOS DE ACTIVIDAD: INCIDENCIAS, PETICIONES, CONSULTAS Y PROBLEMAS

Una de las preguntas más frecuentes en la oposición es la diferenciación precisa entre los tipos de solicitudes. ITIL 4 establece definiciones claras que ayudaDIGITAL implementa.

5.1. Incidencias (Incidents)

5.1.1. Características de una Incidencia

• Algo que funcionaba, ha dejado de funcionar.
• Requiere acción correctiva inmediata.
• Se prioriza según impacto y urgencia.
• Ejemplos:
  • «No puedo imprimir desde mi PC»
  • «Diraya muestra error al guardar informes clínicos»
  • «El ordenador no arranca»
  • «No recibo correos electrónicos»

5.2. Peticiones de Servicio (Service Requests)

5.2.1. Características de una Petición

• Se solicita algo nuevo o diferente del estado actual.
• No es una rotura de servicio, es una necesidad planificada.
• Suelen tener flujos de aprobación (autorizaciones de superiores).
• Ejemplos:
  • «Solicito acceso a la aplicación BPS para consulta de población asignada»
  • «Necesito que me instalen Microsoft Project en mi equipo»
  • «Alta de cuenta de correo para nuevo personal»
  • «Cambio de ubicación de impresora de una planta a otra»

5.3. Problemas (Problems)

5.3.1. Gestión de Problemas en ayudaDIGITAL

Los usuarios finales normalmente no registran problemas directamente. La Gestión de Problemas es un proceso interno del equipo TIC:

• Se identifica un patrón de incidencias recurrentes (ej: «Todos los martes a las 9:00, Diraya se ralentiza en Consultas Externas»).
• Se abre un registro de PROBLEMA para investigar la causa raíz.
• Tras el análisis, se implementa una solución permanente (ej: «La causa era una tarea programada de backup que consumía recursos. Se reprograma para horario nocturno»).
• Se cierra el problema y se documenta en la KB como «Error Conocido – Resuelto».

La diferencia entre los tipos de actividad no es meramente terminológica. Determina el flujo, las autorizaciones, los compromisos, el tratamiento de la prioridad y los equipos participantes. Una incidencia parte de una interrupción o degradación no planificada; una petición solicita una prestación predefinida; una consulta demanda información o asesoramiento; un problema investiga la causa subyacente de una o varias incidencias.

Una misma necesidad puede cambiar de perspectiva. La contraseña olvidada puede resolverse mediante una petición estándar de restablecimiento; una imposibilidad generalizada de autenticación constituye una incidencia; la repetición de bloqueos por una política defectuosa puede originar un problema. La clasificación debe atender al objetivo del proceso y al estado esperado del servicio, no solo a las palabras usadas por el usuario.

6. GESTIÓN DE INCIDENCIAS

La gestión de incidencias tiene como objetivo restaurar la operación normal del servicio lo antes posible y minimizar el impacto negativo sobre la actividad. «Operación normal» no siempre significa eliminar definitivamente la causa. Una solución temporal o workaround puede restablecer la capacidad de trabajo mientras la gestión de problemas investiga la causa raíz y la gestión de cambios implanta la corrección permanente.

El proceso comienza con la detección o comunicación. La incidencia se registra y se categoriza mediante servicio, CI, tipología y síntoma. A continuación se calcula o ajusta la prioridad, se realiza el diagnóstico inicial y se comprueba el conocimiento disponible. Si el primer nivel dispone de un procedimiento verificado, puede resolver en el primer contacto; de lo contrario, se asigna al resolutor adecuado con la información necesaria.

1. Detección y registro: creación del identificador y captura de datos mínimos.
2. Categorización: ubicación en el catálogo y elección de tipología, síntoma y CI.
3. Priorización: evaluación de criticidad, severidad e impacto.
4. Diagnóstico inicial: comprobaciones, preguntas y búsqueda de soluciones conocidas.
5. Escalado: transferencia funcional o jerárquica cuando proceda.
6. Investigación y resolución: aplicación de solución definitiva o temporal.
7. Validación y cierre: documentación, confirmación y clasificación de la causa.

Las incidencias graves requieren comunicación y seguimiento reforzados. La documentación del SAS distingue P0, prioridad extrema reservada a incidencias excepcionales, y P1, prioridad muy alta. Una P1 puede pasar a P0 cuando concurre una disrupción de gran alcance, por ejemplo afectación de servicios críticos asistenciales con impacto en la ciudadanía, varios centros de más de una provincia o un número importante de usuarios. P0 no es una prioridad cotidiana ni aplicable a peticiones.

La resolución debe documentar las acciones realizadas. Esta obligación permite auditoría, transferencia de conocimiento y análisis posterior. En una incidencia relevante puede realizarse análisis forense operativo —no necesariamente forense judicial— para reconstruir qué ocurrió, cómo respondió el servicio, si el escalado fue correcto y qué mejoras deben implantarse. El objetivo es evitar la repetición de fallos de proceso y fortalecer la continuidad.

La comunicación con el usuario forma parte del proceso. Debe informar de la recepción, cambios significativos de estado, peticiones de colaboración y resolución. En incidencias generalizadas es más eficiente emitir avisos coordinados que responder individualmente con mensajes contradictorios. La comunicación debe ser comprensible, evitar tecnicismos innecesarios y no prometer tiempos que no estén respaldados por un acuerdo formal.

7. GESTIÓN DE PETICIONES, ACCESOS Y PROBLEMAS

Las peticiones de servicio representan demandas previsibles que pueden normalizarse: alta o baja de accesos, cuentas de correo, VPN, reglas de red, modificaciones de datos maestros, instalación de software autorizado o mejora de una aplicación. El catálogo define qué se puede solicitar, quién puede hacerlo, qué datos son obligatorios, qué aprobaciones se necesitan y qué equipo ejecuta cada paso.

La estandarización permite automatizar. Un formulario puede validar el perfil del solicitante, solicitar la autorización del responsable, crear tareas para varios equipos y registrar el resultado. La automatización no elimina los controles: los accesos deben seguir el principio de mínimo privilegio, las reglas de cortafuegos requieren validación de seguridad y los cambios con riesgo deben pasar por la gestión de cambios.

La documentación contractual del SAS describe específicamente un servicio de gestión de accesos destinado a dotar y revocar permisos, manteniendo el registro, verificando solicitudes y monitorizando las acciones necesarias. La baja o modificación oportuna es tan importante como el alta. Un acceso que permanece activo después de un cambio de puesto constituye un riesgo de seguridad y de cumplimiento.

La gestión de problemas opera en dos modalidades. La reactiva investiga las causas de incidencias ya producidas; la proactiva analiza tendencias, eventos y datos para prevenir futuras interrupciones. El registro del problema reúne incidencias relacionadas, hipótesis, análisis, causa raíz, errores conocidos, alternativas de trabajo y cambios necesarios.

Cuando se identifica la causa y existe una alternativa de trabajo, puede registrarse un error conocido. El error conocido no equivale a problema resuelto: significa que la organización comprende suficientemente el fallo y dispone de información para reducir su impacto, aunque la eliminación definitiva requiera una versión de software, un cambio de arquitectura o la actuación de un proveedor.

El comité de problemas coordina a equipos técnicos, responsables funcionales y terceros. Su función es priorizar investigaciones, asignar acciones, valorar el impacto en el negocio y comprobar que las soluciones se implantan. La relación con JIRA u otras herramientas de desarrollo permite vincular errores a versiones de producto; la relación con la base de conocimiento difunde soluciones temporales; la relación con la CMS aporta datos de configuración.

7.1. Relación con la gestión de cambios

Muchas resoluciones y peticiones requieren modificar el entorno. Instalar una versión, alterar una configuración, ampliar permisos o cambiar una regla de red puede restaurar el servicio, pero también introducir riesgo. La gestión de cambios proporciona evaluación, autorización, planificación, prueba, comunicación y reversión. El registro de ayudaDIGITAL debe enlazar la solicitud con el cambio cuando proceda.

Un cambio estándar es repetible, de bajo riesgo y preautorizado; puede estar integrado en una petición del catálogo. Un cambio normal necesita evaluación y autorización según su riesgo. Un cambio de emergencia acelera el procedimiento para restaurar o proteger un servicio crítico, pero no elimina la obligación de documentar y revisar posteriormente.

La gestión de problemas propone correcciones, pero no debe implantarlas de forma descontrolada. El problema identifica causa y solución; el cambio gobierna la modificación; la gestión de versiones o despliegues introduce el software; la configuración registra el nuevo estado. Esta cadena evita que una solución técnica correcta se convierta en una nueva incidencia por falta de coordinación.

7.2. Accesos y principio de mínimo privilegio

Las solicitudes de acceso deben indicar sistema, función, perfil, duración y responsable que autoriza. Conceder un perfil genérico más amplio de lo necesario facilita el trabajo inmediato, pero incrementa riesgo. El mínimo privilegio obliga a proporcionar solo las capacidades indispensables y a revisar los accesos cuando cambie el puesto.

La separación de funciones puede exigir que quien solicita no sea quien aprueba ni quien ejecuta. El registro demuestra la cadena de autorización. Para accesos temporales debe existir fecha de caducidad; para cuentas genéricas, justificación, responsable y controles adicionales; para bajas, revocación coordinada en todos los sistemas afectados.

8. CATÁLOGO DE SERVICIOS Y DE SOLICITUDES

El catálogo de servicios es un documento oficial y dinámico que describe los servicios ofrecidos por la organización TIC. En ayudaDIGITAL se presenta segmentado por perfiles y categorías para que cada profesional vea las opciones que le corresponden. El catálogo no es una simple lista de aplicaciones: establece el punto de encuentro entre la oferta del servicio y la demanda del usuario.

Cada elemento del catálogo debe incluir una denominación comprensible, descripción, tipo de demanda, categoría, destinatarios, datos requeridos, autorizaciones, procedimiento, resolutores, escalados y compromisos. Mantenerlo actualizado exige coordinación entre las áreas de la STIC, porque una aplicación nueva, una retirada, un cambio de proveedor o una modificación normativa alteran la forma de atención.

El anexo contractual del catálogo contiene ejemplos concretos como altas en Diraya, DMSAS, GERHONTE, SIGLO, SARAC, cuentas de correo, VPN, nombres DNS, políticas de copia de seguridad y reglas de cortafuegos. Estos ejemplos muestran que el catálogo combina servicios asistenciales, corporativos, de seguridad, comunicaciones y productividad.

El catálogo de solicitudes es la vista operativa que el usuario emplea para registrar una necesidad. Debe usar lenguaje orientado a la tarea: «alta de acceso», «problema de impresión» o «modificación de regla de cortafuegos» resulta más útil que el nombre interno de un equipo resolutor. Una buena categorización dirige la solicitud; una mala categorización produce reasignaciones, retrasos y datos estadísticos poco fiables.

La segmentación por perfiles evita sobrecargar al usuario con opciones irrelevantes y reduce solicitudes no autorizadas. El perfil puede depender de categoría profesional, centro, unidad, responsabilidad o pertenencia a grupos. La personalización no debe ocultar un canal para comunicar incidencias generales que afecten a cualquier profesional.

El portal muestra al usuario una vista filtrada, pero detrás existen procesos de petición, acceso, cambio, incidente o consulta. Dos elementos visualmente similares pueden tener flujos muy diferentes. El alta de una cuenta nominativa puede requerir validación de identidad y aprobación; una guía de uso puede resolverse mediante conocimiento; una modificación de firewall debe someterse a análisis técnico y de seguridad.

8.1. Relación entre catálogo, portal y procesos

La publicación del catálogo requiere gobierno. El propietario del servicio define qué se ofrece; seguridad establece controles y autorizaciones; los grupos resolutores documentan actividades; el service desk valida que la descripción sea comprensible; la gestión de niveles de servicio incorpora compromisos; la gestión financiera o contractual puede aportar costes y límites. La incorporación o retirada de un elemento debe comunicarse y versionarse.

Un elemento de catálogo debe evitar ambigüedades. La denominación «problema informático» sería demasiado genérica, mientras «alta VPN para profesional del SAS» identifica el resultado esperado. Los campos deben solicitar solo información útil y aplicar validaciones. Cuando existe un catálogo de centros, aplicaciones o perfiles, conviene ofrecer selección controlada en lugar de texto libre.

El catálogo puede analizarse en varios niveles. En la parte superior se sitúan las categorías de servicio; debajo aparecen servicios, ofertas y elementos de solicitud; finalmente, cada formulario recoge atributos y reglas. Esta jerarquía permite navegar desde una necesidad expresada en lenguaje de usuario hasta un procedimiento técnico concreto.

8.2. Estructura lógica del catálogo

La gestión del catálogo incluye mantener matrices de escalado y procedimientos, formar a operadores y comunicar cambios. También debe personalizar la oferta según el perfil. Esta segmentación reduce errores de solicitud y evita que una persona pida prestaciones para las que no está legitimada.

9. GESTIÓN DE LA CONFIGURACIÓN Y ACTIVOS TIC

La gestión de activos y la gestión de la configuración están relacionadas, pero persiguen objetivos diferentes. La gestión de activos controla el valor, coste, propiedad, estado contractual y ciclo de vida de los recursos. La gestión de la configuración mantiene información fiable sobre los elementos necesarios para prestar servicios y sobre sus relaciones. Un ordenador puede ser simultáneamente activo patrimonial y elemento de configuración, pero no todos los elementos de configuración tienen tratamiento patrimonial.

La documentación del SAS utiliza el término CMS, sistema de gestión de la configuración, como conjunto de fuentes y herramientas que proporcionan información centralizada. Una CMDB es una base de datos incluida en ese sistema. El CMS puede integrar varias CMDB, inventarios automáticos, repositorios documentales y datos de monitorización.

La gestión de activos contribuye a la configuración con datos de adquisición, garantía, contrato, asignación y retirada. A su vez, la configuración aporta información sobre uso y dependencia que ayuda a decidir renovación o sustitución. La coordinación evita que un equipo figure retirado patrimonialmente pero siga asociado a un servicio activo.

En incidencias, el CI aporta contexto y criticidad. En problemas, permite correlacionar fallos y estudiar componentes comunes. En cambios, ayuda a analizar impacto, dependencias y riesgo. Después del cambio, la configuración debe actualizarse; si no se hace, la CMDB pierde fiabilidad precisamente cuando más se necesita.

9.1. Integración con incidencias, problemas y cambios

La auditoría compara el estado registrado con el real. Las discrepancias pueden revelar instalaciones no autorizadas, equipos retirados que siguen activos, cambios no documentados o relaciones obsoletas. El objetivo no es que la CMDB contenga todos los datos imaginables, sino que los datos necesarios sean suficientemente fiables para apoyar decisiones.

La información puede proceder de descubrimiento automático, herramientas de gestión del puesto, directorios, contratos, responsables de servicio y registros manuales. Cuando varias fuentes describen el mismo elemento se necesita reconciliación: identificar qué fuente es autoritativa para cada atributo y resolver duplicados. Por ejemplo, la herramienta de inventario puede ser autoritativa para memoria y versión instalada, mientras el responsable de servicio lo es para criticidad y propietario funcional.

9.2. Exactitud, reconciliación y auditoría

Las relaciones deben tener semántica: «se ejecuta en», «depende de», «se conecta a», «está ubicado en» o «es responsable de». Una colección de CI sin relaciones se parece a un inventario enriquecido, pero no permite análisis de impacto. Al mismo tiempo, un modelo excesivamente detallado resulta difícil de mantener. La profundidad debe responder a casos de uso concretos: soporte, cambios, continuidad, seguridad y auditoría.

El valor de la configuración aparece cuando los CI se relacionan. Una aplicación puede depender de servidores de presentación, servicios de autenticación, bases de datos, almacenamiento, balanceadores, DNS, redes y certificados. Si una base de datos falla, la relación permite identificar qué aplicaciones y centros pueden verse afectados. Si se planifica un cambio de certificado, permite anticipar consumidores y ventanas de intervención.

9.3. Modelo de relaciones y servicio

La relación entre solicitud y CI es decisiva. Si una incidencia se vincula al equipo o aplicación correcta, el técnico puede consultar historial, criticidad, ubicación, versión, dependencias y cambios recientes. También se puede detectar que múltiples incidencias apuntan al mismo componente. Sin esta relación, la gestión queda reducida a textos libres difíciles de correlacionar.

La calidad de configuración depende de procesos de alta, modificación, verificación y retirada. El descubrimiento automático detecta hardware y software, pero no comprende por sí solo la importancia de negocio, el responsable funcional o la relación lógica entre servicios. Por eso la automatización debe complementarse con gobierno y reconciliación de datos.

El ciclo de vida del activo comprende planificación, adquisición, recepción, instalación, asignación, operación, mantenimiento, reasignación y retirada segura. La retirada debe incluir borrado o destrucción adecuada de la información, actualización del inventario y cierre de relaciones. En un entorno sanitario, la pérdida de control sobre un equipo puede implicar riesgos de confidencialidad, disponibilidad y continuidad.

10. MATRIZ DE PRIORIZACIÓN DE LA ACTIVIDAD

La prioridad expresa la importancia relativa de una solicitud y determina la rapidez y el nivel de atención que debe recibir. No debe confundirse con el orden de llegada ni con la presión subjetiva del solicitante. La matriz convierte variables previamente definidas en una prioridad reproducible, reduce decisiones arbitrarias y permite aplicar acuerdos de nivel de servicio coherentes.

En la documentación operativa del SAS, el cálculo automático de prioridad se aplica a las incidencias. Las consultas y peticiones se tratan por defecto con prioridad normal, aunque un profesional TIC puede modificarla excepcionalmente. Se distinguen cuatro niveles globales: P0 extrema, solo para incidencias; P1 muy alta; P2 alta; y P3 normal.

10.1. Variables del cálculo

El modelo utiliza tres variables: criticidad, severidad e impacto. La criticidad indica la importancia del CI para el servicio o negocio. La severidad expresa el grado de afección asociado a la tipología o síntoma. El impacto describe el contexto y alcance de la incidencia.

La severidad muy grave se asocia a indisponibilidad para trabajar; la grave, a pérdida de una funcionalidad importante; y la leve, a degradación que permite continuar trabajando. El impacto se interpreta de manera distinta según el ámbito. En puesto de usuario se valora si existe otro equipo cercano y si el trabajo es de cara al paciente. En sistemas de información se valora si afecta a un usuario, a varios o a muchos compañeros. Para infraestructura, el personal TIC valora el alcance real o potencial y la redundancia disponible.

10.2. Matriz por defecto

La matriz combina el impacto con el producto lógico criticidad por severidad. Los valores 1, 2 y 3 representan respectivamente muy alto, alto y normal para impacto y criticidad; en severidad representan muy grave, grave y leve. El resultado 1 equivale a P1, 2 a P2 y 3 a P3.

                 CRITICIDAD × SEVERIDAD
IMPACTO   C1S1 C1S2 C1S3 C2S1 C2S2 C2S3 C3S1 C3S2 C3S3
   1        1    1    2    1    2    2    1    2    2
   2        1    1    2    2    2    3    2    3    3
   3        2    2    3    2    3    3    3    3    3

Existe una matriz específica para soporte provincial, además de reglas especiales para puestos de especial importancia. Si un usuario de un puesto de especial importancia no puede continuar su trabajo en un equipo cercano, la incidencia puede clasificarse como prioridad muy alta con independencia de otras variables. Esta regla refleja la necesidad de proteger la asistencia sanitaria y determinados puestos esenciales.

11. NIVELES DE SOPORTE, ASIGNACIÓN Y ESCALADO

La asignación selecciona el grupo que debe intervenir. Para que sea correcta, la categorización debe relacionar servicio, tipología, CI y localización con la matriz de escalado. El centro de servicios necesita mantener estas matrices actualizadas porque los contratos, proveedores, aplicaciones y competencias cambian.

El escalado funcional se produce cuando el equipo actual no dispone de conocimiento, acceso o herramientas suficientes. El jerárquico se utiliza cuando la prioridad, el riesgo de incumplimiento o la necesidad de coordinación exige informar a responsables. Ambos pueden coexistir: una incidencia P1 puede escalarse funcionalmente al especialista de una aplicación y jerárquicamente al gestor de incidencias y responsables de operación.

Los niveles de soporte no deben entenderse como una jerarquía personal, sino como niveles de capacidad resolutiva. El primer nivel debe resolver todo lo que pueda de forma segura y documentada. Escalar demasiado pronto aumenta transferencias y tiempos; retener demasiado una solicitud impide que llegue al especialista. La calidad se mide por el equilibrio entre resolución en primer contacto y escalado oportuno.

El escalado debe incluir información suficiente: síntoma, alcance, pruebas realizadas, resultados, evidencias, CI y contacto. Una solicitud sin diagnóstico previo obliga al siguiente equipo a repetir trabajo. Por ello, los indicadores del SAS controlan la calidad de los datos de escalado, incluida la presencia del CI y del síntoma correctos.

El seguimiento no termina con la asignación. ayudaDIGITAL debe conocer la evolución, detectar demoras, comunicar al usuario y activar mecanismos de intervención cuando se superan umbrales. La coordinación con múltiples resolutores es especialmente importante en incidencias que atraviesan red, autenticación, aplicación y base de datos.

12. CONOCIMIENTO, AUTOSERVICIO, EVENTOS Y AUTOMATIZACIÓN

La gestión del conocimiento transforma experiencias de resolución en información reutilizable. Una base de conocimiento eficaz contiene soluciones verificadas, errores conocidos, guías, preguntas frecuentes y procedimientos. Su valor depende de la actualización, la clasificación y la adaptación al público: una guía para el usuario debe ser clara; un procedimiento técnico puede contener detalles de diagnóstico y escalado.

«Busca tu Solución» representa el enfoque de autoservicio de ayudaDIGITAL. El usuario puede resolver necesidades sencillas sin esperar atención asistida, mientras el centro de servicios reduce contactos repetitivos. El autoservicio no consiste en trasladar responsabilidad al usuario; debe ofrecer instrucciones seguras, comprensibles y con una vía clara para registrar la solicitud si no funciona.

La gestión de eventos complementa la comunicación de usuarios. Las herramientas de monitorización generan eventos que deben filtrarse, correlacionarse e interpretarse. Un evento informativo no es necesariamente una incidencia; una excepción que indica interrupción puede generar una incidencia; una tendencia repetida puede originar un problema; una modificación relevante puede actualizar la configuración.

La automatización puede validar formularios, asignar grupos, solicitar aprobaciones, ejecutar tareas estándar y enviar notificaciones. Debe estar gobernada: un error automatizado se propaga con rapidez. Los flujos necesitan control de versiones, pruebas, registros de auditoría, gestión de excepciones y revisión periódica.

La inteligencia artificial puede apoyar la búsqueda de manuales, clasificación o respuesta a consultas, pero no elimina la responsabilidad de verificar. ayudaDIGITAL ha incorporado una funcionalidad de búsqueda sobre manuales dentro del proyecto AlejandrIA, accesible desde distintos canales. En un ámbito sanitario, la respuesta generada debe apoyarse en documentación revisada y nunca debe utilizarse para inventar procedimientos o solicitar credenciales.

13. NIVELES DE SERVICIO, INDICADORES, SEGURIDAD Y MEJORA CONTINUA

Los acuerdos de nivel de servicio traducen expectativas en compromisos medibles. Pueden incluir tiempos de atención, diagnóstico, escalado y resolución, disponibilidad de canales, calidad de registro y satisfacción. No existe un único tiempo universal para todas las organizaciones ni para todas las prioridades; debe utilizarse el acuerdo concreto aplicable al servicio.

Los indicadores deben cubrir eficacia, eficiencia y calidad. Medir solo el número de tickets cerrados incentiva cierres prematuros. Es preferible combinar resolución en primer contacto, reaperturas, escalados incorrectos, calidad del dato, antigüedad de solicitudes, cumplimiento de compromisos, satisfacción y recurrencia.

La mejora continua utiliza estos datos para identificar causas, diseñar acciones, comprobar resultados y estandarizar. El ciclo PDCA resulta aplicable: planificar la mejora, implantarla de forma controlada, comprobar indicadores y actuar para consolidar o corregir. El responsable de mejora de procesos audita, modela y promueve la reingeniería cuando el proceso no alcanza sus objetivos.

La seguridad atraviesa todo el servicio. La autenticación debe verificar al usuario antes de ejecutar operaciones sensibles; los accesos requieren autorización; los registros deben protegerse frente a consulta o modificación indebida; las comunicaciones deben limitar datos personales y secretos. Las contraseñas nunca deben incluirse en una solicitud.

El ENS exige una gestión basada en riesgos y medidas de protección adecuadas. La trazabilidad de ayudaDIGITAL contribuye a saber quién realizó una acción y cuándo. La protección de datos exige minimización: una incidencia técnica debe describir el fallo sin copiar información clínica identificable salvo que sea estrictamente necesaria y esté autorizada.

13.1. Gestión de la demanda, disponibilidad y continuidad del centro de servicios

La disponibilidad de un servicio de soporte no depende únicamente de mantener abierto un canal. Requiere personas, herramientas, telefonía, autenticación, conectividad, repositorios de conocimiento y sistemas de registro capaces de continuar operando ante picos de demanda o fallos parciales. La documentación contractual exige que ayudaDIGITAL disponga de mecanismos para afrontar tanto variaciones estacionales previsibles como aumentos no planificables derivados de una incidencia generalizada. Por ello, la planificación debe combinar análisis histórico, capacidad de refuerzo y procedimientos de continuidad.

Una punta de demanda puede ser planificable cuando existe un patrón conocido, por ejemplo incorporaciones, renovaciones de contratos o periodos de alta necesidad de credenciales. En ese caso, la organización debe anticipar recursos, reforzar conocimiento y preparar comunicaciones. Una caída generalizada de un servicio crítico es un evento no planificable: genera contactos simultáneos, reduce la utilidad de atender cada caso de forma aislada y exige activar mensajes coordinados, agrupación de incidencias y seguimiento centralizado.

La agrupación no debe hacer desaparecer la trazabilidad individual cuando el usuario necesita conocer el resultado, pero evita duplicar diagnósticos. Una incidencia maestra puede concentrar la investigación y relacionar solicitudes hijas o contactos asociados. Cuando el servicio se restaura, el centro comunica la resolución de forma consistente y conserva los datos para evaluar volumen, tiempos, impacto y causas.

La continuidad del propio service desk debe contemplar la indisponibilidad de un canal. Si el Área Personal no funciona, los canales asistidos o móviles pueden mantener el contacto; si el canal telefónico se degrada, el autoservicio y las notificaciones deben seguir disponibles. Esta redundancia de canales es una consecuencia práctica de la omnicanalidad, aunque no todos los canales ofrecen exactamente las mismas funciones.

13.2. Gobierno de los datos de soporte

Los datos registrados por ayudaDIGITAL tienen valor operativo y de gobierno. Permiten resolver solicitudes, detectar tendencias, justificar mejoras y conocer la calidad de los servicios. Para que sean útiles deben ser completos, coherentes, actuales y comparables. Los campos estructurados —servicio, categoría, CI, síntoma, impacto, causa y resolución— permiten análisis que no serían posibles con descripciones libres heterogéneas.

La calidad se deteriora cuando se utiliza una categoría genérica para cualquier caso, se asigna un CI aproximado o se cierra con textos como «solucionado». Estas prácticas dificultan reconocer problemas recurrentes y falsean los indicadores. El gobierno del dato exige catálogos controlados, reglas de obligatoriedad, formación de operadores, revisiones de calidad y corrección de registros.

La causa de cierre debe diferenciar, entre otros supuestos, fallo de hardware, defecto de software, configuración, comunicaciones, acceso, procedimiento de usuario o ausencia de incidencia. Esta clasificación no pretende culpar; busca aprender. Una elevada proporción de incidencias por uso puede indicar que la interfaz o la formación deben mejorar, mientras una recurrencia por configuración apunta a cambios técnicos o a controles de despliegue insuficientes.

13.3. Experiencia del profesional y comunicación

La experiencia del usuario se forma durante todo el recorrido, no solo al recibir la solución. Influyen la facilidad para encontrar el canal, la claridad del formulario, el tiempo hasta la primera atención, la comprensión de los mensajes, la frecuencia de las actualizaciones y la utilidad de la resolución. Un servicio técnicamente correcto puede percibirse como deficiente si el profesional desconoce qué ocurre durante horas; una comunicación transparente puede reducir incertidumbre incluso antes de restaurar el servicio.

La comunicación debe adaptar el lenguaje al destinatario. Al profesional final le interesa qué servicio está afectado, qué alternativa puede utilizar y cuándo recibirá una nueva actualización. Al resolutor le interesan síntomas, registros, CI y pruebas. A la dirección le interesa impacto, riesgo, evolución y decisiones necesarias. Reutilizar el mismo mensaje técnico para todos reduce su eficacia.

Las encuestas de satisfacción deben interpretar el contexto. Una valoración negativa puede deberse a la indisponibilidad del servicio, aunque el centro de soporte haya actuado correctamente; una valoración positiva no demuestra que el proceso sea eficiente. Por ello se combina percepción con datos objetivos. La mejora continua analiza ambos planos y distingue entre satisfacción con la atención, satisfacción con la solución y satisfacción con el servicio tecnológico afectado.

14. APLICACIÓN PRÁCTICA E IDEAS CLAVE PARA EL EXAMEN

14.1. Caso: indisponibilidad de aplicación clínica

Si una aplicación clínica deja de funcionar para numerosos usuarios, se registra una incidencia, se identifica el servicio y CI afectados, se valora severidad e impacto y se aplica la matriz. El centro de servicios realiza diagnóstico inicial, emite comunicación coordinada y escala a los grupos responsables. Si se cumplen condiciones excepcionales de gran alcance, la organización puede activar el protocolo P0.

14.2. Caso: alta de acceso

Una incorporación que necesita acceso a GERHONTE o Diraya formula una petición de servicio. El catálogo solicita los datos, autorización y perfil necesarios. La gestión de accesos verifica la legitimidad, aplica mínimo privilegio, registra la actuación y prevé la baja o modificación cuando cambie la relación funcional.

14.3. Caso: fallos recurrentes

Varias incidencias similares se relacionan con un problema. El gestor investiga la causa, identifica un error conocido y publica una solución temporal. La corrección definitiva puede requerir un cambio y una nueva versión. Cerrar las incidencias con el workaround no significa cerrar el problema.

14.4. Caso: avería de puesto

Para una avería de equipo, el impacto no se valora solo por el precio del dispositivo. Se pregunta si el usuario puede continuar en otro equipo cercano y si su trabajo es de cara al paciente. La condición de puesto de especial importancia puede modificar el tratamiento.

• ayudaDIGITAL: soporte integral TIC y punto único de contacto para profesionales del SAS.
• Canales: Área Personal, escritorio, app, WhatsApp, Zoom, teléfono y correo, según el portal oficial.
• Incidencia: interrupción o degradación; objetivo: restaurar el servicio.
• Petición: prestación estándar definida en catálogo.
• Problema: causa real o potencial de incidencias; puede generar error conocido.
• Catálogo: oferta oficial y dinámica de servicios y solicitudes, segmentada por perfiles.
• Configuración: CI, relaciones, CMDB y CMS; no confundir con inventario.
• Prioridad: P0 solo incidencias; P1 muy alta, P2 alta, P3 normal.
• Cálculo: criticidad del CI, severidad de tipología e impacto.
• Escalado: funcional por capacidad y jerárquico por gravedad o supervisión.

15. MAPA CONCEPTUAL