Luis Gómez CabezasDivulgación desde la dirección: PropTech, transformación digital e IA aplicada.

Reflexiones

El día que un proyecto brillante técnicamente no cambió nada

·7 min de lectura

Para un servicer, construimos un sistema de autofacturación de la gestión técnica de inmuebles. Antes de este proyecto, cada trabajo técnico realizado sobre un inmueble (una reparación, un mantenimiento, una intervención de urgencia) generaba un albarán manual por parte del proveedor, que después alguien del equipo interno tenía que revisar, contrastar contra el presupuesto aprobado, y validar línea por línea antes de convertirlo en factura. Con cientos de intervenciones mensuales repartidas entre múltiples proveedores, ese proceso manual era lento, propenso a errores de cálculo, y absorbía muchas horas de un equipo que podía dedicarse a cosas de más valor.

El sistema que construimos generaba albaranes automatizados con el desglose completo de los trabajos técnicos realizados, agrupando por los distintos tipos de IVA aplicables, con el reparto de costes por activo calculado automáticamente cuando una misma intervención afectaba a varios inmuebles a la vez, y consolidando todo en un único albarán que el proveedor solo tenía que completar con su número de serie para convertir en factura.

Técnicamente, era un proyecto del que sentirse orgulloso. Resolvía de raíz un proceso manual, propenso a errores, que antes se hacía a mano activo por activo. El cálculo era correcto, el desglose fiscal estaba bien resuelto, la automatización funcionaba exactamente como se había diseñado. En cualquier comité de seguimiento, era el tipo de proyecto que se enseñaba con orgullo.

La tesis

El cálculo puede ser perfecto y el proyecto puede fracasar igual. Un sistema no cambia nada por ser técnicamente impecable. Cambia algo cuando la persona que tiene que usarlo, o aprobarlo, puede hacerlo sin fricción. La distancia entre esas dos cosas se llama decisión, y ahí es exactamente donde casi nadie mira cuando diseña.

Dónde se rompió, exactamente

El problema apareció en el momento de la aprobación. Los aprobadores de los albaranes eran perfiles de gestión técnica, no perfiles contables. Y el desglose que el sistema generaba, aunque fuera correcto hasta el último decimal, exigía un nivel de comprensión contable que ese perfil no tenía por qué dominar.

En la práctica, el aprobador veía un albarán con todos los trabajos realizados, y eso lo entendía perfectamente: sabía qué intervención se había hecho, en qué inmueble, y si correspondía. Pero esos mismos trabajos aparecían agrupados por tipo de IVA (10%, 21%, exentos), y ahí los números empezaban a no cuadrarle a simple vista. Encima, veía las cuentas contables agrupadas según la tipología de trabajo, un segundo criterio de agrupación superpuesto al primero que tampoco entendía. El técnico dominaba los trabajos realizados. No dominaba, ni tenía por qué, los criterios contables analíticos con los que el sistema había decidido organizar esa misma información.

El resultado no fue rechazo directo. Fue algo más lento y más costoso: confusión, dudas, y retrasos en la aprobación de albaranes que, en realidad, estaban perfectamente calculados. El sistema no había fallado. Había fallado la traducción entre lo que el sistema sabía y lo que la persona que tenía que decidir podía entender con la información que se le mostraba.

Por qué es tan fácil no verlo

Cuando se diseña un sistema así, toda la energía del equipo técnico se concentra en que el cálculo sea correcto: que el desglose por IVA cuadre, que el reparto de costes sea exacto, que no haya errores de redondeo. Es un trabajo real, difícil, y fácil de medir. Lo que no se mide con la misma facilidad es si la persona al otro lado de la pantalla puede tomar una decisión con esa información sin tener que pararse a descifrarla primero.

