Modelos y registros · ISO 20000 · Apartado 8.6.3
Registro de problemas y errores conocidos ISO 20000-1
Lo que se hace con la causa de las incidencias, no con su síntoma: encontrarla, documentar cómo esquivarla mientras tanto y eliminarla para que no vuelva.
En una frase
El registro de problemas nace del análisis de las incidencias, anota la clasificación, la prioridad, la causa raíz, la solución temporal y la acción definitiva, y registra como error conocido lo que tiene causa identificada pero aún no se ha resuelto, porque el apartado 8.6.3 de ISO/IEC 20000-1 exige analizar los datos de incidencias para detectar problemas, registrarlos, identificar sus causas y hacer el seguimiento de la eficacia de su resolución.
- Dónde lo pide la norma
- ISO 20000 · Apartado 8.6.3 Los apartados se citan con la numeración de ISO/IEC 20000-1:2018, la edición vigente y la misma que usa la Academia.
- Tipo de información
- Registro obligatorio Registro de problemas y errores conocidos (8.6.3)
- Quién lo rellena
- Gestor de problemas Con los grupos técnicos de cada servicio
- Cuándo
- Tras una incidencia grave o una tendencia También de forma proactiva, a partir del análisis periódico de incidencias
- Cuánto se conserva
- Lo fija la organización La norma pide controlar la conservación y la eliminación de la información documentada (7.5.3) sin fijar plazos. Lo habitual es cubrir al menos el ciclo de certificación de tres años, o el plazo del contrato con el cliente si es mayor.
Qué pide la norma
Lo que exige ISO 20000 y lo que deja a tu criterio
La organización analiza los datos y las tendencias de las incidencias para identificar problemas. Los problemas se registran, clasifican, priorizan, escalan si es necesario y se resuelven cuando es posible.
Se investiga la causa raíz y se determinan acciones para reducir o evitar las incidencias. Si la solución exige un cambio, se tramita por la gestión del cambio. Los problemas con causa identificada pero sin solución definitiva se registran como errores conocidos, con la información para reducir su impacto.
La eficacia de la resolución de problemas se sigue, se revisa y se informa. Es el proceso que conecta la operación diaria con la mejora continua del capítulo 10.
Estructura
Campos que debe tener el modelo
- Número, fecha y origen: incidencia grave, tendencia, proactivo
- Incidencias vinculadas
- Servicio y elementos de configuración afectados
- Prioridad
- Análisis de causa raíz y método
- Solución temporal publicada para el centro de servicio
- Error conocido: sí o no
- Acción definitiva y solicitud de cambio asociada
- Seguimiento de la eficacia y cierre
Ejemplo
Ejemplo: caducidad de certificados
Empresa, personas y cifras inventadas: el ejemplo solo enseña cómo queda un registro bien cumplimentado.
| Campo | Contenido |
|---|---|
| Problema | PRB-26-021 · 16 de abril de 2026 · origen: incidencia grave INC-26-0318 |
| Incidencias vinculadas | INC-26-0318 y otras 2 en 2025 por certificados caducados en otros servicios |
| Causa raíz | Cinco porqués: los certificados se renuevan a demanda y no hay inventario con fechas de caducidad |
| Solución temporal | Comprobación semanal manual de los certificados críticos |
| Error conocido | Sí, hasta implantar la acción definitiva |
| Acción definitiva | Inventario de certificados como elementos de configuración con aviso a 30 días · CHG-26-077 |
| Eficacia | Revisión a los 6 meses: 0 incidencias por caducidad de certificados · cerrado |
En la auditoría
Errores que suelen señalar los auditores
- Problemas cerrados al aplicar la solución temporal.
- No se analizan tendencias de incidencias: solo se abren problemas tras una caída grave.
- Errores conocidos que el centro de servicio no puede consultar.
- Acciones definitivas aplicadas sin pasar por la gestión del cambio.
- Sin seguimiento de la eficacia tras el cierre.
En Kimobox
Cómo se lleva este registro en Kimobox
- 1Las incidencias recurrentes se vinculan a un registro de problema con su análisis de causa raíz.
- 2Incidencias y problemas quedan vinculados y su causa raíz, documentada y trazable.
- 3La acción definitiva se asigna con responsable, fecha y aviso de retraso, y su eficacia se verifica más tarde.
Preguntas frecuentes
Lo que nos preguntan antes de empezar
¿Qué es un error conocido?
Un problema cuya causa raíz se conoce, o del que existe una forma de reducir o eliminar su impacto, pero que aún no tiene solución definitiva. Se registra para que el centro de servicio resuelva antes las incidencias que provoca.
¿Problema e incidencia son lo mismo?
No. La incidencia es el síntoma: el servicio falla. El problema es la causa, conocida o no, de una o varias incidencias. La gestión de incidencias restablece el servicio; la de problemas evita que vuelva a fallar.
Lleva los registros de ISO 20000 sin plantillas sueltas
Te enseñamos el módulo funcionando con datos parecidos a los tuyos.
Sigue explorando
Páginas relacionadas
Entrega y soporte del servicio
Este bloque cubre la operación diaria: la resolución de incidencias, la gestión de problemas y la atención…
Modelo de catálogo de servicios TI según ISO 20000-1
Qué debe incluir el catálogo de servicios que pide ISO/IEC 20000-1: descripción, resultados previstos…
Modelo de acuerdo de nivel de servicio (SLA) ISO 20000-1
Qué debe recoger un SLA según ISO/IEC 20000-1 (8.3.3): servicios, objetivos de nivel, límites de carga…
Modelo de informe de nivel de servicio ISO 20000-1
Qué debe contener el informe de servicio que pide ISO/IEC 20000-1: cumplimiento de SLA, carga, incidencias…
Fuentes
De dónde sale cada dato
Referencias al texto oficial vigente. Si una norma se revisa, esta página se actualiza y la fecha de revisión lo refleja.
- ISO/IEC 20000-1:2018 — Gestión del servicio. Requisitos del sistema de gestión del servicio ISO/IEC · Septiembre de 2018