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

PropTech

Comprar vs construir: la pregunta que nadie hace antes de firmar

·9 min de lectura

En un servicing, abordamos la diferenciación entre Build to Sell y Build to Rent: dos modelos operativos completamente distintos, desde el AML hasta el proceso de firma, y sobre todo en la gestión posterior del alquiler. Esa diferencia obligaba a tener dos plataformas diferenciadas, y ahí surgió la pregunta que parece simple hasta que la tienes delante de verdad: ¿lo compramos o lo construimos?

Evaluamos muchos productos del mercado. Algunos resolvían bien la parte de firma electrónica, pero no tenían ni idea de cómo gestionar un alquiler una vez firmado. Otros gestionaban bien el ciclo de vida del alquiler, pero trataban el AML como un trámite añadido, no como una pieza central del proceso. Ninguno se ajustaba a las necesidades informacionales reales de un fondo de inversión, ni a una operativa moderna, ni a una visión de centralización del cliente como parte central de la solución.

Las soluciones PropTech seguían siendo muy incipientes, muy centradas en resolver problemas concretos, pero ninguna se presentaba como una solución validada para el conjunto de la operativa. La consecuencia práctica, si querías cubrir el ciclo completo comprando, era montar un tetris de tres o cuatro productos distintos, cada uno excelente en su parcela, y ninguno diseñado para hablar con los demás. Cada pieza del tetris resolvía su problema. El conjunto generaba uno nuevo: quién es el dueño del dato del cliente cuando ese cliente pasa de un sistema a otro en mitad de su relación con el servicing.

Esta falta de interconexión no era una rareza de aquel proyecto concreto. Era, y sigue siendo hoy, uno de los problemas más acuciantes de la primera era PropTech: cada sistema sigue estructurando la información según su propia lógica interna, pensada para resolver su parcela, no para convivir con las demás. Si para gestionar bien una operativa necesitas encadenar tres, cuatro o cinco productos distintos, el verdadero reto deja de ser elegir buenos productos. Se convierte en resolver cómo esos productos intercambian información entre sí sin perder ni contaminar los datos por el camino. La mejor solución que encontramos para eso no fue insistir en que los productos se integraran directamente entre sí, sino crear un stage informacional propio que actuara de core: alguien que recoge la información de todos lados, la cura, y la traduce a un formato común que todos los sistemas puedan entender, en lugar de dejar que cada sistema hable su propio idioma con los demás.

La tesis

Cuando ninguna opción del mercado se ajusta y construir puede ser un fracaso, la pregunta correcta no es "comprar o construir". Es qué parte del problema es tan específica que merece una capa propia, y qué parte ya está resuelta lo suficientemente bien en el mercado como para no reinventarla.

Dónde se rompió, exactamente

Decidimos construir. Fue un proyecto costoso en tiempo y en dinero, y al final no cumplió la expectativa. El fracaso no vino de un error técnico puntual, vino de algo más de fondo: construir nos hizo depender de áreas de negocio que no estaban bien estructuradas para definir un producto de esa magnitud.

No es lo mismo reducir la definición a un caso de uso concreto que hablar de un proyecto con distintas capas de arquitectura e integración, que exige una visión holística de las necesidades y de cómo encajan entre sí, no una definición desde el detalle aislado. Negocio sabía describir procesos concretos: cómo se firma un contrato, qué pasa en una incidencia de mantenimiento. Lo que no sabía, ni tenía por qué saber, era cómo esos procesos debían encajar en una arquitectura conjunta que soportara ambos modelos operativos a la vez, con sus flujos de información compartidos y sus puntos de divergencia.

Construir, en ese contexto, no fue una decisión de ingeniería. Fue delegar en negocio un ejercicio de arquitectura que negocio nunca había tenido que hacer.

Por qué es tan fácil no verlo

Cuando el mercado no ofrece nada que encaje, construir parece la única alternativa razonable. La lógica es simple: si nadie lo ha resuelto bien, lo resolvemos nosotros. Pero esa lógica esconde una trampa, porque asume que la organización que va a definir el proyecto tiene la misma madurez que la organización que va a definir un caso de uso puntual. Son capacidades distintas, y la segunda no garantiza la primera.

Y hay una segunda razón, más general: comprar y construir se presentan casi siempre como dos opciones excluyentes, cuando en realidad el problema casi nunca es monolítico. Un ciclo operativo completo (captación, AML, firma, gestión del alquiler, cobro) tiene partes que el mercado resuelve razonablemente bien, y partes que son tan específicas del propio modelo de negocio que ningún producto genérico las va a cubrir nunca del todo. Tratar la decisión como un sí o un no para todo el ciclo es lo que lleva, casi inevitablemente, a construirlo todo desde cero o a aceptar un tetris de productos que no hablan entre sí.

Cómo lo aplico ahora

El enfoque que aplicaría hoy es distinto: hacer uso de plataformas que ya resuelven bien los problemas complejos que no son diferenciales para el negocio, y construir una capa core de producto propia que integre esas soluciones mediante un middleware potente de sincronización. Sobre eso, un maestro de información que actúe como datalake de unificación de los distintos actores integrados: el AML de un proveedor, la firma de otro, la gestión del alquiler quizás de un tercero, todo orquestado y centralizado desde una capa propia que sí entiende la visión completa del cliente y del negocio.

