La gestión de incidencias devuelve el servicio cuanto antes; la gestión de problemas busca la causa de fondo para que la avería no vuelva. Funcionan cuando cada incidencia queda enlazada a su problema, al cambio que la provocó, al equipo afectado y al artículo que la resolvió. Dokuflex une esos siete registros con 13 enlaces y 30 listados.
Qué diferencia una incidencia de un problema
Una incidencia es algo que alguien sufre ahora; un problema es lo que la causa. «El ERP no abre en contabilidad» es una incidencia. «El disco del servidor del ERP se llena cada fin de mes» es el problema que hay detrás de esa incidencia y de las que vendrán.
La distinción importa porque cada una se cierra por un motivo distinto. La incidencia se cierra cuando el usuario vuelve a trabajar, aunque sea con un parche. El problema se cierra cuando la causa desaparece, normalmente con un cambio. Mezclarlas lleva a uno de dos errores: tener a todo el equipo investigando mientras la gente no puede trabajar, o cerrar la misma incidencia una y otra vez sin que nadie mire por qué vuelve.
| Incidencia | Problema | |
|---|---|---|
| Qué es | Una interrupción o petición concreta | La causa de una o varias incidencias |
| Objetivo | Que el usuario vuelva a trabajar | Que no vuelva a pasar |
| Se cierra con | Una solución, aunque sea temporal | Un cambio que elimina la causa, o un error conocido documentado |
| Quién lo mira | El técnico de guardia | Quien conoce el sistema afectado |
Siete señales de que tu soporte trabaja en islas
El soporte trabaja en islas cuando cada cosa está bien registrada en su sitio pero nada apunta a nada. Si reconoces tres o más de estas señales, el cuello de botella no es el equipo, es cómo se relaciona la información:
- La misma avería abierta diez veces por diez personas, y cada técnico la trata como nueva.
- Copiar y pegar los datos de la incidencia al informe de la reunión y luego a la wiki.
- Nadie sabe qué se tocó en el servidor la semana antes de que empezara a fallar.
- La solución está en la cabeza de quien la aplicó, y cuando está de vacaciones se vuelve a investigar desde cero.
- La garantía caduca sin que nadie se entere hasta que el equipo se estropea.
- Se reinicia un equipo sin saber qué otros dependen de él.
- A fin de mes hay que juntar hojas para saber cómo va el soporte.
Ninguna de estas señales se arregla con más disciplina al rellenar. Se arregla cuando los registros se conocen entre sí: cuando abrir una incidencia te enseña el problema, el cambio y el equipo, y abrir el equipo te enseña todas sus incidencias.
Los siete registros de un servicio de TI ordenado
Un servicio de TI ordenado necesita siete registros, y cada uno responde a una pregunta distinta. No hace falta implantarlos todos a la vez, pero sí que, cuando existan, apunten unos a otros:
| Registro | Pregunta que responde | Debe apuntar a |
|---|---|---|
| Peticiones e incidencias | ¿Qué le pasa a quién, ahora? | Equipo afectado, problema, cambio causante, artículo con la solución, incidencia principal |
| Problemas | ¿Por qué vuelve a pasar? | Incidencias de origen, equipo, artículo con la solución temporal |
| Cambios | ¿Qué se ha tocado, quién lo aprobó y cuándo? | Problema que resuelve, equipo que modifica |
| Revisiones posincidente | ¿Qué aprendimos de la caída grave? | Incidencia de origen, equipo, problemas que se abren |
| Base de conocimiento | ¿Cómo se resolvió la última vez? | Incidencias que resolvió, problemas que la citan |
| Inventario de activos de TI | ¿Qué tenemos, en qué estado y de qué depende? | Otros equipos de los que depende |
| Solicitudes de acceso | ¿Quién tiene acceso a qué y por qué? | Incidencia de referencia, equipo o sistema |
Fíjate en la columna de la derecha: casi todo apunta al inventario. El equipo es el punto donde se cruzan las incidencias, los problemas, los cambios y los accesos, y por eso su ficha es la más útil cuando algo falla. Es la misma idea que en un maestro de clientes y proveedores: un registro común al que todos los demás se refieren.
Hay un octavo tipo de incidencia que conviene dejar fuera: la de ciberseguridad. Tiene plazos legales de notificación y su contenido es confidencial, así que necesita un circuito propio con acceso restringido. Lo explicamos en cómo notificar un incidente NIS2 en 24 y 72 horas.
De la incidencia a la causa raíz, paso a paso
El análisis de causa raíz en una pyme no necesita una metodología pesada: necesita que cada paso deje rastro en el registro siguiente. Este es el recorrido completo:
- Agrupa las repetidas. Cuando llegan cinco incidencias por lo mismo, elige una como principal y enlaza las demás a ella. Se trabaja una, y quien abrió las otras ve en qué punto está.
- Señala el equipo afectado. Sin este dato no hay forma de ver más tarde que el mismo servidor acumula incidencias.
- Abre un problema desde la incidencia. El problema nace con el equipo y la incidencia de origen ya puestos; no hay que volver a escribirlos.
- Mira los cambios recientes sobre ese equipo. Una parte importante de las averías empieza con un cambio: una actualización, una regla de cortafuegos, una migración. Si la incidencia apunta al cambio que la provocó, el patrón aparece solo.
- Documenta una solución temporal. Mientras se investiga, el técnico que recibe la siguiente incidencia debe ver cómo salir del paso. Un problema con solución temporal y causa identificada es lo que se llama un error conocido.
- Cierra con un cambio. La corrección definitiva pasa por el circuito de aprobación de cambios y queda enlazada al problema que resuelve.
- Escribe el artículo. Lo aprendido va a la base de conocimiento, enlazado a las incidencias que resolvió. La próxima vez, el técnico lo encuentra desde la propia incidencia.
Si la caída fue grave, añade una revisión posincidente entre los pasos 3 y 6: qué pasó, cuánto duró, cómo se detectó y qué se hará distinto, sin buscar culpables. De ella suelen salir uno o varios problemas. La lógica es la misma que la de las no conformidades y acciones correctivas de ISO 9001: corregir el efecto no basta si la causa sigue ahí.
Inventario de activos de TI: garantías, mantenimientos y dependencias
Un inventario de activos de TI útil no es una lista de números de serie: es la ficha a la que se asoma todo lo demás. Para que sirva en el día a día necesita tres cosas que una hoja de cálculo no da:
Historia en la ficha
Al abrir el servidor del ERP debes ver sus incidencias, sus problemas, los cambios que se le han hecho, las revisiones en las que aparece y quién ha pedido acceso a él. Es lo primero que se consulta cuando vuelve a fallar.
Avisos antes de que sea tarde
Una fecha de fin de garantía en una celda no avisa a nadie. Lo que funciona es que el sistema cree una tarea a quien lleva el equipo con margen suficiente para renovar o planificar la sustitución, y que no la repita cada día.
Dependencias sencillas
Basta con que cada equipo diga de cuál depende: la impresora del servidor de archivos, los puestos del router. Con eso, antes de reiniciar el router ves la lista de lo que cuelga de él. No hace falta un mapa gráfico para evitar el susto más habitual.
Marca además la criticidad de cada activo. Cuando entran tres incidencias a la vez, la que afecta a un equipo crítico pasa delante, y el listado de críticos es la primera lista que se revisa al planificar mantenimientos.
Hoja de cálculo, bandeja de correo o herramienta ITSM
La elección depende menos del tamaño del equipo que de cuántas relaciones necesitas ver. Así se comparan las tres opciones habituales en una pyme:
| Opción | Bien para | Se queda corta en |
|---|---|---|
| Bandeja de correo compartida | Recibir peticiones sin cambiar nada | Estado, responsable, duplicados y cualquier cifra |
| Hoja de cálculo | Un inventario o una lista de incidencias con pocos técnicos | Relaciones entre hojas, avisos, historial de cambios, varias personas editando |
| Suite ITSM grande | Departamentos de TI con niveles de soporte y acuerdos de servicio formales | Coste, implantación y configuración para una pyme |
| Plataforma de procesos con los registros enlazados | Pymes que necesitan las relaciones sin la complejidad | Temporizadores de nivel de servicio con escalado por niveles y mapas gráficos de dependencias |
Si estás valorando el coste de dar el salto, en cuánto cuesta automatizar procesos desglosamos qué partidas pesan de verdad en una pyme.
Cómo lo resuelve Dokuflex: la suite Servicio de TI
Dokuflex, plataforma BPM low-code con IA, reúne los siete registros de esta guía en un solo módulo gratuito, Servicio de TI, con su propio grupo en el menú. Las plantillas sueltas son islas; aquí los procesos se conocen entre sí:
- Siete procesos, 13 enlaces y 30 listados: peticiones e incidencias, problemas, cambios, revisiones posincidente, base de conocimiento, activos de TI y solicitudes de acceso. Cada relación se ve y se abre desde los dos lados: la incidencia enseña su problema, y el problema enseña todas las incidencias que le apuntan.
- Cuatro botones de «crear desde»: de una incidencia salen con un clic el problema, la revisión posincidente o el artículo de conocimiento, y de una revisión, el problema. Nacen con los datos ya copiados y enlazados a su origen.
- Incidencia principal: las repetidas se agrupan en la que se trabaja.
- Inventario de activos de TI con criticidad, garantía y una lista sencilla de dependencias: cada activo dice de cuál depende y su ficha lista los que dependen de él.
- Tres alertas que crean una tarea: garantía que vence en 30 días y mantenimiento en 15 (como mucho una vez al mes por equipo), e incidencia fuera de plazo.
- Un panel del servicio: el cuadro de mando de incidencias trae un gráfico por cada uno de los otros seis procesos, además de gráficos por activo y por meses.
- Numeración legible: cada registro lleva el prefijo de su proceso (INC-0003, PRB-0001, RFC-0002), así que una referencia dice qué es antes de abrirla.
El módulo trae datos de ejemplo ya enlazados para que recorras el circuito el primer día, y como todo en Dokuflex se puede ampliar sin programar con la plataforma BPM low-code: añadir campos, cambiar estados o crear tus propios informes. Los incidentes de ciberseguridad quedan fuera de la suite a propósito, en su módulo NIS2 propio.
Crea una cuenta gratuita e instala «Servicio de TI» desde el catálogo de módulos. Si prefieres verlo aplicado a tu inventario y tus tipos de incidencia, pide una sesión de 20 minutos.
Preguntas frecuentes
¿Qué diferencia hay entre una incidencia y un problema de TI?
Una incidencia es una interrupción concreta que alguien sufre ahora: la impresora no imprime, el ERP va lento. Un problema es la causa de fondo de una o varias incidencias. La incidencia se cierra cuando el usuario vuelve a trabajar; el problema, cuando la causa se ha eliminado o, al menos, se ha documentado una solución temporal.
¿Cómo se hace un análisis de causa raíz de incidencias en una pyme?
Agrupa las incidencias repetidas en una principal, abre un problema que las enlace, revisa qué equipo afectan y qué cambios se hicieron en él antes del fallo, documenta una solución temporal mientras investigas y cierra el problema con el cambio que lo corrige. Lo que se aprende va a un artículo de la base de conocimiento.
¿Qué es una revisión posincidente?
Es el análisis que se hace después de una incidencia grave, sin buscar culpables: qué pasó, cuánto duró, cómo se detectó, qué funcionó y qué no. Su resultado son acciones concretas, y la más habitual es abrir un problema para eliminar la causa. En inglés se conoce como post mortem.
¿Sirve una hoja de cálculo para llevar el inventario de equipos informáticos?
Sirve para saber qué equipos tienes, pero no avisa de nada ni se relaciona con las incidencias. Si quieres que el inventario te ponga una tarea antes de que venza una garantía o toque un mantenimiento, y ver desde la ficha de un servidor todo lo que le ha pasado, necesitas que el inventario forme parte del mismo sistema que las incidencias.
¿Necesita una pyme una herramienta ITSM completa?
No siempre. Muchas pymes no necesitan temporizadores de acuerdo de nivel de servicio por niveles ni un mapa gráfico de dependencias, pero sí que incidencias, problemas, cambios, inventario y conocimiento estén enlazados. Una plataforma de procesos con esos registros unidos cubre ese mínimo sin el coste ni la implantación de una suite ITSM grande.
¿Los incidentes de ciberseguridad se gestionan igual que las incidencias de soporte?
No. Un incidente de ciberseguridad tiene plazos legales de notificación y su información es confidencial, así que conviene llevarlo en un circuito propio con acceso restringido. En Dokuflex es un módulo aparte, Incidentes de ciberseguridad NIS2, y no forma parte de la suite Servicio de TI.
Que cada incidencia sepa de dónde viene y cómo se resolvió
Crea tu cuenta gratis, instala «Servicio de TI» y recorre el circuito con los datos de ejemplo. O cuéntanos cómo trabaja tu soporte y te lo enseñamos aplicado a tu caso en 20 minutos.