Construir o configurar: cómo decide Bredia qué tipo de solución encaja con cada cliente

Construir software a medida o configurar productos del mercado es la decisión que más temprano aparece en un proyecto de transformación y la que más caro cuesta corregir cuando se toma mal. Esta pieza enmarca la decisión con los cinco criterios que Bredia aplica cuando entra a un proyecto, los criterios que conviene descartar y cuatro ejemplos de cómo se materializa en proyectos reales sin nombrar al cliente.

La decisión que este artículo enmarca

Cuando una organización contrata transformación operativa, en algún momento del proyecto enfrenta la pregunta arquitectónica: ¿construimos software a medida para este flujo o configuramos un producto del mercado que ya existe? La pregunta parece técnica pero condiciona presupuesto, tiempo de implementación, capacidad de mantenimiento interno y dependencia con proveedor externo durante los siguientes tres a diez años.

Tomarla por defecto es la forma más común de equivocarla. Algunos proveedores responden "siempre construir" porque su modelo de negocio depende de horas de desarrollo. Otros responden "siempre configurar" porque venden licencias del producto. La respuesta correcta para una organización específica depende del problema operativo concreto que se va a resolver y de cinco criterios que se evalúan en conjunto.

Esta pieza expone los cinco criterios con los que Bredia toma la decisión cuando entra a un proyecto, los criterios que recomienda descartar y cuatro ejemplos de cómo la decisión se materializa en proyectos reales.

Criterio 1: madurez del proceso operativo

La primera pregunta es sobre el proceso, no sobre la tecnología. ¿El proceso operativo que vamos a soportar está bien definido, estandarizado y compartido por muchas organizaciones del sector? Si la respuesta es sí, un producto del mercado es probable buen ajuste. El producto encapsula la práctica madura del sector y la organización gana valor adoptándola.

Si el proceso es específico de la organización (procesos derivados de la forma particular de operar, ventajas competitivas reales codificadas en el flujo de trabajo, integraciones con sistemas internos que ningún otro actor del sector tiene), el producto del mercado obliga a degradar la operación a un denominador común. La adopción del producto en este caso destruye lo que diferencia operativamente a la organización.

La pregunta de criterio se resuelve mejor con una conversación que con una respuesta abstracta. Cuando entrevistamos a las personas que ejecutan el proceso, ¿describen el proceso como "estándar de la industria" o como "lo que nosotros hacemos distinto a los demás"? Si es lo primero, hay producto. Si es lo segundo, hay que construir o configurar con extensiones de gran calado.

Criterio 2: especificidad del workflow

El segundo criterio profundiza el primero. Los flujos altamente específicos (regulación regional poco cubierta por productos globales, integración con sistemas propios complejos, casos de borde frecuentes que un producto estándar no cubre) se acomodan mal en los productos del mercado. La organización termina configurando el producto para que se parezca a lo que necesita y descubre, en el sexto mes, que la configuración es tan extensa que la herramienta dejó de ser un producto y se volvió un proyecto de personalización profunda.

Los flujos estándar (gestión de tareas genérica, comunicación interna, almacenamiento documental sin requisitos especiales) están bien soportados por productos comerciales. Construir una herramienta propia para estos flujos es una inversión que no produce retorno.

La pregunta de criterio es si el flujo se acomoda al producto o el producto debe acomodarse al flujo. Si el flujo tiene que acomodarse al producto y la organización está dispuesta a hacerlo, porque la práctica estándar que el producto encapsula vale más que la práctica actual de la organización, hay producto. Si el producto tiene que acomodarse al flujo con personalizaciones extensas, hay que construir.

Criterio 3: presupuesto y horizonte temporal

Construir tiene una curva de costo distinta a la de configurar. La configuración tiene un costo alto inicial de licencia (puede ser una licencia perpetua o una suscripción anual sustantiva), un costo bajo recurrente de mantenimiento y actualizaciones, y dependencia con la hoja de ruta del proveedor. La construcción tiene un costo alto inicial de desarrollo (puede ser tres a diez veces el costo de la licencia equivalente), un costo medio recurrente de mantenimiento y evolución, y cero dependencia con un proveedor externo.

