Proceso: Gestión de Incidencias

Objetivo

Establecer la forma de restaurar la operación normal del servicio lo antes posible ante una interrupción de éste minimizando el impacto negativo en las operaciones del negocio.

Alcance

Este proceso aplica a toda la STIC.
La gestión de incidencias se ocupa de aquellos sucesos que supongan, o puedan suponer, la interrupción de un servicio. 
Los sucesos que puedan ser comunicados directamente por usuarios (ya sean finales o técnicos) a través de los distintos canales del CSU (Teléfono, Web autoservicio, Nueva Web Técnica, Correo electrónico, Fax y Buzón de voz). 
Queda fuera del alcance del documento la gestión local que realiza las áreas de las incidencias sin intervención del CSU. 

Política

1. Todas las incidencias se registrarán en el sistema de información de gestión de incidencias y se clasificarán de acuerdo a los criterios establecidos en los procedimientos del proceso.
2. En el registro de incidencias dependiendo del impacto, de la criticidad del CI, y de la severidad de la tipología se determina según los criterios preestablecidos un nivel de prioridad.
3. La tipificación de incidencias servirá como base para su asignación al grupo de resolución más adecuado y para la notificación a los niveles de autoridad que tengan que supervisar su tratamiento.
4. El personal técnico asignado a las incidencias tendrá la obligación de documentar los principales pasos que realice, desde la investigación hasta la resolución.
5. El personal técnico asignado a las incidencias tendrá acceso al conocimiento de ayuda para la resolución (errores conocidos, soluciones temporales) recogido en la base de conocimiento de soporte, así como a los datos relevantes de configuración centralizados por gestión de la configuración en la CMS.
6. Se clasificarán específicamente las incidencias graves (P1) y serán tratadas bajo la supervisión de las niveles de autoridad de la organización que sean notificados, de acuerdo a los criterios de escalado establecidos en los procedimientos del proceso.

Roles y responsabilidades

Responsable STIC

• Responsable máximo del Servicio.

Responsabilidades genéricas:

• • Impulsar la implantación de planes de mejora del servicio.
  • Analizar indicadores.

Subdirección STIC
Departamento del SAS encargado de la Gestión de las TIC. 

Responsable del proceso
Es el rol que se señala como responsable final del proceso, y que se ocupa de su planificación, apoya su operación, controla su desarrollo e impulsa su mejora. 
Responsabilidades genéricas:

• Lidera el proceso en la organización, integrando al personal de los distintos departamentos involucrados, y adaptando la respuesta de dicho proceso a las directrices que se establezcan desde la Dirección, al objeto de la Gestión de Servicios de TI.
• Establece los principios y objetivos específicos del proceso y responde de sus resultados.
• Actúa como patrocinador del proceso en su diseño, revisión y mejora.
• Solicita a la Dirección los recursos y capacidades necesarios para cubrir los objetivos del proceso.
• Informa a la Dirección del estado del proceso.
• Garantiza que se definan y asignen los roles y responsabilidades adecuados para el proceso.
• Garantiza la formación y concienciación de las personas asignadas a roles del proceso, así como de otro personal involucrado, en sus principios y procedimientos.
• Lleva a cabo campañas de concienciación para ganar apoyo en el planteamiento del proceso.
• Garantiza la implantación en la organización de las políticas y estándares del proceso.
• Garantiza que todos los implicados estén suficientemente involucrados en el proceso.
• Se ocupa de establecer unas buenas relaciones de trabajo con todas las organizaciones implicadas en el proceso, tanto internas como externas.

Gestores del proceso
Es el rol que se señala como responsable de la ejecución operativa del proceso dentro de cada contrato vertical y grupo de soporte, y que garantiza su correcta realización basándose en la planificación y los principios establecidos dentro de su ámbito contractual. 
Responsabilidades genéricas:

• Ejecuta tareas operativas y coordina a otros roles ejecutores en la operación del proceso.
• Supervisa el desarrollo del proceso, informando al Propietario del proceso, y solicitando directrices ante necesidades y situaciones particulares.
• Facilita el alineamiento de las áreas de la STIC con el flujo de trabajo del proceso.
• Propone y acuerda relaciones y puntos de contacto del proceso con las áreas de la STIC que operen procesos.
• El Gestor de Incidencias de CSU, coordina la comunicación de incidencias de alto impacto realizando los escalados jerárquicos correspondientes.

Solicitante
Es el rol que detecta la incidencia y la comunica al proceso. Puede realizar las actividades de registro o bien delegarlas en el rol de Técnico de soporte a incidencias. 
Puede ser un usuario final o un usuario técnico. 
Responsabilidades genéricas:

• Puede ejecutar las tareas de registro.
• Se encarga de verificar y aceptar la resolución final.

