1. INTRODUCCIÓN Y ENCUADRE DEL SERVICIO

ayudaDIGITAL es el servicio de Soporte Integral TIC que el Servicio Andaluz de Salud pone a disposición de sus profesionales para resolver necesidades relacionadas con las tecnologías necesarias en su trabajo diario. Integra el Centro de Servicios al Usuario y los servicios vinculados al puesto de usuario. Su finalidad práctica es que el profesional disponga de una entrada corporativa reconocible para comunicar incidencias, formular peticiones, consultar soluciones, recibir información y seguir la evolución de sus solicitudes sin tener que conocer previamente qué equipo técnico, proveedor o unidad interna es responsable de cada componente.

Esta función es especialmente relevante en una organización sanitaria extensa, distribuida y con actividad continuada. Un fallo aparentemente sencillo puede depender del puesto de usuario, la identidad corporativa, la red, un servicio horizontal, una aplicación, una base de datos o un proveedor externo. El usuario no debe reconstruir esa arquitectura para pedir ayuda. El centro de servicios recibe la necesidad, la registra, la clasifica, la relaciona con el servicio o elemento afectado, realiza el diagnóstico inicial y, cuando no puede resolverla, la escala al grupo competente conservando la trazabilidad.

1.1. Service desk y punto único de contacto

En gestión de servicios, un service desk es la práctica que facilita la comunicación entre el proveedor de servicios y las personas usuarias. En un modelo de punto único de contacto, las distintas necesidades convergen en un servicio reconocible que mantiene una visión común de la solicitud. Esto no significa que el primer nivel resuelva todo: significa que la relación con el usuario se organiza de forma coherente mientras internamente pueden intervenir múltiples resolutores.

Conviene distinguir este concepto del help desk tradicional. El help desk se asocia históricamente a la reparación reactiva de fallos técnicos. Un service desk moderno abarca además peticiones, comunicación, conocimiento, catálogo, seguimiento, configuración y coordinación. ayudaDIGITAL encaja en este segundo enfoque: atiende tanto una impresora que no funciona como una solicitud de acceso, un problema con credenciales, una consulta sobre una herramienta corporativa o una necesidad que deba derivarse a un equipo especializado.

1.2. Enfoque operativo del Técnico/a Especialista Informática

Para un Técnico/a Especialista Informática, el tema debe estudiarse desde la operación. Importa saber qué datos necesita un ticket, cómo distinguir incidencia y petición, cómo documentar pruebas, cuándo escalar, qué información aporta un CI, cómo se utiliza una base de conocimiento y qué variables intervienen en la prioridad. El técnico debe ser capaz de transformar una frase vaga como «no funciona» en un registro útil: identificar usuario y ubicación, servicio afectado, síntoma, alcance, posibilidad de trabajo alternativo, evidencias y acciones realizadas.

El soporte de calidad combina técnica y comunicación. Un diagnóstico correcto que no queda documentado se pierde; una escalada sin evidencias obliga a repetir trabajo; una solución rápida que expone una contraseña introduce un riesgo; una categorización errónea envía la solicitud al grupo equivocado. El trabajo cotidiano consiste precisamente en evitar esas pérdidas de información y mantener continuidad entre usuario, herramienta, resolutores y conocimiento.

1.3. Marco conceptual

ITIL 4 aporta vocabulario y prácticas útiles para interpretar el servicio: service desk, gestión de incidencias, gestión de peticiones de servicio, gestión de problemas, gestión del conocimiento, gestión de configuración del servicio y gestión de activos. No debe afirmarse que ayudaDIGITAL «es ITIL» ni que toda su operativa derive de una única publicación. La organización dispone de procedimientos, catálogos, herramientas y reglas propias del SAS que concretan esos conceptos.

El Esquema Nacional de Seguridad y la normativa de protección de datos también condicionan la atención: identidad, autorización, mínimos privilegios, trazabilidad y minimización de información deben mantenerse durante todo el ciclo de la solicitud. Una herramienta de soporte no es una excepción a las políticas de seguridad; al contrario, concentra información operativa valiosa y debe tratarla de forma controlada.

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