La diferencia con construirlo todo no es solo de coste. Es de dónde se concentra el riesgo. Construir todo desde cero pone en riesgo cada pieza del ciclo operativo a la vez. Construir solo la capa de integración y orquestación, apoyándose en soluciones de mercado ya maduras para lo que no es diferencial, concentra el riesgo únicamente en la pieza que de verdad aporta ventaja competitiva: el maestro de información y la visión centralizada del cliente.

Para decidir qué pieza cae en cada lado, uso un criterio bastante concreto, no una intuición: si puedes contratar algo que tenga un retorno directo comparando el coste operativo que te ahorra frente al coste del producto, y además esa solución es escalable con un coste bajo a medida que el negocio crece, cómpralo, aunque no sea perfecto. Si no existe nada en el mercado que cumpla esas dos condiciones a la vez (retorno directo y escalabilidad barata), esa pieza es candidata real a construirse, porque significa que el mercado todavía no ha resuelto ese problema de forma que compense pagarlo en vez de construirlo.

Aplicado al caso de Build to Sell y Build to Rent, esto habría significado algo muy distinto de lo que hicimos entonces. En lugar de construir dos plataformas completas desde cero, habría tenido sentido identificar qué proveedores de mercado resolvían bien el AML y la firma electrónica para ambos modelos, dejarles esa parte, y concentrar el desarrollo propio en la capa que sí era genuinamente distinta entre Build to Sell y Build to Rent: el modelo de gestión posterior del alquiler, y el maestro de información que unificara al cliente independientemente de qué plataforma comercial lo hubiera captado. Esa capa core es pequeña comparada con construir el ciclo completo, pero es exactamente donde vive la diferencia competitiva real. El resto es infraestructura que el mercado ya sabe hacer, y pagar por ella es más barato que reconstruirla mal.

Donde sí merece la pena construir desde cero

Esta regla tiene una excepción clara, y no es menor: cuando el mercado en el que operas es muy incipiente, o el modelo de negocio es tan cambiante que sabes de antemano que vas a necesitar mucha capacidad de adaptación y de cambio constante. En esos casos, no tiene sentido buscar un producto de mercado que no va a existir todavía, ni construir una solución rígida que se quede obsoleta en la siguiente vuelta del negocio.

Ahí lo que hay que sentar son bases de arquitectura modulares, pensadas explícitamente para ir incorporando cambios en los distintos anillos informacionales según el negocio evoluciona. No es "construir todo de golpe", es construir con la expectativa deliberada de que el diseño de hoy va a cambiar, y prepararlo para eso desde el principio.

La objeción que me tomo en serio

Un CFO tiene una presión obvia de obtención de resultados: hay que mejorar inmediatamente los resultados de la compañía, y eso arrastra también a los sistemas de información. Esa presión lleva, de forma natural, a una visión resultadista: comprar algo, implantarlo, y dar un salto visible cuanto antes.

Es una objeción legítima, y entiendo de dónde viene. El problema es que esa decisión, tomada bajo esa presión, suele ser una resolución a modo de parche que no resiste después del impacto inicial, porque no resuelve de verdad el problema de fondo. El salto se ve bien en el primer trimestre. Pero si la solución comprada no cubre el ciclo operativo completo ni permite la centralización de cliente que el negocio necesita, el parche empieza a mostrar sus costuras en cuanto el negocio crece o cambia, y entonces el coste de corregirlo es mayor que si se hubiera invertido ese tiempo al principio en definir bien qué construir y qué comprar.

Un caso real de este mismo patrón, muy repetido en el sector: promotoras que dan el salto de gestionar todo en Excel a un sistema monolítico que cubre contratos, facturación y contabilidad de una sola vez. A corto plazo es un salto visible, y el CFO lo puede enseñar como una mejora inmediata. Pero rápidamente se dan cuenta de que ese sistema no responde al reporting que el negocio necesita, y añade una complejidad operativa que antes no existía, porque no puede adaptarse a la manera en que la promotora hace sus seguimientos presupuestarios reales. El sistema resolvió el problema visible, dejar de usar Excel, y dejó intacto el problema de fondo: tener la información estructurada de la forma en que el negocio realmente necesita decidir y hacer seguimiento. Ese es el coste oculto del parche resultadista, no se ve en el primer trimestre, se ve en el primer cierre de presupuesto que no cuadra con lo que el sistema es capaz de darte.

Para el lunes

La próxima vez que te enfrentes a una decisión de comprar o construir, no la plantees como una elección única para todo el proyecto. Divide el ciclo operativo en piezas, y pregúntate, pieza por pieza, cuál es genuinamente diferencial para tu negocio y cuál no. Lo que no sea diferencial, cómpralo, aunque no sea perfecto. Lo que sí lo sea, constrúyelo, pero solo si tienes la madurez organizativa para definirlo con visión de conjunto, no como una suma de casos de uso sueltos.

También te puede interesar

← Volver al blog