El dato no es el activo, es la trazabilidad del activo
·6 min de lectura
En la migración de una entidad bancaria, arrancamos con más de 13.000 ofertas de venta de inmuebles cargadas en el sistema. Sobre el papel, un volumen de negocio considerable, la base de un pipeline comercial sólido para arrancar la integración con buen pie.
Nos costó darnos cuenta, a través de nuestra propia lógica de negocio, de que muchas de esas ofertas eran comercialmente imposibles. La lógica de negocio impedía tener ofertas activas sobre inmuebles que ya se encontraban en estados avanzados de venta, y sin embargo, ahí estaban, conviviendo en el mismo sistema como si nada. A eso se sumaba un problema más de fondo: el modelo de posicionamiento comercial que aplicábamos en el destinatario de los activos no se había adaptado a la necesidad real de la nueva cartera de inmuebles. Era un modelo pensado para otro perfil de activo, con otra lógica de mercado detrás, y lo aplicamos tal cual sobre una cartera que no encajaba con esos supuestos. El resultado era previsible: convertía en un pequeño milagro que fuéramos capaces de mirar cada oferta y posicionarla en su situación real dentro del modelo operativo del servicer de destino.
La tesis
El dato no es el activo. Es la trazabilidad del activo. Tener un registro en un sistema no significa tener información fiable sobre lo que representa: de dónde viene, cuándo se validó por última vez, y si sigue siendo coherente con el resto del modelo. Sin eso, un volumen de dato alto no es una ventaja, es una promesa sin verificar.
Dónde se rompió, exactamente
Al iniciar los procesos de migración, las propias validaciones automáticas empezaron a arrojar muchísima incoherencia en la conformación de las ofertas salientes. No fue un incidente puntual ni una alarma aislada. Fue un patrón que se repetía cuanto más se profundizaba: ofertas duplicadas, ofertas sobre inmuebles ya vendidos, ofertas con datos de posicionamiento que no encajaban con la realidad del activo.
La complejidad del problema fue tal que tuvimos que hacer una revisión muy profunda de todo el modelo. El resultado, después de esa revisión, fue que de las 13.000 ofertas iniciales quedaron menos de 4.500 como realmente válidas y coherentes con el estado comercial del activo. El impacto no fue solo numérico. Fue de pipeline, de previsiones ya comunicadas, y de credibilidad frente a un cliente bancario que había recibido cifras basadas en un volumen que, en la práctica, nunca existió del todo.
Por qué es tan fácil no verlo
El error no estaba en no tener dato. Estaba en confundir volumen de registros con calidad de información. Un sistema que muestra 13.000 filas transmite una sensación de robustez inmediata: cuantas más filas, más parece que el negocio está bien dimensionado, mejor parece la migración, más tranquilo se queda todo el mundo en el comité de seguimiento. Nadie pregunta por la trazabilidad de cada fila cuando el número total ya suena bien.
Y hay una segunda razón, más técnica: la incoherencia rara vez se ve mirando un solo registro. Una oferta, aislada, puede parecer perfectamente válida. Solo aparece como problema cuando la cruzas con el estado comercial real del activo, con otras ofertas sobre el mismo inmueble, con el histórico de cambios. Sin ese cruce sistemático, el dato malo se esconde perfectamente dentro del dato bueno, y ambos suman al mismo número total que todo el mundo mira en la reunión de seguimiento.
Cómo lo aplico ahora
La sistematización que aplicamos desde entonces se basa en una doble verificación. Por un lado, muchas capas de control sobre el dato origen, antes de que entre siquiera al modelo de destino. Por otro lado, readaptar el modelo de datos de destino con cada nueva necesidad de negocio, porque los modelos son vivos y están en constante evolución, no algo que se diseña una vez y se congela.
Pero la pieza central de todo esto es tener definido lo que llamo el data tape crítico: el conjunto de información que es esencial para el modelo operativo y para los requisitos de cobro por la prestación de servicios. No todo el dato necesita el mismo nivel de exigencia. Lo que sí necesita trazabilidad exhaustiva, sin excepción, es ese núcleo crítico del que depende tanto la operativa diaria como la facturación del servicio. Identificar ese núcleo antes de empezar a validar es lo que evita que el esfuerzo de control se diluya en información que, en realidad, no compromete nada si falla.
Donde la trazabilidad exhaustiva no compensa
Esto tiene un límite razonable, y merece decirse con la misma claridad que el resto: exigir trazabilidad exhaustiva sobre absolutamente todo el dato, siempre, no es sostenible ni tiene sentido. La excepción está en los tiempos de curado de la información. Cuando hay muchas fuentes contradictorias y la volumetría es muy elevada, validar registro a registro contra el modelo completo se vuelve inviable en los plazos que exige cualquier migración real.
En esos casos, la respuesta no es renunciar al control, es aplicarlo con criterio: hacer muestreos para identificar cuáles son las fuentes más confiables, y aplicar el nivel de exhaustividad más alto sobre la que se determina como fuente maestra. No se trata de validar el 100% de cada dato uno a uno, sino de decidir, con criterio estadístico, en qué fuente confías más y concentrar ahí el esfuerzo de trazabilidad real.
La objeción que me tomo en serio
La objeción, casi siempre, viene por el lado reputacional de los indicadores clave del departamento afectado. Una caída brusca del pipeline, provocada por eliminar duplicidades o por retirar ofertas que hasta ese momento se consideraban válidas, es difícil de explicar hacia arriba en la organización sin que suene a fracaso.
Y hay una variante todavía más delicada: las proyecciones de ingresos, en muchos de estos modelos, se construyen sobre precios de transferencia de los activos que no siempre reflejan las consideraciones reales de valor de mercado. Cuando la trazabilidad expone que esos precios no son realistas, no solo cae el volumen de ofertas. Cae también la previsión de ingresos que ya se había comunicado a dirección, o incluso al propio cliente bancario. Es una objeción legítima porque el coste de decir la verdad sobre el dato es real, inmediato y visible, mientras que el coste de no decirla se paga más tarde, cuando ya es mucho más caro corregirlo.
No hay una forma cómoda de resolver esa tensión. Pero la alternativa (seguir vendiendo pipeline sobre datos que no van a sostenerse) no elimina el problema, solo lo traslada hacia adelante, con un cliente que en algún momento va a comparar lo que se le prometió con lo que realmente se pudo entregar.
Para el lunes
La próxima vez que revises un volumen de dato que parece sólido, no preguntes cuántos registros hay. Pregunta cuántos de ellos forman parte del data tape crítico, cuándo se validó por última vez cada uno, y si esa validación se hizo contra una fuente maestra identificada o simplemente se asumió como buena porque estaba ahí. Si nadie puede responder a eso con claridad, el número que tienes delante no es información. Es una promesa que todavía no se ha puesto a prueba.
También te puede interesar
Reflexiones
El día que un proyecto brillante técnicamente no cambió nada
El cálculo puede ser perfecto y el proyecto puede fracasar igual. La distancia entre las dos cosas se llama decisión, y ahí es donde casi nadie mira.
·7 min
IA aplicada
Quién responde si el agente se equivoca
Un agente de IA que funciona bien en el 95% de los casos no está resuelto. Está esperando al 5% donde nadie ha decidido todavía quién responde.
·7 min
Transformación digital
Transformar no es migrar
Cambiar de herramienta es fácil de aprobar y difícil de justificar. La pregunta que de verdad transforma algo casi nunca es "¿qué sistema necesitamos?".
·7 min