La información institucional vigente en agosto de 2026 presenta ayudaDIGITAL como un servicio disponible de forma ininterrumpida las 24 horas de los 365 días del año y ofrece varios canales para trasladar incidencias y peticiones. El canal es la interfaz con el profesional; la solicitud debe conservar una identidad y una trazabilidad comunes aunque cambie la vía de contacto. Esta continuidad es la base de la omnicanalidad.

El portal de contacto enumera actualmente app móvil, Área Personal web, ayudaDIGITAL Escritorio, WhatsApp, Zoom, teléfono y correo electrónico corporativo. Además, algunas interfaces incorporan chat o asistentes digitales. La lista puede evolucionar, por lo que en una oposición conviene separar el dato institucional vigente del concepto estable: todos los canales deben alimentar un modelo de soporte coherente y no convertirse en silos independientes.

3.1. Área Personal web

El Área Personal es el canal de autoservicio más completo para registrar y gestionar solicitudes. Permite diferenciar peticiones e incidencias, consultar su evolución, acceder a soluciones de autorresolución, gestionar preferencias y realizar acciones relacionadas con el expediente. Para el técnico tiene una ventaja fundamental: el formulario puede estructurar datos antes de que la solicitud llegue al resolutor.

Un formulario bien diseñado obliga o ayuda a escoger servicio, tipo de necesidad, ubicación, aplicación o equipo afectado, síntoma y descripción. Los campos condicionales reducen preguntas innecesarias. Si el usuario selecciona que una aplicación no está disponible para varios compañeros, el sistema puede solicitar información distinta de la que pediría ante un teclado roto. Esta captura estructurada mejora la tipificación y facilita las reglas de asignación.

3.2. ayudaDIGITAL Escritorio

ayudaDIGITAL Escritorio acerca el soporte al puesto de trabajo corporativo. La documentación del SAS permite registrar y seguir solicitudes y ofrece utilidades relacionadas con el equipo y con la identidad profesional. Entre las funciones publicadas se encuentran la consulta de información del puesto, la localización, avisos asociados a la contraseña DMSAS, acceso a soluciones y otras herramientas de productividad o soporte.

Desde el punto de vista del diagnóstico, un cliente de escritorio puede aportar contexto que el usuario desconoce: nombre del equipo, sistema operativo, red, ubicación lógica o datos inventariados. Ese contexto debe manejarse de forma controlada y nunca sustituye a la descripción del síntoma. Saber que el equipo tiene una determinada versión no demuestra que esa versión sea la causa del fallo.

3.3. App móvil

La app móvil permite llevar el canal de soporte fuera del equipo habitual. Resulta útil cuando el puesto afectado no permite navegar, cuando el profesional está en movilidad o cuando necesita consultar la evolución de una solicitud desde otro lugar. La aplicación se publica como «ayudaDIGITAL» en las tiendas oficiales y permite registrar o gestionar necesidades y recibir información del servicio.

3.4. WhatsApp y AYDI

WhatsApp es un canal oficial de ayudaDIGITAL. La información institucional actual publica el número corporativo 955 01 70 00 y explica que el asistente digital AYDI puede guiar al profesional, consultar solicitudes o derivar la conversación a una persona agente cuando la automatización no resuelve la necesidad. La primera interacción puede requerir verificación de la identidad y del teléfono registrado.

La mensajería no elimina las reglas de seguridad. Nunca debe utilizarse para remitir contraseñas ni para volcar información clínica innecesaria. Si el asistente facilita un enlace de registro, el expediente formal debe quedar en la herramienta corporativa de solicitudes; la conversación es un canal de entrada, no un sustituto de la trazabilidad.

3.5. Zoom

Desde febrero de 2026 el SAS publica Zoom como nuevo canal de contacto de ayudaDIGITAL, dentro de su estrategia de omnicanalidad. Para utilizarlo se requiere una cuenta corporativa activa de Zoom y se contacta con el usuario o contacto «ayudaDIGITAL». Es un buen ejemplo de cómo el catálogo de canales puede ampliarse sin cambiar la naturaleza del servicio.

