¿Cuándo tiene que llegar un dato para que sirva?
Cada decisión tiene su momento, y el dato tiene que llegar antes. Algunas lo necesitan al instante, y esas conviene automatizarlas. La mayoría de las que toma un gerente se deciden bien con el dato de ayer, siempre que signifique lo mismo para todos, traiga contexto y alguien lo esté vigilando.
Tiempo real, para decidir todos los días.
En un diagnóstico reciente nos sentamos con un corralón de materiales de construcción: unas cien personas, tres sucursales y la cuarta en camino. El gerente comercial tenía clara la prioridad. Quería ver ventas, stock y compras en tiempo real. Y en la misma frase dijo para qué: para tomar decisiones todos los días.
El resto de la conversación iba en la misma línea. La deuda vencida la vigilaba alguien a mano. Lo que le faltaba era información financiera del día a día: qué cheques había disponibles, cuánto se podía pagar a proveedores y con qué plazos.
Para decidir todos los días no hace falta ver un número cambiar cada segundo. Hace falta que esté ahí por la mañana, cuando se decide qué comprar y a quién pagar. «Tiempo real» es la palabra que el mercado le dio para pedir eso. No se equivocaba de problema; en todo caso, de palabra.
Cada decisión pide el dato a su propio ritmo.
Esto está estudiado desde 1971. Anthony Gorry y Michael Scott Morton, en el MIT, distinguieron tres tipos de decisión (control operativo, control de gestión y planificación estratégica) y sostuvieron que la información que necesita cada una es de otra naturaleza, no solo de otro nivel de detalle. El control operativo usa datos detallados, exactos y consultados sin parar; la planificación estratégica, datos agregados que se miran de tanto en tanto. El control de gestión, donde vive casi todo lo que decide un gerente, queda en medio.
Richard Hackathorn lo dibujó después como una curva. Cuanto más tarda una respuesta desde que ocurre un hecho, menos vale. Pero cada decisión tiene su propia curva. En algunas, como ofrecer un producto complementario mientras el cliente compra en línea, cualquier demora se come el valor. En otras, el valor baja despacio hasta que se cruza un límite, legal o de la propia empresa, y a partir de ahí ya no sirve.
Colin White le puso nombre: right time. Josep Lluís Cano lo recoge en Business Intelligence: competir con información, un libro de 2007 pensado para pymes, y lo traduce como «a tiempo». Cada situación de negocio pide su propio plazo de respuesta. A veces es tiempo real; a veces, minutos u horas no cambian nada.
El tiempo real es para las decisiones que ya tienen regla.
Gorry y Scott Morton ponían ejemplos muy concretos de decisión operativa. Qué descuento aplicar cuando entra un pedido. Qué precio corresponde. Desde qué almacén se despacha. Cuándo y cuánto reponer un artículo de mucha rotación. Se repiten a diario y siguen reglas bien definidas, y de ese tipo de problema decían que el proceso de decisión se puede automatizar casi entero.
Lo viví antes de Kairos. Habíamos integrado el ERP de un concesionario de motos con Mercado Libre, y la sincronización de stock tardaba media hora; así había funcionado siempre. En junio del año pasado empezó a tardar dos horas, y nos escribieron: lo que se vendía en el mostrador no podía tardar tanto en darse de baja de la publicación. Ahí el tiempo real no es un lujo. Si dos personas compran la última unidad, una en el mostrador y otra en la web, una de las dos se queda sin ella. Con media hora de desfase el riesgo ya existía; con dos horas dejó de ser tolerable.
Esa decisión, si un artículo sigue a la venta, la toma el sistema para cada comprador que entra, y no puede esperar a que alguien abra un tablero. Si decidir vale durante minutos, cualquier persona mirando una pantalla llega tarde. El propio Hackathorn advertía que, con datos cada vez más rápidos, el cuello de botella iba a pasar a ser la decisión.
Esas decisiones se automatizan: una regla o un agente que actúa en cuanto llega el dato, con la autonomía que la empresa le fije y con aprobación humana donde la operación lo exija. Cuando una decisión de este tipo lo pide, conectamos esa fuente en tiempo real. Es una configuración para ese caso concreto, no el punto de partida.
Para muchas decisiones de cada mañana basta con el dato de anoche.
Las decisiones de un gerente son de otra clase. Se toman cada día o cada semana, y su curva cae despacio: una hora de demora no las estropea. Las estropea decidir sin el dato, o con uno que llega cuando la decisión ya está tomada.
Las alertas que dejamos preparadas desde el primer día lo muestran mejor que la teoría. La de caída de venta compara cada sucursal contra el mes anterior y se evalúa el lunes: la venta se cierra por mes, así que mirarla a diario solo produciría el mismo aviso siete veces. La de cliente en riesgo solo avisa de los que llevan entre tres meses y un año sin comprar. A partir de un año, la regla deja de considerarlos recuperables con una visita. En medio queda el cliente que compraba y dejó de hacerlo, que es sobre el que un supervisor puede actuar esta semana. Esa ventana es la curva de Hackathorn escrita como una regla.
Por eso nuestro punto de partida no es el tiempo real. Cuando empezamos con una empresa, los datos se cargan completos cada madrugada y los tableros amanecen con el día anterior cerrado. Los avisos se evalúan una vez por semana, y es a propósito: uno que se repite cada día mientras el problema sigue abierto deja de leerse. El ritmo del aviso también se diseña según la decisión que tiene que provocar.
Antes de pedir tiempo real, clasifica tus decisiones.
Esta tabla resume todo lo anterior. Recorre las decisiones de una semana normal y pon cada una en su fila.
Si una decisión de la primera fila la toma hoy una persona mirando una pantalla, ahí sí tienes un problema de tiempo real. Si a una de la segunda te la quieren resolver con tiempo real, lo que falta casi nunca es velocidad. Suele ser una de las tres cosas de la sección siguiente.
| Tipo de decisión | Ejemplos | Cuándo tiene que llegar el dato | Quién actúa |
|---|---|---|---|
| Operativa, con regla | Cuánto stock queda a la venta en cada canal. Qué descuento aplicar al entrar un pedido. | Al momento | Una regla o un agente, con la autonomía que fijes |
| De gestión | Qué sucursal cayó. Qué cliente dejó de comprar. A qué proveedor pagar primero. | Antes de la reunión en la que se decide: el dato de anoche, el aviso del lunes | El gerente, avisado a tiempo |
| Estratégica | Abrir una sucursal. Cambiar de ERP. | Cuando se prepara la decisión | La dirección, con datos agregados |
Un dato puntual todavía puede no servir para decidir.
Hasta aquí, el cuándo. Pero una cifra lista para decidir no es solo una cifra correcta que llega a su hora. Le hacen falta tres cosas más.
Que signifique lo mismo para todos. Si ventas calcula el margen con un criterio y finanzas con otro, el dato llega a tiempo para empezar una discusión. Cada indicador se define una vez, por escrito, y todas las áreas leen esa definición. Lo desarrollamos en El mejor controller es el que no tiene que buscar los números.
Que venga con contexto. Qué cambió, desde cuándo, qué puede haberlo causado y qué decisión pide. Un número suelto obliga a quien lo recibe a reconstruir la historia antes de decidir, y ese rato sale del mismo margen de tiempo que se quería ganar.
Que alguien lo vigile. Alberto Ballvé, que participó en la fundación del IAE, lo dejó escrito en Tablero de control hace más de veinticinco años. Cada indicador lleva una referencia contra la que medir el desvío, un nivel a partir del cual preocupa y un responsable de monitorearlo que avisa hacia arriba. El diseño era correcto. Lo que falla en una empresa mediana es quién hace de responsable: casi siempre, la misma persona que prepara el cierre, y preparar se come a vigilar. Cano lo planteaba del otro lado: el valor está en decidir, no en preparar la información. En el corralón, la deuda vencida la vigilaba alguien a mano.
Vigilar incluye vigilar al que vigila. En uno de nuestros proyectos, la alerta de rechazo en la entrega no disparó nunca, y no porque no hubiera rechazos: la métrica dejaba fuera los comprobantes anulados, que es justo donde ese ERP registra el rechazo. Valía cero siempre. Una alerta que no puede dispararse es peor que no tenerla: nadie la echa de menos y todos la cuentan como cubierta. Por eso no nos basta con definir una alerta: comprobamos que significa lo que creemos que significa.
Esa vigilancia es la que hacen los agentes que describimos en Ver el mes antes del cierre del mes: miran los indicadores que tú definas y avisan cuando se salen de rango, con el detalle de qué cambió y desde cuándo.
Un dato en tiempo real que nadie mira también llega tarde.
Dos palabras para el tiempo.
Los griegos tenían dos palabras para el tiempo. Chronos era el del reloj, el que se cuenta. Kairós, el del momento oportuno, el que se aprovecha o se pierde; de ahí viene nuestro nombre. El calendario del cierre, la frecuencia de carga y el refresco del tablero se miden en chronos. Las decisiones viven en kairós.
La pregunta útil deja de ser cada cuánto se actualiza tu información. Pasa a ser cuándo tiene que estar en tu mesa para cada decisión que tomas, y quién te avisa si ese día no está.
Lo que suele preguntarse sobre el tiempo real.
¿Mi empresa necesita datos en tiempo real?
Para algunas decisiones, sí: las operativas, que se repiten muchas veces al día y siguen una regla, como el stock que se vende en varios canales a la vez o el descuento que se aplica a un pedido. Para casi todas las que toma un gerente, no. Necesitan el dato antes de decidir, y en la mayoría basta con el del día anterior. Para saberlo, recorre tus decisiones una por una y pregúntate cuánto pierde cada una por cada hora de retraso.
¿Un tablero en tiempo real no resuelve lo mismo?
Resuelve la frescura del dato. No resuelve que alguien lo mire, que todas las áreas lo calculen igual ni que venga con el contexto para decidir. Por eso el dato no puede quedarse esperando a que alguien abra el tablero: tiene que llegar a quien decide, como aviso, notificación o informe, en el momento que pide cada decisión.
¿Cada cuánto se actualizan los datos en Kairos?
Cuando empezamos con una empresa, cada madrugada, con la carga completa del día anterior, y los avisos se evalúan una vez por semana. Cuando una decisión necesita el dato al momento, esa fuente se conecta en tiempo real; es trabajo específico para ese caso.
¿Y las decisiones que sí piden tiempo real?
Automatizarlas. Una regla o un agente actúa en cuanto llega el dato, con la autonomía que fijes y con aprobación humana donde la operación lo exija. Esperar a que alguien lo vea en una pantalla es justo lo que esas decisiones no se pueden permitir.
Relacionado: Ver el mes antes del cierre del mes · El mejor controller es el que no tiene que buscar los números · Migrar de ERP sin quedarte ciego.
Para qué empresas encaja. Y para cuáles no.
Encaja bien si
- Te ofrecieron tableros en tiempo real y no tienes claro para qué decisiones los quieres.
- Ventas, finanzas y operaciones llegan a la misma reunión con números distintos.
- Hay indicadores que alguien vigila a mano, cuando puede.
- Decisiones repetitivas, como publicar stock o aplicar descuentos, esperan a que alguien las mire.
Probablemente no lo necesitas si
- Cada decisión importante ya tiene su dato a tiempo y alguien que avisa cuando se desvía.
- Tu operación cabe en una hoja de cálculo que alguien revisa cada día.
- El dato que te falta no lo registra tu ERP: ninguna frecuencia de carga lo arregla.
De las decisiones de esta semana, ¿cuáles esperaron a un dato y cuáles a que alguien lo mirara?
En 30 minutos completamos la tabla con tus decisiones: cuáles piden tiempo real, cuáles se deciden bien con el dato de ayer y quién tendría que avisar.
Reservar diagnóstico de 30 minutos