ayudaDIGITAL
Existen distintos niveles de técnicos de soporte de incidencias:
Soporte Primer Nivel:

• CSU 
  • • Técnicos nivel 1.
    • Técnicos de soporte especializado.
      • Técnicos de soporte funcional especializado.
      • Técnicos de soporte técnico especializado.
      • Supervisores.

Soporte Segundo Nivel:

• Corporativo: AT1, AT2, mantenimiento hardware, proveedores de cada contrato de Desarrollo Software, Servicios Horizontales, OCA, Gobernanza, etc.
• Soporte Local: Resolutores locales de las áreas.

Proveedor
Empresa encargada de proporcionar servicios de mantenimiento y soporte. 

Soporte a puesto de usuario
Conjunto de recursos técnicos, humanos y materiales encargado de proporcionar servicios de mantenimiento y soporte in situ. 

Diagrama de estados

Figura 1. Estados de las incidencias 

Tabla 1. Estados incidencia. 

Flujo del proceso

Figura 2. Flujo procedimiento. 

Inicio de solicitud

• Rol: Solicitante / CSU.
• Entrada:
  • No hay.
• Acciones:
  • Si el inicio de la incidencia proviene del soporte local a hospitales se escala la incidencia automáticamente al Proveedor. Continúa en actividad 6. "Analizar incidencia".
  • Si el inicio de la incidencia proviene desde la Web de autoservicio y es una petición de escalado directo a informática se escala la incidencia automáticamente al Proveedor. Continúa en actividad 6. "Analizar incidencia".
  • Si el inicio de la incidencia no cumple ninguno de los 2 criterios anteriores y se ha creado desde la web de autoservicio se continúa en actividad 1. "Registrar incidencia por solicitante".
  • Si el inicio de la incidencia es mediante Teléfono, Email o Fax continúa en actividad 1'. "Registrar incidencia por primer nivel".

Actividad 1. Registrar incidencia por solicitante.

• Rol: Solicitante.
• Entrada:
  • No hay.
• Acciones:
  • El solicitante utiliza la Web de autoservicio para dar de alta una incidencia. Al finalizar el registro la incidencia queda asignada al soporte de primer nivel. El sistema realizará automáticamente la asignación a alguno de los técnicos de sistemas de primer nivel que esté disponible.
• Transiciones de estado:
  • Incidencia de Nueva a Abierta.
  • Continúa en subproceso "Revisar registro".

Subproceso. Revisar registro

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • En la siguiente figura se identifican las actividades de este subproceso:

 
Figura 3. Subproceso Revisar registro. 

• Revisar tipificación.
  • Primer nivel revisa la tipificación propuesta por el solicitante. Puede determinar que la 'request' hecha en forma de incidencia no es tal y que debe tratarse como petición. En ese caso la tipificación será de tipo petición.* y pasará a tratarse dentro del proceso de Gestión de Peticiones.
  • Asociada a la tipificación está el concepto de severidad, como una medida del grado en que se ve afectada la prestación de servicio cuando se produce una incidencia de una tipología dada.
    • La severidad que puede tomar los valores 1 (ALTA), 2 (MEDIA) o 3 (BAJA).

• Seleccionar CIs
  • Asociado a cada CI existe la Criticidad que puede tomar los valores 1 (ALTA), 2 (MEDIA) o 3 (BAJA).
  • Se define la criticidad como una medida del grado en que se ve afectada la prestación del servicio al usuario cuando se produce una incidencia sobre un CI dado.

• Establecer impacto
  • Se define el impacto como una medida del volumen de usuarios que se ven afectados por la ocurrencia de una incidencia dada sobre un cierto CI o por la gravedad de la incidencia (independientemente del número de usuarios afectados). Sus valores pueden ser.
    • Ninguno (valor por defecto), 1 (ALTA), 2 (MEDIA) o 3 (BAJA).

• Calcular prioridad
  • La prioridad es una medida de la importancia de una incidencia y determina la rapidez con la que una incidencia debe quedar resuelta.
  • La prioridad se calcula a partir de:
    • La severidad de la tipificación
    • La criticidad del CI
    • El impacto de la incidencia.
  • Los valores que puede tomar la prioridad son P1 (más prioritaria), P2 (prioridad media) o P3 (menos prioritaria).

• Transiciones de estado:
  • No hay cambio de estado.
  • Si no existe un grupo resolutor determinado Continúa en actividad 2. "Diagnosticar incidencia".
  • Si existe un grupo resolutor determinado continúa en actividad 5. "Escalar incidencia".

