Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.
Extracto
Divbox
classestiloindice
Expandir
titleÍndice

Tabla de contenidos
outlinetrue
absoluteUrltrue
excludeAyuda relacionada:.*

Divbox
classdivcontenedor
Divbox
stylewidth: 92%; text-align: left;
classdivcontenido

Image Added Proceso
Titulo pagina



Objetivo

Extracto

Buscar y desarrollar soluciones permanentes que impidan que vuelvan a producirse determinadas incidencias provocadas por esa causa.

Alcance 

El procedimiento

de 

de Gestión de Problemas

 se

se encargará de resolver los problemas que impacten sobre los Sistemas de Información gestionados desde la Subdirección de Tecnologías de la Información y la Infraestructura que los soporta

del Ámbito centralizado


Abarca desde que se identifica un problema, ya sea de manera proactiva o reactiva, hasta la resolución que da solución a la causa del problema identificado.


Descripción de Actividades

Definiciones

Ámbito centralizado: La gestión TIC dentro del SAS que se gestiona de manera centralizada, es decir, común para todo el SAS.
Causa raíz: (ITIL Operación del Servicio) La causa original o subyacente de una incidencia o problema.
Grupo lógico: Agrupación de elementos HW (físico o virtual) y SW dentro de una plataforma que tiene un fin determinado tecnológico o de negocio.
Incidencia: (ITIL Operación del Servicio) Interrupción no planificada de un servicio de TI o reducción en la calidad de un servicio de TI. También lo es el fallo de un elemento de configuración que no ha impactado todavía en el servicio. Por ejemplo, el fallo de uno de los discos de un "mirror".
Mejora: Todas aquellas entradas que buscan la evolución (cambio) de una aplicación y requieren ser planificadas para su resolución. 
Problema: (ITIL Operación del Servicio) Causa de uno o más incidencias. En el momento en el que se crea el registro de problemas no es frecuente conocer su causa, por lo que es necesario realizar su investigación mediante el proceso de gestión de problemas.
Error conocido: (ITIL Operación del Servicio) Problema que posee una causa raíz documentada y una solución temporal. Los errores conocidos son creados y gestionados a través de su ciclo de vida por la gestión de problemas. Los errores conocidos pueden ser identificados también por el área de desarrollo o suministradores.
Plataforma: Entidad destinada a proveer de servicios tecnológicos o sustentar aplicaciones de negocio
Solución temporal (workaround): (ITIL Operación del Servicio) Reducción o eliminación del impacto de un incidencia o problema para el que una resolución completa no está todavía disponible. Por ejemplo, reiniciando un elemento de configuración que falla. Las alternativas para problemas se documentan en los registros de errores conocidos. Las alternativas para incidencias que no tienen asociados registros de problemas se documentan en el registro de incidencias.
Versión: Agrupación de mejoras y/o incidencias de una determinada aplicación que persiguen implantarse de manera conjunta. Es la unidad de gestión del responsable de producto. 

Acrónimos

CI: Configuration Item
EC: Error Conocido
GP: Gestor de Problemas
IT: Information Technology
ITIL: IT Infrastructure Library
PL: Plan de Lanzamiento
RGP: Responsable del seguimiento y control de problemas
RP: Responsable del Proceso
RFC: Request For Change 
SAS: Servicio Andaluz de Salud
STIC: Subdirección de Tecnologías de la Información y Comunicaciones 

Política

  • Todos los registros de problemas deberán registrarse y tratarse en la herramienta que da soporte, Nueva Web Técnica, NWT https://ws001.sspa.juntadeandalucia.es/webtecnica/#login con logon DMSAS.
  • Se intentará fijar una solución temporal cuanto antes, si bien el objetivo final de la gestión de problemas es aportar una solución definitiva mediante el proceso de Gestión de Cambios.
  • Existirán comités de problemas, por aplicación, conjunto de aplicaciones y/o plataformas (al criterio del RGP y GP) la apertura de registros de problemas, así como los seguimientos de los existentes.
  • El RGP es siempre el responsable último del problema, la responsabilidad viene determinada sobre el CI que se está analizando.
  • El CI causa raíz que inicialmente coincidirá con el CI afectado, pero podrá cambiar a medida que avance el estudio del problema.
  • El cambio de RGP, y por tanto de responsabilidad del problema a través del cambio del CI, sólo puede hacerlo el RGP o el GP por delegación. Será una buena práctica que se lo comunique al nuevo RGP de antemano.
  • Durante la investigación:
    • El proveedor que está investigando podrá solicitar peticiones a otro proveedor que estén en su catálogo.
    • Si necesita que otro proveedor investigue, escalará al RGP para que haga la transferencia. Es decir, un proveedor no escala a otro proveedor directamente.