Para el técnico, la lección es que la incorporación de un canal requiere integración de identidad, enrutamiento, registro, horarios, protección de datos, conservación del contexto y transferencia a agente. Añadir una aplicación de chat sin conectarla al expediente produciría una experiencia multicanal, pero no verdaderamente omnicanal.

3.6. Teléfono

El canal telefónico continúa siendo esencial cuando el usuario necesita atención síncrona o cuando los canales digitales están afectados. El SAS publica la extensión corta 31 70 00 en la red corporativa y el número 955 01 70 00. La llamada debe terminar, cuando corresponda, en un registro trazable con la misma calidad de datos que una solicitud iniciada por web.

El teléfono también constituye un mecanismo de continuidad. En mayo de 2026 una intervención planificada sobre CA-SDM dejó temporalmente indisponibles varios canales digitales y la Web Técnica, mientras el canal telefónico siguió operativo; los agentes registraron de forma temporal la actividad en una herramienta alternativa para mecanizarla posteriormente en CA-SDM. El caso demuestra que omnicanalidad también significa diseñar degradación controlada y recuperación.

3.7. Correo electrónico corporativo

El portal actual incluye el correo ayudadigital.sspa@juntadeandalucia.es como canal de atención. Al usar correo corporativo deben mantenerse las mismas cautelas: describir la necesidad sin incluir secretos, aportar solo los adjuntos imprescindibles y evitar cadenas con datos personales ajenos al diagnóstico. Si la petición necesita seguimiento, el contenido debe quedar asociado al expediente corporativo.

3.8. Multicanalidad frente a omnicanalidad

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

Clasificar correctamente la actividad es una de las decisiones más importantes del centro de servicios. Una persona puede decir «tengo un problema» para referirse a cualquier necesidad, pero en gestión de servicios incidencia, petición, consulta y problema tienen finalidades distintas. La categoría seleccionada condiciona el flujo, las aprobaciones, la prioridad, la asignación y los indicadores.

5.1. Incidencia

Una incidencia es un suceso que causa o puede causar una interrupción de un servicio o una reducción de su calidad. El objetivo no es realizar una investigación académica de la causa, sino restaurar la operación normal cuanto antes y minimizar el impacto. Puede resolverse con una corrección definitiva o con una solución temporal segura que permita continuar trabajando.

• Ejemplo de puesto: el equipo no arranca o la impresora deja de responder.
• Ejemplo de aplicación: una función que estaba disponible devuelve error o el servicio queda inaccesible.
• Ejemplo de comunicaciones: un centro pierde conectividad o existe una degradación relevante.
• Ejemplo potencial: falla un componente redundante y el servicio queda expuesto a una nueva avería.

Las incidencias de producción se someten al modelo de prioridad corporativo. La prioridad no depende solo de que el usuario escriba «urgente»: se calcula a partir de criticidad del CI, severidad de la tipología o síntoma e impacto.

5.2. Petición de servicio

Una petición de servicio solicita una prestación predefinida: información, acceso, provisión, modificación estándar o actuación recogida en el catálogo. No parte necesariamente de un fallo. Su ventaja es la estandarización: al conocer de antemano datos, autorizaciones, tareas y resolutores, muchas peticiones pueden tramitarse mediante formularios y flujos repetibles.

• Alta o modificación autorizada de acceso a una aplicación.
• Creación de una cuenta o recurso corporativo cuando proceda.
• Instalación de software previamente autorizado.
• Solicitud de VPN, DNS, comunicaciones u otra prestación catalogada.

Algunas peticiones requieren aprobación y otras no. Por tanto, «petición» no significa «debe aprobarla un superior»; significa que se solicita una prestación estándar cuyo procedimiento está definido.

5.3. Consulta

La consulta busca información, orientación o aclaración. Puede resolverse mediante conocimiento, autoservicio o atención asistida. Una pregunta sobre cómo utilizar una herramienta no debe convertirse automáticamente en incidencia si la herramienta funciona correctamente. Si durante la consulta se descubre un fallo real, puede registrarse o reclasificarse la actividad correspondiente.

5.4. Problema

