Cómo decidir si construyes o compras una solución de IA: el proceso paso a paso

El problema no es elegir mal, es no tener proceso

La pregunta “¿construimos o compramos?” casi nunca se resuelve con información, se resuelve con la opinión de quien habló último. Tecnología llega con ganas de construir porque quiere control y aprendizaje interno. Negocio llega con ganas de comprar porque quiere el resultado operando este trimestre. Los dos argumentos son legítimos y los dos son incompletos si nadie documentó el dolor real ni comparó alternativas concretas antes de sentarse a discutir.

Ya existe una tabla de criterios para comparar las dos opciones (costo total, velocidad, control, dependencia del proveedor, mantenimiento), y vive en la guía hermana “Build vs buy solución de IA”. El problema es que tener la tabla no resuelve nada si nadie llenó las columnas con datos propios. Esta guía es el proceso para llegar a esa tabla con información real: qué recolectar primero, en qué orden evaluar, quién tiene que estar en la sala y cómo se documenta la decisión final para poder revisarla después si las condiciones cambian.

El error más común no es construir cuando tocaba comprar, ni comprar cuando tocaba construir. Es no tener un proceso explícito de decisión: sin uno, la elección la termina haciendo la persona con más peso político en la sala, no el dato.

Qué resuelve exactamente este proceso

Este proceso no compara costos ni vendor lock-in, esa comparación ya está resuelta en la guía de criterios. Lo que resuelve es cómo llegar hasta ahí: qué información juntar antes de evaluar, en qué secuencia se hace, y cómo se deja constancia de la decisión para que no dependa de la memoria de quien estuvo en la reunión.

El resultado esperado no es “construimos” o “compramos” como frase suelta en un chat. Es un documento corto, puede ser una página, con el dolor descrito, las alternativas evaluadas, el costo proyectado a dos o tres años y la razón explícita de la elección. Ese documento es el que se revisa si las condiciones cambian, no la opinión de nadie meses después.

El proceso paso a paso

Estos son los cinco pasos, en orden. Saltarse el orden, por ejemplo evaluar proveedores antes de documentar el dolor, es la forma más común de terminar comparando alternativas que no resuelven lo mismo.

Paso 1: documenta el proceso exacto y el dolor que se quiere resolver

Antes de hablar de tecnología, se escribe qué proceso de negocio se quiere cambiar, cómo funciona hoy (no como dice el manual, como ocurre de verdad) y cuánto cuesta ese proceso en tiempo, dinero o errores. Sin esto, cualquier alternativa, construida o comprada, se evalúa contra una idea vaga, no contra un dolor medido. Esta documentación no necesita ser extensa, necesita ser específica: “el equipo pierde tres horas al día conciliando pedidos entre dos sistemas” es útil, “necesitamos más eficiencia operativa” no lo es.

Paso 2: evalúa dos o tres alternativas reales de comprar

Incluso si la intuición ya apunta a construir, se evalúan formalmente dos o tres plataformas o proveedores que existan hoy en el mercado para ese proceso. No es una búsqueda superficial de veinte minutos: es probar cada alternativa contra el dolor documentado en el paso uno y anotar, con datos, qué tanto lo resuelve sin recurrir a workarounds forzados. Este paso se hace incluso cuando parece un trámite, porque casi siempre cambia la conclusión que se daba por sentada al entrar a la reunión.

• Qué tan bien cubre el proceso tal cual funciona hoy, sin obligar a rediseñar la operación para que le quepa al producto.
• Qué tan rápido se puede probar con datos reales de la empresa, no solo con una demo genérica del proveedor.
• Qué pasa con los datos y el conocimiento operativo si algún día se cambia de proveedor: la portabilidad se revisa aquí, no después de firmar.

Paso 3: estima el costo real de construir, no solo las horas de desarrollo

El error más caro de este paso es cotizar solo el desarrollo inicial. El costo real de construir incluye el mantenimiento de los próximos dos o tres años: monitoreo del sistema en producción, ajustes cuando el proceso cambia, actualización cuando el modelo o la API subyacente cambia, y el tiempo de quien tiene que responder cuando algo falla un sábado. Una solución construida que nadie proyectó cómo mantener no es más barata que comprar, solo pospone el gasto y lo esconde en el presupuesto de otra área.

• Costo de desarrollo inicial, sea con equipo propio o con un proveedor externo contratado para eso.
• Costo de mantenimiento anual proyectado a dos o tres años, no un estimado optimista de “no debería fallar mucho”.
• Costo de la capacidad interna necesaria para sostenerlo si la persona o el proveedor que lo construyó ya no está disponible.