Roles y responsabilidades

  • Solicitante: Es el rol que ocupa aquella persona, personal de TI, que remite a Gestión de Problemas una propuesta de un problema, ya sea de manera reactiva o proactiva.
  • Responsable del proceso. RP: Rol propietario 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.
    • Lidera el proceso en la STIC, integrando a los distintos roles involucrados, y adaptando la respuesta de dicho proceso a las directrices que se establezcan desde la STIC.
  • Responsable de la gestión del problema. RGP: Rol responsable último del problema en todas sus fases. Concretamente:
    • Monitorización y registro:
        • Detectar problemas, tanto de forma reactiva como proactiva.
        • Decide si se aborda un problema propuesto por otros roles.
    • Investigación:
        • Dota de mecanismos para que los resolutores puedan investigar: convoca comités de problemas, orquesta distintos resolutores, etc.
        • Decide si se suspende un problema que está en investigación, pudiéndose apoyar en el GP.
    • Resolución:
        • Analiza el coste de la solución/es propuesta/s por el resolutor/es y decide si se resuelve o no, pudiéndose apoyar en el GP.
  • Gestor del problema.GP. Es el que da soporte operativo a todo el proceso al RGP en todo el ciclo de vida del Problema y tiene funciones específicas sobre el seguimiento del problema.
    • Monitorización y registro:
        • Detectar problemas, tanto de forma reactivo como proactiva.
        • Analizar la propuesta de problemas: revisar si es efectivamente un problema, evitar duplicados.
        • Asociar incidencias a problemas.
    • Investigación y resolución:
        • Dar soporte al RGP en las actividades de investigación y resolución.
    • Seguimiento:
        • Monitorizar el desempeño del problema.
  • Resolutor (Proveedor): Es el que trabaja de manera activa en la resolución del problema. Concretamente:
    • Monitorización y registro:
      • Detectar problemas, tanto de forma reactiva como proactiva.
    • Investigación:
      • Investigar la causa raíz problema, buscar una solución temporal mientras se resuelve el problema.
    • Resolución:
      • Resolver el problema una vez el problema es error conocido.
En la siguiente tabla se identifica rol del proceso con la responsabilidad STIC 

ROL Gestión problemas

Responsabilidad STIC

RP

Servicios Horizontales STIC

GP

CSU

RGP

Responsables Producto o Responsable Sistemas determinado del CI informado

Proveedor

Proveedor que tiene asignado el soporte del CI.

Actividades del proceso

El proceso de Gestión de Problemas se compone de 4 actividades principales, que se describen a continuación: 
  • Planificación del proceso: Se definen y mantienen los principios y planteamientos para desarrollar el proceso de gestión de problemas, siempre alineados a las directrices de la STIC.
  • Monitorización y Registro: Fase en la que se realizan las actividades previas a la creación del problema. Se identifican posibles problemas, tanto de manera reactiva, como proactiva, realizándose el registro una vez confirmada la ocurrencia del mismo.
  • Investigación: Se busca la causa raíz del problema y se proponen soluciones provisionales o definitivas al mismo.
  • Resolución: Una vez identificada la causa raíz, se registra la petición de resolución para implementar la solución y se verifica que el error no vuelve a producirse.
  • Seguimiento: Consiste en la monitorización del desempeño del problema.

