Software a medida o SaaS: cómo decidir antes de contratar
Por Carlos Isidoro De Ayala Diaz ·
Software a medida o SaaS: compara procesos, integración, seguridad, coste total, mantenimiento y salida antes de elegir una solución para tu empresa B2B.
Empieza por el proceso y por qué necesita cambiar
Elegir entre un SaaS y software a medida no empieza comparando pantallas. La empresa debe describir qué operación quiere mejorar, quién participa, qué datos utiliza, dónde se detiene y cómo se sabe que termina bien. Un proceso común, como registrar vacaciones o emitir una factura estándar, suele tener soluciones maduras. Un flujo que combina reglas propias, varios canales y decisiones que diferencian el servicio puede necesitar adaptación, integración o desarrollo específico.
La descripción debe incluir excepciones. Si un pedido cambia después de aprobarse, falta una referencia, interviene un franquiciado o la tarifa depende de un acuerdo particular, hay que saber qué persona decide y qué evidencia queda. Una demostración preparada por un proveedor enseña el recorrido ideal; los ejemplos reales muestran si la herramienta encaja en el trabajo diario. Pueden anonimizarse para evaluar sin compartir datos personales ni secretos comerciales.
También se separan necesidades imprescindibles, mejoras y preferencias. Una necesidad imprescindible está vinculada a una obligación o a un resultado observable. Una mejora aporta valor, pero puede esperar. Una preferencia describe cómo se realiza hoy y quizá tenga una alternativa más sencilla. Esta clasificación evita construir cada hábito histórico como una función exclusiva o descartar un producto porque utiliza otra secuencia razonable.
La guía de compra tecnológica de GOV.UK propone explicar la necesidad del usuario, el problema y el proceso de decisión entre construir, comprar o combinar. No es una norma para empresas españolas, pero ofrece un criterio útil: justificar la elección con necesidades y limitaciones, no con la moda de una tecnología. El resultado del análisis debe permitir que dirección y usuarios comparen opciones con la misma base.
Compara SaaS, adaptación y desarrollo con el mismo alcance
Un SaaS puede poner en marcha funciones conocidas sin que la empresa mantenga toda la infraestructura. A cambio, trabaja dentro del modelo, las integraciones, las licencias y el calendario del proveedor. Antes de elegirlo hay que confirmar perfiles, permisos, exportaciones, API, límites, ubicaciones de datos, soporte y capacidad para representar las excepciones prioritarias. Configurable no significa que cualquier proceso pueda adaptarse sin desarrollo o sin cambiar la forma de trabajar.
Adaptar una plataforma existente puede conservar funciones maduras y añadir módulos o conexiones donde existe una diferencia real. Esta vía intermedia necesita distinguir configuración soportada, extensiones propias y cambios en el núcleo del producto. Cuanto más invasiva sea la modificación, más trabajo puede requerir una actualización. La propuesta debe indicar qué parte mantiene el fabricante, qué parte mantiene el implantador y cómo se prueba la compatibilidad entre versiones.
El desarrollo a medida tiene sentido cuando el proceso aporta una diferencia comprobable, el mercado no cubre los requisitos o las integraciones necesitan un control que las opciones disponibles no ofrecen. No elimina dependencias: exige equipo, arquitectura, infraestructura, seguridad, pruebas, documentación y mantenimiento. La empresa debe decidir quién prioriza el producto y quién sostiene la operación después de la primera entrega. Tener el código no equivale a poder evolucionarlo sin conocimiento ni entorno reproducible.
La comparación se hace por capacidades equivalentes. Si un presupuesto SaaS incluye alojamiento, copias y actualizaciones, la alternativa a medida debe contemplarlas. Si la opción propia permite una integración que el SaaS cobra aparte, ese coste también se registra. Puede existir una solución híbrida: adquirir funciones comunes y desarrollar una capa para el proceso diferencial. La decisión no necesita ser binaria si los límites entre componentes quedan claros.
Calcula el ciclo de vida, la seguridad y la posibilidad de salida
El coste inicial no representa el coste total. La comparación incluye análisis, licencias, implantación, migración, integraciones, personalizaciones, infraestructura, formación y tiempo de los usuarios. Después llegan soporte, observabilidad, copias, recuperación, actualizaciones, correcciones de seguridad y cambios de proveedores conectados. Conviene construir escenarios con supuestos visibles, como número de usuarios o volumen, sin presentar una estimación comercial como ahorro garantizado.
La seguridad también cambia de reparto. En un SaaS existe responsabilidad compartida: el proveedor protege parte del servicio y la empresa mantiene identidades, accesos, dispositivos, configuración y uso de datos. NCSC recomienda administración central, permisos correctos, baja de cuentas, software cliente actualizado y revisión de registros, además de comprobar las afirmaciones públicas del proveedor. En software propio, estos controles siguen siendo necesarios y se añade la responsabilidad de integrar prácticas seguras en el ciclo de desarrollo.
NIST SSDF organiza prácticas para preparar la organización, proteger el software, producir entregas seguras y responder a vulnerabilidades. Sirve para pedir evidencias a un proveedor y para definir el trabajo de un desarrollo propio: repositorio y dependencias controlados, revisión, pruebas, procedencia de componentes, gestión de fallos y capacidad de corregir. No convierte una lista de controles en garantía de ausencia de vulnerabilidades, pero ayuda a comparar responsabilidades que a menudo quedan fuera de una propuesta funcional.
La salida se prepara antes de contratar. La empresa necesita saber qué datos puede exportar, en qué formato, cuánto tarda, cuánto cuesta y qué ocurre con archivos, registros, configuraciones e integraciones. La orientación de GOV.UK sobre dependencia cloud recomienda formatos y estándares abiertos para conservar el control de los datos. En software a medida se añaden código, documentación, secretos, infraestructura, licencias y conocimiento. El plan debe permitir transición sin prometer una portabilidad automática que nunca se ha ensayado.
Prueba con casos reales y convierte la decisión en un alcance
La evaluación puede comenzar con una matriz breve: proceso, requisito, opción estándar, configuración necesaria, integración, desarrollo, dependencia y criterio de aceptación. No hace falta asignar una puntuación arbitraria a todo. Los puntos que pueden detener la operación se prueban; los demás se documentan para una fase posterior. Si el proveedor no puede demostrar una función crítica o facilitar documentación suficiente, la incertidumbre se registra en lugar de asumir que se resolverá durante la implantación.
Un piloto utiliza usuarios representativos y una muestra controlada de datos. Recorre operaciones normales, permisos distintos, errores y una excepción importante. También comprueba importación, exportación y una integración prioritaria. El objetivo no es construir gratis una parte del proyecto, sino reducir incertidumbre antes del compromiso principal. Cada prueba conserva resultado esperado, evidencia y persona que puede aceptar o rechazar el comportamiento.
La propuesta final identifica producto o arquitectura, módulos, configuración, integraciones, personalizaciones, migración, pruebas, formación, soporte y exclusiones. También separa costes de terceros, responsabilidades del cliente y condiciones de cambio. En un desarrollo se concretan entregas de código y documentación; en un SaaS, licencias, niveles de servicio disponibles y condiciones del proveedor. Ninguna modalidad debería ocultar qué ocurre después de la puesta en marcha.
Élite Solutions Tech puede analizar desde Murcia procesos y alternativas para empresas regionales o proyectos nacionales. El resultado puede recomendar reutilizar, contratar, adaptar, integrar o desarrollar según la evidencia, sin convertir el software a medida en la respuesta automática. Para preparar una primera reunión basta con describir el proceso, usuarios, herramientas actuales y principal bloqueo; los accesos y datos sensibles se coordinan después por un canal autorizado.