Gestión por excepción: Por qué aspiro a tener dashboards vacíos

Existe una fantasía peligrosa en el mundo corporativo: el “Centro de Control”. Nos imaginamos una sala oscura llena de pantallas gigantes con gráficos en tiempo real, donde un gerente toma café y observa cómo se mueven las agujas del negocio cual controlador aéreo.

La realidad operativa es muy distinta. Nadie tiene tiempo para mirar pantallas. Si tienes que entrar a un dashboard proactivamente para enterarte de que hay un problema, ya llegaste tarde. El incendio ocurrió hace 4 horas y tú recién estás viendo el humo en el gráfico.

Como profesional enfocado en la eficiencia, he declarado la guerra a las “Vanity Metrics”. Mi objetivo como Business Engineer no es tener un dashboard lleno de información; es tener un sistema silencioso que solo me hable cuando algo se sale del plan.

Esto se llama Gestión por Excepción (un principio clásico de Fayol y Drucker): concentrar la atención directiva solo en los desvíos significativos respecto al plan, delegando el resto a procedimientos y sistemas.

El problema del modelo “Pull” (Ir a buscar)

La mayoría de las herramientas de Business Intelligence (PowerBI, Looker, Tableau) funcionan bajo un modelo “Pull”:

1. Tú te acuerdas de revisar (dependencia de la memoria humana).
2. Tú abres la herramienta y esperas que cargue (fricción).
3. Tú filtras los datos y buscas anomalías visualmente.
4. Tú interpretas si la línea subió o bajó.

Este proceso tiene un Punto Único de Falla (SPOF): TÚ. Si ese día tuviste reuniones todo el día, si se te olvidó revisar, o si simplemente el gráfico estaba muy cargado y no viste la caída, el problema (una fuga de presupuesto, un retraso en hormigonado) pasa desapercibido hasta el cierre de mes.

La solución: El modelo “Push” (Que te vengan a avisar)

Una vez que migramos los datos de Excel a una Base de Datos SQL (como vimos en Excel no es una base de datos: La frontera entre flexibilidad y anarquía ), ganamos la capacidad de interrogar a los datos automáticamente.

No necesitamos inteligencia artificial compleja. Necesitamos automatización determinista. La arquitectura es simple: en lugar de yo mirar el gráfico de “Gasto de Combustible” todos los días, un script en el servidor lo hace por mí.

La arquitectura del “Vigilante Silencioso”

Técnicamente, esto se implementa con Trabajos Programados (Cron Jobs) que ejecutan consultas SQL de validación.

Imagina un script que corre cada noche a las 23:00 PM y ejecuta esta lógica:

1
    -- Consulta de validación de consumo excesivo
2
    SELECT obra_id, consumo_litros
3
    FROM gastos_combustible
4
    WHERE fecha = CURRENT_DATE
5
    AND consumo_litros > (
6
        SELECT AVG(consumo_litros) * 1.20 -- Umbral del 20% sobre el promedio
7
        FROM gastos_combustible
8
        WHERE fecha > CURRENT_DATE - INTERVAL '30 days'
9
    );

• Si el resultado es 0 filas: El sistema no hace nada. Silencio absoluto. El negocio opera según lo previsto.
• Si hay resultados: El sistema dispara inmediatamente un Webhook a Slack, Teams, WhatsApp, o una notificación de aviso en nuestro sistema ERP que estamos construyendo, con los detalles.

Calibrar umbrales: empieza amplio, aprieta después

Ese 1.20 (20% sobre el promedio) que aparece en el SQL no es ley divina, es un punto de partida conservador. Los umbrales se calibran empíricamente:

1. Empieza amplio. Las primeras 2-4 semanas conviene un margen generoso (30-50% sobre el promedio histórico) para no perderte excepciones reales mientras aprendes la variabilidad natural del negocio.
2. Mide la tasa de aciertos. Lleva un registro: ¿de cada 10 alertas, cuántas eran reales? Si más de 3 son falsos positivos, el umbral está mal puesto.
3. Aprieta progresivamente. Con datos de un trimestre ya puedes bajar al rango operativo (10-20%). Es preferible perder una alerta amarilla a tener un celular que suena por todo.

