Proceso: Gestión de Peticiones


Objetivo

Ofrecer servicios a los usuarios que permitan la realización de consultas o dudas sobre las aplicaciones existentes, así como solicitar la inclusión de evoluciones sobre los sistemas software en explotación.

Alcance

Este proceso aplica a toda la STIC. 

La gestión de peticiones se ocupa de aquellas solicitudes que estén agrupadas en alguna de las siguientes categorías:

  1. Petición de ampliación y adquisición de equipamiento Hardware o Software.
    • No existe ningún funcionamiento anómalo. En estos casos el usuario requiere la instalación de nuevos equipos, la ampliación de memoria, software de mercado, etc.
  2. Petición de Servicio.
    • Las peticiones de servicio suelen estar relacionadas con cambios estándar preestablecidos, pueden implicar una secuencia de actuaciones a realizar en diferentes sistemas y por diferentes agentes.
    • Ejemplos:
  3. Alta/baja/modificación de usuarios en los sistemas corporativos (correo electrónico + dominio + aplicación gestión, etc.).
  4. Distribuciones de software. El usuario o la empresa desarrolladora precisa del envío/distribución de software sobre su sistema.
  5. Envío de notificaciones, etc.
  6. Peticiones de cambio/mantenimiento de software.
    • Solicitud de cambios, adaptaciones o nuevas funcionalidad de software.

Política

  1. Todas las peticiones se registrarán en el sistema de información de gestión de peticiones y se clasificarán de acuerdo a los criterios establecidos en los procedimientos del proceso.
  2. En el registro de peticiones 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 peticiones 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 peticiones 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 peticiones 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.

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.


Solicitante
Es el rol que detecta la petición y la comunica al proceso. Puede realizar las actividades de registro o bien delegarlas en el rol de Técnico de soporte. 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 peticiones:
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. 
Área Funcional
Cada una de las agrupaciones de las actividades o procesos  que se realizan en el Servicio Andaluz de Salud. 
CTI
Responsable de Centros de Tratamiento de Información del Servicio Andaluz de Salud. 
Sistema
Conjunto de elementos software y hardware.

Diagrama de estados


Figura 1. Estados de las peticiones

Estado

Descripción

Abierta

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

Planificada

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

Pendiente de aprobarPetición asociada a un flujo en el que se requiere la aprobación de un interviniente para continuar su gestión.

Pendiente confirmar cierre

Estado en la que se encuentra una petición cuando un resolutor aporta una solución, y hasta que el solicitante afectado confirma su cierre.

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

Petición ya finalizada (fijada) y confirmada con el solicitante afectado.

Cancelada

Petición cancelada a solicitud del usuario afectado.

RechazadaEstado en que queda una solicitud cuando se rechaza dentro de un flujo de aprobación.



Flujo del proceso


Figura 2. Flujo del proceso. 
Inicio de solicitud

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

Actividad 1. Registrar petición por solicitante,

  • Rol: Solicitante.
  • Entrada:
    • No hay.
  • Acciones:
    • El solicitante utiliza la Web de autoservicio para dar de alta una petición. Al finalizar el registro la petición 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:
    • Petición de "Nueva" a "Abierta".
    • Continúa en subproceso "Revisar registro".

Subproceso. Revisar registro

  • Rol: CGU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • En la siguiente figura se identifican las actividades de este subproceso:

 