Actividad 1'. Registrar incidencia por primer nivel.

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • El solicitante utiliza alguno de los siguientes medios para comunicar una incidencia: Teléfono, correo electrónico, fax.
  • Si la incidencia entra por medio del teléfono, la creación de la misma y asignación al técnico del nivel 1 se realiza en el mismo momento.
  • Si la incidencia entra por medio de correo electrónico o fax la incidencia queda registrada en el sistema a la espera de asignación a algún técnico de nivel 1 o nivel 2.
  • En la siguiente figura se identifican las actividades de este subproceso:

Figura 4. Subproceso Registrar incidencia primer nivel. 

• Seleccionar tipificación.
  • Selecciona la tipificación de la incidencia de un catálogo posible.
  • Se trata de una categorización de la incidencia según una estructura en árbol. El primer nivel del árbol determina qué tipo de incidencia se está registrando. Por debajo de ese primer nivel, se encuentran sub-categorías que permiten categorizar con más detalle la incidencia correspondiente. La tipificación de una incidencia se establece inicialmente en el momento de su registro, y puede ser modificada a lo largo de la vida de la incidencia, conociéndose dicha operación como re-tipificación.
  • Se debe asegurar que:
    • Se debe llegar a un nivel de profundidad adecuado, de modo que la incidencia quede suficientemente bien tipificada.
    • Durante el ciclo de vida de la incidencia se deben realizar las re-tipificaciones necesarias para adecuar la categorización al conocimiento real que se va teniendo acerca de la incidencia.
    • Se debe asegurar que en el momento de cierre la incidencia, ésta queda bien categorizada.
    • Asociada a la tipificación está el concepto de severidad, como una medida del grado en que se ve afectada la prestación de servicio cuando se produce una incidencia de una tipología dada.
      • La severidad que puede tomar los valores 1 (ALTA), 2 (MEDIA) o 3 (BAJA).
• Seleccionar CIs
  • Asociado a cada CI existe la Criticidad que puede tomar los valores 1 (ALTA), 2 (MEDIA) o 3 (BAJA).
  • Se define la criticidad como una medida del grado en que se ve afectada la prestación del servicio al usuario cuando se produce una incidencia sobre un CI dado.

• Establecer impacto
  • Se define el impacto como una medida del volumen de usuarios que se ven afectados por la ocurrencia de una incidencia dada sobre un cierto CI o por la gravedad de la incidencia (independientemente del número de usuarios afectados). Sus valores pueden ser.
    • Ninguno (valor por defecto), 1 (ALTA), 2 (MEDIA) o 3 (BAJA).

• Calcular prioridad
  • La prioridad es una medida de la importancia de una incidencia y determina la rapidez con la que una incidencia debe quedar resuelta.
  • La prioridad se calcula a partir de:
    • La severidad de la tipificación
    • La criticidad del CI
    • El impacto de la incidencia.
  • Los valores que puede tomar la prioridad son P1 (más prioritaria), P2 (prioridad media) o P3 (menos prioritaria).

Una incidencia en cualquier momento puede ser reclasificada y cambiar sus atributos.

• Transiciones de estado:
  • No hay cambio de estado.
  • Continúa en actividad 2. "Diagnosticar incidencia".

Actividad 2. Diagnosticar incidencia.

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • Se realiza un primer análisis de la información proporcionada por el solicitante con el objeto de emitir un diagnóstico o juicio por el que se determina qué provoca la incidencia, como paso previo y estrictamente necesario para poder proceder a resolverla.
  • Se revisan todas las incidencias abiertas, para determinar si existen otras ocurrencias similares con el mismo diagnóstico, siendo la primera diagnosticada la que se conoce como Incidencia de impacto generalizado. Si es el caso, la incidencia se relaciona a la generalizada y no se cierra la incidencia hasta que se cierre la incidencia con la que está relacionada (incidencia "padre"). Se revisan las incidencias que un mismo solicitante pueda tener con objeto de evitar tener incidencias duplicadas.
• Transiciones de estado:
  • No hay cambio de estado.
  • Si el técnico puede resolver la incidencia continúa en actividad 3. "Resolver incidencia primer nivel".
  • Si el técnico no puede resolver la incidencia continúa en actividad 5. "Escalar incidencia".

Actividad 3. Resolver incidencia primer nivel.

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • En esta actividad se realiza la acción resolutiva de acuerdo al diagnóstico. Para ello podrá consultar las bases de datos de conocimiento que los equipos resolutores disponen.
  • El proceso de Gestión de Problemas podrá consultar las incidencias y determinar si alguna de ellas necesita conocer su causa raíz, abriendo para esta un registro de problemas.