Un problema es una causa real o potencial de una o más incidencias. Su gestión pretende reducir la probabilidad y el impacto de las incidencias mediante identificación de causas, análisis de tendencias, soluciones temporales y errores conocidos. No siempre puede eliminarse inmediatamente la causa: a veces debe controlarse el riesgo mientras se prepara un cambio o una nueva versión.

Los problemas suelen abrirse internamente a partir de recurrencias, incidencias graves o análisis proactivo. El usuario final comunica el efecto que sufre; el equipo de gestión de problemas investiga patrones y causas. Si se comprende suficientemente el problema y existe un workaround, puede documentarse un error conocido. Error conocido no significa necesariamente problema cerrado ni solución definitiva implantada.

5.5. Comparación operativa

5.6. Un mismo servicio, distintos tipos de actividad

Imagina una aplicación corporativa. Una nueva incorporación necesita perfil de acceso: petición. El profesional pregunta dónde se encuentra una función: consulta. La aplicación deja de autenticar a numerosos usuarios: incidencia. Se descubre que el fallo se repite cada vez que caduca un certificado por un procedimiento defectuoso: se abre un problema para controlar la causa y evitar recurrencias.

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 en la actividad. La definición operativa del SAS se centra en sucesos que causan o pueden causar interrupción o reducción de la calidad del servicio. No exige conocer la causa raíz antes de actuar: si una solución temporal devuelve la capacidad de trabajo, la incidencia puede quedar restaurada mientras otro proceso investiga la causa.

La primera obligación es registrar la incidencia. El expediente permite saber quién comunica, qué servicio está afectado, qué síntoma se observa, qué CI se relaciona, qué impacto existe, quién intervino y qué acciones se ejecutaron. La documentación corporativa exige que el técnico deje constancia de los pasos principales desde la investigación hasta la resolución.

6.1. Registro, revisión y tipificación

El primer nivel revisa la tipificación propuesta. Una solicitud presentada como incidencia puede resultar ser una petición y debe redirigirse al proceso adecuado. La tipificación se organiza jerárquicamente y puede modificarse durante el ciclo de vida mediante una re-tipificación. El objetivo es que la categoría final refleje el conocimiento real adquirido durante el diagnóstico, no que permanezca congelada por lo que seleccionó inicialmente el usuario.

La tipología puede llevar asociada una severidad y determinados síntomas pueden afinarla. Esto explica por qué dos fallos de la misma aplicación no tienen necesariamente el mismo tratamiento: «funciona lento pero puedo trabajar» no equivale a «la aplicación no está disponible».

6.2. Selección del CI e impacto

La incidencia debe relacionarse con el elemento o elementos de configuración relevantes. El CI aporta criticidad, propietario, ubicación y dependencias. El impacto completa el contexto: puede representar el número de usuarios afectados o la gravedad de la consecuencia. En puesto de usuario importa si existe equipo alternativo y si la atención es de cara al ciudadano; en sistemas de información importa el alcance entre usuarios; en infraestructura puede considerarse también el riesgo potencial cuando falla la redundancia.

6.3. Diagnóstico inicial

Diagnosticar no es reiniciar por rutina. El técnico formula hipótesis y busca evidencias. Debe revisar información del solicitante, comprobar incidencias abiertas similares, consultar conocimiento disponible y evitar duplicados. Si existe una incidencia generalizada, las nuevas ocurrencias pueden relacionarse con ella para centralizar el diagnóstico y la comunicación.

Ejemplo de registro técnico
Servicio: aplicación corporativa
Síntoma: indisponibilidad al iniciar sesión
Alcance: 1 usuario / varios / generalizado
CI: aplicación o componente relacionado
Pruebas: conectividad, identidad, acceso alternativo
Resultado: qué se verificó y qué se descartó
Acción: resuelto en N1 o escalado con evidencias

El bloque anterior no es una plantilla literal de CA-SDM; es un esquema mental para el opositor. Lo importante es que cada prueba tenga una finalidad. Si el navegador llega al portal pero la aplicación devuelve un error de autorización, repetir un ping indefinidamente no mejora el diagnóstico. Si varios usuarios de distintas ubicaciones presentan el mismo síntoma, conviene buscar un componente compartido.