Figura 3. Subproceso Revisar registro.

  • Revisar tipificación.
    • 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 petición 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 petición 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 petición dada sobre un cierto CI o por la gravedad de la petición (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 petición y determina la rapidez con la que una petición debe quedar resuelta.
    • La prioridad se calcula a partir de:
      • La severidad de la tipificación
      • La criticidad del CI
      • El impacto de la petición.
    • 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 petición".
    • Si existe un grupo resolutor determinado continúa en actividad 5. "Escalar petición".

Actividad 1'. Registrar petición por primer nivel.

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • El solicitante utiliza alguno de los siguientes medios para comunicar una petición: Teléfono, correo electrónico, fax.
    • Si la petición 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 petición entra por medio de correo electrónico o fax la petición 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 petición primer nivel.

  • Seleccionar tipificación.
    • Selecciona la tipificación de la petición de un catálogo posible.
    • Se trata de una categorización de la petición según una estructura en árbol. El primer nivel del árbol determina qué tipo de petición se está registrando. Por debajo de ese primer nivel, se encuentran sub-categorías que permiten categorizar con más detalle la petición correspondiente. La tipificación de una petición se establece inicialmente en el momento de su registro, y puede ser modificada a lo largo de la vida de la petición, 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 petición quede suficientemente bien tipificada.
      • Durante el ciclo de vida de la petición se deben realizar las re-tipificaciones necesarias para adecuar la categorización al conocimiento real que se va teniendo acerca de la petición.
      • Se debe asegurar que en el momento de cierre la petición, é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 petición 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 petición 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 petición dada sobre un cierto CI o por la gravedad de la petición (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 petición y determina la rapidez con la que una petición debe quedar resuelta.
    • La prioridad se calcula a partir de:
      • La severidad de la tipificación
      • La criticidad del CI
      • El impacto de la petición.
    • Los valores que puede tomar la prioridad son P1 (más prioritaria), P2 (prioridad media) o P3 (menos prioritaria).

Una petición en cualquier momento puede ser reclasificada y cambiar sus atributos.

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

Actividad 2. Diagnosticar petición.

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se realiza un primer análisis de la información proporcionada por el solicitante con el objeto de determinar si puede resolver la petición o bien debe procederse a su escalado.
  • Transiciones de estado:
    • No hay cambio de estado.
    • Si el técnico puede resolver la petición continúa en actividad 3. "Resolver petición primer nivel".
    • Si el técnico no puede resolver la petición continúa en actividad 5. "Escalar petición".

Actividad 3. Resolver petición primer nivel.

  • Rol: CSU.
  • Entrada:
    • Petición 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 "Cerrada" si la petición se ha registrado por llamada telefónica del solicitante y se acuerda en la conversación telefónica que la petición ha quedado resuelta. Finaliza el proceso.
    • De "Abierta" a "Fijada" si la petición 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:
    • Petición en estado "Fijada".
  • Acciones:
    • El solicitante decide si la solución aportada soluciona la petición que registró en el sistema.
  • Transiciones de estado:
    • De "Fijada" a "Cerrada" si la petición se ha solucionado satisfactoriamente. Finaliza el proceso.
    • De "Fijada" a "Abierta" si la petición no se ha solucionado satisfactoriamente. Continúa en actividad 2. "Diagnosticar petición".

Actividad 5. Escalar petición.

  • Rol: CSU.
  • Entrada:
    • Petición 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 petición".

Actividad 6. Analizar petición.

  • Rol: Soporte segundo nivel.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se analiza si la petición debe ser atendida o se ha producido un error en el escalado.
      • Si se ha producido un error en el escalado se devuelve la petición al primer nivel para que procedan al correcto escalado. Continúa en actividad 5. "Escalar petición".
      • 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 petición" es disponer de la información necesaria y suficiente que permita resolver la petición.
  • 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 petición".
    • Si el técnico de segundo nivel puede resolver la petición continúa en actividad 7. "Resolver petición segundo nivel".

Actividad 7. Resolver petición segundo nivel.

  • Rol: Soporte segundo nivel.
  • Entrada:
    • Petición 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 petición 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:
    • Petición 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 petición 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 petición".
    • No hay cambio de estado si la petición 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:
    • Petición en estado "Fijada".
  • Acciones:
    • CSU contacta telefónicamente con, al menos, 3 usuarios que confirmen la correcta resolución de la petición.
  • Transiciones de estado:
    • No hay cambio de estado si se confirma la resolución de la petición. 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 petición".
    • De "Fijada" a "Abierta" si no se confirma la resolución de la petición. Continúa en actividad 7. " Resolver petición segundo nivel" para que el proveedor proceda a su resolución.

Subproceso. Gestión de cambios.

  • Rol: Proveedor.
  • Entrada:
    • Petición 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".


Procedimiento nueva solicitud SSPA

Flujo del proceso

 
Figura 5. Flujo del proceso nueva solicitud SSPA. 
Inicio de solicitud

  • Rol: Solicitante.
  • Entrada:
    • No hay.
  • Acciones:
    • El usuario solicitante rellena el formulario de solicitud de datos y envía un fax a CSU.
    • El sistema procesa automáticamente el fax recibido y crea una nueva solicitud.
  • Transiciones de estado:
    • Petición creada en estado "Abierta". Continúa en actividad 1. "Cumplimentar datos formulario".

Actividad 1. Cumplimentar datos formulario

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • CSU revisa y completa la solicitud, escalando la solicitud al área funcional encargada de aprobar o rechazar la solicitud.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 2. "Escalar a área funcional".

Actividad 2. Escalar a área funcional

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
    • La petición puede venir por una solicitud creada por un solicitante o porque el solicitante no esté conforme con la solución aportada.
  • Acciones:
    • Escalar la petición al área funcional para que proceda a su aprobación o rechazo.
  • Transiciones de estado:
    • No hay. Continúa en actividad 3. "Aprobar o rechazar petición".

Actividad 3. Aprobar o rechazar petición

  • Rol: Área funcional.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • El responsable funcional estudia la solicitud de datos procediendo a su aprobación o rechazo.
  • Transiciones de estado:
    • No hay cambio de estado si se aprueba la petición. Se devuelve la solicitud a CSU para que la escale a CTI. Continúa en actividad 4. "Escalar a CTI".
    • De "Abierta" a "Fijada" si se rechaza la petición.

Se envía un correo automático al usuario para que proceda al cierre o reapertura de la petición. Continúa en actividad 13. "Enviar comunicación a solicitante".
Actividad 4. Escalar a CTI

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición a CTI.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 5. "Crear estructura FTP".

Actividad 5. Crear estructura FTP

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Crear carpeta del usuario en FTP seguro.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 6. "Escalar a proveedor".

Actividad 6. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que prepare el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 7. "Preparar script".

Actividad 7. Preparar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Preparar script de obtención de datos.
    • La petición puede venir escalada por CSU o porque se haya producido una ejecución incorrecta de un script.
  • Transiciones de estado:
    • No hay cambio de estado.
    • Si el proveedor tiene permisos para ejecutar el script continúa en actividad 8. "Ejecutar script".
    • Si el proveedor no tiene permisos para ejecutar el script continúa en actividad 9. "Escalar a CTI".

Actividad 8. Ejecutar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ejecutar script para obtener los datos de la petición.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 12. "Finalizar solicitud" si la ejecución del script ha sido correcta.
    • No hay cambio de estado. Continúa en actividad 15. "Escalar a proveedor volver a ejecutar script" si la ejecución no ha sido correcta.

Actividad 9. Escalar a CTI

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición a CTI para que se encargue de la ejecución del script.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 10. "Ejecutar script".

Actividad 10. Ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ver acciones indicadas en la actividad 8. "Ejecutar script".
  • Transiciones de estado:
    • No hay cambio de estado. Si la ejecución ha sido correcta continúa en actividad 11. "Escalar a proveedor".
    • No hay cambio de estado. Si la ejecución no ha sido correcta continúa en actividad 15. "Escalar a proveedor volver a ejecutar script".

Actividad 11. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que finalice las tareas asociadas a la solicitud.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 12. "Finalizar solicitud".

Actividad 12. Finalizar solicitud

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Formatear datos extraídos.
    • Encriptar fichero.
    • Dejar fichero encriptado en FTP seguro.
    • Se escala la petición a CSU para que comunique la resolución de la petición al usuario.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 13. "Enviar comunicación a solicitante".

Actividad 13. Enviar comunicación a solicitante

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se envía una comunicación por correo electrónico al solicitante incluyendo instrucciones a seguir para acceder a los datos.
  • Transiciones de estado:
    • De "Abierta" a "Fijada". Continúa en actividad 14. "Aceptar o rechazar solución".

Actividad 14. Aceptar o rechazar solución

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

Actividad 15. Escalar a proveedor volver a ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que vuelva a preparar el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 7. "Preparar script".


Procedimiento solicitud de datos periódicos SSPA

Alcance

La solicitud de datos periódicos implica la creación de una nueva solicitud cada vez que se ejecuta el proceso, con la particularidad de que el formulario de entrada que envía el solicitante se adjunta automáticamente a la solicitud si no es la primera ejecución del proceso, ya que este formulario no varía.

Flujo del proceso

 
Figura 6. Flujo del proceso solicitud de datos periódicos SSPA. 
Inicio de solicitud solicitante

  • Rol: Solicitante.
  • Entrada:
    • No hay.
  • Acciones:
    • La primera vez que se realiza una solicitud periódica se ejecuta el "Procedimiento nueva solicitud SSPA" descrito más arriba.
  • Transiciones de estado:
    • Al finalizar el procedimiento la petición está en estado "Cerrada". Se finaliza el proceso.

Inicio de solicitud automático

  • Rol: Sistema.
  • Entrada:
    • Solicitud "padre" ya existente.
  • Acciones:
    • Si no es la primera vez que se realiza una solicitud periódica el sistema crea automáticamente la solicitud de petición de datos, asociada a la primera solicitud periódica que se creó (solicitud "padre").
  • Transiciones de estado:
    • Solicitud creada en estado "Abierta". Continúa en actividad 1. "Cumplimentar datos formulario".

Actividad 1. Cumplimentar datos formulario

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • CSU revisa y completa la solicitud, escalando la solicitud al proveedor.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 2. "Escalar a proveedor".

Actividad 2. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que prepare el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 3. "Preparar script".

Actividad 3. Preparar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Preparar script de obtención de datos.
    • La petición puede venir escalada por CSU o porque se haya producido una ejecución incorrecta de un script.
  • Transiciones de estado:
    • No hay cambio de estado.
    • Si el proveedor tiene permisos para ejecutar el script continúa en actividad 4. "Ejecutar script".
    • Si el proveedor no tiene permisos para ejecutar el script continúa en actividad 5. "Escalar a CTI".


Actividad 4. Ejecutar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ejecutar script para obtener los datos de la petición.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 8. "Finalizar solicitud" si la ejecución del script ha sido correcta.
    • No hay cambio de estado. Continúa en actividad 11. "Escalar a proveedor volver a ejecutar script" si la ejecución no ha sido correcta.

Actividad 5. Escalar a CTI

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición a CTI para que se encargue de la ejecución del script.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 6. "Ejecutar script".

Actividad 6. Ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ver acciones indicadas en la actividad 4. "Ejecutar script".
  • Transiciones de estado:
    • No hay cambio de estado. Si la ejecución ha sido correcta continúa en actividad 7. "Escalar a proveedor".
    • No hay cambio de estado. Si la ejecución no ha sido correcta continúa en actividad 11. "Escalar a proveedor volver a ejecutar script".

Actividad 7. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que finalice las tareas asociadas a la solicitud.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 8. "Finalizar solicitud".

Actividad 8. Finalizar solicitud

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Formatear datos extraídos.
    • Encriptar fichero.
    • Dejar fichero encriptado en FTP seguro.
    • Se escala la petición a CSU para que comunique la resolución de la petición al usuario.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 9. "Enviar comunicación a solicitante".

Actividad 9. Enviar comunicación a solicitante

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se envía una comunicación por correo electrónico al solicitante incluyendo instrucciones a seguir para acceder a los datos.
  • Transiciones de estado:
    • De "Abierta" a "Fijada". Continúa en actividad 10. "Aceptar o rechazar solución".

Actividad 10. Aceptar o rechazar solución

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

Actividad 11. Escalar a proveedor volver a ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que vuelva a preparar el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 3. "Preparar script".


Procedimiento solicitud de datos especiales

Alcance

La solicitud de datos especialmente sensibles (por ejemplo, las solicitudes de datos de Acceso a Historia Clínica), son realizados por parte de un usuario o un juzgado, los cuales remitirán la petición a la dirección de la STIC que realizará la aprobación previa. 
 
Figura 7. Flujo del proceso solicitud de datos especiales.

Flujo del proceso


Inicio de solicitud Usuario

  • Rol: Usuario.
  • Entrada:
    • No hay.
  • Acciones:
    • Un usuario de cualquier área solicita la creación de una solicitud de acceso a datos sensibles.
  • Transiciones de estado:
    • Petición creada en estado "Abierta". Continúa en actividad 1. "Reclasificar".

Inicio de solicitud Subdirección STIC

  • Rol: Subdirección STIC.
  • Entrada:
    • No hay.
  • Acciones:
    • Un usuario perteneciente a la subdirección de la STIC solicita la creación de una solicitud de acceso a datos sensibles.
  • Transiciones de estado:
    • Petición creada en estado "Abierta". Continúa en actividad 1'. "Cumplimentar datos formulario".

Inicio de solicitud Responsable TIC

  • Rol: Responsable TIC.
  • Entrada:
    • No hay.
  • Acciones:
    • Un responsable TIC solicita la creación de una solicitud de acceso a datos sensibles.
  • Transiciones de estado:
    • Petición creada en estado "Abierta". Continúa en actividad 1'. "Cumplimentar datos formulario".

Actividad 1. Reclasificar

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Cualquier solicitud que no llegue desde la STIC será reclasificada como consulta. Se le informa al usuario del procedimiento, indicándole que las peticiones deben ser realizadas por algún miembro de la Subdirección.
  • Transiciones de estado:
    • Petición de "Abierta" a "Cerrada". Se finaliza el proceso.

Actividad 1'. Cumplimentar datos formulario

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • CSU revisa y completa la solicitud, escalando la solicitud al proveedor.
    • Si la solicitud ha sido creada por un responsable de la STIC se escala como si procediera de la Subdirección STIC. En este caso el responsable de STIC debe proporcionar un conjunto de datos que permita completar los datos necesarios de la solicitud.
    • Si la solicitud proviene directamente de la Subdirección STIC se comprueba si el origen de la solicitud es un juzgado, en cuyo caso se modifica la urgencia de la petición (estableciéndolo con valor 5).
  • Transiciones de estado:
    • No hay cambio de estado. Se crean 3 peticiones en el sistema.
      • La primera petición es la inicial y es la que implica la creación de la carpeta FTP (compartida para los scripts obtenidos en las 3 peticiones).
    • Continúa en actividad 2. "Escalar a CTI".

Actividad 2. Escalar a CTI

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición a CTI.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 3. "Crear estructura FTP".

Actividad 3. Crear estructura FTP

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Crear carpeta del usuario en FTP seguro.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 4. "Escalar a proveedor".

Actividad 4. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que prepare el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 5. "Preparar script".

Actividad 5. Preparar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Preparar script de obtención de datos.
    • La petición puede venir escalada por CSU o porque se haya producido una ejecución incorrecta de un script.
  • Transiciones de estado:
    • No hay cambio de estado.
    • Si el proveedor tiene permisos para ejecutar el script continúa en actividad 6. "Ejecutar script".
    • Si el proveedor no tiene permisos para ejecutar el script continúa en actividad 7. "Escalar a CTI".

Actividad 6. Ejecutar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ejecutar script para obtener los datos de la petición.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 10. "Finalizar solicitud" si la ejecución del script ha sido correcta.
    • No hay cambio de estado. Continúa en actividad 13. "Escalar a proveedor volver a ejecutar script" si la ejecución no ha sido correcta.

Actividad 7. Escalar a CTI

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición a CTI para que se encargue de la ejecución del script.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 8. "Ejecutar script".

Actividad 8. Ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ver acciones indicadas en la actividad 6. "Ejecutar script".
  • Transiciones de estado:
    • No hay cambio de estado. Si la ejecución ha sido correcta continúa en actividad 9. "Escalar a proveedor".
    • No hay cambio de estado. Si la ejecución no ha sido correcta continúa en actividad 13. "Escalar a proveedor volver a ejecutar script".

Actividad 9. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que finalice las tareas asociadas a la solicitud.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 10. "Finalizar solicitud".

Actividad 10. Finalizar solicitud

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Formatear datos extraídos.
    • Encriptar fichero.
    • Dejar fichero encriptado en FTP seguro.
    • Se escala la petición a CSU para que comunique la resolución de la petición al usuario.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 11. "Enviar comunicación a solicitante".

Actividad 11. Enviar comunicación a solicitante

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se envía una comunicación por correo electrónico al solicitante incluyendo instrucciones a seguir para acceder a los datos.
  • Transiciones de estado:
    • De "Abierta" a "Fijada". Continúa en actividad 12. "Aceptar o rechazar solución".

Actividad 12. Aceptar o rechazar solución

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

Actividad 13. Escalar a proveedor volver a ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que vuelva a preparar el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 5. "Preparar script".


Procedimiento solicitud de datos provenientes de integración

Alcance

La solicitud de datos provenientes de integración implica la obtención de datos provenientes de aplicaciones de terceros. Para este tipo de petición debe ser la Subdirección de la STIC la que solicite la petición.

Flujo del proceso

 
Figura 8. Flujo del proceso solicitud de datos provenientes de integración. 
Inicio de solicitud Subdirección STIC

  • Rol: Subdirección STIC.
  • Entrada:
    • No hay.
  • Acciones:
    • Un usuario perteneciente a la subdirección de la STIC solicita la creación de una solicitud para la obtención de datos de aplicaciones de terceros.
  • Transiciones de estado:
    • Petición creada en estado "Abierta". Continúa en actividad 1. "Cumplimentar datos formulario".

Actividad 1. Cumplimentar datos formulario

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • CSU revisa y completa la solicitud, escalando la solicitud al proveedor.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 2. "Escalar a proveedor".

Actividad 2. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que prepare el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 3. "Preparar script".

Actividad 3. Preparar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Preparar script de obtención de datos.
    • La petición puede venir escalada por CSU o porque se haya producido una ejecución incorrecta de un script.
  • Transiciones de estado:
    • No hay cambio de estado.
    • Si el proveedor tiene permisos para ejecutar el script continúa en actividad 4. "Ejecutar script".
    • Si el proveedor no tiene permisos para ejecutar el script continúa en actividad 5. "Escalar a CTI".

Actividad 4. Ejecutar script

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ejecutar script para obtener los datos de la petición.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 8. "Finalizar solicitud" si la ejecución del script ha sido correcta.
    • No hay cambio de estado. Continúa en actividad 11. "Escalar a proveedor volver a ejecutar script" si la ejecución no ha sido correcta.

Actividad 5. Escalar a CTI

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición a CTI para que se encargue de la ejecución del script.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 6. "Ejecutar script".

Actividad 6. Ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Ver acciones indicadas en la actividad 4. "Ejecutar script".
  • Transiciones de estado:
    • No hay cambio de estado. Si la ejecución ha sido correcta continúa en actividad 7. "Escalar a proveedor".
    • No hay cambio de estado. Si la ejecución no ha sido correcta continúa en actividad 11. "Escalar a proveedor volver a ejecutar script".

Actividad 7. Escalar a proveedor

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que finalice las tareas asociadas a la solicitud.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 8. "Finalizar solicitud".

Actividad 8. Finalizar solicitud

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Formatear datos extraídos.
    • Encriptar fichero.
    • Dejar fichero encriptado en FTP seguro.
    • Se escala la petición a CSU para que comunique la resolución de la petición al usuario.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 9. "Enviar comunicación a solicitante".

Actividad 9. Enviar comunicación a solicitante

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se envía una comunicación por correo electrónico al solicitante incluyendo instrucciones a seguir para acceder a los datos.
  • Transiciones de estado:
    • De "Abierta" a "Fijada". Continúa en actividad 10. "Aceptar o rechazar solución".

Actividad 10. Aceptar o rechazar solución

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

Actividad 11. Escalar a proveedor volver a ejecutar script

  • Rol: CTI.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición al proveedor para que vuelva a preparar el script de obtención de datos.
  • Transiciones de estado:
    • No hay cambio de estado. Continúa en actividad 3. "Preparar script".


Proceso reclamación de peticiones. 

Figura 9. Proceso reclamación de peticiones. 
Actividad 1. Iniciar reclamación

  • Rol: Solicitante.
  • Entrada:
    • Petición 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: CSU.
  • Entrada:
    • Petición 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 petición al proveedor. Se envía de forma automática un correo electrónico al proveedor indicándole que se escala la petición.
  • 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 petición proveedor".

Actividad 3. Escalar a supervisión

  • Rol: CSU.
  • Entrada:
    • Petición 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: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • El técnico del grupo de supervisión contacta con el proveedor para que agilice la resolución de la petición. Continúa en actividad 5. "Resolver petición proveedor".
  • Transiciones de estado:
    • No hay. Continúa en actividad 5. "Resolver petición proveedor".

Actividad 5. Resolver petición

  • Rol: Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • El proveedor procede a la resolución de la petición..
  • 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: CSU.
  • Entrada:
    • Petición en estado "Fijada".
  • Acciones:
    • Se produce la revisión de la solución si la naturaleza de la petición lo permite. En caso de ser una petición 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 petición.
    • De "Fijada" a "Abierta" si no se da por resuelta la petición. Continúa en actividad 7. "Escalar responsable STIC".

Actividad 7. Informar responsable STIC

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se informa al responsable de la STIC para que intervenga en la petición.
  • Transiciones de estado:
    • No hay. Continúa en actividad 8. "Realizar gestiones".

Actividad 8. Realizar gestiones

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

Actividad 9. Informar a usuario

  • Rol: CSU.
  • Entrada:
    • Petición en estado "Fijada".
  • Acciones:
    • Se informa al usuario de la resolución de la petición.
  • 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:
    • Petición en estado "Fijada".
  • Acciones:
    • Se informa al usuario de la resolución de la petición.
  • 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 petición proveedor".



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

  • Rol: CSU / Soporte puesto usuario / Proveedor HP.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se solicita información adicional al solicitante creador de la petición 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: Resto Proveedores (Todos los proveedores excepto proveedor HP).
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • Se escala la petición 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:
    • Petición en estado "Abierta".
  • Acciones:
    • Se solicita información adicional al solicitante creador de la petición 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:
    • Petición 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.




Proceso cancelación. 
Actividad 1. Solicitar cancelación

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

Actividad 2. Cancelar petición

  • Rol: CSU / Proveedor.
  • Entrada:
    • Petición en estado "Abierta".
  • Acciones:
    • El técnico resolutor cancela la petición.
  • Transiciones de estado:

De "Abierta" a "Cancelada". F inaliza el proceso.

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

  • Rol: Responsable STIC / Proveedor.
  • Entrada:
    • Peticiones 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 peticiones (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:
    • Peticiones 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 12. Proceso cierre administrativo. 
Proceso cierre administrativo (automático).

  • Rol: No aplica.
  • Entrada:
    • Peticiones en estado "Fijada".
  • Acciones:
    • El sistema cierra aquellas peticiones 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 peticiones 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 13. Proceso cierre administrativo (automático).

Glosario

  • Petición 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 peticiones 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 peticiones, 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.


  • FTP: File Transport Protocol: Protocolo que permite la transferencia de ficheros.


  • STIC: Subdirección de Tecnologías de la Información y las Comunicaciones.

Anexos

Motivos de planificación de incidencias y peticiones

ver en gestión de incidencias.

Procedimiento para la gestión de la demanda de provisión y comunicaciones WAN de CTI

1      Introducción

Actualmente, el proveedor de ADMINISTRACIÓN SISTEMAS CENTRALIZADOS – CTI realiza una gestión de la demanda registrada en ayudaDIGITAL relativa a PROVISION Y SOPORTE COMUNICACIONES WAN que es propia de SANDETEL, consiste en, una vez asignada la solicitud desde CSU realizan las siguientes acciones:

1.- Verificar que los datos recogidos en la solicitud son completos y correctos.
2.- Solicita a SANDETEL la atención de la demanda.
3.- Seguimiento periódico de la demanda.
4.- Una vez resuelta por SANDETEL, control de calidad de la solución aportada.
5.- Proporciona la respuesta al usuario final.

2      Situación Actual

En la actualidad, no existe una integración entre SERVICIOS CGES y SANDETEL para la demanda de PROVISIÓN Y SOPORTE COMUNICACIONES WAN, por ello, la solicitud está asignada en todo momento al proveedor ADMINISTRACIÓN SISTEMAS CENTRALIZADOS – CTI, computando los tiempos SLA del ciclo de vida completo al proveedor y, por tanto, impactando en los ANS de éste.

En la actualidad, se han iniciado las negociaciones con SANDETEL para regular esta demanda y evolucionar la integración que ya existe entre SERVICIOS CGES y SANDETEL incorporando también la demanda relativa a la PROVISIÓN Y SOPORTE COMUNICACIONES WAN.

3      Procedimiento Provisional

Por el momento, y hasta que no se evolucione la integración con SANDETEL, se establece un procedimiento provisional para solucionar la situación actual, que consiste en un nuevo contacto llamado “PROVISION Y SOPORTE COMUNICACIONES WAN (Asignado a SANDETEL)”, bajo la misma organización funcional de ADMINISTRACIÓN DE SISTEMAS CENTRALIZADOS – CTI, al que únicamente se podrá asignar la demanda relativa a la PROVISIÓN Y SOPORTE COMUNICACIONES WAN, no pudiendo utilizarse bajo ningún concepto para el resto de demanda.

Este contacto será utilizado por el proveedor de ADMINISTRACIÓN DE SISTEMAS CENTRALIZADOS – CTI para que escale la demanda a este contacto, sólo y únicamente en el momento en el que la solicitud haya sido solicitada a SANDETEL (punto 2 del apartado 1). Una vez quede confirmado que SANDETEL ha resuelto la solicitud, se volverá a escalar la misma a otro contacto de la organización funcional ADMINISTRACIÓN DE SISTEMAS CENTRALIZADOS – CTI (punto 4 del apartado 1), bien sea al técnico nominativo que esté gestionando la solicitud o al contacto genérico de la organización. Es ADMINISTRACIÓN DE SISTEMAS CENTRALIZADOS – CTI  quien realizará el seguimiento continuado a dicha demanda hasta su resolución y conformidad.

El tiempo que esté asignada la demanda al contacto PROVISION Y SOPORTE COMUNICACIONES WAN (Asignado a SANDETEL) quedará excluido de los indicadores y ANS donde aplique del contrato de ADMINISTRACIÓN DE SISTEMAS CENTRALIZADOS.


Formación

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



Ayuda relacionada:

  • Enlace
  • Enlace