Un “muro de pantallas” no falla por falta de tecnología. Falla porque no define:

• qué decisiones se toman ahí,
• quién manda cuándo,
• qué datos son “verdad oficial”,
• y qué evidencia queda al final.

La consecuencia típica: cada dependencia sigue operando por su cuenta, el centro se vuelve una sala de monitoreo cara y, cuando hay crisis, todo se coordina por llamadas y chats fuera del sistema.

Los 7 requisitos (si cumples esto, no será un muro)

1) Propósito operativo: decisiones concretas, no “visibilidad”

¿Qué decisión cambia si el centro existe? Si no puedes responder, será muro.

Define 3–5 decisiones “core” del centro, por ejemplo:

1. priorizar incidentes en picos,
2. activar protocolos multi-agencia,
3. reasignar recursos entre jurisdicciones,
4. escalar a mando (cuando y con qué evidencia),
5. comunicar narrativa oficial (situational report).

Señales de que sí funciona

• Hay un catálogo de decisiones con responsables y umbrales (p. ej., “cuando X ocurre, se activa Y”).
• Las decisiones quedan registradas y se pueden auditar.

Error común

“El objetivo es ver todo”. Ver todo sin decidir mejor = ruido.

2) Modelo de autoridad y roles: quién manda, cuándo, y con qué facultad

Multi-agencia sin mando claro = parálisis o conflicto.

Define:

• Comandante del incidente (por tipo de evento y por fase: contención, estabilización, recuperación).
• Responsable de despacho vs responsable de coordinación (no siempre son la misma persona).
• Rol de enlace por dependencia (quién valida, quién ejecuta).
• RACI mínimo (Responsible, Accountable, Consulted, Informed).

Señales de que sí funciona

• En un ejercicio, todos pueden decir quién decide y quién ejecuta sin discutirlo.
• Los cambios críticos (prioridad, jurisdicción, recursos) exigen el rol correcto.

Error común

“Todos deciden”. Eso suele significar “nadie decide”.

3) Folio único y “tejido del incidente”: una sola historia compartida

Sin folio único, cada dependencia lleva su propio expediente y al final no hay verdad común.

Requisito mínimo:

• Un folio único desde el primer registro.
• Timeline del incidente (eventos atómicos con timestamps y autor).
• Sub-eventos como hijos, no como casos sueltos.

Señales de que sí funciona

• Puedes reconstruir: primer contacto → validación → despacho → arribo → resolución → cierre, con responsables.
• No hay “casos duplicados” que compiten entre sí.

Error común

Integrar pantallas (CCTV, mapas, radios) sin integrar el caso.

4) Interoperabilidad gobernada: integra lo que puedas sostener (y medir)

Integrar “todo” rápido casi siempre crea fragilidad: datos inconsistentes, timestamps rotos, dependencia del proveedor.

Prioriza por valor operativo y auditabilidad:

1. Registro/foliado del incidente
2. Despacho y tiempos (asignación/aceptación/arribo/cierre)
3. Ubicación con fuente y confianza
4. Comunicaciones relevantes (sin capturar “todo”, captura lo crítico)
5. Evidencia (audio/video/documentos) vinculada al folio

Señales de que sí funciona

• Cada integración referencia folio y entrega timestamps confiables.
• Hay reglas de “dato oficial” (qué campo manda si hay conflicto entre fuentes).

Error común

Integrar por exhibición (demo) y no por operación (turno real).

5) Workflows y playbooks: del “monitor” al “orquestar”

El centro debe convertir información en acciones repetibles.

Implementa:

• Workflows por tipo de incidente (p. ej., inundación, bloqueo, violencia, incendio, falla eléctrica).
• Checklists por fase (activación, despliegue, coordinación, comunicación, cierre).
• Escalamiento con umbrales (no por “intuición del turno”).
• Asignación y confirmación (quién acepta qué tarea y cuándo).

Señales de que sí funciona

• Dos turnos distintos ejecutan el mismo incidente con variación mínima.
• Hay menos dependencia de “la persona que sabe”.

Error común

Pretender que la coordinación “sale sola” con pantallas bonitas.

6) KPIs defendibles + After Action Review: medir para mejorar, no para castigar

Mide con timestamps y estados (no con promedios vacíos):

• Tiempo a validación (folio creado → datos mínimos completos)
• Tiempo a despacho (validado → asignación)
• Tiempo a aceptación (asignación → unidad acepta)
• Tiempo a arribo (aceptación → en sitio)
• Integridad del caso (% con bitácora completa + evidencia mínima)
• Reclasificaciones con motivo (para detectar mala tipificación)
• Reincidencia por zona/tipo (para prevención)

Y agrega un ritual operativo:

After Action Review breve: qué pasó, qué funcionó, qué falló, qué se cambia.

Señales de que sí funciona

• Cambios de proceso/documentación nacen de datos reales.
• El equipo confía en los KPIs porque son reproducibles.

Error común

Medir “tiempo total” y esconder dónde se rompe el flujo.

7) Resiliencia, continuidad y seguridad: si cae en crisis, no era centro de mando

Un centro de mando existe para el peor día. Diseña para fallas.

Requisito mínimo:

• Plan de continuidad operativa (degradación controlada: qué sigue funcionando si se cae X).
• Redundancia donde duele (energía, conectividad, almacenamiento de evidencia, autenticación).
• Roles y permisos (quién puede ver/editar/cerrar; cambios versionados).
• Registro de auditoría (quién consultó o exportó evidencia).

Señales de que sí funciona

• Puedes operar “modo degradado” sin perder folio/bitácora.
• No hay accesos compartidos; hay trazabilidad por usuario.

Error común

Confiar en que “nunca se va a caer” o que “TI lo arregla”.

Checklist rápido: ¿tu centro es coordinación o solo monitoreo?

Marca sí/no:

1. ¿Hay 3–5 decisiones “core” documentadas del centro?
2. ¿Existe modelo de autoridad (RACI) por tipo de incidente y fase?
3. ¿Todo gira sobre folio único y timeline auditable?
4. ¿Las integraciones entregan timestamps confiables y referencian folio?
5. ¿Hay workflows/checklists por incidente y escalamiento por umbral?
6. ¿KPIs reproducibles + AAR periódico con cambios reales?
7. ¿Continuidad operativa y control de accesos/auditoría de evidencia?

Si respondes “no” en 3 o más, tu riesgo de “muro de pantallas” es alto, aunque el hardware sea de primer nivel.

Cierre: el centro de mando no es una sala; es un sistema de decisiones

El indicador más honesto no es cuántas pantallas tienes, sino:

• cuántas decisiones coordinadas puedes ejecutar,
• cuánta variación entre turnos logras reducir,
• y qué tan fácil es auditar un incidente sin “reconstrucción artesanal”.