Un gerente abre su tablero y encuentra 34 indicadores encendidos. Verdes, rojos, amarillos, flechas que suben y bajan. Y entonces ocurre lo que ningún directorio confesará en voz alta: cierra la pantalla y decide con el estómago. No por falta de datos, sino por exceso. El QlikSense tablero de excepciones nace precisamente de esa herida. Es la disciplina de mostrar solo aquello que exige una decisión, y esconder todo lo que está bajo control. Porque un buen tablero no se mide por cuánto muestra, sino por cuánto te ahorra mirar.
La investigación es incómoda. La memoria de trabajo humana se satura alrededor de 7±2 elementos a la vez (Ley de Miller, confirmada por estudios modernos de resonancia). Empuja más allá de 9 datos y la calidad de la decisión se desploma. Sin embargo, seguimos diseñando dashboards como vitrinas. En este artículo te muestro cómo construir en QlikSense un tablero que decide contigo, no contra ti.
El problema real: eres data-rich y decision-poor
Hay una paradoja que define a la mayoría de las empresas que «invirtieron en BI»: tienen más datos que nunca y toman peores decisiones que antes. La sobrecarga de KPIs convierte al tablero en ruido. Cuando un CEO enfrenta una pantalla con 30 luces rojas y verdes parpadeando, el cerebro gasta toda su energía en decidir dónde mirar, y no le queda ninguna para pensar estratégicamente.
Los números lo confirman. Una investigación de KPMG reveló que el 35% de los profesionales de experiencia de cliente pierden tiempo excesivo navegando entre dashboards saturados de información, lo que genera fatiga y baja productividad. La consecuencia es predecible: los líderes se repliegan al «gut feel» porque los datos son demasiado ruidosos para interpretarlos.
Aquí está la verdad de fondo: las organizaciones que deciden con datos multiplican por 3,8 su retorno frente a las que deciden por intuición. Pero ese retorno no viene de acumular métricas. Viene de filtrar el mundo hasta dejar solo la señal. Y esa es, técnicamente, la esencia de un tablero de excepciones.
La solución con QlikSense: gobernar por excepción
La idea es simple de enunciar y poderosa en la práctica. En lugar de mostrar todos los productos, todas las sucursales o todos los clientes, el tablero muestra solo los que se salieron de la norma. Lo que está dentro del rango esperado se calla. Lo que se desvió, grita. A esto se le llama management by exception, y QlikSense lo implementa con tres piezas: banderas en el script, umbrales gobernados por variables, y expresiones Set Analysis que aíslan la desviación.
Paso 1: crear la bandera de excepción en el script
Todo empieza en la carga. En lugar de calcular la excepción en cada objeto (caro y frágil), la marcamos una sola vez en el modelo. Cargamos ventas reales contra su objetivo y precalculamos la desviación relativa.
// Umbral de tolerancia gobernado desde el script
SET vTolerancia = 0.10; // 10% de desviación aceptable
Hechos:
LOAD
Producto,
Sucursal,
Real,
Objetivo,
// Desviación relativa, protegida contra división por cero
If(Objetivo = 0, Null(), (Real - Objetivo) / Objetivo) AS DesviacionPct,
// Bandera de excepción: 1 si el desvío supera la tolerancia
If(Objetivo > 0 and
Fabs((Real - Objetivo) / Objetivo) > $(vTolerancia), 1, 0) AS FlagExcepcion
RESIDENT Ventas;Analicemos cada parte. La variable vTolerancia centraliza el umbral: si mañana el directorio decide que 8% es el nuevo límite, cambias un número y todo el tablero obedece. La función Fabs() toma el valor absoluto, porque una excepción puede ser por exceso o por defecto. Y FlagExcepcion deja precalculado un 1 o un 0 que después usaremos para filtrar sin recalcular nada en pantalla.
Paso 2: aislar la excepción con Set Analysis
Con la bandera en el modelo, el KPI de cabecera deja de contar todo y cuenta solo lo que se desvió. Esta expresión responde una pregunta ejecutiva concreta: ¿cuántas ventas están fuera de control ahora mismo?
// Monto de ventas en estado de excepción
Sum( {<FlagExcepcion = {1}>} Real )
// Cuántas combinaciones producto-sucursal se desviaron
Count( DISTINCT {<FlagExcepcion = {1}>} Producto & '|' & Sucursal )El modificador {<FlagExcepcion = {1}>} es el corazón del patrón: le dice a QlikSense que ignore todo lo que está bajo control y opere solo sobre las excepciones, respetando además las selecciones que el usuario ya hizo. Es un filtro que convive con el análisis, no que lo reemplaza.
Paso 3: mostrar solo a los infractores con AGGR y Rank
Un directorio no quiere una tabla de 400 filas. Quiere las cinco que importan. Combinamos AGGR() para calcular la desviación por entidad y Rank() para quedarnos solo con los peores casos, en una dimensión calculada.
// Dimensión calculada: solo el Top 5 de mayor desviación absoluta
If(
Aggr(
Rank( Sum({<FlagExcepcion={1}>} Fabs(Real - Objetivo)) )
, Producto) <= 5,
Producto
)La expresión ordena los productos por magnitud del desvío y devuelve el nombre solo si está entre los cinco peores; el resto se colapsa. El resultado es una tabla que nunca crece: siempre muestra las cinco decisiones más urgentes, sin importar si tu catálogo tiene 50 o 5.000 SKUs.
Impacto en el negocio: del reporte a la decisión
Cuando un tablero se rediseña por excepción, el cambio no es estético, es económico. El tiempo que un comité gerencial dedica a «entender la pantalla» cae de forma notoria, y ese tiempo se reinvierte en discutir qué hacer. La reunión deja de ser un recorrido por gráficos y se convierte en una lista corta de decisiones.
Además, la excepción bien diseñada acorta la distancia entre el evento y la acción. Un desvío que antes se descubría al cierre de mes, ahora aparece encendido apenas cruza el umbral. Esa velocidad es dinero: cada día que un producto opera fuera de control es margen que se fuga sin que nadie lo mire. El tablero de excepciones no informa más rápido; decide más rápido.
Errores comunes y cómo evitarlos
El primero es confundir excepción con alarma. Si todo se marca como excepción, nada lo es. El umbral debe ser lo bastante estricto para que un semáforo rojo signifique de verdad «actúa hoy».
El segundo es codificar los umbrales dentro de las expresiones. Cuando el límite vive repetido en veinte objetos, cambiarlo es una pesadilla. Gobiérnalo desde una variable única, como hicimos con vTolerancia.
El tercero es abusar del color. Si el tablero tiene rojo, verde, amarillo, azul y naranja, el color deja de ser señal y pasa a ser decoración. Reserva el rojo para lo que exige acción y deja el resto en tonos neutros.
El cuarto es olvidar el drill-down. Mostrar poco arriba no significa esconder el detalle. El directorio ve las cinco excepciones; el analista, con un clic, ve las cuarenta métricas que las explican.
Mejores prácticas desde la experiencia
Diseña de arriba hacia abajo: primero la pregunta que el líder debe responder, después el dato que la responde, y solo al final el gráfico. Si un objeto no cambia ninguna decisión, sácalo. Es doloroso, pero cada elemento que quitas hace más valiosos a los que quedan.
Precalcula en el script todo lo que puedas. Las banderas de excepción, los flags de estado y las clasificaciones pertenecen al modelo, no a la capa visual. Tu tablero será más rápido y tus expresiones, más legibles. Y documenta cada umbral: un límite sin dueño ni criterio es una decisión disfrazada de dato. Si quieres profundizar en cómo estos principios se conectan con la estrategia de datos de tu empresa, revisa el resto de contenidos en hectorpincheira.com.
Conclusión estratégica
Un tablero no existe para demostrar cuántos datos tienes. Existe para reducir la incertidumbre de quien decide. El QlikSense tablero de excepciones invierte la lógica que nos enseñaron: en vez de preguntar «¿qué puedo mostrar?», pregunta «¿qué debe ver para actuar?». Y en esa inversión está la diferencia entre un equipo que mira reportes y uno que toma decisiones.
La próxima vez que abras tu dashboard, cuenta las luces encendidas. Si son más de las que puedes decidir en una reunión, no tienes un problema de datos. Tienes un problema de diseño. Y ahora sabes exactamente cómo resolverlo.