Principales entradas

  • Detección proactiva
  • Gestión de incidencias

    Principales salidas

    • Problema resuelto, con o sin propuesta de cambio para su resolución
    • Solución temporal.
    • Problema suspendido.

    Relaciones con otros procesos

    • Gestión de incidencias: es la entrada principal al proceso, ya que proporciona incidencias de las que hay que encontrar su causa raíz para evitar que se reproduzcan. Por otro lado, también es salida, ya que proporciona a soluciones temporales al proceso de incidencias.
    • Gestión de capacidad, disponibilidad, seguridad: detectan problemas y las proponen al proceso.
    • Gestión de cambios: proporciona las soluciones definitivas a los problemas.
    • Mejora continua: mediante la monitorización del proceso a través de los KPIs implementados, se obtiene la información necesaria para la identificación de mejoras.

    Matriz RASCI

    Para aclarar la participación de los distintos roles se usa la matriz RASCI, dónde: 
    R (Responsible) = Ejecutor de la actividad. El que trabaja en ella, y por tanto tiene asignado el problema.
    A (Accountable) = Responsable final del problema. Debe garantizar la ejecución de todas las actividades y garantizar la calidad de las mismas.
    S (Supported) = Recurso asignado al ejecutor de la actividad (Responsible).
    C (Consultant) = Aporta información para realizar la actividad. Asesora durante la actividad.
    I (Informed) = Informado. Es informado de la evolución de la actividad. 
    Actividades

    Responsable Proceso

    RGP

    GP

    Solicitante

    Proveedor

    Planificación Proceso

    R,A

    C

    C

     

     

    Registrar

     

    A

    R, I

    R

     

    Diagnosticar

     

    A, C, I

    C,I

     

    R

    Resolver

     

    A,R

    C,I

     

    R

    Mejora Continua Proceso

    A

     

    R

     

     

    Tabla 2. Matriz RASCI 

    Procedimiento

    La herramienta que soporta el proceso es Nueva Web Técnica

    https://ws001.sspa.juntadeandalucia.es/webtecnica/

    • Para crear problemas: REGISTRAR PROBLEMA
    • Para actuar sobre problema: PROBLEMAS PENDIENTES DE QUE YO ACTUE
    • Para buscar sobre todos los problemas: BUSCAR EN TODOS LOS PROBLEMAS

    Diagrama del proceso 

    Flujo de estados

    Actividades del procedimiento

    Tabla resumen

    Actividad proceso

    Actividad procedimiento

    Rol

    Descripción

    Entrada

    Salida

    Proceso relacionado

    Monitorización y registro

    Registrar problema

    Solicitante

    El problema es dado de alta en la herramienta de soporte, y es asignada al GP.

    Incidencias, revisión proactiva.

    Registro del problema para revisar.

    Gestión Incidencias 
    Gestión capacidad, disponibilidad, seguridad

    Monitorización y registro

    Revisar propuesta de problema

    GP

    El GP hace una primera revisión del problema

    Registro del problema para revisar.

    Registro revisado 

    1. No es problema. Registro problema cerrado. Fin proceso 
    2. Es problema. Problema escalado al RGP para que decida

     

    Monitorización y registro

    Decidir abordar problema

    RGP

    Decide qué hacer con el problema.

    Registro revisado

    Decisión tomada: 

    1. Problema suspendido 
    2. Problema a investigar

     

    Investigación

    Investigar causa raíz y buscar workaround (solución temporal)

    Proveedor

    El proveedor investiga el problema con objeto de encontrar al menos en primera instancia un workaround, así como la causa raíz. 
    Si tiene causa raíz conocida y al menos un workaround se trata de un error conocido

    Problema a investigar.

    Problema investigado: 

    1. Problema investigado con/sin workauround/s y sin causa raíz identificada. Problema a evaluar la investigación 
    2. Error conocido. Problema a resolver

    Gestión incidencias

    Investigación

    Evaluar investigación

    RGP

    El RGP debe determinar qué hacer con el problema.

    Problema investigado

    Problema evaluado: 

    1. No se continua con el problema. Problema suspendido 
    2. Se continua con la investigación 
      1. Problema escalado al proveedor para que continúe investigando 
      2. Cambio de responsabilidad del CI.

     

    Resolución

    Evaluar propuesta de resolución

    RGP

    Decide si es viable la solución

    Error conocido

    1. No se resuelve el problema. Problema suspendido 
    2. Se resuelve el Problema 

     

    Resolución

    Resolver

    RGP/Proveedor

    Se elige la opción de resolución

    Error conocido

    1. Problema resuelto con Cambio. 
    2. Problema resuelto sin Cambio. 

    Gestión de cambios

    Resolución

    Revisar resolución

    RGP

    El RGP confirma la solución aportada. 

    Problema resuelto

    1. Problema cerrado 
    2. Problema reabierto si no se está conforme.

     

    Monitorización y registro

    Registrar Problema
    • Rol: Solicitante, otros procesos.

    • Entrada:

    Roles


    ROL

    Descripción

    SolicitanteRol solicitante del problema

    RP

    Rol responsable del proceso. El que supervisa el proceso en su totalidad.

    GP

    Rol Gestor de Problemas. Opera, vigila, controla que se realicen todas las actividades. Da soporte tanto al Responsable del Proceso como a RGP.

    RGP

    Rol Responsable de la gestión del problema (de uno o varios). Es el que debe hacer que un de determinado resolutor o resolutores se encargue de resolver el problema. Así mismo suspenderlo si considera que no es el momento de abordarlo.

    Resolutor

    Rol resolutor de uno o varios problemas. Sobre un mismo problema pueden actuar varios resolutores.

    El rol de resolutor lo puede desempeñar tanto un proveedor de servicios como personal STIC



    Diagrama de flujo (actividades y estados)

    Lucidchart
    lcId0ee2c259-06e6-4969-b4e2-f09b9ced0926
    rich-viewertrue
    autoUpdatetrue
    autofitfalse
    nameg_ problemas - ZF_q~ncLqpc3
    width1333
    convertedFromonprem
    origParamseyIiOiIiLCJhdXRvVXBkYXRlIjoidHJ1ZSIsInNpemUiOiI5MDAiLCJzaW1wbGVWaWV3ZXIiOiJ0 cnVlIiwiYXR0YWNobWVudElkIjoiOTI0NzIwNjUiLCJ2ZXJzaW9uIjoiMiJ9
    documentTokenv2_a6e1e2f5828237805490e82a02adb9c4deb98e396c1a1bd6651088e7494603f9-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=acf074db-7240-4d65-b038-dd9f77e0046b&p=
    idacf074db-7240-4d65-b038-dd9f77e0046b
    alignLeft
    height1035

    draw.io Diagram
    diagramNameg_ problemas (from Lucidchart).drawio
    revision1





    Descripción del flujo


    Registrar 

    Existen diversas formas de detección de problemas en la organización: análisis de una incidencia, sospecha o detección por parte de primera línea, detección automática por parte de las herramientas de monitorización, análisis de proveedores, GP, RGPs o RP.

  • Acciones:
  • Recopilar la información del problema.Registrar problema en la herramienta de soporte de problemas, informando el

    El paso principal es registrar el problema identificado por el usuario, recopilando toda la información posible acerca de este, tanto del CI sobre el que se detecta el problema

    , así

    como la prioridad

    del problema.Salida:Problema registrado

    de este. Una vez se realiza el registro a través de área personal de ayudaDIGITAL el problema queda asignado al GP para

    revisar.
  • Estado "Abierta"
  • Va a "Revisar propuesta de problema"
  •  Revisar propuesta de problema
    • Rol: GP.
    • Entrada:
      • Problema registrado.
    • Acciones
      • Revisa si es un problema.
      • Revisa si hay incidencias que se deban asociar al problema
      • Escala al RGP, o bien cierra.
    • Salida:
  • Si no es un problema:
    • Se Cierra y se informa de la causa (duplicado, etc.).
    • Estado "Cerrada". Fin del proceso
  • Si es un problema
  • Se Escala al responsable del CI, RGP
  • Estado "Abierta"
  • Va a "Decidir abordar el problema"
    Decidir abordar el problema
    • Rol: RGP
    • Entrada:
      • Propuesta de problema revisada.
    • Acciones
      • El RGP decide si se debe o no abordar el análisis y resolución del problema. Para tomar dicha decisión el RGP podrá contar con el soporte del proveedor, GP, e interno de la STIC.
    • Salida:
      • Se decide no abordar el problema:
        • Se Suspende.
        • Estado "Suspendida". Puede ocurrir que a futuro dicho problema se recupere.
      • Se decide abordar el problema
        • Se Escala al proveedor.
        • Estado "Abierta"

                         Va a subproceso Investigación.

    Investigación

    Se

    ser revisado.

    Revisar

    El GP revisa siempre en primera instancia el problema, determina si es o no un problema o si se trata de un duplicado, en cualquiera de estos casos cerrará el problema recibiendo notificación el solicitante.

    Si aplica, se asigna al RGP, que será siempre responsable del CI sobre el que se ha detectado el problema: una aplicación o una plataforma.

    Decidir abordar

    Desde Web Técnica, el RGP debe decidir qué hacer con el problema.

    • Es posible que determine que no se debe abordar por diversos motivos: coste vs beneficio, indisponibilidad de recursos para abordarlos. En dicho caso el problema se suspende. Siempre el RGP tendrá la capacidad de retomar el problema.
    • O bien decide dedicar esfuerzos a resolver el problema y deberá determinar el modo de hacerlo.


    Convocar Kick off 

    El RGP ha decidido que se deber abordar, por lo que tendrá que organizar la forma en que la resolución se debe llevar a cabo.

    • Puede ocurrir que la resolución del problema se circunscriba al ámbito de competencia de un único resolutor. En ese caso lo asignará a este y le comunicará de la manera que tengan acordada que el problema se debe investigar. Por ejemplo, a través de reuniones de periódicas de operación del servicio.
    • Puede ocurrir que el problema sea multidisciplinar y necesite de varios resolutores para afrontarlo. En este caso se convocará una reunión ad hoc específica para iniciar ese problema. A esta reunión deberán asistir tantos los resolutores responsables del mantenimiento de las aplicaciones como de plataformas afectadas, así como sus responsables y el GP. De esta reunión deberá salir un plan de trabajo acordado entre todas las partes. Esta reunión la convocará siempre el GP.

    Investigar

    Durante la actividad de investigación siempre se busca la causa raíz del problema y se proponen soluciones provisionales o definitivas al mismo.

    Es decir se desarrollan al mismo tiempo dos actividades. Para llevarlas a cabo, se podrán usar:
  • Reuniones de gestión de problemas.
  • Técnicas de resolución de problemas.
  • Reproducciones

    Se aplicarán técnicas de resolución de problemas y reproducciones en condiciones adecuadas del problema.

     Investigar causa raíz y  Buscar workaround (solución temporal)
  • Rol: Proveedor
  • Entrada subproceso:
    • Problema escalado al proveedor.
  • Acciones:
  • Durante la investigación el proveedor irá dejando constancia de aquellos avances realizados.
  • Durante la investigación puede surgir la necesidad de solicitar a otro proveedor una petición de su catálogo. Dicha solicitud se hará a través del proceso de gestión de peticiones que le devolverá al problema aquella información solicitada. Por ejemplo, proporcionar el log de una aplicación.
  • El proveedor debe buscar al menos una solución temporal. Se pueden proponer de 1 a n soluciones temporales: a

    Durante esta actividad el problema tiene las siguientes características:

    • Asignación del problema:

    El problema lo tiene siempre asignado el resolutor (proveedor). Si se trata de un problema multidisciplinar lo tendrá siempre el resolutor sobre el que recae el mayor peso de la resolución del problema.

    • Escalar del problema

    Un resolutor puede escalar sin necesidad de escalar previamente al RGP el problema a otro resolutor. Se deberá realizar el cambio de CI necesario para que esté alineado con el resolutor que lo está investigando, el que recibe, que revise.

    • Actualización del problema.

    Todos aquéllos que participen en el problema deben dejar constancia de los avances. Lo puede hacer tanto el resolutor que lo tiene asignado, como el RGP, como otros resolutores (de haberlos) o el GP.

    El GP se demandará actualizar con una periodicidad mínima mensual, el estado de los problemas, siendo de obligado cumplimiento para todos los resolutores.

    En caso de que haya algún bloqueo, el proveedor lo elevará al RGP deberá actuar para ayudar a superarlo, pudiéndose apoyar en el GP.

    • Documentación de soluciones temporales

    Se hallan soluciones temporales se documentarán y se asociarán al problema. Un problema debería al menos tener una solución temporal y a medida que se avanza en el análisis es posible se mejore en la calidad de

    los workarounds

    las soluciones temporales disponibles.

  • Documentará, si aplica, los motivos por los que cree que es necesario escalar a un proveedor distinto.
  • Documentará, de hallarse, la causa raíz del problema.
  • Salida:
    • Problema analizado con/sin workauround/s y sin causa raíz identificada.
      • Se Escala al RGP
      • Estado "Abierta"
      • Va a Actividad 6. Evaluar investigación
    • Error conocido.
      • Si el problema se resuelve como "Mejora", es decir hay que hacer una evolución de la aplicación o plataforma:
        • Se Escala al RGP
        • Estado "Abierta"
        • Va a subproceso de Resolución,  "Evaluar la propuesta de resolución"
      • Si el problema puede se resuelve como si fuese una "incidencia":
        • Estado "Abierta"
        • Va a subproceso de Resolución, "Resolver"
     Evaluar la investigación
    • Rol: RGP
    • Entrada:
      • Problema analizado con/sin workauround/s y sin causa raíz identificada
    • Acciones:
      • El RGP debe determinar qué hacer con el problema. Puede que decida que no se avance más en él, o se deba continuar con el análisis, ya sea por el proveedor que hasta ahora ha estado trabajando sobre el problema o se ha determinado que la causa raíz está en otro CI que no es de su responsabilidad.
    • Salida:
      • Si se decide no continuar con la investigación del problema:
        • Se Suspende.
        • Estado "Suspendida". Puede ocurrir que a futuro dicho problema se recupere.
      • Si se decide continuar con la investigación del problema:
        • Si continúa investigando el mismo proveedor
          • Se Escala al proveedor
          • Estado "Abierta"
          • Va a subproceso Investigación y el proveedor deberá dedicar esfuerzos y recursos a la investigación.
        • Si se determina cambiar la responsabilidad del problema
          • Se Cambia CI (se cambia la responsabilidad del RGP)
          • El nuevo RGP Escala al proveedor.
          • Estado "Abierta"
          • Va a subproceso Investigación y el nuevo proveedor deberá dedicar esfuerzos y recursos a la investigación.

    Resolución

    Evaluar la propuesta de resolución
    • Rol: RGP
    • Entrada:
      • Problema investigado. Es error conocido.
    • Acciones
      • Decide si es viable la resolución del problema: el coste frente al beneficio de abordar la resolución de un problema determinará esta decisión por parte del RGP.
    • Salida:
      • Si decide que no es viable la resolución:
        • Se Suspende.
        • Estado "Suspendida". Puede ocurrir que a futuro dicho problema se recupere.
      • Si decide que es viable la resolución:
        • Va a  "Determinar resolución"
    Determinar resolución
    • Rol: Proveedor o RGP
    • Entrada:
      • Problema con resolución viable.
    • Acciones
      • Resolver el problema.
    • Salida:
      • Si el problema necesita para ser resuelto en Gestión de Cambios (Necesita de una versión de JIRA, o de una RFP o PL de sistemas):
        • Se envía mediante integración a las herramientas de Gestión de Cambios (JIRA/FARO)
        • Estado "Pdte. Implantar"
        • Una vez se cierra el flujo de Cambios
          • Estado "Pdte. Confirmar cierre"
          • Va a "Revisar resolución" 
      • Si no requiere ningún tipo de cambio, se resuelve el Problema y va a "Revisar resolución"
    Revisar resolución
    • Rol: RGP
    • Entrada:
      • Problema resuelto pendiente de confirmar el cierre.
    • Acciones:
      • Determinar si está conforme con la resolución.
    • Salida:
      • Problema cerrado con conformidad del RGP.
        • Estado "Cerrado". Fin del proceso.
      • Problema no resuelto (no conformidad del RGP).
        • Estado "Abierto". El RGP debe determinar qué hacer de nuevo con el problema: suspender, volver a investigar, volver a resolver.

    Seguimiento

    Comité de Problemas

    Los aspectos de seguimiento y control de problemas serán revisados en las reuniones de Comité de Problemas. 
    Organización:
    Los comités de problemas los convocará el RGP y/o GP en función del listado de problemas vigente. 
    Agenda:
    En estas reuniones se supervisan los diferentes problemas detectados desde la última reunión así como otros ya revisados pero que aún no hayan sido resueltos. En estos últimos casos se evalúa el impacto en los servicios y la urgencia de tratamiento, y se estudia la necesidad de realizar una reclasificación y reasignación de recursos, u otro tipo de actuación, con el objetivo de obtener una solución acorde al caso. Del mismo modo, serán tratados los errores conocidos, en particular en lo referente a las soluciones definitivas propuestas, lanzamiento de Cambios y/o soluciones temporales aportadas, con objeto de mantener informados a los distintos grupos de interés y tomar aquellas decisiones o actuaciones que se han de realizar y que se consideren oportunas. 
    Acciones tras la reunión:
    A la finalización de esta actividad el Gestor de Problemas actualizará o registrará los problemas que hayan sido tratados y los resultados o conclusiones adoptadas. También serán reflejadas las reasignaciones de prioridad u otro tipo de actuaciones que se hayan determinado en el transcurso de la reunión mantenida por las distintas Áreas. Asimismo, serán comunicados a las partes implicadas aquellos aspectos que le sean de interés o aplicables 

    Indicadores
    El Gestor de Problemas
    • Causa subyacente del problema

    El resolutor deberá documentar la causa subyacente de hallarse. No hay una forma definida: puede ser un comentario, un documento anexado.

    • Error conocido

    Un problema con al menos una solución temporal y con la causa subyacente identificada, pasa a ser un error conocido. Se puede determinar que este problema no deba resolverse de manera definitiva. Los errores conocidos de estas características quedarán fuera de las revisiones periódicas de problemas, en estado suspendido, pero se evaluará si deben resolverse de manera definitiva, por ejemplo, porque el volumen de incidencias repetitivas así lo indique.


    Resolver

     

    Un vez identificada la causa subyacente del problema, el resolutor podrá resolverlo, con o sin Gestión de Cambios de la misma manera que se resuelve una incidencia o una petición.

    Cada resolutor acordará con el RGP la mejor manera de ejecutar la resolución: por ejemplo si es necesario una autorización expresa o no o que deba resolverlo el RGP (realizar la acción de resolver en la herramienta).

    El problema una vez se resuelve se asigna al RGP que debe aceptar de manera expresa el cierre. Si este no se efectúa se cierra automáticamente a los 7 días.


    Cancelar


    El RGP dispondrá de la opción de cancelar un problema. Dicha opción está reservada para casos muy concretos, como pueden ser problemas de cierta antigüedad que con la evolución de los productos ya no tenga sentido mantenerlos. Las cancelaciones siempre deberán tener un registro de justificación.



    Cambiar prioridad


    El RGP podrá establecer la prioridad que estime necesaria a los problemas para maneja.


    Seguimiento e indicadores

    Seguimiento:

    • El proceso tendrá la menos una reunión mensual de coordinación para revisar la salud del proceso e identificar mejoras a éste. A estas reuniones asistirán los responsables de operación de las áreas de sistemas y proyectos, el GP y el responsable de mejora de procesos de SSHH.
    • Así mismo se mantendrán reuniones operativas con cada uno de los resolutores para revisar el avance de los problemas asignados. A dichas reuniones asistirá el GP, con los responsables de operación de las áreas de la STIC, RGPs y sus proveedores de servicio.
    • Dentro del la resolución concreta de una problema, podrá haber tantas reuniones técnicas como sean necesarias.
    • El GP deberá garantizar que los problemas vigentes tengan actualizaciones, de no ser así, lo elevará al RGP entendiéndose que se trata de un problema que debería estar suspendido.
    • En el MTI están publicados varios tableros para facilitar el seguimiento de los problemas a todos los interesados.


    Indicadores:

    El Gestor de Problemas podrá elaborará informes de gestión del proceso. Entre las métricas a obtener en dichos informes se podrá encontrar a modo de ejemplo:

    • Tasa EC = nª EC/N º de problemas en un periodo
    • Tasa problemas suspendidos = nº problemas suspendidos/Nº de problemas de un periodo
    • Tiempo medio de resolución de un problema
    Adicionalmente el Gestor de Problemas reportará con la periodicidad que se estime oportuna, o a solicitud del algún rol del proceso, informes de seguimiento de problemas particulares, listado de problemas u otra información del proceso que se considere necesaria.

    Actas

    Formación

     

    View file
    nameGuia Gestion Problemas 2024.pdf
    height250






    Ayuda relacionada:

    • Enlace
    • Enlace


    Propiedades de página
    hiddentrue
    DescripciónBuscar y desarrollar soluciones permanentes que impidan que vuelvan a producirse determinadas incidencias provocadas por esa causa.
    CategoríaServicios
    SubcategoríaOperación
    Modificado

    Modifieddate

    Divbox
    classir-arriba


    HTML
    <script>
    /*------*/
    /* JS para botón para Subir al inicio de la página (fixed esquina derecha abajo)*/
    /*------*/
    $(document).ready(function(){
    	$('.ir-arriba').click(function(){
    		$('body, html').animate({
    			scrollTop: '0px'
    		}, 300);
    	});
    
    	$(window).scroll(function(){
    		if( $(this).scrollTop() > 0 ){
    			$('.ir-arriba').slideDown(300);
    		} else {
    			$('.ir-arriba').slideUp(300);
    		}
    	});
    });
    </script>

    Actas

    Actas gestión de problemas