• Transiciones de estado:
  • De "Abierta" a "Fijada" y después a "Cerrada" si la incidencia se ha registrado por llamada telefónica del solicitante y se acuerda en la conversación telefónica que la incidencia ha quedado resuelta. Se finaliza el proceso.
  • De "Abierta" a "Fijada" si la incidencia se ha registrado por correo electrónico o por Fax. El sistema envía una comunicación automática al usuario para que acepte o rechace la solución aportada. Continúa en actividad 4. "Aceptar o rechazar solución".

Actividad 4. Aceptar o rechazar solución.

• Rol: Solicitante.
• Entrada:
  • Incidencia en estado "Fijada".
• Acciones:
  • El solicitante decide si la solución aportada soluciona la incidencia que registró en el sistema.
• Transiciones de estado:
  • De "Fijada" a "Cerrada" si la incidencia se ha solucionado satisfactoriamente. Finaliza el proceso.
  • De "Fijada" a "Abierta" si la incidencia no se ha solucionado satisfactoriamente. Continúa en actividad 2. "Diagnosticar incidencia".

Actividad 5. Escalar incidencia.

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • Si en el diagnóstico realizado desde el primer nivel se determina que no se puede resolver, se recurre a segundo nivel para que realice el análisis pertinente y proceda a su resolución.
• Transiciones de estado:
  • No hay cambio de estado.
  • Continúa en actividad 6. "Analizar incidencia".

Actividad 6. Analizar incidencia.

• Rol: Soporte segundo nivel.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • Se analiza si la incidencia debe ser atendida o se ha producido un error en el escalado.
    • Si se ha producido un error en el escalado se devuelve la incidencia al primer nivel para que procedan al correcto escalado. Continúa en actividad 5. "Escalar incidencia".
    • Si es escalado es correcto se realiza un análisis de la información proporcionada por el solicitante, complementada con la información de soporte de primer nivel. El objetivo, al igual que en la actividad 2. "Diagnosticar incidencia" es emitir un diagnóstico o juicio por el que se determina qué provoca la incidencia, como paso previo y estrictamente necesario para poder proceder a resolverla. Continúa en actividad 7. "Resolver incidencia segundo nivel".
• Transiciones de estado:
  • No hay cambio de estado.
  • Si se ha producido un escalado incorrecto se devuelve al soporte de primer nivel mediante el proceso de escalado. Continúa en actividad 5. "Escalar incidencia".
  • Si el técnico de segundo nivel puede resolver la incidencia continúa en actividad 7. "Resolver incidencia segundo nivel".

Actividad 7. Resolver incidencia segundo nivel.

• Rol: Soporte segundo nivel.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • En esta actividad se realiza la acción resolutiva de acuerdo al diagnóstico. Para ello podrá consultar las bases de datos de conocimiento que los equipos resolutores disponen.
• Transiciones de estado:
  • De "Abierta" a "Fijada" si no se requiere la creación de un cambio. Continúa en actividad 8. "Verificar solución".
  • De "Abierta" a "Pdte implantar" si se requiere la creación de un cambio. Se ejecuta el subproceso "Gestión de cambios". Cuando finaliza el subproceso "Gestión de cambios" la incidencia pasa de "Pendiente de implantar" a "Fijada". Continúa en actividad 8. "Verificar solución".

Actividad 8. Verificar solución.

• Rol: Soporte segundo nivel.
• Entrada:
  • Incidencia en estado "Fijada".
• Acciones:
  • Los grupos resolutores deben verificar la solución aportada, confirmando que la resolución es definitiva.
  • Se documenta en la base de datos de conocimiento.
  • En caso de ser necesario se escala a soporte de primer nivel (por ejemplo si hay es una solución parcial que requiere la intervención de otro resolutor, o bien si es necesario reclasificar).
• Transiciones de estado:
  • No hay cambio de estado si es una incidencia de prioridad P1. Continúa en actividad 9. "Solicitar confirmación de resolución con al menos 3 usuarios".
  • De "Fijada" a "Abierta" si la solución requiere de la intervención de otro proveedor o es necesario reclasificar. Continúa en actividad 5. "Escalar incidencia".
  • No hay cambio de estado si la incidencia se soluciona en su totalidad. Continúa en actividad 4. "Aceptar o rechazar solución ".

Actividad 9. Solicitar confirmación de resolución con al menos 3 usuarios

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Fijada".
• Acciones:
  • CSU contacta telefónicamente con, al menos, 3 usuarios que confirmen la correcta resolución de la incidencia.
• Transiciones de estado:
  • No hay cambio de estado si se confirma la resolución de la incidencia. Continúa en actividad 4. "Aceptar o rechazar solución".
  • De "Fijada" a "Abierta" si la solución requiere de la intervención de otro proveedor o es necesario reclasificar. Continúa en actividad 5. "Escalar incidencia".
  • De "Fijada" a "Abierta" si no se confirma la resolución de la incidencia. Continúa en actividad 7. " Resolver incidencia segundo nivel" para que el proveedor proceda a su resolución.