6.4. Resolución en primer nivel

Cuando existe conocimiento verificado y permisos suficientes, N1 debe resolver de forma segura. La resolución en primer contacto reduce transferencias, pero no debe convertirse en objetivo aislado. Un cierre superficial que provoca reapertura empeora el servicio. La solución debe documentarse y, si es reutilizable, alimentar la base de conocimiento.

6.5. Escalado y seguimiento

Si el primer nivel no puede resolver, la incidencia se escala funcionalmente al grupo con capacidad técnica o permisos adecuados. Debe acompañarse de síntoma, alcance, CI, pruebas, resultados y evidencias. El escalado jerárquico es distinto: se utiliza cuando la gravedad, el riesgo de incumplimiento o la necesidad de coordinación requiere informar a responsables con autoridad de supervisión.

Las incidencias P1 reciben controles adicionales de seguimiento y comunicación según el procedimiento corporativo. El modelo automático de prioridad ordinario produce P1, P2 o P3. La documentación también contempla un procedimiento específico para incidentes P0; al estudiar este tema no debe inventarse una cuarta fila de la matriz ni deducir por intuición sus criterios si no se dispone del procedimiento aplicable.

6.6. Validación, cierre y relación con problemas

La resolución debe indicar qué se hizo y cuál fue el resultado. El solicitante puede verificar y aceptar la solución. Si la causa permanece o aparecen recurrencias, las incidencias pueden relacionarse con un problema. Un workaround puede ser suficiente para restaurar el servicio, pero no transforma automáticamente la causa en «resuelta».

El cierre también es una oportunidad de calidad. Debe comprobarse que la tipificación final es correcta, que el CI es el adecuado, que la resolución es comprensible y que no quedan datos sensibles innecesarios en adjuntos o comentarios. Un ticket bien cerrado es una fuente de conocimiento; uno cerrado con «solucionado» aporta muy poco al siguiente técnico.

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 determina la importancia relativa de una incidencia y la rapidez con la que debe ser tratada. No equivale a «lo que el usuario considera urgente», al rango jerárquico de quien llama ni al orden de llegada. El proceso corporativo busca que incidencias comparables reciban un tratamiento comparable mediante variables definidas de antemano.

10.1. Ámbito de aplicación

El modelo automático se aplica a solicitudes de tipo incidencia en entornos productivos. Las consultas y peticiones de producción y los registros de entornos no productivos se tratan por defecto con prioridad normal. Las peticiones de datos, por su naturaleza planificable, también parten de prioridad normal. Profesionales TIC autorizados pueden modificar la prioridad cuando las necesidades del servicio lo justifican; una modificación manual debe quedar documentada y saca la solicitud de la matriz automática durante su ciclo de vida.

La documentación distingue un modelo por defecto y un modelo específico para soporte provincial. Por ello no conviene estudiar una única tabla como si todo el soporte del SAS utilizara exactamente la misma combinación. La lógica y las variables son comunes; determinadas reglas se adaptan al ámbito contractual.

10.2. Criticidad

La criticidad expresa la importancia del CI para el servicio o el negocio. En el modelo actual se manejan niveles muy alta, alta y normal. La criticidad no describe lo que está ocurriendo ahora, sino la relevancia intrínseca del elemento para la prestación. Un componente central sin redundancia puede ser muy crítico aunque en ese momento la avería afecte todavía a pocos usuarios.

10.3. Severidad

La severidad refleja el grado de afección de la aplicación o componente y se asocia a la tipología o al síntoma. Los niveles documentados son:

• Muy grave: indisponibilidad para trabajar.
• Grave: pérdida de una funcionalidad importante.
• Leve: degradación del servicio que permite continuar trabajando, por ejemplo con un tiempo de respuesta elevado.

La presencia de un síntoma específico permite afinar la severidad. En una misma categoría «aplicación no funciona correctamente», «lentitud que permite trabajar» y «aplicación no disponible» representan situaciones distintas.

10.4. Impacto

