Software a medida vs. SaaS: cuándo comprar, integrar o construir

“¿Compramos una plataforma o desarrollamos un sistema?” parece una decisión de dos opciones. En la práctica, una empresa tiene al menos cuatro caminos: ordenar el proceso, comprar y configurar un SaaS, integrar herramientas existentes o construir software a medida.

Elegir bien no consiste en encontrar la opción con más funciones. Consiste en entender qué parte del proceso es estándar, qué parte diferencia al negocio y qué capacidad tendrá la empresa para operar la solución durante su vida útil.

El software no corrige por sí solo responsabilidades ambiguas, datos inconsistentes o reglas que cambian cada semana. Por eso la decisión empieza en la operación.

Qué significa cada alternativa

Ordenar o estandarizar primero

No es una evasión de la decisión tecnológica. Es la ruta adecuada cuando cada persona ejecuta el proceso de manera distinta, las excepciones no están documentadas o todavía cambia la oferta.

El objetivo es definir etapas, responsables, datos y reglas antes de configurarlos en cualquier sistema. A veces esta etapa demuestra que una hoja mejor organizada es suficiente; otras veces produce los requisitos que faltaban para elegir con criterio.

Comprar y configurar un SaaS

SaaS significa software como servicio: se utiliza una aplicación operada por un proveedor, normalmente a través de internet, mientras la empresa configura usuarios, permisos y opciones disponibles. La definición formal de NIST aclara que el consumidor usa la aplicación, pero no administra la infraestructura subyacente y suele tener una capacidad de configuración limitada al producto.

Es una buena ruta cuando el proceso es común —por ejemplo, contabilidad, colaboración, tickets o un flujo comercial convencional— y el producto cubre lo necesario sin deformar la operación.

Integrar y automatizar

Puede que las herramientas actuales sí funcionen, pero estén desconectadas. El formulario recibe solicitudes, el CRM organiza oportunidades y el correo comunica; la fricción está en que alguien mueve los datos entre ellas.

En ese caso, reemplazar todo puede ser innecesario. Una integración puede conservar los sistemas útiles y automatizar los traspasos, como en el flujo del formulario al CRM.

Construir software a medida

Consiste en diseñar una aplicación alrededor de requisitos propios. Aporta mayor control sobre el flujo, la interfaz, los permisos, las integraciones y la evolución, pero también crea responsabilidades: priorizar, probar, proteger, mantener, documentar y dar soporte.

Conviene evaluarlo cuando el proceso es estable, central y suficientemente particular; cuando las restricciones de los productos existentes son recurrentes; o cuando la forma de operar representa una capacidad que la empresa necesita conservar y mejorar.

Comparación rápida

Ninguna columna es superior por definición. Una empresa puede usar SaaS para contabilidad, integrar su formulario con un CRM y construir una aplicación para una parte distintiva de su entrega.

Cuándo conviene comprar y configurar SaaS

La opción suele ser sólida cuando se cumplen varias condiciones:

• el proceso se parece al de muchas otras empresas;
• las funciones centrales ya existen en el producto;
• adaptar algunas prácticas no elimina una ventaja del negocio;
• la plataforma ofrece permisos, registros y exportación adecuados;
• existen integraciones suficientes o una API viable;
• el equipo puede adoptar el flujo sin sostener procesos paralelos indefinidamente;
• las condiciones de seguridad, soporte y continuidad son aceptables.

Comprar no significa aceptar el producto sin análisis. Hay que revisar cómo salen los datos, qué ocurre si cambia el precio o el plan, quién responde ante incidentes y qué funciones dependen de complementos.

Cuándo conviene integrar lo que ya existe

La integración merece atención cuando el problema se describe con frases como estas:

• “el equipo captura lo mismo en dos sistemas”;
• “las solicitudes llegan, pero nadie las asigna de forma consistente”;
• “el CRM funciona, aunque el reporte requiere copiar datos”;
• “cada herramienta tiene una parte de la verdad”;
• “una actualización no se refleja en el resto del flujo”.

Antes de integrar, define una fuente de verdad por dato. Por ejemplo, el CRM puede gobernar responsable y etapa; el sistema administrativo, estado de facturación; la herramienta de formularios, evidencia del envío original. Sin esa definición, sincronizar en ambos sentidos puede multiplicar conflictos.

La guía para decidir qué procesos automatizar primero ayuda a separar una conexión útil de una integración innecesariamente amplia.

Cuándo conviene considerar software a medida

El proceso es propio y representa una diferencia real

No basta con decir “trabajamos diferente”. La diferencia debe poder describirse: reglas de asignación particulares, configuración compleja de un servicio, coordinación entre roles, lógica de capacidad o trazabilidad que los productos existentes no resuelven razonablemente.

El proceso ya es estable

Construir sobre reglas que todavía cambian aumenta retrabajo. La empresa debe conocer las etapas principales, los datos, las excepciones y los responsables, aunque el sistema evolucione después.

Las limitaciones son recurrentes, no incidentales