Subproceso. Gestión de cambios.

• Rol: Proveedor.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • El proveedor solicita la creación de una solicitud de cambio.
  • El sistema gestiona el cambio a través del subproceso "Gestión de cambios" definido.
• Transiciones de estado:
  • De "Pendiente de implantar" a "Fijada".
  • Al finalizar el subproceso continúa en actividad 8. "Verificar solución".

Proceso reclamación de incidencias. 

Gestión de Reclamaciones

Proceso solicitar información. 
Actividad 1. Solicitar información adicional

• Rol: CSU / Proveedor
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • Se solicita información adicional al solicitante creador de la incidencia para poder gestionar de manera adecuada la solicitud.
• Transiciones de estado:

De "Abierta" a "Planificada". Continúa en actividad 2. "Proporcionar información adicional". 
Actividad 1'. Escalar a CSU

• Rol: Todos los proveedores 
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • Se escala la incidencia a CSU para que le solicite la información al solicitante.
• Transiciones de estado:
  • No hay. Continúa en actividad 2' "Escalar a usuario".

Actividad 2'. Solicitar información adicional

• Rol: CSU.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • Se solicita información adicional al solicitante creador de la incidencia para poder gestionar de manera adecuada la solicitud.
• Transiciones de estado:
  • De "Abierta" a "Planificada". Continúa en actividad 2. "Proporcionar información adicional".

Actividad 2. Proporcionar información adicional

• Rol: Solicitante.
• Entrada:
  • Incidencia en estado "Planificada".
• Acciones:
  • El solicitante proporciona la información que le ha sido requerida.
• Transiciones de estado:
  • De "Planificada" a "Abierta". Finaliza el proceso.

Figura 6. Proceso solicitar información. 
Proceso cancelación. 
Actividad 1. Solicitar cancelación

• Rol: Solicitante.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • El solicitante requiere la cancelación de una incidencia.
• Transiciones de estado:
  • No hay. Continúa en actividad 2. "Cancelar incidencia".

Actividad 2. Cancelar incidencia

• Rol: CSU / Proveedor.
• Entrada:
  • Incidencia en estado "Abierta".
• Acciones:
  • El técnico resolutor cancela la incidencia.
• Transiciones de estado:
  • De "Abierta" a "Cancelada". F inaliza el proceso.

Figura 7. Proceso cancelación. 
Proceso cierre administrativo. 
Actividad 1. Solicitar cierre administrativo

• Rol: Responsable STIC / Proveedor.
• Entrada:
  • Incidencias en estado "Abierta", "Planificada", "Fijada" o "Pendiente de implantar".
• Acciones:
  • El responsable de la STIC o el Proveedor solicitan la aplicación del cierre administrativo de un conjunto de incidencias (sin que se produzca notificación al usuario).
• Transiciones de estado:
  • No hay. Continúa en actividad 2. "Ejecutar proceso de cierre".

Actividad 2. Ejecutar proceso de cierre

• Rol: CSU.
• Entrada:
  • Incidencias en estado "Abierta", "Planificada", "Fijada" o "Pendiente de implantar".
• Acciones:
  • El técnico resolutor ejecuta el proceso de cierre administrativo sobre las incidencias, sin que se produzca notificación al usuario.
• Transiciones de estado:
  • De "Abierta", "Planificada", "Fijada" o "Pendiente de implantar" a "Cerrada". Finaliza el proceso.

 
Figura 8. Proceso cierre administrativo. 
Proceso cierre administrativo (automático).

• Rol: No aplica.
• Entrada:
  • Incidencias en estado "Fijada".
• Acciones:
  • El sistema cierra aquellas incidencias que están en estado "Fijada" desde hace más de 7 días naturales, cuya tipología sea distinta de "petición.datos.sensibles" y cuyo estado del recurso sea distinto a "en reparación".
  • El sistema cierra aquellas incidencias que están en estado "Fijada" desde hace más de 30 días naturales, cuya tipología sea "petición.datos.sensibles" y cuyo estado del recurso sea distinto a "en reparación".
• Transiciones de estado:
  • De "Fijada" a "Cerrada". Finaliza el proceso.

Figura 9. Proceso cierre administrativo (automático). 

Glosario

• Incidencia cualquier evento que no forma parte de la operativa estándar y, que causa, o puede causar, una interrupción o reducción en la calidad del servicio.

• Petición de Servicio: aquellos servicios estándar que son suministrados a través de procedimientos acordados (por ejemplo cambio de contraseñas, creación de cuentas de usuario, permisos de acceso a recursos, etc.).

