¿Qué antigüedad puede tener un dato cuando se decide?
La frecuencia correcta de sincronización entre dos sistemas es la que encaja con la decisión que el dato alimenta, no la más rápida que permite la tecnología. Cada información envejece a su propio ritmo. La pregunta de arquitectura es qué edad puede tener cuando alguien actúa sobre ella.
¿Por qué "tiempo real" no es la respuesta por defecto?
Porque el ritmo correcto depende de la decisión, no de la herramienta. Richard Wang y Diane Strong preguntaron a consumidores de datos qué significa la calidad para ellos. La investigación partió de 179 atributos recogidos con 25 consumidores de datos de empresas y 112 estudiantes de MBA con experiencia profesional, pasó por una encuesta con 355 respuestas válidas, llegó a 20 dimensiones y terminó con 15, agrupadas en cuatro categorías.
La oportunidad quedó en la categoría contextual, la que solo se evalúa frente a la tarea en cuestión. El artículo, publicado en el Journal of Management Information Systems, la define como la medida en que la edad del dato es apropiada para la tarea, y adopta la visión de que un dato de calidad es el que sirve a quien lo usa.
Eso desarma la regla única. El problema no es de tecnología de sincronización, es de arquitectura: decidir la edad de cada dato. Un saldo de inventario consultado al prometer un plazo a un cliente y un costo medio leído en el cierre del mes no tienen la misma exigencia. Sincronizar ambos cada minuto da trabajo de construcción y de monitoreo, y solo uno de ellos lo aprovecha. Esta parte es lectura nuestra, no del estudio.
¿A qué velocidad envejece cada dato?
A velocidades distintas, y se puede estimar por atributo. Heinrich, Kaiser y Klier propusieron, en la conferencia ICIS de 2007, una métrica en la que la oportunidad de un valor es la probabilidad de que siga siendo válido. Esa probabilidad cae de forma exponencial con la edad, a una tasa propia de cada atributo. En el caso que analizaron los autores, el nombre de pila de un cliente tiene tasa cero y la tarifa contratada, 0,4 por año. Con la misma edad, ambos tienen una validez muy distinta.
El caso es una campaña de un operador de telefonía móvil alemán, con cifras anonimizadas. En una campaña anterior, dirigida a 82.000 clientes, la tasa media de éxito fue de cerca del 8,5%. Entre los clientes con oportunidad estimada de 0,2 a 0,3, fue del 4,4%. Entre los de 0,9 a 1, del 12,6%. Según la estimación de los autores, dirigirse solo a los clientes por encima de 0,4 elevaría la rentabilidad de la campaña siguiente en 30 puntos porcentuales. La explicación es simple: quien tiene la dirección desactualizada ni siquiera puede aceptar la oferta.
El límite es este: el estudio trata de una campaña de marketing en Alemania, y la oportunidad allí es una probabilidad estimada, no una edad medida en horas. Muestra que la edad del dato tiene un efecto medible en el resultado y que la tasa de envejecimiento varía por atributo. No sirve como referencia para su proceso.
¿Qué edad tiene el dato cuando la carga corre cada cierto tiempo?
Entre cero y el intervalo de la carga, y en promedio como máximo la mitad de él. Cho y Garcia-Molina, de Stanford, definen la edad de un elemento copiado como cero cuando la copia está al día y, en caso contrario, el tiempo transcurrido desde que cambió el original. Aplicado a una sincronización de intervalo fijo T, un cambio hecho justo después de una carga solo llega en la siguiente. El cambio más antiguo que aún falta en la copia tiene entre 0 y T de edad, y el promedio es como máximo T/2 si las consultas se reparten a lo largo del intervalo. Esa aritmética es nuestra, no del artículo.
El efecto se suma cuando los sistemas se encadenan. Si el sistema A alimenta al B cada hora y el B alimenta el panel una vez por noche, el retraso posible llega a 25 horas, más el tiempo que tarda en correr cada carga. Quien lee el panel poco antes de la carga siguiente ve una foto que puede tener más de un día, sin que la pantalla lo diga.
Dos paneles también pueden discrepar por definición. Aquí la discrepancia es de tiempo: las dos fuentes se leen con edades distintas y nadie marcó la edad de cada una.
¿Todo dato necesita la misma cadencia?
No, y la idea de sincronizar más veces lo que más cambia no siempre se sostiene. El artículo de Cho y Garcia-Molina, de 1999 y presentado en SIGMOD 2000, trata un problema emparentado: con un presupuesto limitado de actualizaciones, cuántas dedicar a cada elemento de una copia. El contexto de los autores son las copias de páginas web, así que la lección vale como principio, no como receta.
El resultado más contraintuitivo es que actualizar cada elemento en proporción a cuánto cambia resultó peor que actualizarlos todos al mismo ritmo. En un ejemplo suyo, un elemento que cambia nueve veces al día rinde poco en cada actualización, porque queda viejo enseguida, y uno que cambia una vez al día rinde más. En una estimación con datos reales de la web, que los propios autores llaman tosca, la política proporcional dejaría en promedio un 12% de los elementos al día, frente al 57% de la uniforme.
La lectura que hacemos para una operación es otra capa: el ritmo no debe venir solo de cuánto cambia el dato, sino de lo que la decisión pierde cuando está viejo. Un dato que cambia todo el tiempo y sobre el que nadie decide en minutos puede esperar. Un dato que cambia poco, pero bloquea un pedido cuando está mal, merece atención especial.
Un ejemplo práctico: el saldo de inventario que el CRM no ve
El escenario siguiente es hipotético. Los números son supuestos ilustrativos, no mediciones. Un distribuidor con 60 personas usa un ERP para inventario y costos, un CRM para propuestas y una hoja de cálculo para logística. Una integración nocturna copia datos del ERP al CRM a las dos de la madrugada.
A las dos de la tarde, un vendedor promete 40 unidades a un cliente con base en el saldo de las dos de la madrugada. Al mediodía, otro pedido ya había consumido 30. El problema no está en la integración, que corre como fue diseñada. Está en tratar tres datos distintos como si tuvieran la misma edad.
El saldo de inventario alimenta una promesa hecha en el momento, y la edad aceptable es de minutos, o una consulta directa al ERP al prometer. La situación de crédito del cliente cambia pocas veces al mes, pero bloquea un pedido cuando cambia, así que sirve la carga diaria, siempre que un bloqueo dispare una actualización inmediata. El costo medio por producto se lee en el cierre, y basta una carga al final del ciclo. Tres datos, tres edades máximas. Una única integración nocturna atiende bien al costo, atiende al crédito solo con un disparador adicional y falla en el que más pesa a la hora de vender.
¿Cómo fijar la edad máxima de cada dato?
Empiece por un inventario corto: los datos que pasan de un sistema a otro y alimentan una decisión, entre cinco y diez para comenzar. Para cada uno, escriba quién decide con él, en qué momento y qué ocurre si está viejo. De esa respuesta sale la edad máxima aceptable, anotada junto al dato, en minutos u horas. Solo después se elige el mecanismo de sincronización.
A continuación, haga que la pantalla diga la edad. Un campo con la hora de la última carga le da al usuario lo que Wang y Strong ponen en el centro de la calidad: la edad del dato frente a la tarea. Por último, vigile el retraso real contra el máximo acordado. Una sincronización que se detuvo sin aviso es la falla que trata Tu automatización se detuvo. ¿Cuándo lo vas a saber?.
En el caso de Reatop, los recolectores de residuos hospitalarios trabajan en zonas sin señal estable, y la aplicación registra los pesajes sin conexión y sincroniza los datos automáticamente cuando detecta red. La cadencia allí vino del contexto de uso: el dato nace donde no hay red y llega cuando la hay.
Preguntas frecuentes
La implementación va a exigir demasiado tiempo del equipo. ¿Es así?
El inventario de cinco a diez datos cabe en una o dos conversaciones cortas con quienes deciden con ellos. Ese recorte es una recomendación nuestra de diseño, no una cifra de investigación. El trabajo de construcción, si lo hay, se limita a los datos en que la edad pesa, lo que evita reescribir integraciones que ya sirven.
No veo cómo medir el resultado. ¿Qué medir?
Mida la edad del dato en el momento de la decisión y cuántas decisiones se rehicieron por dato viejo, como un pedido prometido y no cumplido. Registre ambos números antes de cambiar nada. El estudio de Heinrich y colegas muestra que la tasa de éxito varió con la oportunidad estimada, pero no es una referencia para su proceso, así que su propia línea de base importa más.
Temo que esto no elimine los cuellos de botella de verdad. ¿Resolvería el tiempo real?
No siempre. Si la espera está en una aprobación o en una cola de revisión humana, sincronizar más rápido no la toca. Antes de cambiar la cadencia, confirme que el retraso está en el dato y no en la decisión. Cuando está en el dato, la edad máxima por información indica dónde invertir.
El siguiente paso
Si su panel y su ERP muestran números de edades distintas sin avisar, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es una invitación para mapear qué datos cruzan sus sistemas y qué edad puede tener cada uno: hable con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico