Un problema es la causa, todavía desconocida o aún no corregida, de uno o varios incidentes. La Gestión de problemas de Portail ZAPP sirve para buscarla, documentarla, ofrecer una solución alternativa a los agentes mientras tanto y, después, hacerla corregir mediante un cambio. Las pantallas están abiertas a los agentes del Service Desk, a los Problem Managers, a los administradores y, para consultar, crear y vincular un problema, a los Major Incident Managers.
La lista de problemas
La entrada Lista de problemas del menú abre la página Problemas: número, título, estado, modo, impacto, frecuencia y fecha de identificación. Una insignia señala los problemas Mayor y los Errores conocidos. Filtra por texto (número o título), por Estado o por Modo; la casilla Solo abiertos está marcada por defecto. La lista se limita a los 200 problemas más recientes: afina la búsqueda si un mensaje lo indica.
Crear un problema
Hay tres maneras de crear un problema:
- Nuevo problema, desde la lista;
- Crear un problema, desde la ficha de un ticket de incidente (abierto o resuelto: un problema se identifica a menudo después). El formulario lo indica («Problema creado a partir del incidente») y el ticket se vincula al problema al guardar;
- Crear un problema proactivo, desde una alerta de tendencia (ver más abajo).
El formulario agrupa:
- Identificación: un Título (el síntoma en una frase) y una Descripción (síntomas, servicios y usuarios afectados, desde cuándo);
- Causa y solución alternativa: la Causa raíz y la Solución alternativa, a menudo vacías al principio;
- Calificación: el Modo (Reactivo, surgido de incidentes; Proactivo, anticipado por el análisis de tendencias), el Impacto (1–5), la Frecuencia (1–5) y la casilla Problema mayor;
- Responsable: el Responsable del problema.
Los Problem Managers reciben un correo electrónico por cada problema nuevo.
Hacer avanzar el problema
El estado cambia con los botones de la ficha:
| Estado | Qué significa | Siguientes pasos posibles |
|---|---|---|
| Identificado | El problema está registrado | Iniciar la investigación, Cancelar el problema |
| Investigación | Se busca la causa | Declarar error conocido, cambio vinculado, Marcar como resuelto, cancelación |
| Error conocido | La causa se conoce, la corrección aún no está hecha | cambio vinculado, Marcar como resuelto, Reanudar la investigación |
| Cambio planificado | Hay un cambio correctivo vinculado | Marcar como resuelto, vuelta a error conocido o a investigación |
| Resuelto | La corrección está hecha | Cerrar, Reabrir si los incidentes vuelven |
| Cerrado, Cancelado | El expediente ha terminado | — |
Se aplican algunas reglas, sea cual sea la pantalla:
- la Causa raíz debe estar redactada antes de pasar a Error conocido o a Resuelto; la ficha lo recuerda mientras esté vacía;
- Cambio planificado no se elige a mano: el problema pasa a ese estado cuando vinculas un cambio (ver más abajo);
- una cancelación exige un motivo (duplicado, falsa alarma…);
- Cerrar y Cancelar el problema están reservados a los Problem Managers y a los administradores;
- para todo lo demás, pueden hacer avanzar el problema su autor, su responsable, los Problem Managers y los administradores.
Cuando el problema se resuelve, su autor y su responsable reciben un correo electrónico.
Vincular los incidentes
La tarjeta Incidentes vinculados agrupa los tickets que presentan el mismo síntoma. Búscalos por número o título en Vincular tickets, márcalos y haz clic en Vincular la selección. El vínculo aparece también en cada ticket. Un ticket que no tienes derecho a ver se muestra sin su título («ticket fuera de tu alcance»).
Desde la ficha de un ticket de incidente, Vincular a un problema propone los problemas abiertos y aquellos a los que el ticket ya está vinculado.
Esta tarjeta solo existe si el módulo Service Desk está instalado.
Analizar la causa raíz
El botón Analizar de la tarjeta Análisis de causa raíz abre dos herramientas:
- 5 porqués: parte del síntoma y pregunta «¿por qué?» en cada respuesta, hasta llegar a la causa sobre la que actuar. No hace falta rellenar las cinco líneas si la causa aparece antes;
- Diagrama de Ishikawa: enumera las causas posibles por familia (Métodos, Hardware e infraestructura, Software y datos, Personas, Medición y supervisión, Entorno), una por línea. No todas las familias son necesariamente pertinentes.
El análisis no rellena la causa raíz: una vez encontrada la causa, redáctala en el campo Causa raíz del problema (botón Editar).
Calificar un problema mayor
Cuando el impacto y la frecuencia sitúan el problema en la zona alta de la matriz, la ficha lo propone como mayor; Calificar como mayor lo confirma. Un problema mayor exige una Revisión posterior al cierre (Desviaciones observadas, Lecciones aprendidas) antes de cerrarse: la tarjeta de revisión se abre cuando el problema está Resuelto.
Error conocido y KEDB
Cuando la causa se conoce pero aún no está corregida, Declarar error conocido pasa el problema a Error conocido y publica un artículo en la KEDB, la base de errores conocidos guardada en la base de conocimientos: síntoma, causa raíz, solución alternativa y enlace al problema. Los Problem Managers, el autor y el responsable reciben un aviso de la primera publicación.
- Actualizar el artículo vuelve a publicar el artículo tras modificar la causa o la solución alternativa;
- si la KEDB no está configurada, la ficha lo indica: un administrador debe elegir la base de conocimientos en los Ajustes de problemas. El error conocido se registra de todos modos, y el artículo se publica más tarde desde la ficha.
En la ficha de un ticket de incidente, el recuadro Errores conocidos propone a los agentes los artículos de la KEDB cercanos al ticket, con su solución alternativa.
Corregir mediante un cambio
La tarjeta Cambio correctivo vincula el problema con el cambio que corrige su causa (módulo Gestión de cambios):
- Vincular un cambio existente: búscalo por número o título y haz clic en Vincular;
- Crear un cambio: se crea un borrador de cambio, prellenado con el título y la causa raíz, que abres para completarlo.
El problema pasa entonces a Cambio planificado. Cuando ese cambio se cierra con éxito, el Problem Manager y el responsable reciben un aviso, y la ficha invita a comprobar que los incidentes ya no se repiten antes de Marcar como resuelto: un problema nunca se resuelve automáticamente. Si el cambio se abandona, Quitar el vínculo (cambio abandonado) devuelve el problema a error conocido o a investigación.
Estas acciones dependen de tus derechos en el módulo de cambios. Si ese módulo no está instalado, la tarjeta solo muestra el número guardado.
Tendencias
La página Tendencias detecta los síntomas que se repiten: cuando el número de incidentes de una misma Categoría o de un mismo CI supera el umbral en el periodo (por defecto 5 incidentes en 7 días, ajustable por un administrador), aparece una alerta en Alertas por tratar y los Problem Managers reciben un aviso.
- Crear un problema proactivo abre un problema en modo Proactivo a partir de la alerta;
- Descartar archiva la alerta sin seguimiento.
Una alerta también puede cerrarse sola: Cubierta cuando un problema ya cubre el síntoma, Remitida cuando los incidentes cesan. Las alertas tratadas siguen visibles en Alertas tratadas. El gráfico muestra los incidentes en 30 o 90 días. Sin el módulo Service Desk no se calcula ninguna tendencia.
Panel y Kanban
- Panel de problemas: indicadores del periodo, matriz de priorización impacto × frecuencia (haz clic en una casilla para listar sus problemas), problemas propuestos como mayores, errores conocidos sin solución alternativa o no publicados;
- Kanban de problemas: los problemas por estado. Arrastra una tarjeta a una columna resaltada para aplicar la transición, con las mismas reglas que en la ficha. El paso a Cambio planificado se hace desde la ficha, vinculando el cambio. El Kanban requiere el módulo Cuadrículas de datos; sin él, usa la lista.
El asistente de IA
Cuando hay un proveedor de IA configurado, tres botones ayudan al análisis:
- Sugerir la causa probable, junto a la causa raíz, a partir del síntoma y de los incidentes vinculados;
- Redacción asistida, junto a la solución alternativa;
- Proponer los 5 porqués, en la pantalla de análisis.
La propuesta aparece en un recuadro («Propuesta del asistente: revísala antes de aplicarla»): Aplicar (o Reemplazar los porqués) la copia en el campo, Descartar la cierra. No se guarda nada hasta que haces clic en Guardar.
Cuando la IA está desactivada, estos botones no aparecen; todo lo demás de la gestión de problemas funciona. El recuadro Errores conocidos de los tickets sigue proponiendo artículos, mediante una búsqueda en las palabras del ticket.
Ver también
- «Ajustar la gestión de problemas»: base de la KEDB y umbral de tendencias (administradores).
- «Ajustar el asistente de IA de los problemas»: las instrucciones del asistente de IA (administradores).