Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 10 Siguiente »


Proceso de 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.


CGES
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. 

Procedimiento

Diagrama de estados

 
Figura 1. Estados de las incidencias 

Estado

Descripción

Abierta

Estado en el que está asignada a un grupo resolutor y pendiente de resolver.

Retrasada

Estado que implica parada de reloj asignada al grupo resolutor. Se produce cuando se solicita más información al usuario.

Fijada

Estado en la que se encuentra una incidencia cuando un resolutor aporta una solución, y hasta que el solicitante afectado confirma su cierre.
Este estado se denomina "Pendiente de confirmación cierre" en la herramienta "Web de autoservicio".

Pendiente de implantar

Estado en el que se encuentra una solicitud de cambio (RFC) cuando la petición de lanzamiento (PL) asociada se ha instalado de forma satisfactoria.

Cerrada

Incidencia ya finalizada (fijada) y confirmada con el solicitante afectado

Cancelada

Incidencia cancelada a petición del usuario afectado


Tabla 1. Estados incidencia. 


Flujo del proceso


Figura 2. Flujo procedimiento. 
Inicio de solicitud

  • Rol: Solicitante / CGES.
  • 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: CGES.
  • 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: CGES.
  • 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: CGES.
  • 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: CGES.
  • 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: CGES.
  • 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: CGES.
  • Entrada:
    • Incidencia en estado "Fijada".
  • Acciones:
    • CGES 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. 

Figura 5. Proceso reclamación de incidencias. 
Actividad 1. Iniciar reclamación

  • Rol: Solicitante.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • El solicitante reclama sobre una solicitud abierta mediante alguno de los siguientes canales: Teléfono, Web de autoservicio o correo electrónico.
  • Transiciones de estado:
    • No hay. Continúa en actividad 2. "Registrar ticket reclamación"

Actividad 2. Registrar ticket reclamación

  • Rol: CGES.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • Se realiza un registro de la reclamación (ticket de tipo "reclamación") asociado a la solicitud inicial.
    • Se escala la incidencia al proveedor. Se envía de forma automática un correo electrónico al proveedor indicándole que se escala la incidencia.
  • Transiciones de estado:
    • No hay. Si el solicitante ha iniciado la reclamación por teléfono y solicita la intervención de un responsable continúa en actividad 3. "Escalar a supervisión".
    • No hay. Si el solicitante no solicita la intervención de un responsable continúa en actividad 5. "Resolver incidencia proveedor".

Actividad 3. Escalar a supervisión

  • Rol: CGES.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • El técnico de nivel 1 transfiere la llamada al grupo de Supervisión, quien le atiende la reclamación de manera personalizada.
  • Transiciones de estado:
    • No hay. Continúa en actividad 4. "Contactar con proveedor".

Actividad 4. Contactar con proveedor

  • Rol: CGES.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • El técnico del grupo de supervisión contacta con el proveedor para que agilice la resolución de la incidencia. Continúa en actividad 5. "Resolver incidencia proveedor".
  • Transiciones de estado:
    • No hay. Continúa en actividad 5. "Resolver incidencia proveedor".

Actividad 5. Resolver incidencia

  • Rol: Proveedor.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • El proveedor procede a la resolución de la incidencia..
  • Transiciones de estado:
    • De "Abierta" a "Fijada". Continúa en actividad 6. "Revisión de la solución".

Actividad 6. Revisión de la solución

  • Rol: CGES.
  • Entrada:
    • Incidencia en estado "Fijada".
  • Acciones:
    • Se produce la revisión de la solución si la naturaleza de la incidencia lo permite. En caso de ser una incidencia de prioridad 1 se confirmará la solución con al menos 3 usuarios.
  • Transiciones de estado:
    • No hay. Continúa en actividad 9. "Informar a usuario" si se da por resuelta la incidencia.
    • De "Fijada" a "Abierta" si no se da por resuelta la incidencia. Continúa en actividad 7. "Escalar responsable STIC".

Actividad 7. Informar responsable STIC

  • Rol: CGES.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • Se informa al responsable de la STIC para que intervenga en la incidencia.
  • Transiciones de estado:
    • No hay. Continúa en actividad 8. "Realizar gestiones".

Actividad 8. Realizar gestiones

  • Rol: Responsable STIC.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • El responsable de la STIC gestiona la incidencia con el proveedor, mediante conversación telefónica o por correo electrónica.
  • Transiciones de estado:
    • No hay. Continúa en actividad 5. "Resolver incidencia".