El impacto se interpreta según el tipo de incidencia. Para un puesto de usuario, el modelo valora si el profesional puede seguir trabajando en otro equipo cercano y si su actividad es de cara al ciudadano. Para sistemas de información, el alcance distingue un único usuario, varios usuarios o muchos usuarios. Para infraestructura tecnológica, el personal TIC puede valorar además el impacto potencial cuando la pérdida de redundancia deja un servicio expuesto a un riesgo relevante.

10.5. Matriz por defecto

La matriz por defecto cruza impacto con criticidad y severidad. Los valores 1, 2 y 3 representan, respectivamente, niveles altos de atención: 1 = prioridad muy alta (P1), 2 = prioridad alta (P2), 3 = prioridad normal (P3). En la notación siguiente C1 es criticidad muy alta, C2 alta, C3 normal; S1 es severidad muy grave, S2 grave y S3 leve; I1 es impacto muy alto, I2 alto e I3 normal.

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

La tabla es útil para examen porque muestra que ninguna variable actúa sola. Una incidencia de alto impacto no es automáticamente P1 si el cruce con criticidad y severidad produce otro resultado. Del mismo modo, un CI crítico no convierte cualquier degradación menor en la máxima prioridad.

10.6. Puestos de especial importancia y soporte provincial

En el ámbito de puesto de usuario existen ubicaciones o puestos identificados como de especial importancia. La documentación de soporte provincial establece un tratamiento especial cuando la persona afectada no puede continuar desarrollando su trabajo en un equipo cercano: en ese contexto la incidencia puede clasificarse con prioridad muy alta independientemente del resto de variables. Si existe equipo alternativo, se aplica la matriz correspondiente.

Este criterio demuestra por qué la prioridad no debe confundirse con el «cargo» del solicitante. Lo relevante es el impacto operativo y asistencial definido por el servicio. El técnico debe registrar correctamente el contexto para que la regla pueda aplicarse.

10.7. P0 y límites de la matriz

El proceso corporativo documenta P1, P2 y P3 como resultados de la matriz ordinaria y dispone además de un procedimiento específico para incidentes P0. P0 debe estudiarse como una gestión excepcional separada, no como una cuarta salida calculada añadiendo arbitrariamente una fila o columna a la matriz anterior.

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.

13.2. Dependencias comunes y continuidad: el caso CA-SDM

La omnicanalidad puede ocultar dependencias comunes. Área Personal, app, Escritorio, WhatsApp o Zoom parecen canales independientes para el profesional, pero varios pueden apoyarse en la misma herramienta de gestión de solicitudes. Los avisos del SAS de febrero y mayo de 2026 identifican CA-SDM como la herramienta corporativa utilizada por el Centro de Servicios al Usuario. Durante intervenciones planificadas sobre ella, varios canales quedaron temporalmente indisponibles de forma simultánea.

La respuesta de continuidad mantuvo el teléfono operativo y utilizó un registro alternativo temporal para mecanizar posteriormente la actividad. Para un técnico C1, este caso enseña a diseñar procedimientos de contingencia: identificar dependencias, definir un canal mínimo, conservar fecha y solicitante, evitar pérdida de información, reconciliar los tickets después de la recuperación y comunicar las limitaciones del modo degradado.

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

14.1. Caso: una aplicación clínica no está disponible

Un profesional comunica que una aplicación clínica no está disponible. El técnico no debe asumir de entrada que «se ha caído el servidor». Primero identifica usuario, centro, aplicación, hora, mensaje y alcance. Si solo afecta a una persona, prueba identidad, sesión y puesto. Si afecta a varios usuarios, busca incidencias similares y componentes compartidos. Si el alcance es generalizado, relaciona las ocurrencias y evita que cada una genere un diagnóstico independiente.

La solicitud se tipifica como incidencia, se selecciona el CI, se establece impacto y se calcula la prioridad con criticidad y severidad. Si N1 no puede resolver, escala con las pruebas realizadas. Durante una incidencia grave, la comunicación coordinada evita que distintos equipos den mensajes contradictorios.

14.2. Caso: alta de acceso a una aplicación