Un umbral mal calibrado convierte al vigilante silencioso en el “Pedro y el lobo” del siguiente punto.

La trampa de “Pedro y el lobo” (Fatiga de alertas)

El mayor riesgo de este modelo no es técnico, es psicológico. Si configuras alertas para todo (“Se ingresó una factura”, “Alguien inició sesión”, “El gasto subió un 1%”), tu celular sonará cada 5 minutos.

¿El resultado? Silenciarás el grupo. Y el día que haya un incendio real, no lo verás porque tu cerebro habrá aprendido a ignorar la notificación.

Para evitar la fatiga, aplico la regla del Semáforo inverso en la ingeniería de alertas:

1. Verde (Operación normal): Nunca notificar. El éxito es el silencio.
2. Amarillo (Desviación leve): No enviar alerta inmediata. Agregar a un “Reporte de Anomalías Semanal” que se envía los viernes. Ejemplo: Rendimiento levemente bajo de maquinaria.
3. Rojo (Crítico/bloqueante): Notificación inmediata al celular (Push Notification). Ejemplo: Carga de combustible en día Domingo (prohibido) o Gasto > 50% del presupuesto en un solo día.

La alerta debe ser sagrada. Si suena, debe doler.

Anatomía de una alerta accionable

Un error común de los desarrolladores es enviar alertas “técnicas” o “muertas” que solo generan ansiedad pero no soluciones.

Opción incorrecta (Mala UX)

Atención: El gasto de combustible es alto en la Obra Norte. ID #4055.

(Esto me obliga a abrir el laptop, loguearme en el sistema, buscar el ID, entender el contexto… pierdo 15 minutos).

Opción correcta

Atención: Anomalía de consumo detectada

• Obra: Norte
• Recurso: Petróleo Diésel
• Gasto Hoy: 1.200 L
• Promedio histórico: 800 L
• Desviación: +50% (crítico)
• Responsable de carga: Juan Pérez

Acciones disponibles:

1. Ver detalle de carga
2. Llamar al capataz
3. Marcar como error de digitación

Esta segunda alerta me da el contexto, la evidencia y la acción en una sola pantalla. Puedo tomar la decisión ejecutiva en 30 segundos desde el teléfono, sin abrir el computador.

Cerrar el bucle: la alerta es el inicio, no el final

Una alerta que suena y no se registra es solo ruido. La gestión por excepción exige cerrar el ciclo, si no, el sistema degenera en un grupo de WhatsApp más.

Cada excepción debe quedar persistida

Toda alerta disparada (incluso las que se marcan como “falso positivo” o “error de digitación”) debe escribirse en una tabla de excepciones con al menos:

• Timestamp
• Obra/recurso afectado
• Valor observado vs umbral
• Responsable de la resolución
• Acción tomada (corregir, escalar, descartar)
• Tiempo de resolución

Esto no es burocracia, es materia prima para la auditoría. Si en marzo hubo 15 alertas amarillas, en abril 22 y en mayo 40, tienes una señal de degradación que aparece en los datos antes de que explote en los KPIs financieros del cierre.

La acción correctiva escribe de vuelta al sistema

Cuando la alerta accionable ofrece “Marcar como error de digitación”, esa acción no puede quedarse en un log efímero: debe corregir el registro en la base de datos. Si no, la próxima consulta volverá a detectar la misma “anomalía” mañana y el vigilante se vuelve repetitivo e irritante.

Regla: la excepción cierra cuando la causa raíz desaparece del dato, no cuando el humano deja de verla.

Conclusión

Un dashboard lleno de gráficos verdes y números moviéndose es una pérdida de tiempo y energía mental. Te da una falsa sensación de control (“lo estoy viendo”), pero no te ayuda a tomar decisiones.

La verdadera eficiencia operativa se logra cuando confías lo suficiente en tu sistema como para no mirarlo. Mi aspiración máxima es un dashboard vacío. Si mi celular no suena, sé que la obra marcha bien. Si suena, sé que es algo que realmente requiere mi atención inmediata.