A cinco años, la configuración suele ser más barata para procesos estándar porque el costo inicial se amortiza en la curva de actualizaciones que el proveedor entrega. A diez años, la matemática cambia: los costos de licenciamiento que crecen con el uso, los costos de migración cuando el proveedor cambia condiciones y los costos de adaptación cuando el proveedor evoluciona en direcciones que no encajan con la organización empiezan a sumar.

La pregunta de criterio es si el cliente tiene un horizonte de tres años o de diez. Una organización en un sector regulado con vida operativa larga prevista (banca, energía, gobierno) suele beneficiarse del horizonte largo. Una organización en un sector dinámico con incertidumbre estratégica alta (fintech, healthtech, edtech) suele beneficiarse del horizonte corto. El diferencial cambia la matemática.

Criterio 4: capacidad de mantenimiento interno post-launch

Configurar un producto del mercado exige un equipo interno menor para mantenerlo, porque el proveedor mantiene el producto. Pero exige capacidad de integración (administradores funcionales del producto, integraciones con sistemas internos) y capacidad de gobernanza (decisiones sobre qué configurar, qué pedir al proveedor, cómo gestionar la relación contractual a lo largo del tiempo). El equipo es menor, pero debe existir y tener competencias específicas.

Construir software a medida exige un equipo interno robusto de desarrollo y mantenimiento. Si la organización no tiene capacidad técnica para mantener el software construido, debe firmar un contrato de mantenimiento sostenido con el proveedor que lo construyó. Sin alguna de esas dos opciones, el software construido se degrada en dieciocho a treinta meses y la organización termina pagando una reescritura completa o adoptando un producto del mercado a destiempo.

La pregunta de criterio se resuelve con otra más concreta: quién va a mantener esto en tres años, cuando los actuales hayan rotado. Si la organización no puede contestarla con claridad, construir es un riesgo operativo material a futuro.

Criterio 5: dependencia tecnológica con proveedor externo

Configurar un producto crea dependencia con la hoja de ruta del proveedor. Si el proveedor cambia sus precios, deprecia funcionalidad crítica, es adquirido por una empresa con prioridades distintas o reorienta su producto en una dirección que no encaja con el flujo de la organización, esta debe ajustarse. La capacidad de respuesta al cambio del proveedor es limitada.

Construir software propio elimina la dependencia externa, pero crea dependencia con el equipo que lo construyó. Si el equipo rota, si el proveedor que lo desarrolló no quiere mantenerlo, si las decisiones de arquitectura tomadas hace cuatro años envejecen mal, la organización enfrenta el problema sola.

En sectores regulados (banca, salud) o estratégicos (defensa, infraestructura crítica), la dependencia con un proveedor externo importa más. Las regulaciones sectoriales pueden exigir soberanía operativa sobre los sistemas críticos. En sectores no regulados con productos maduros y proveedores estables, la dependencia importa menos.

La pregunta de criterio es qué dependencia podemos asumir con criterio operativo. La respuesta honesta evita justificar la preferencia técnica con un argumento que no aplica al caso.

Qué no debe usarse como criterio

Cuatro razones aparecen con frecuencia en conversaciones sobre la decisión y no constituyen criterio operativo defendible.

"Porque otra empresa del sector lo hizo así." Lo que funcionó para otra organización en contexto distinto no se aplica linealmente. Las decisiones de arquitectura tomadas por un líder de sector responden a su tamaño, su madurez, su capacidad técnica interna y su horizonte estratégico, que rara vez son los mismos del observador que copia la decisión.

"Porque está de moda construir con IA." Las herramientas cambian; los criterios operativos no. Una organización que decide construir software a medida porque "hoy se puede con IA y desarrollo asistido" toma una decisión cuyas consecuencias se sienten en los próximos diez años; las herramientas de desarrollo asistido por IA que existen hoy serán distintas dentro de dieciocho meses.

"Porque el proveedor X promete que su producto resuelve todo." Las promesas comerciales son insumo de la decisión, no la decisión. La forma de evaluar la promesa es someter al proveedor a pilotos acotados con casos de uso reales de la organización antes de comprometer la decisión completa.

"Porque construir es más sexy o configurar es más conservador." Las preferencias estéticas no estructuran inversión sostenida. La organización que construye por preferencia estética cuando los criterios apuntan a configurar paga la diferencia durante el ciclo de vida del proyecto. La que configura por preferencia estética cuando los criterios apuntan a construir descubre las limitaciones operativas del producto en el peor momento.