• CSU (Centro de Servicios al Usuario): conjunto de infraestructura y recursos destinados a la atención de incidencias y peticiones comunicadas por los usuarios, asegurando la calidad y la eficiencia en la prestación de los servicios de TI. Actúan como primer punto de contacto entre los usuarios y el área de TI.

• TI (Tecnología de la Información): Tecnología utilizada para almacenar, comunicar o, procesar información y que da soporte a los procesos de negocio a través de los servicios solicitados al área de TI. La tecnología típicamente involucra hardware, infraestructura de CPD, telecomunicaciones y software. La información tratada puede incluir datos de negocio, imágenes, videos y audio.

• ITIL (Information Technology Infraestructure Library): Marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI). ITIL resume un extenso conjunto de procedimientos de gestión creados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda la infraestructura, desarrollo y operaciones de TI.

• ANS (Acuerdo de Nivel de Servicio): contrato escrito entre un proveedor de servicio y su cliente con el objeto de fijar el nivel acordado para la calidad del servicio.

• CI (Configuration Item): componentes de una infraestructura que actualmente se encuentran bajo manejo de la configuración.

• CMDB (Configuration Management DataBase) Base de datos de configuración): base de datos que contiene los detalles relevantes de cada CI (elemento de configuración) y la relación entre ellos, incluyendo el equipo físico, software y la relación entre las incidencias, problemas, cambios y otros datos de los servicios de TI. La CMDB es un repositorio de información donde se relacionan todos los componentes de un sistema de información, y sean hardware, software, documentación, etc.

• Incidencia Generalizada: Degradación del servicio que afecta a varios o todos los usuarios de dicho servicio.

Anexos

Escalados Incidencias Prioridad 1

Cuando se registra de prioridad 1, además de seguir su curso natural (recepción, registro, clasificación, escalado, etc.), se toman otras medidas de control. Son las siguientes: 

• El Gestor de Incidencias de CSU deberá Informar telefónicamente al técnico resolutor que tiene asignada la incidencia. Igualmente la dirección del servicio es informada de manera constante de la apertura y el seguimiento de la incidencia.
• El Gestor de Incidencias de CSU hará seguimientos telefónicos periódicos a lo largo del día (al menos cada hora), para saber con más nivel de detalle la evolución de la incidencia.
• En el caso de que la incidencia grave pueda afectar a los niveles de servicio ANS acordados con el cliente, la dirección del servicio mantendrá informado a éste de la progresión y resolución de la incidencia.

Cuando un resolutor distinto del CSU asigne directamente una solicitud con prioridad 1 a otro resolutor, el sistema de telefonía realizará una llamada de cortesía informando de dicha asignación.

• Dicha llamada se realizará si la asignación se produce un día laboral entre las 15:00h y 08:00h del día siguiente o los fines de semana y festivos durante las 24h del día.
• El sistema de telefonía realizará automáticamente una llamada de teléfono al número de contacto facilitado por el resolutor. Se realizarán un total de 3 intentos de contacto.
• Una vez descolgada la llamada, una locución informará sobre la asignación de la solicitud de Prioridad 1 y el código de la misma. La locución se repetirá hasta 5 ocasiones, para que el técnico tenga tiempo suficiente de anotar el código.
• Al finalizar la locución el sistema solicitará al técnico que confirme la escucha a través de una pulsación en el teclado. De no hacerlo, continuará realizándose el intento de contacto.

Matriz de Priorización

El modelo de prioridad se aplicará sólo a las solicitudes de tipo Incidencias de entornos productivos. Las Consultas y Peticiones de entornos productivos, y todos los registros de entornos no productivos, por defecto se tratarán como prioridad Normal.
Las peticiones de datos, por su naturaleza, son panificables lo que implica que deben ser priorizadas por el resolutor encargado de planificarla no en CSU y por lo tanto también irán clasificadas con prioridad Normal.

En ocasiones esa prioridad puede ser conveniente aumentarla o disminuirla por necesidades del negocio. Pues bien, para ello los profesionales TIC del SAS y Jefes de Proyectos tienen la posibilidad de establecer una prioridad de manera manual tanto a peticiones como incidencias. U na vez se realice un cambio manual, la solicitud quedará fuera de la matriz de cálculo automatizado durante todo su ciclo de vida.

Se definen dos modelos, uno para las incidencias que se encuentren asignadas al resolutor de Soporte Provincial, y otro para el resto de Resolutores.

En los siguientes gráficos se muestran de manera resumida las variables que intervienen en cada uno de ellos.

Usuario o ubicación afectada

En el ámbito del Puesto de Usuario del contrato de Soporte Provincial, con el fin de mejorar atención al usuario final y la asistencia sanitaria al ciudadano, hay identificados una serie de puestos de trabajo (PTEI) que requieren de una atención especial, denominados estos Puesto de Especial Importancia.

