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

Transformación digital

Transformar no es migrar

·7 min de lectura

Hace años, en un servicer inmobiliario donde trabajaba, la dirección de operaciones impulsó la construcción de una herramienta específica para el proceso de formalización de contratos. El sistema que existía entonces centralizaba toda la operativa de negocio: carteras, activos, procesos comerciales, seguimiento. Funcionaba, con sus límites, como funciona cualquier sistema que lleva años en producción. Pero para el proceso de formalizaciones, la dirección de operaciones decidió que necesitaba algo propio, diseñado a su medida, sin depender de la hoja de ruta de IT.

Se aprobó, se contrató, se construyó. Y se convirtió en uno de esos proyectos que se recuerdan durante años, no por lo que consiguió, sino por lo que costó conseguirlo: cinco veces el presupuesto inicial, varios meses de retraso, y una complejidad de uso tan alta que, cuando por fin se puso en marcha, el propio equipo de negocio, el que supuestamente iba a beneficiarse de tener "su" herramienta, no la respaldó.

La tesis

Transformar no es migrar. No es cambiar de sistema, ni construir uno nuevo, ni dejar de usar el que ya existe. Transformar es cambiar cómo se decide qué hace falta de verdad, y esa pregunta casi nunca se resuelve comprando o construyendo una herramienta antes de entenderla.

Dónde se rompió, exactamente

Quedó claro casi desde el principio. No fue un fallo técnico que se descubriera a mitad de desarrollo, fue una directriz. El director de operaciones estaba más interesado en dejar su firma en algo propio que en evaluar honestamente si lo que ya existía funcionaba o cubría las necesidades reales del equipo. Y ese punto de partida contaminó todo lo que vino después.

El sistema se diseñó desde la excepción, no desde lo común. En vez de construir una lógica que respondiera a las necesidades funcionales más repetitivas (el 80% de los casos que se repiten cada semana, cada mes), se diseñó pensando en los casos especiales, los bordes, las excepciones que ocurren pocas veces pero que "algún día podrían pasar". Esa decisión, tomada en el diseño inicial, es la que generó una lógica de funcionamiento tremendamente compleja: un sistema pensado para manejar cualquier excepción imaginable acaba siendo difícil de usar incluso para el caso normal.

Y para colmo, como no fueron capaces de llevarse la funcionalidad completa a la nueva herramienta, tuvieron que construir además una capa de integración con el sistema que ya estaba en funcionamiento. El proyecto que nació para sustituir al sistema original terminó necesitando hablar con él de todas formas, solo que ahora con una capa adicional de complejidad, de puntos de fallo, y de coste de mantenimiento que no existía antes.

Por qué es tan fácil no verlo

Hay algo seductor en la idea de construir algo propio. Un sistema hecho a medida promete resolver exactamente lo que el sistema genérico no resuelve, y quien lo impulsa suele estar convencido de que conoce el negocio mejor que nadie, incluida la gente que va a usarlo cada día. Ese exceso de confianza no es mala fe. Es un sesgo muy humano: cuanto más arriba estás en la jerarquía, más fácil es confundir "lo que yo creo que necesita el equipo" con "lo que el equipo necesita de verdad".

Y hay una segunda razón, más estructural: construir algo nuevo es más visible, más atribuible, más fácil de defender en un comité que decir "vamos a configurar mejor lo que ya tenemos". Un proyecto nuevo tiene nombre, presupuesto propio, un equipo dedicado. Reconfigurar un sistema existente no genera el mismo relato de logro, aunque a menudo sea la decisión correcta.

Y hay una tercera razón, la más difícil de detectar desde dentro: este tipo de decisiones casi nunca están especialmente argumentadas en datos. Se toman desde la convicción, desde la urgencia de resolver algo que molesta, desde la certeza personal de quien las impulsa. Normalmente los procesos de negocio que se quieren digitalizar ni siquiera están bien documentados, o lo están de forma vaga, y no se tiene claro ni la volumetría real de casos ni los tiempos operativos de ejecución de esos procesos. Se aprueba un proyecto de varios cientos de miles de euros sobre una base de "todos sabemos que esto hace falta", sin que nadie haya medido cuántas formalizaciones se procesan al mes, cuánto tarda cada una hoy, ni qué porcentaje de esos casos son realmente excepcionales frente a los que se repiten cada semana. Sin ese dato de partida, cualquier discusión posterior sobre si el proyecto tiene sentido se libra a ciegas.