Cómo Bredia toma esta decisión en proyectos reales

Cuatro ejemplos ilustran cómo los cinco criterios aplican en proyectos concretos. Los detalles operativos están anonimizados; las decisiones de arquitectura son reales.

Ejemplo 1, plataforma de cumplimiento tributario para grupo regional. Configuramos Microsoft 365 con Power BI en lugar de desarrollar una plataforma a medida. Madurez del proceso: el tax compliance consolidado es una práctica industrial madura. Especificidad del flujo: alta a nivel de jurisdicción regional, aunque el flujo general se acomoda al ecosistema Microsoft. Presupuesto y horizonte: el cliente prioriza obtener resultados visibles rápido por encima de la personalización profunda. Capacidad de mantenimiento: el cliente ya tiene un equipo de IT que mantiene Microsoft 365 corporativo. Dependencia: aceptable dado el dominio establecido de Microsoft en grupos empresariales regionales. Las tax-tech especializadas se incorporan en ciclos posteriores para automatizaciones puntuales por jurisdicción.

Ejemplo 2, sistema de recepción de solicitudes legal para multinacional. Construimos una integración a medida en lugar de adoptar un producto comercial. Madurez del proceso: el ingreso de solicitudes legales del cliente tiene reglas específicas derivadas de su estructura organizacional. Especificidad del flujo: muy alta, con integración crítica con SAP corporativo y casos de borde frecuentes que ningún producto del mercado evaluado cubría sin personalización extensiva. Presupuesto y horizonte: el cliente tiene un horizonte de ocho a diez años y presupuesto para sostener el desarrollo. Capacidad de mantenimiento: equipo interno de IT robusto. Dependencia: el cliente prefiere depender de su propio equipo antes que de un proveedor externo.

Ejemplo 3, gestión documental para firma de abogados. Configuramos un producto del mercado (iManage o NetDocuments según el caso) en lugar de construir a medida. Madurez del proceso: la gestión documental para una firma de abogados es práctica estándar del sector, con productos especializados maduros. Especificidad del flujo: baja. Las firmas tienen flujos similares y los productos especializados los cubren bien. Presupuesto y horizonte: la firma prioriza resultados rápidos y costo total bajo. Capacidad de mantenimiento: la firma no tiene equipo interno para mantener software a medida. Dependencia: aceptable dado que los productos del segmento tienen estabilidad histórica documentada.

Ejemplo 4, herramienta de IA para investigación normativa. Configuramos un modelo comercial en lugar de entrenar un modelo propio. Madurez del proceso: la investigación normativa asistida es una práctica emergente, aunque ya bien cubierta por modelos comerciales generales. Especificidad del flujo: media. Los modelos comerciales alcanzan la barrera de capacidad para los casos de uso de la organización. Presupuesto y horizonte: el costo de entrenar un modelo propio sobre normativa regional excede ampliamente el valor incremental sobre el modelo comercial. Capacidad de mantenimiento: la organización no tiene capacidades de ML/IA internas. Dependencia: aceptable dado que los grandes proveedores comerciales mantienen estabilidad y el costo de cambio es bajo.

Conversemos

La decisión construir o configurar se firma al inicio del proyecto, después de aplicar los cinco criterios con disciplina. Cuando se firma con disciplina, el resto del proyecto avanza sin volver sobre la pregunta. Cuando se firma sin disciplina, la pregunta vuelve cada tres a seis meses y la energía organizacional se gasta en el debate.

Si lideras una transformación operativa y la pregunta arquitectónica está abierta en tu proyecto, conversemos. La conversación es más útil cuando empieza por el problema operativo concreto que se quiere resolver y termina con la arquitectura que mejor lo resuelve, no al revés. La decisión sobre arquitectura es trabajo de la línea Design; la ejecución de cualquiera de las dos rutas (configurar producto o construir a medida) se hace en Build; la operación recurrente, cuando el cliente la delega, vive en Run.

El caso de la plataforma de cumplimiento tributario para un grupo empresarial multi-jurisdicción ilustra la decisión configurar sobre construir en un proyecto real.