Sólo para las incidencias de este ámbito asignadas al resolutor de este contrato (Soporte Provincial), las que sean reportadas por el usuario de un PTEI y que el usuario no pueda continuar desarrollando su trabajo en un equipo cercano (impacto Alto o Muy Alto), se clasificarán con prioridad Muy Alta, independientemente del resto de variables. En el caso de que pueda continuar con su trabajo en otro equipo, se le aplicará la prioridad resultante del cruce de variables en la matriz de escalado del contrato de Soporte Provincial.

A continuación se enumera la relación de servicios del catálogo de Servicios de la STIC que están asociados al ámbito del puesto de usuario.

• Agenda Corporativa
• Impresión
• Movilidad y telefonía móvil
• Fax y telefonía fija
• Servicio equipo informático
• Soporte operación puesto usuario

Criticidad

Indica cómo de crítico o importante es el elemento CI afectado para el servicio o negocio. La criticidad asignada a un recurso hardware dependerá de su naturaleza, mientras que las de los recursos software las definirá el negocio. Existen tres niveles de criticidad:
Muy Alta: Elemento muy crítico.
Alta: Elemento con cierta criticidad para el negocio o una categoría HW que por su naturaleza se ha identificado como de cierta criticidad.
Normal: Elemento que no se considera crítico para el negocio o en el caso de HW por su naturaleza.

Severidad

Indica la afección del CI. Es el grado de afección que tiene la aplicación o componente afectado por la incidencia, y es un atributo que recoge la tipología de la solicitud. Hay definidos tres niveles de severidad:
Muy Grave: Indisponibilidad para trabajar.
Grave: Pérdida de una funcionalidad importante.
Leve: Degradación del servicio, permitiendo trabajar pero con un tiempo de respuesta alto. 
Determinadas tipologías tendrán asociada un "síntoma" que llevará asociada una severidad diferente a la de la tipología. Así, por ejemplo, para una incidencia de sistema, el síntoma podrá ser "indisponibilidad", "lentitud", "bloqueo" …

Impacto

La definición de impacto variará en función del tipo de incidencia que se registre.

Para incidencias de equipamiento hardware los posibles valores de impacto serán:
Normal (3): El usuario puede continuar trabajando en otro equipo cercano.
Alto (2): El usuario no puede seguir trabajando en otro equipo cercano y su trabajo no es de cara al paciente.
Muy Alto (1): El usuario no puede seguir trabajando en otro equipo cercano y su trabajo es de cara al paciente. 

Mientras que para las incidencias sobre Sistemas de Información (Funcionales o de Sistema), serán:
Normal (3): Sólo le sucede a un usuario.
Alto (2): Le sucede al usuario y a algún compañero más, pero no a todos.
Muy Alto (1): Le sucede al usuario y a muchos de sus compañeros. 

Si se trata de una incidencia hardware asociada a servicios tecnológicos reportadas por personal de TI, puede ocurrir que la avería de un elemento no afecte a ningún usuario y sin embargo el impacto de esta sea potencialmente alto. En estos casos el impacto lo especificará la persona que reporte la incidencia de acuerdo con los siguientes valores:
Normal (3): Un servicio tecnológico no vital se encuentra afectado o el servicio dispone de los elementos de redundancia necesarios que permiten garantizarlo ante una nueva incidencia
Alto (2): la incidencia afecta a un servicio tecnológico que da soporte a un grupo minoritario de usuarios o está funcionando en una situación en la que este riesgo es asumible.
Muy Alto (1): La incidencia afecta ya un grupo muy significativo de usuarios de los servicios a los que da soporte la plataforma o potencialmente será afectado al quedar el servicio expuesto a un riesgo inasumible

Matriz de cálculo de Prioridad

Matriz por defecto

En función de las variables antes definidas, la prioridad de una incidencia saldrá del cruce de los mismos sobre la siguiente matriz:

Matriz de Soporte Provincial

Para este contrato, las prioridades resultantes del cruce de las variables difieren de la matriz genérica, siendo los que se recogen en la siguiente tabla:

Listado de ubicaciones PTEI

Las ubicaciones identificadas como de especial importancia son:
Ámbito de Primaria:

• UCCU Admisión
• Plan Andaluz de Teleictus

Ámbito de Especializada:

• Admisión (Urgencias y Hospitalización)
• Clasificación de Urgencias (triaje)
• Cocina y Dietética
• Farmacia hospitalaria
• Quirófano
• Sala de rayos
• Sala vacunas COVID
• UCI
• Zona de aislamiento
• Plan Andaluz de Teleictus