Y hay una segunda razón, más estructural, que va más allá de este proyecto concreto: negocio e IT son como esa imagen de la Capilla Sixtina, con el dedo que se acerca sin llegar a tocarse del todo. Son dos mundos que deberían entenderse, pero que muchas veces hablan lenguajes muy distintos. Es habitual que el perfil técnico se acerque a negocio, que intente traducir, que busque el punto de encuentro. Pero al perfil de negocio le resulta mucho más resistente entender cómo se estructura técnicamente una solución. Esa asimetría no es simétrica en ningún sentido: hace que las definiciones de lo que realmente se necesita queden vagas, y que peticiones de altísima complejidad se acepten como plausibles simplemente porque nadie en la sala tiene la autoridad ni el conocimiento para cuestionarlas con propiedad.

Cómo lo aplico ahora

Lo que aprendí de este caso es que, por muy complejo que sea el cálculo por detrás, a la capa de decisión hay que darle la información estructurada de forma que pueda consumirla de manera sencilla y efectiva. Si alguien tiene que tomar una decisión, no hay que abrumarlo con toda la información disponible. Hay que darle exactamente la que necesita para decidir con total rigor, ni más ni menos.

Eso significa, en la práctica, separar dos capas que antes tratábamos como una sola: la capa donde el cálculo ocurre, que puede (y debe) ser tan compleja como el problema lo exija, y la capa donde alguien decide, que necesita una interfaz de comprensión simple, aunque lo que soporte esa interfaz sea sofisticado. Confundir ambas capas es lo que convierte un proyecto técnicamente brillante en un proyecto que nadie sabe usar con confianza.

En términos prácticos, esto se traduce en preguntas muy concretas antes de dar un diseño por bueno: ¿qué es lo mínimo que esta persona necesita ver para saber si aprueba o rechaza? ¿Puede tomar esa decisión sin tener que abrir una segunda pantalla, sin llamar a nadie, sin tener que verificar manualmente que el desglose cuadra? Si la respuesta exige formación adicional para el usuario, normalmente no es un problema de formación. Es una señal de que el diseño ha delegado en la persona un trabajo de interpretación que debería haber resuelto el propio sistema antes de mostrarle nada.

Donde sí hace falta más profundidad, no menos

Esto tiene un matiz importante, y no es una excepción a la regla, es un refinamiento de ella. Cuando hablamos de temas que impactan la representación legal de la empresa, o que tienen implicaciones legales directas, el impacto de una decisión mal tomada tiene una repercusión mucho más elevada, y ahí no puede existir el mínimo error. Eso no justifica darle menos información a quien decide, todo lo contrario. Justifica darle más profundidad, pero con una estructura igual de simple y autoexplicativa que soporte esa profundidad adicional.

La regla no cambia: la estructura sigue siendo lo que hace la información consumible. Lo que cambia es cuánta profundidad necesita esa estructura para sostener una decisión de mayor riesgo. Simplificar en exceso un caso de alto impacto legal, solo por aplicar la misma regla sin matiz, sería tan peligroso como abrumar de datos a alguien que solo necesita aprobar un albarán bien calculado.

La objeción que me tomo en serio

Un responsable técnico defendería, con razón parcial, que la calidad y complejidad del cálculo ya es el verdadero valor del proyecto, y que si negocio no lo entiende, es un problema de formación de negocio, no de diseño de la solución.

Es una objeción que entiendo, porque en parte protege algo real: no se puede simplificar hasta el punto de perder rigor técnico solo para que resulte cómodo de leer. Pero la objeción se sostiene mal cuando se mira con honestidad la asimetría que describía antes. Pedirle a negocio que entienda la estructura técnica al mismo nivel que IT entiende el negocio no es una expectativa razonable, ni siquiera es una expectativa recíproca. El perfil técnico tiene, casi siempre, más facilidad y más incentivo para acercarse al lenguaje de negocio que al revés. Si esa asimetría es la norma, diseñar como si no existiera no es un problema de formación ajena. Es un problema de diseño propio.

Para el lunes

La próxima vez que termines un desarrollo técnicamente sólido, no preguntes si el cálculo es correcto. Ya lo sabes, para eso lo has construido con cuidado. Pregunta si la persona que tiene que aprobarlo, usarlo o decidir sobre él, puede hacerlo con la información que le vas a mostrar, sin tener que llamarte a ti para que se lo traduzcas. Si la respuesta es no, el proyecto no está terminado. Solo está calculado.

También te puede interesar

← Volver al blog