Un marco de Bredia para comparar software a medida y productos del mercado según el proceso, el costo total, el mantenimiento y las dependencias, con cuatro ejemplos anonimizados.
Construir software a medida o configurar productos del mercado es una decisión que condiciona el costo, el mantenimiento y la evolución de un proyecto de transformación. Esta pieza presenta los cinco criterios de Bredia para evaluarla y cuatro ejemplos anonimizados de su aplicación.
Los criterios son un marco de decisión de Bredia, no un estudio comparativo de precios del mercado. La revisión del 12 de octubre de 2026 precisa cómo evaluar el costo total y las dependencias de cada alternativa.
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 y relación con proveedores durante el ciclo de vida del sistema.
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.
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 tiene particularidades relevantes, hay que comprobar cuáles soporta el producto mediante configuración, integración o extensiones. Adaptar un proceso puede ser razonable; perder una capacidad que diferencia a la organización puede no serlo. Esa diferencia debe demostrarse con requisitos y pruebas, no solo con la percepción de que el proceso es único.
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.
El segundo criterio profundiza el primero. Los flujos con regulación específica, integraciones complejas o casos de borde requieren una prueba de ajuste más detallada. La evaluación debe identificar qué se resuelve por configuración, qué exige desarrollo adicional y cómo se mantendrán esas extensiones cuando cambie el producto.
Para flujos como gestión de tareas o almacenamiento documental sin requisitos especiales, conviene evaluar primero las alternativas disponibles. Construir puede justificarse si hay restricciones que esas alternativas no resuelven, pero requiere demostrar el beneficio frente al costo total de mantener una solución propia.
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.
La comparación útil es el costo total durante un mismo horizonte y para un alcance equivalente. Configurar un producto puede incluir licencias, migración, integración, administración, formación y actualizaciones de extensiones. Construir puede incluir diseño, desarrollo, infraestructura, seguridad, pruebas, soporte y evolución. Ambas opciones pueden depender de terceros.
El modelo de costos debe explicitar volumen de usuarios, consumo, cambios previstos, aumentos contractuales, capacidad interna y condiciones de salida. Conviene comparar escenarios de crecimiento y continuidad, incluyendo migración de datos y transferencia de conocimiento. Un precio de licencia y una cotización de desarrollo inicial no son magnitudes equivalentes.
La pregunta de criterio es durante cuánto tiempo se espera utilizar la solución y qué incertidumbres podrían cambiar esa expectativa. No hay una relación universal entre el precio de una licencia y el costo de construir, ni un año a partir del cual una alternativa pase automáticamente a ser más barata.
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 capacidad de mantenimiento, interna o contratada. Esa capacidad debe cubrir actualizaciones, seguridad, incidentes y cambios de negocio. Si se delega, conviene acordar documentación, acceso al código, derechos de uso y transferencia a otro equipo. La ausencia de ese plan crea un riesgo de continuidad; no permite predecir un plazo fijo de degradación para todos los sistemas.
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.
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 cambia las dependencias, pero no las elimina. La operación puede depender del equipo de desarrollo, la infraestructura, bibliotecas, APIs y otros servicios contratados. La propiedad del código ayuda a conservar opciones solo si existen documentación, acceso y capacidad para mantenerlo o transferirlo.
La criticidad del proceso, los requisitos contractuales y las normas aplicables deben orientar el análisis de continuidad y salida. No conviene atribuir una exigencia de "soberanía" a un sector completo sin identificar la disposición concreta y comprobar que aplica al sistema evaluado.
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.
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." El método de desarrollo no resuelve por sí solo la conveniencia de construir. La organización seguirá necesitando evaluar calidad, seguridad, mantenimiento y costo durante la vida del sistema.
"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.
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. Especificidad del flujo: media. La alternativa comercial se consideró adecuada para el alcance evaluado, sin extender esa conclusión a toda la investigación jurídica. Presupuesto y horizonte: el entrenamiento propio no se justificó frente al valor esperado en ese caso. Capacidad de mantenimiento: la organización no tenía capacidades de ML/IA internas. Dependencia: la continuidad y las opciones de cambio del servicio deben reevaluarse cuando cambien sus condiciones.
La decisión debe registrar los criterios, los supuestos y las condiciones que justificarían revisarla. Un cambio de volumen, regulación, estrategia o proveedor puede hacer razonable reconsiderarla. Documentar el razonamiento permite distinguir un cambio de contexto de una preferencia técnica.
Para identificar alternativas del mercado legal, el Mapa Legaltech de Iberoamérica permite explorar empresas por país de sede y tipo de solución, con fuentes documentadas en las fichas. Es un punto de partida para investigar proveedores; la inclusión no acredita ajuste a un proceso ni reemplaza la evaluación técnica y contractual.
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.
Cuéntanos qué proceso, herramienta o forma de trabajo quieres revisar con tu equipo.