Adicionalmente se encuentran habilitados los siguientes PTEI:

Ámbito Hospitalario de la provincia de Almería:

El Hospital Torrecárdenas tiene además:

• Box o Consultas de Urgencias
• Paritorio
• Sala de reanimación

Ámbito Hospitalario de la provincia de Córdoba:

Todos los centros del área del H. Reina Sofía, el H. Valle de los Pedroches y el H. Infanta Margarita:

• Camas de observación de Urgencias

El Hospital Reina Sofía tiene además:

• Lavandería (Sala sucia)

Ámbito Hospitalario de la provincia de Huelva:

El Hospital Juan Ramón Jiménez tiene además:

• Centralita

Ámbito Hospitalario de la provincia de Sevilla :

En los edificios principales de H. G. Virgen del Rocío, H. U. Virgen Macarena, H. U. Ntra. Sra. de Valme y H. Ntra. de la Merced:

• Centralita

El H. U. Virgen Macarena tiene además:

• Unidad de ictus

El H. Ntra. de la Merced tiene además:

• Laboratorio de urgencias

El H. U. Ntra. Sra. de Valme tiene además:

• Central de seguridad de instalaciones

Los centros de la Agencia Bajo Guadalquivir, incorporados al SAS, tienen configurados los siguientes puestos:

• Admisión (Urgencias y Hospitalización)
• Clasificación de Urgencias (triaje)
• Laboratorio de urgencias
• Quirófano
• Sala de rayos
• UCI

Ámbito Hospitalario de la provincia de Granada:

En los edificios principales de H. G. Virgen de las Nieves, H. San Cecilio, H. Santa Ana y H. Comarcal de Baza:

• Box o Consultas de Urgencias

En H. Comarcal de Baza tiene además:

• Central de Partos

Ámbito Hospitalario de la provincia de Jaén:

En los edificios principales de H. Jaén, H. San San Agustín y H. San Juan de la Cruz:

• Paritorio

Síntomas asociados a tipologías

Los síntomas que se mostrarán en el área personal de ayudaDiGITAL y APP de  son los siguientes:
Para Incidencias reportadas a través del elemento "una aplicación no funciona correctamente".

Para Incidencias reportadas a través del elemento "un equipo no funciona correctamente".

Para Incidencias reportadas a través del elemento "una aplicación muestra datos incorrectos".

Para Incidencias reportadas a través del elemento "una impresora no funciona correctamente".

Adicionalmente, en la herramienta de Gestión de Incidencias del CSU se han configurado los siguientes síntomas:

En el caso de que el usuario tenga un síntoma en su incidencia que no coincida con ninguno de los de la lista, el registro se realizará sin síntoma, y la severidad de la solicitud será la asociada a la tipología.

Listado de causas raíces al resolver una incidencia

(1) Valor por defecto al seleccionarla, pudiendo ser modificada por el técnico y en tal caso debiendo aportar una justificación del cambio.

Procedimientos

Procedimiento de planificación de incidencias y peticiones

Debido a ciertas situaciones que se pueden dar durante el ciclo de vida de una incidencia o petición, y que son ajenas al proveedor que la tiene asignada, desde la STIC se ha determinado la necesidad de implementar la acción de "planificar", en base a la naturaleza de cada contrato y con las reglas de negocio que se determine para cada uno de ellos.

A continuación se muestran los diferentes motivos de planificación que están definidos y los resolutores a los que se le aplica:

Notificación al usuario de la solicitud : Cuando se planifica una solicitud, se envía una notificación al usuario vía correo electrónico informándole de este hecho, con toda la información indicada por el técnico que realiza la planificación (motivo, descripción y fecha de planificación).

Reactivación de la solicitud planificada: Para todos los motivos es requerida una fecha de planificación con un nº de días máximo, dependiendo de cada motivo. Llegada la fecha indicada, la solicitud pasará de estar “planificada” a “abierta”, a menos que el proveedor que la tiene asignada la reactive manualmente antes de la fecha de planificación.

Además, el usuario reactivará indirectamente una solicitud planificada, si registra una reclamación o un comentario sobre su solicitud y el motivo de planificación es "tres intentos fallidos de contacto con el usuario en un día".

Procedimiento de análisis forense de incidencias

El documento se sube en el espacio Servicio de Gestión TIC en la sección "Gestión de incidencias → Informes de análisis forense " con la nomenclatura:

Informe_Análisis_Forense_Incidencia+Tipo/Aplicación+ubicación afectada+código solicitud

Acceder a los informes de análisis forense aquí .

Plantilla de informe de análisis forense de incidencias

Procedimiento de Incidencias P0

Formación

Accede aqui a la guía de buenas prácticas para documentar solicitudes en Web Técnica