Mejor adopción, más arquitectura: el trade-off detrás de unos datos fiables

Cada campo traslada la complejidad a otra parte

El requisito visible suele llegar en forma de lista: país, tipo de cliente, canal, familia de producto, ventas históricas, segmento, responsable, estado de rendimiento, tipo de movimiento comercial, prioridad y siguiente acción, en cada oportunidad. La forma más barata de cumplirlo es convertir cada dato que falta en un campo.

Añadir un campo sale barato en términos de arquitectura porque la integración la hace otra persona. El comercial recuerda el país, busca en otro sistema lo que se vendió el año pasado, interpreta qué significa «movimiento comercial», clasifica la situación con definiciones que nadie le ha explicado y mantiene cada valor al día a mano. El usuario se ha convertido en la capa de integración.

La complejidad no desaparece cuando se saca del sistema: se desplaza. La pregunta de fondo detrás de un formulario es dónde debe recaer el coste de obtener información fiable: en quien la introduce o en el sistema que lo rodea, y en qué condiciones.

Un dato estructurado puede seguir sin ser fiable

Los formularios que obligan a reconstruir lo que la organización ya sabe producen datos estructurados y operativamente débiles. Los valores de relleno superan la validación. «Otros» acaba siendo la clasificación más elegida. Los campos se actualizan la víspera de la reunión de seguimiento y se quedan desfasados el resto del mes, mientras el trabajo que importa se va a una hoja de cálculo.

Nada de esto aparece en un informe de completitud. Un conjunto de datos puede estar completo del todo y, aun así, estar desactualizado, basarse en suposiciones, interpretarse de forma distinta en cada equipo o haberse rellenado solo para cumplir una regla. La completitud mide si existe un valor. La fiabilidad depende de que lo aporte la fuente adecuada, en el momento adecuado y con una definición compartida.

Tampoco la adopción depende solo del número de campos. La gente acepta introducir bastante información cuando de verdad le corresponde aportarla y recibe algo útil a cambio. Cinco campos bastan para generar rechazo si los valores ya existen en otro sitio. Lo que pesa es la relación entre el esfuerzo que se aporta y el valor que se recibe.

Decidir quién debe cargar con el esfuerzo

No toda la información merece el mismo tratamiento. Ayuda distinguir cinco tipos. Los hechos ya existen con autoridad en algún sitio: la identidad legal, el país, el responsable actual de la cuenta, los pedidos históricos, el objetivo vigente, la última actividad. Si el sistema puede obtenerlos de forma fiable, volver a pedírselos al usuario es puro desperdicio.

La información derivada se calcula a partir de los hechos: el rendimiento frente al objetivo, los días desde la última actividad, si una cuenta tiene oportunidades abiertas, un segmento definido con criterios gobernados. Lo normal es calcularla, no teclearla: una derivación introducida a mano es un cálculo que alguien olvidará rehacer.

La información inferida es la que el sistema puede proponer sin tener certeza: el tipo de movimiento comercial más probable, el cliente con el que probablemente coincide, una prioridad sugerida. Según la confianza y la consecuencia, puede ordenarse, rellenarse de antemano o presentarse para su confirmación, pero una suposición no debería pasar en silencio a registrarse como un hecho.

El juicio exige interpretar: por qué una cuenta rinde por debajo de lo esperado, si una oportunidad está realmente cualificada, si una excepción es aceptable. El compromiso es la información cuya introducción explícita crea responsabilidad: la siguiente acción, la fecha comprometida, el riesgo aceptado, la decisión y su motivo. La atención humana debería emplearse en juicio y compromiso, no en reconstruir hechos que el sistema ya conoce.

Mejorar la adopción suele exigir más arquitectura

Pensemos en un gestor de cuentas que actualiza una oportunidad. El diseño ingenuo le hace once preguntas. Uno rediseñado obtiene de su fuente el país, el responsable, la jerarquía de producto y las ventas históricas; deriva el estado de rendimiento, la madurez de la relación y el contexto de oportunidades abiertas, y sugiere el tipo de movimiento comercial y la prioridad. A la persona se le pide lo que solo ella puede aportar: la intención, por qué ahora, el siguiente compromiso y cualquier excepción que el sistema no puede conocer. Introducir menos datos puede dar una información más rica cuando la arquitectura asume más trabajo.

Esa sencillez tiene un coste. Alguien tiene que diseñar la autoridad de cada fuente, la identidad canónica, las integraciones, los contratos de datos, las reglas de derivación y de precedencia, la vigencia, la confianza, las correcciones, la conciliación, la trazabilidad y quién responde de cada valor inferido. Una interfaz sencilla puede apoyarse en una arquitectura bastante más sofisticada. No es complejidad accidental, sino complejidad que el sistema absorbe a propósito para que no la cargue quien participa en el proceso.

Compensa cuando la interacción es frecuente, la realizan muchas personas, los hechos ya existen, las decisiones posteriores dependen del dato y el modelo operativo depende de que la gente use el sistema. Suele compensar poco en procesos esporádicos o temporales, con información que solo conoce el usuario, o cuando la integración cuesta más que el esfuerzo que elimina. Es un trade-off, no una doctrina.

No automatizar la responsabilidad

El fallo contrario es igual de real. Automatizarlo todo acumula supuestos ocultos, valores por defecto erróneos, datos derivados que se quedan obsoletos cuando cambia una fuente e inferencias que nadie sabe explicar. La interfaz se simplifica mientras la información pierde credibilidad.

La IA amplía las opciones, pero no cambia el principio. Antes que ella están las integraciones, las reglas deterministas, las búsquedas, los datos maestros y los valores calculados. La IA aporta sobre todo cuando el material no está estructurado: extraer contexto de un correo, sugerir una clasificación, ordenar posibles coincidencias. Pero la confianza no es autoridad. Un valor ambiguo o con consecuencias importantes puede seguir necesitando confirmación humana, y el registro debería distinguir lo confirmado de lo que solo se ha propuesto.

El compromiso merece un cuidado especial. Que un modelo pueda adivinar la siguiente acción no significa que la organización deba dejar de pedir a alguien que se comprometa con ella. Una siguiente acción explícita, con responsable y fecha, es el momento en que nace la responsabilidad; eliminarla por comodidad elimina justo lo que el proceso existe para producir. Se trata de preguntar al usuario solo cuando su aportación es la fuente adecuada de verdad, de juicio o de compromiso.

Una prueba antes del próximo campo

Antes de crear un campo, conviene hacerse unas pocas preguntas. ¿Para qué se necesita esta información y qué decisión la usa? ¿Quién o qué la conoce realmente? ¿Existe ya en alguna fuente con autoridad? ¿Puede derivarse, o sugerirse con una incertidumbre que la decisión pueda tolerar? ¿Alguien tiene que responder de ella o comprometerse con ella? ¿Y qué ocurre cuando se queda desactualizada?

Las respuestas rara vez eliminan todos los campos, ni deberían. Lo que cambia es que cada campo pasa a ser una decisión deliberada sobre dónde recae el coste de una información fiable, no la manera por defecto de sacar la complejidad de la arquitectura para cargarla sobre las personas a las que el sistema debería servir.