Paso 4: reúne a negocio y tecnología en la misma sala para decidir juntos

Esta decisión no la toma bien un solo lado. Tecnología sola tiende a sobrevalorar el control y a subestimar el tiempo real de desarrollo. Negocio solo tiende a sobrevalorar la velocidad de comprar y a subestimar el costo de mantenimiento. La reunión de decisión necesita a quien es dueño del proceso de negocio y a quien va a sostener la solución técnicamente, con los datos de los pasos uno a tres sobre la mesa, no con un resumen verbal de lo que cada quien recuerda.

Paso 5: documenta la decisión con su razón explícita

La decisión final se escribe, no se asume. Un documento corto que diga qué se decidió, qué alternativas se evaluaron, qué costo se proyectó y por qué se eligió esa opción sobre las otras. Ese documento cumple dos funciones: obliga a que la razón sea explícita, no “nos pareció mejor”, y sirve de referencia si en un año hay que revisar la decisión porque el volumen, el presupuesto o el mercado cambiaron.

Los errores que se repiten en este proceso

• Saltarse el paso uno: evaluar proveedores o estimar el desarrollo antes de documentar el dolor con datos propios, comparando alternativas contra una idea vaga en vez de un proceso medido.
• Evaluar el mercado a medias cuando la intención ya es construir: mirar una sola plataforma por cumplir el trámite, sin ponerla a prueba en serio contra el dolor real.
• Cotizar solo el desarrollo inicial y dejar el mantenimiento de los próximos años fuera de la conversación, hasta que aparece como sorpresa en el presupuesto del siguiente año.
• Dejar la decisión en un solo lado: que tecnología decida sin negocio en la sala, o que negocio decida sin nadie que entienda el costo real de sostener lo construido.
• No escribir la razón de la decisión: decidir en una reunión y no dejar constancia, de forma que un año después nadie recuerda por qué se eligió esa opción y la revisión se vuelve una discusión nueva desde cero.

Cómo se ve esto en la práctica

Una empresa de logística mediana quería resolver la conciliación manual entre su sistema de pedidos y el de facturación, un proceso que le costaba varias horas diarias a dos personas y generaba errores frecuentes en los cobros. La primera reacción del equipo técnico fue proponer construir un conector propio. Antes de aprobarlo, se aplicó el proceso: se documentó el dolor exacto (horas perdidas y monto promedio de los errores de facturación al mes), se evaluaron dos plataformas de integración ya existentes en el mercado, y se estimó el costo del conector propio a tres años, incluyendo quién lo iba a mantener si la persona que lo programara dejaba la empresa.

El resultado no fue el que el equipo técnico esperaba al inicio: una de las plataformas evaluadas cubría la mayor parte del proceso sin workarounds forzados, y el costo de mantenerla era menor que el de sostener un conector propio con una sola persona como único punto de conocimiento. Se decidió comprar para ese proceso específico y se documentó la razón, incluyendo la condición bajo la cual se reconsideraría construir: si el volumen crecía lo suficiente como para justificar el control adicional.

El punto no es que comprar siempre gane, es que la decisión salió de datos comparables y no de la preferencia inicial del equipo técnico. Si el resultado del paso dos hubiera sido que ninguna plataforma cubría el proceso sin parches forzados, el mismo proceso habría llevado a construir, con el costo de mantenimiento ya proyectado desde el inicio.

Mi criterio

Cómo saber si este proceso se ejecutó bien

No se mide por si la decisión fue construir o comprar, las dos pueden ser correctas dependiendo del caso. Se mide por si el proceso para llegar ahí quedó completo y documentado.

• Existe un documento con el dolor descrito en números, no en sensaciones.
• Se evaluaron de verdad dos o tres alternativas de comprar, con evidencia de cómo cada una cubrió o no el caso.
• El costo de construir incluye una proyección de mantenimiento a dos o tres años, no solo el desarrollo inicial.
• La decisión final tiene una razón escrita y una condición explícita bajo la cual se reconsideraría.
• Negocio y tecnología estuvieron en la misma conversación antes de decidir, no en conversaciones separadas que alguien tuvo que reconciliar después.

Una señal de alerta temprana: si a los pocos meses de operar nadie puede explicar por qué se eligió construir o comprar sin recurrir a “fue lo que decidimos en su momento”, el proceso no se documentó bien, aunque la elección técnica haya sido correcta.