Cómo lo aplico ahora

Hoy, cuando alguien llega con la propuesta de construir o comprar una herramienta específica, hacemos un análisis profesional antes de comprometer nada: qué cubre exactamente, cuándo se va a utilizar, qué capacidades presenta a nivel de capa informacional, cómo se integra con los sistemas vigentes, qué implicaciones tiene en seguridad y tratamiento de la información. Y con todo eso encima de la mesa, decidimos si de verdad merece la pena por el retorno de la inversión que se obtiene.

No es un proceso para bloquear iniciativas. Es un proceso para que la decisión de construir algo nuevo se tome con la misma disciplina con la que se toma cualquier otra inversión, no con la urgencia de quien quiere ver su idea hecha realidad cuanto antes.

Donde sí hace falta construir algo nuevo

Esto tiene un límite claro, y conviene decirlo porque "nunca construyas nada nuevo, reconfigura lo que tienes" sería tan simplista como el error contrario. Existen casos claros donde construir una herramienta específica es la decisión correcta, especialmente cuando se trata de modelos con muchas ejecuciones, procesos estandarizables, asociados a una especificación particular del negocio que ningún sistema genérico va a cubrir bien.

Un ejemplo real: una herramienta de scoring y valoración de potenciales inquilinos para procesos de alquiler, donde el cliente sube su documentación y el sistema ejecuta automáticamente el scoring, conecta con listas de blanqueo de capitales y morosidad, y decide si el perfil es potencialmente válido para pasar a validación manual por el equipo de formalizaciones. Ese es un proceso de alto volumen, altamente repetitivo, con reglas de negocio específicas y una necesidad real de automatización que ningún ERP genérico resuelve de fábrica.

La diferencia con el caso de la herramienta de formalizaciones no está en si se construye algo nuevo o no. Está en si el diseño responde a lo común y repetitivo (donde construir aporta valor real) o si responde a la excepción y al deseo de tener algo propio, que es donde la complejidad se dispara sin que el retorno lo justifique.

La objeción que me tomo en serio

La objeción de la dirección de operaciones, en su momento, fue clara: IT no tenía el conocimiento de negocio, no entendía las necesidades funcionales reales, y por tanto no era quién para frenar ni para diseñar la solución.

Es una objeción que merece tomarse en serio, hay mucho proyecto de IT fracasado precisamente por construir soluciones técnicamente correctas pero desconectadas de cómo funciona el negocio de verdad. El problema, en este caso concreto, es que la propia dirección de operaciones fue incapaz de plasmar esas necesidades en un documento con un nivel de detalle mínimamente operable. Contrataron equipos externos, y el resultado fueron requisitos de alto nivel, con nulo detalle, muchos de ellos contradictorios entre sí, algo que se hizo evidente en la primera conversación seria sobre el documento.

Al final, con el apoyo forzado de analistas de IT, el documento de definición funcional creció hasta más de 350 páginas. Trescientas cincuenta páginas para explicar algo que, según la objeción original, IT "no podía entender" porque no conocía el negocio lo suficiente. Si hacen falta 350 páginas para especificar un proceso, la objeción no sostiene lo que pretendía sostener: el problema no era que IT no entendiera el negocio. Era que nadie, ni negocio, ni IT, ni los consultores externos, tenía todavía una idea suficientemente clara de lo que hacía falta construir.

Esa es, quizá, la lección más incómoda del caso: cuando un proyecto necesita cientos de páginas para explicarse a sí mismo antes de empezar, no es un problema de documentación. Es la señal de que el proyecto todavía no está listo para construirse.

Para el lunes

La próxima vez que alguien te proponga cambiar de sistema o construir algo nuevo, no preguntes primero qué herramienta hace falta. Pregunta qué es lo que realmente se necesita, y exige que esa respuesta esté vinculada al proceso real: cuántas veces se ejecuta, cuánto tarda hoy, y qué parte de ese volumen es el caso común frente a la excepción. Si nadie en la sala puede responder eso con datos, todavía no estáis hablando de una herramienta. Estáis hablando de una intuición sin verificar, y ese es el momento de pararse, no el de firmar el contrato.

También te puede interesar

← Volver al blog