---
id: KB-IC-009
url: https://app.codecontract.io/ayuda/informes-y-calidad/analizar-por-que-paso-algo
idioma: es
categoria: informes-y-calidad
subcategoria: calidad
audiencia: usuario
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [en]
relacionados: [KB-IC-002, KB-IC-007]
citadoPor: [KB-IU-008, KB-IC-014, KB-IC-019]
---

# Analizar por qué pasó algo

_La diferencia entre corregir un caso y corregir la causa._

**Responde a:** análisis de causa raíz · por qué se repite el mismo fallo · acción correctiva eficaz · investigar una incidencia

Un fallo se corrige en minutos: se rehace el documento, se llama al proveedor, se repite el envío. Lo que cuesta es que no vuelva, y para eso hay que saber por qué pasó — que casi nunca es lo que parece a primera vista.

## Bajar un nivel, tres veces

La técnica es simple: preguntar «¿y por qué?» tres veces sobre la respuesta anterior. Casi siempre en la tercera aparece algo que se puede cambiar, y en la primera solo aparece una persona.

| Nivel | Respuesta típica | Qué se puede hacer con ella |
| --- | --- | --- |
| Primera | «Se le olvidó a alguien» | Nada. Es un nombre, no una causa |
| Segunda | «No había forma de saber que tocaba» | Ya se puede trabajar |
| Tercera | «Ese documento no tenía caducidad marcada» | Esto sí se arregla, y para todos |

> [!IMPORTANT]
> Si la conclusión de un análisis es el nombre de una persona, el análisis no ha terminado. Las personas se equivocan; lo que hay que buscar es qué permitió que ese error llegara a producir consecuencias sin que nada lo parara antes.

## Cómo se comprueba que la corrección funcionó

1. **Definid qué tendría que dejar de pasar** — En una frase concreta y medible, no «mejorar el control».
2. **Poned una fecha para mirarlo** — Tres meses suele bastar para saber si se repite.
3. **Cerrad solo entonces** — Cerrar el día que se aplica la corrección es cerrar sin saber si funcionó.

> [!WARNING]
> Cuidado con la corrección que consiste en pedirle a alguien que tenga más cuidado. No es una acción correctiva: es la misma situación con una persona más presionada, y falla igual en cuanto haya un día malo.

> [!NOTE]
> Los análisis que sirven suelen acabar en un cambio pequeño y aburrido: marcar una caducidad, cambiar el título de una solicitud, asignar un responsable. Los que acaban en un procedimiento nuevo de diez páginas rara vez cambian nada.

**¿Hay que hacerlo con todas las incidencias?**

No. Con las que tienen consecuencias y con las que se repiten.

**¿Quién debería hacerlo?**

Alguien que no esté implicado directamente, si es posible.

**¿Y si la causa está fuera de nuestra empresa?**

Se documenta igual: la acción entonces es sobre la relación con ese tercero.

## Ejemplos

**Una empresa concluye que un seguro venció «porque se le pasó a la responsable de compras».**

- Baja dos niveles más: ese tipo de documento no tenía caducidad marcada

→ Corrige la configuración y el problema deja de poder repetirse con nadie, no solo con ella.

**Pasa algo y el análisis se hace de memoria dos semanas después.**

- Consulta la secuencia registrada con fechas
- Identifica en qué paso concreto falló
- Registra la causa y la acción con fecha de revisión

→ El análisis parte de hechos y la acción se puede comprobar meses después.

**Se busca un culpable en lugar de una causa.**

- Mira qué paso del proceso lo permitió

→ La acción corrige el proceso y no a una persona.

**Se identifica la causa y no se cambia nada.**

- Registra la acción con responsable y fecha

→ El análisis produce un cambio.

**El mismo problema vuelve a los seis meses.**

- Consulta si ya había pasado antes

→ La causa se ataca en lugar del síntoma.

**El análisis se queda en un documento que nadie abre.**

- Regístralo en el expediente del incidente

→ Se encuentra cuando vuelve a hacer falta.