Actividad 9. Informar a usuario

  • Rol: CGES.
  • Entrada:
    • Incidencia en estado "Fijada".
  • Acciones:
    • Se informa al usuario de la resolución de la incidencia.
  • Transiciones de estado:
    • No hay. Continúa en actividad 10. "Aceptar o rechazar solución".

Actividad 10. Aceptar o rechazar solución

  • Rol: Solicitante.
  • Entrada:
    • Incidencia en estado "Fijada".
  • Acciones:
    • Se informa al usuario de la resolución de la incidencia.
  • Transiciones de estado:
    • De "Fijada" a "Cerrada" si el usuario acepta la solución. Finaliza el proceso.
    • De "Fijada" a "Abierta" si el usuario no acepta la solución. Si el solicitante ha iniciado la reclamación por teléfono y solicita la intervención de un responsable continúa en actividad 3. "Escalar a supervisión".
    • De "Fijada" a "Abierta" si el usuario no acepta la solución. Si el solicitante no solicita la intervención de un responsable continúa en actividad 5. "Resolver incidencia proveedor".



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

  • Rol: CGES / Soporte puesto usuario / Proveedor HP.
  • 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 "Retrasada". Continúa en actividad 2. "Proporcionar información adicional"
Actividad 1'. Escalar a CGES

  • Rol: Resto Proveedores (Todos los proveedores excepto proveedor HP).
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • Se escala la incidencia a CGES 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: CGES.
  • 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 "Retrasada". Continúa en actividad 2. "Proporcionar información adicional".

Actividad 2. Proporcionar información adicional

  • Rol: Solicitante.
  • Entrada:
    • Incidencia en estado "Retrasada".
  • Acciones:
    • El solicitante proporciona la información que le ha sido requerida.
  • Transiciones de estado:
    • De "Retrasada" 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: CGES / Proveedor.
  • Entrada:
    • Incidencia en estado "Abierta".
  • Acciones:
    • El técnico resolutor cancela la incidencia.
  • Transiciones de estado:
    • De "Abierta" a "Cancelada". Finaliza el proceso.



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

  • Rol: Responsable STIC / Proveedor.
  • Entrada:
    • Incidencias en estado "Abierta", "Retrasada", "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: CGES.
  • Entrada:
    • Incidencias en estado "Abierta", "Retrasada", "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", "Retrasada", "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

Matriz de severidad, criticidad del CI, urgencia y severidad

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: 

Prioridad
( 1=Muy Alta,
2=Alta,
3=Normal)

 

Criticidad(C) X Severidad(S)

 

 

 

 

 

 

 

 

 

 

C1XS1

C1XS2

C2XS1

C1XS3

C2XS2

C3XS1

C2XS3

C3XS2

C3XS3

 

Impacto

1

1

1

1

2

1

1

2

2

2

 

 

2

1

1

1

2

2

2

3

3

3

 

 

3

2

2

2

3

3

3

3

3

3

 


Tabla 2. Matriz criticidad incidencias. 

Matriz de Soporte a puesto de usuario.

Existe un contrato distinto para aquellas incidencias que deban ser resueltas "in situ" (no de forma remota) por un técnico. 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: 

Prioridad
( 1=Muy Alta,
2=Alta,
3=Normal)

 

Criticidad(C) X Severidad(S)

 

 

 

 

 

 

 

 

 

 

C1XS1

C1XS2

C2XS1

C1XS3

C2XS2

C3XS1

C2XS3

C3XS2

C3XS3

 

Impacto

1

1

2

1

2

2

2

2

2

2

 

 

2

2

2

2

2

2

2

3

3

3

 

 

3

2

2

2

3

3

3

3

3

3

 


Tabla 3. Matriz criticidad incidencias (soporte a puesto de usuario). 
NOTA sobre ambas matrices: Actualmente existe un impacto denominado "None" que indica que la incidencia se produce a un usuario. Este impacto debe extinguirse. 

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 co




DocumentoDescripción
Proceso de Gestión de Incidencias v1.0Proceso completo para gestionar incidencias.
Matriz de priorización v1.3.5Criterios de priorización de una incidencia.
Causa raíz_v1Listado de posibles causas raíces al resolver una incidencia. Configurable por contrato.
Planificar configuracion_v1Listado de posibles motivos de configuración para incidencias/peticiones. Configurable por contrato.
  • Sin etiquetas