Comprar o construir. No hay una regla universal, y los expertos no siempre están de acuerdo. Por ejemplo, Canadá prioriza una política de comprar, mientras que el Reino Unido recomienda construir internamente las plataformas core y comprar las piezas de alrededor. Por este motivo, cada vez que lanzamos un nuevo proyecto se plantea el mismo dilema: adquirir un producto de mercado que ya existe, o desarrollar una solución a medida para lo que necesitamos. Dos caminos, y la sensación de que hay que elegir uno para todo el proyecto.

Este artículo presenta una reflexión sobre un paso previo que no se suele realizar: descomponer el sistema en piezas y preguntarse, para cada pieza: ¿esto es core, estratégico o innovador para nosotros, o es infraestructura que necesita todo el mundo?

Un sistema no es una decisión única

"¿Construimos o compramos la plataforma de subvenciones?" Esa forma de preguntar es el primer error que solemos cometer, porque "la plataforma de subvenciones" no es una única cosa. Es una forma de identificarse, un sitio donde guardar documentos, un motor de notificaciones, formularios, informes, un flujo de aprobación y una lógica que codifica las reglas propias de esa administración. No es una decisión: son ocho, y merecen ocho respuestas.

Cuando se decide para el bloque entero en lugar de para las piezas, se cae en uno de dos errores. O la parte específica asusta —"nuestra normativa es complicada, ningún producto la cubrirá"— y se construye todo a medida —incluidas piezas comunes, como el inicio de sesión o el gestor documental, que luego hay que mantener—. O se compra una gran plataforma que promete hacerlo todo y se asume que encajará tal cual, sin identificar qué piezas exigirán más atención. Los dos errores nacen de no haber descompuesto primero.

Una vez descompuesto el sistema en piezas, toca analizar y entender cada una para situarlas en una línea que va de lo más nuestro —lo core, lo estratégico, lo innovador— a la infraestructura común que necesita todo el mundo. De dónde caiga cada pieza depende su respuesta: construir hacia un extremo, comprar hacia el otro.

Complejidad no es singularidad

Analizar y situar cada pieza exige espíritu crítico, porque es fácil clasificarla mal. Un error muy habitual es confundir lo complejo con lo propio. "Esto está lleno de reglas, de plazos, de controles; tiene que ser nuestro”. Parece razonable y casi siempre es falso, porque la complejidad de un proceso público rara vez es propia. A menudo viene de la ley, del reglamento, de la directiva y entonces no es diferencial. Cualquier otra administración sujeta a la misma norma tiene la misma complejidad. Y otras veces esa complejidad viene de un proceso que se ha ido complicando con los años y que podría simplificarse en lugar de trasladarse tal cual al nuevo sistema.

Entonces, ¿cuándo debo construir?

El primer caso es cuando la pieza sea genuinamente propia: el core de la misión de la institución, ventaja diferencial o estratégica por soberanía. A veces una pieza hace lo mismo que haría un producto de mercado y aun así debe ser propia, porque lo que está en juego es el control: datos de salud, de identidad, de seguridad; infraestructura crítica de la que depende un servicio esencial. Ahí, depender de un proveedor único deja de ser una cuestión de coste y pasa a ser una cuestión de quién manda en la infraestructura pública. Es lo que hizo el Ayuntamiento de Boston al construir su propia capa intermedia entre sus servicios y los modelos de IA: compró lo común y construyó la parte estratégica que le garantiza autonomía frente a cualquier proveedor.

El segundo caso es cuando no exista una solución de mercado. No porque la pieza sea especialmente propia, sino porque nadie la vende, ya sea porque es demasiado nueva o porque es un nicho público que ningún proveedor ha encontrado rentable. 

Fuera de esos dos casos, la pieza es común, y el sitio por defecto de lo común es comprar.

Comprar también es una decisión activa

Decidir comprar no significa que la decisión esté cerrada. Porque comprar bien exige, para cada pieza comprada, tres juicios que solo es posible hacer si se ha descompuesto y entendido bien la pieza.

El primero: ¿tendremos que cambiar nuestros procesos para encajar con el producto? Y si es así, ¿estamos dispuestos? Un buen producto de mercado trae consigo una forma de trabajar. Muchas veces, adaptar el proceso al producto es exactamente lo que se debe hacer y lo que más cuesta hacer. 

El segundo: ¿qué hay que configurar y dónde está la tentación de personalizar? Configurar, es decir, ajustar las opciones que el producto ya ofrece es lo recomendable. En cambio, personalizar, es decir modificar su código para amoldarlo a una forma de trabajar, es lo que conviene evitar: cada modificación genera una dependencia del proveedor y suele impedir recibir actualizaciones, de modo que se acaba manteniendo una versión obsoleta de un producto por el que se sigue pagando.

El tercero: ¿necesitaremos construir algo específico que complemente? A veces el producto cubre el 90% y falta una pieza menor, muy específica, que sí es propia. Ese pequeño desarrollo, hecho alrededor del producto y no dentro de él, es a menudo la diferencia entre una compra que encaja y una que no.

Estos tres juicios son la razón por la que descomponer importa tanto del lado de comprar como del de construir. Sin la descomposición, se compra un bloque entero a ciegas y se confía en que encaje. Con ella, se sabe de antemano qué piezas van a exigir cambiar de forma de trabajar, cuáles tocar con cuidado y cuáles complementar.

El caso de Phoenix

El caso más caro del que tenemos noticia es, precisamente, el de una administración que compró, pero no hizo ninguno de esos juicios. En 2009 el Gobierno de Canadá adquirió un producto comercial solvente para sus nóminas. Pero su función pública tenía más de cien convenios y decenas de miles de reglas salariales, y en lugar de preguntarse qué procesos debía simplificar para poder utilizar el producto, decidió personalizarlo para que se amoldara a sus procesos y le añadió más de doscientos desarrollos a medida encima. El sistema, conocido como Phoenix, dejó de pagar correctamente a decenas de miles de funcionarios y ha costado más de 5.000 millones de dólares. Su Auditoría General lo llamó "un fracaso incomprensible de gestión".

Phoenix no fracasó por comprar. Fracasó por comprar sin decidir: sin distinguir qué era común y debía adaptarse al producto, y qué era realmente suyo.

Descomponer es el trabajo

Al final, el trabajo de verdad no está en el "decidimos comprar" o "decidimos construir". Está en el paso previo de partir el sistema en piezas y clasificar cada una con capacidad crítica. ¿Esto es nuestro (core, estratégico, innovador) o solo lo parece? ¿Y si es común, qué me va a exigir comprarlo bien?

Y es un trabajo que hay que rehacer cada cierto tiempo, porque la clasificación no es permanente: la frontera se mueve. Hace pocos años, para que un sistema hiciera algo con inteligencia artificial había que entrenar un modelo propio a medida. Hoy buena parte de eso se resuelve con un modelo de propósito general. La pieza que ayer no tenía más remedio que construirse, hoy se compra. Lo que se clasificó bien una vez conviene volver a mirarlo.

Hacer ese trabajo protege de los dos errores caros a la vez: de construir lo que se podía haber comprado mejor y más barato y de comprar lo que se debía haber controlado —o de comprar sin prever que obligaría a rehacer los procesos de toda la organización—. Lo que no resulta casi nunca es todo comprado o todo construido. En su lugar, la clave es una mezcla desigual, decidida pieza a pieza. No hace falta una matriz de veinte variables. Hace falta descomponer y hacerse, en cada pieza, la única pregunta que ordena el resto.

‍