Una función ausente no justifica necesariamente un desarrollo. La señal es una acumulación consistente de adaptaciones, licencias, complementos, hojas paralelas y tareas manuales que deteriora la operación.

Existe capacidad para mantener el producto

El lanzamiento no es el final. Habrá usuarios, permisos, respaldos, incidentes, cambios regulatorios o de negocio, dependencias y mejoras. La decisión debe incluir quién prioriza y quién sostiene el sistema.

Si el punto de partida son archivos que ya no dan control, revisa primero las ocho señales de que Excel dejó de ser suficiente. No toda señal conduce a desarrollo; algunas se resuelven con gobierno, configuración o integración.

Cómo comparar el costo total sin inventar un promedio

Los rangos públicos de precio suelen mezclar alcances incompatibles: una configuración básica, un MVP, una integración o un sistema crítico no son la misma compra. Comparar una mensualidad contra una cotización de desarrollo produce una lectura incompleta.

Usa el mismo horizonte para todas las alternativas —por ejemplo, 36 meses— y registra las categorías reales, sin asumir cifras hasta contar con propuestas y requisitos comparables.

Costo total de una opción

Costo total = implementación inicial + licencias o infraestructura + integraciones + migración + capacitación + soporte + evolución + costo de salida.

Después compara el costo total con la fricción que se busca resolver:

• tiempo de captura y conciliación;
• retrabajo por información incorrecta;
• retrasos de seguimiento o entrega;
• dependencia de personas clave;
• interrupciones y riesgo operativo;
• oportunidades que no pueden atenderse por falta de capacidad.

Esto no produce automáticamente un retorno garantizado. Permite formular un caso de decisión con supuestos visibles que después pueden verificarse.

Preguntas que deben responder todos los proveedores

La evaluación no termina en una demostración funcional. La guía de adquisición de software de CISA propone revisar la seguridad y la gestión del producto durante su ciclo de vida; aunque fue creada con un contexto de adquisición institucional, sus preguntas sobre transparencia y riesgo son útiles para una empresa.

• ¿Quién es propietario de los datos y cómo se exportan?
• ¿Qué permisos y registros de actividad existen?
• ¿Cómo se corrigen vulnerabilidades y se comunican incidentes?
• ¿Qué respaldos, recuperación y monitoreo forman parte del servicio?
• ¿Qué dependencias externas utiliza la solución?
• ¿Quién atiende soporte y con qué límites?
• ¿Cómo se prueban los cambios antes de producción?
• ¿Qué ocurre si termina la relación comercial?
• ¿Qué documentación recibirá el equipo?
• ¿Cómo se gestionan usuarios, accesos y bajas?

Estas preguntas aplican al SaaS, a una integración y al software a medida. La dependencia no desaparece al construir; cambia de forma.

Señales de una decisión débil

• Elegir por una lista de funciones sin mapear el proceso.
• Desarrollar solo para evitar adaptar una práctica no diferenciadora.
• Comprar porque la configuración inicial parece rápida, sin revisar salida y soporte.
• Comparar mensualidad y desarrollo sin el mismo horizonte ni alcance.
• Automatizar un proceso inestable para “obligar” al equipo a seguirlo.
• Iniciar sin dueño de negocio, criterios de aceptación ni plan de adopción.
• Mantener la hoja anterior como sistema paralelo sin fecha ni reglas de transición.

Una secuencia de decisión más sana

1. Define el problema operativo. Describe síntomas y consecuencias sin nombrar una herramienta.
2. Mapea el flujo. Identifica etapas, datos, responsables y excepciones.
3. Separa lo estándar de lo diferenciador. Lo primero favorece compra; lo segundo puede justificar adaptación o construcción.
4. Explora las cuatro rutas. Ordenar, comprar, integrar y construir.
5. Compara costo total y riesgo. Usa el mismo horizonte y los mismos requisitos.
6. Prueba un tramo. Valida datos, adopción y excepciones antes de ampliar.
7. Define mantenimiento y salida. Toda solución necesita continuidad.

Comprar, integrar o construir: el criterio final

Compra cuando el proceso es común y una plataforma cubre lo importante con condiciones aceptables. Integra cuando las herramientas funcionan, pero la continuidad se pierde entre ellas. Construye cuando el proceso es estable, relevante y propio, y la empresa puede sostener el producto.

En algunos casos, la respuesta será una combinación. La arquitectura correcta es la que da control sin agregar complejidad innecesaria.

Internal Organic diseña software para operaciones que necesitan estructura propia y automatizaciones para conectar procesos y datos existentes. El diagnóstico inicial sirve para distinguir qué capa conviene intervenir primero.

Fuentes y lecturas recomendadas

• NIST SP 800-145: definición de computación en la nube y SaaS
• AWS Architecture Blog: el dilema entre comprar y construir
• AWS Enterprise Strategy: configurar o adaptar como tercera alternativa
• CISA: guía de evaluación de proveedores para pequeñas y medianas empresas