A las 03:17 de la madrugada, la presión de una bomba comienza a caer.
El dato llega correctamente al sistema.
El gráfico cambia.
El indicador pasa de verde a rojo.
La información está disponible.
Pero nadie la ve.
A la mañana siguiente, cuando comienza el turno, el problema ya no es una variación de presión.
Es una detención, una pérdida de producción o una emergencia que pudo haberse atendido antes.
El dashboard funcionó perfectamente.
La operación no.
Mostrar no es avisar
Durante años hemos construido sistemas capaces de capturar, almacenar y visualizar enormes cantidades de información.
Dashboards, paneles, reportes, tendencias, históricos y pantallas de supervisión permiten saber qué está ocurriendo.
Pero todos comparten una condición:
alguien debe mirarlos.
Un dashboard responde una pregunta cuando una persona decide consultarlo.
Un sistema de alertas debe hacer algo diferente:
reconocer que ocurrió un evento, determinar si merece atención y llevarlo hasta quien puede actuar.
No son funciones equivalentes.
El problema no es la pantalla
Un dashboard es una herramienta valiosa.
Permite comprender contexto, revisar tendencias, comparar variables y analizar lo ocurrido.
El problema aparece cuando lo tratamos como si también fuera responsable de asegurar una respuesta.
Pensemos en algunas situaciones:
- una temperatura supera el límite permitido;
- un servidor deja de responder;
- una orden permanece detenida más tiempo del esperado;
- un producto vuelve a tener stock;
- un precio cae bajo el valor definido;
- un contrato se aproxima a su vencimiento;
- un cliente escribe y nadie responde;
- una alarma permanece activa durante varios minutos.
En todos esos casos, mostrar la información es solo una parte del trabajo.
Todavía falta decidir:
- ¿es una condición real o una lectura aislada?;
- ¿qué prioridad tiene?;
- ¿quién debe enterarse?;
- ¿por qué canal?;
- ¿qué información necesita para comprenderla?;
- ¿cuánto tiempo puede pasar sin respuesta?;
- ¿a quién se escala?;
- ¿qué evidencia debe quedar registrada?;
- ¿puede ejecutarse alguna acción automáticamente?
Ahí comienza un sistema de alertas.
De dato a evento
Un dato es una observación.
Por ejemplo:
Presión: 18,4 bar.
Un evento aparece cuando ese dato adquiere significado dentro de un contexto:
La presión se mantuvo bajo 20 bar durante tres minutos mientras la bomba permanecía en operación.
La diferencia es importante.
Alertar por cada lectura fuera de rango puede generar cientos de mensajes inútiles.
No alertar hasta que alguien revise el gráfico puede hacer que una condición importante se descubra demasiado tarde.
Por eso no basta con conectar una variable a una notificación.
Hay que diseñar la señal.
Una alerta debería responder más que “qué pasó”
Una alerta útil no debería obligar al destinatario a abrir tres sistemas distintos para comprenderla.
Debería entregar, en la medida de lo posible:
- qué ocurrió;
- dónde ocurrió;
- cuándo comenzó;
- cuánto tiempo lleva activo;
- qué tan grave es;
- qué otras variables se relacionan;
- qué acción se espera;
- quién más fue informado;
- qué ocurrirá si nadie responde.
Comparemos.
Mensaje sin contexto
Alarma PIT-204 LOW.
Señal accionable
Presión baja persistente en bomba de impulsión
La presión cayó a 18,4 bar y permanece bajo el límite de 20 bar desde hace 3 minutos. La bomba continúa en marcha.
Acción esperada: verificar condición operacional.
Si no existe confirmación en 4 minutos, el evento será escalado al supervisor.
El segundo mensaje no contiene necesariamente más tecnología.
Contiene más criterio.
Cuando todo avisa, nada avisa
Agregar notificaciones parece una solución sencilla.
Pero un sistema que envía demasiados mensajes termina entrenando a las personas para ignorarlos.
Cada falsa alarma reduce la credibilidad de la siguiente.
Cada duplicado consume atención.
Cada mensaje sin contexto obliga a investigar.
Cada alerta enviada a la persona equivocada genera demora.
El ruido no se produce solamente por exceso de datos.
También se produce por falta de diseño.
Una señal necesita propietario
Una alerta enviada a un grupo no necesariamente tiene responsable.
Todos pueden verla y, al mismo tiempo, asumir que alguien más actuará.
Un sistema bien diseñado debe definir:
- destinatario inicial;
- tiempo esperado de respuesta;
- mecanismo de confirmación;
- responsable siguiente;
- escalamiento;
- cierre;
- trazabilidad.
El objetivo no es demostrar que el mensaje fue enviado.
El objetivo es aumentar la probabilidad de que alguien actúe.
El canal también forma parte de la decisión
No todos los eventos deberían llegar de la misma manera.
Un informe diario puede enviarse por correo.
Una oportunidad comercial puede llegar por Telegram.
Una solicitud de cliente puede ingresar al CRM.
Una condición operacional urgente puede requerir WhatsApp.
Un evento crítico sin respuesta puede escalar por SMS.
El mejor canal no es necesariamente el más sofisticado.
Es aquel que permite llegar a la persona correcta en el contexto correcto.
También puede cambiar según:
- horario;
- ubicación;
- turno;
- nivel de urgencia;
- disponibilidad;
- respuesta previa;
- tipo de evento.
Un sistema multicanal no consiste en enviar el mismo mensaje por todas partes.
Consiste en elegir cómo debe viajar cada señal.
El valor aparece en el tiempo que se recupera
El dato puede existir desde el primer segundo.
Pero su valor depende de cuánto tarda en convertirse en acción.
Entre el evento y la respuesta suelen existir varios silencios:
- El sistema registra el cambio.
- Nadie revisa la pantalla.
- Alguien finalmente lo detecta.
- Busca más información.
- Intenta identificar al responsable.
- Envía un mensaje.
- Espera una respuesta.
- Recién entonces comienza la acción.
Reducir ese intervalo puede ser más importante que crear otro dashboard.
Porque, muchas veces, la diferencia entre una desviación menor y un problema serio no está en la cantidad de información disponible.
Está en cuándo alguien se entera.
Un dashboard y un sistema de alertas no compiten
No se trata de reemplazar dashboards, SCADA, plataformas de observabilidad, CRM o sistemas existentes.
Se trata de trabajar sobre ellos.
El dashboard permite ver.
El sistema de alertas permite reaccionar.
Uno entrega profundidad y contexto para el análisis.
El otro reconoce cuándo la información ya no debería esperar a ser consultada.
La arquitectura correcta puede necesitar ambos.
Una pregunta útil para cualquier organización
Mira los sistemas que hoy utiliza tu empresa y pregúntate:
¿Qué evento importante solo descubrimos cuando alguien entra a revisar?
Después pregunta:
¿Qué ocurre si nadie lo mira durante una hora, una noche o un fin de semana?
Ahí suele aparecer una oportunidad concreta de automatización.
No necesariamente necesitas comenzar con un gran proyecto.
Puedes comenzar con un solo evento:
- una falla;
- un cambio;
- un atraso;
- una oportunidad;
- un vencimiento;
- una solicitud;
- una condición crítica.
Definirlo bien ya es una forma de avanzar.
Lo importante no debería depender de que alguien esté mirando
En RedLocal diseñamos sistemas que observan fuentes de información, detectan eventos, filtran el ruido y entregan señales por WhatsApp, Telegram, SMS, correo o el canal que una operación necesite.
No se trata de enviar más mensajes.
Se trata de reconocer cuáles merecen interrumpir a una persona.
Y asegurar que lleguen mientras todavía es posible hacer algo.
¿Qué evento te serviría conocer antes?
No necesitas saber qué tecnología usar ni cómo conectarla.
Describe qué ocurre, dónde ocurre y quién debería enterarse.
Cuéntanos qué debería avisarte.