Una persona que necesita por primera vez acceso autorizado a una aplicación no comunica una incidencia: formula una petición de servicio. El servicio estaba funcionando; lo que se solicita es una nueva prestación. El catálogo debe recoger los datos, perfil y autorizaciones necesarios. El flujo puede incorporar aprobación y debe respetar mínimo privilegio, segregación de funciones y trazabilidad.

Si después de concedido el acceso la aplicación devuelve un error inesperado, la nueva situación sí puede generar una incidencia. Esta secuencia es una trampa típica: el mismo sistema puede aparecer en una petición y en una incidencia; lo que cambia es la naturaleza de la necesidad.

14.3. Caso: fallo recurrente

Durante varias semanas aparecen incidencias con el mismo patrón. Resolver cada una con un reinicio reduce el síntoma, pero no elimina la recurrencia. El conjunto debe analizarse como problema. Se relacionan las incidencias, se investigan hipótesis, se documenta la causa cuando se conoce y se registra un error conocido o una solución temporal si procede. La corrección definitiva puede requerir un cambio controlado.

14.4. Caso: avería de un puesto de usuario

Un equipo no arranca. Antes de asignar prioridad, se pregunta si la persona puede continuar en otro puesto cercano y si su trabajo se realiza de cara al ciudadano. La respuesta modifica el impacto. El precio del PC, la antigüedad del usuario o su insistencia telefónica no sustituyen esas variables. Si se trata de un puesto de especial importancia dentro del ámbito correspondiente, pueden aplicarse reglas específicas.

14.5. Caso: degradación del propio sistema de solicitudes

La intervención sobre CA-SDM de mayo de 2026 constituye un ejemplo real de continuidad del service desk. Al quedar temporalmente indisponible la herramienta corporativa de gestión de solicitudes, varios canales digitales y la Web Técnica no pudieron utilizarse. El teléfono siguió operativo y los agentes registraron temporalmente la actividad en una herramienta alternativa para mecanizarla después.

Desde el punto de vista técnico, la lección es doble. Primero, varios canales pueden depender de un backend común: tener muchas interfaces no elimina un punto de fallo compartido. Segundo, el plan de continuidad debe preservar el servicio mínimo, evitar perder solicitudes y permitir reconciliar posteriormente los registros sin duplicados.

14.6. Caso: phishing comunicado por un profesional

Una persona recibe un correo sospechoso. La solicitud de soporte debe contener la información necesaria para analizar el caso sin ejecutar enlaces ni facilitar credenciales. Las instrucciones de la convocatoria 2025 indicaban informar a ayudaDIGITAL y reenviar el mensaje sospechoso como archivo adjunto al buzón corporativo de abuso, preservando cabeceras útiles para el análisis.

14.7. Evolución histórica: de CGES a ayudaDIGITAL

El examen de 2019 utiliza extensamente la denominación CGES y herramientas de aquella arquitectura. Ese material es útil para comprender la evolución del soporte, pero no debe trasladarse sin nota temporal al entorno actual. La denominación vigente del servicio es ayudaDIGITAL y las herramientas y canales han evolucionado.

14.8. Parejas que debes distinguir

14.9. Lista de repaso final

• ayudaDIGITAL: servicio de Soporte Integral TIC para profesionales del SAS.
• Canales actuales: app, Área Personal, Escritorio, WhatsApp, Zoom, teléfono y correo corporativo.
• Incidencia: interrupción o reducción de calidad; objetivo: restaurar la operación.
• Petición: solicitud de una prestación estándar o acceso.
• Problema: causa real o potencial de una o más incidencias.
• Catálogo: define la oferta de servicios y solicitudes, condiciones, perfiles y circuitos.
• Configuración: CI, relaciones, CMDB y CMS.
• Prioridad: en la matriz ordinaria de incidencias, P1, P2 o P3.
• Entradas del cálculo: criticidad, severidad e impacto.
• P0: procedimiento excepcional separado de la matriz ordinaria.
• Escalado: funcional por capacidad y jerárquico por supervisión o gravedad.
• Seguridad: no compartir contraseñas y minimizar datos personales o clínicos.

15. MAPA CONCEPTUAL