Cuatro criterios que aclaran la decisión
- Compra una capacidad estándar cuando el proceso no diferencia al negocio y el producto satisface los requisitos importantes sin deformar la operación.
- Considera software a medida cuando una regla, integración o experiencia propia crea una ventaja que no puede resolverse responsablemente con configuración.
- Compara el costo total de varios años: implementación, cambio organizacional, integraciones, seguridad, soporte, salida y reemplazo.
- Antes de comprometerte, prueba el flujo más difícil, verifica la portabilidad de los datos y asigna un responsable interno del producto.
1. Define el problema antes de comparar productos
Empieza por describir el resultado que necesita el negocio, no por pedir una lista de funciones. Un proceso de cotización, por ejemplo, puede requerir reglas de precio, aprobación de descuentos, inventario, firma, cobro y seguimiento. Documenta quién inicia cada paso, qué información recibe, qué decisión toma y cómo se reconoce un resultado correcto. Así podrás distinguir una necesidad real de una costumbre que conviene simplificar.
Clasifica los requisitos en tres grupos: obligatorios por ley o control, esenciales para operar y convenientes. Identifica además cuál parte del proceso diferencia a la empresa frente a sus competidores. Una función común como restablecer contraseñas rara vez justifica desarrollo propio. Una lógica de configuración que concentra conocimiento especializado, reduce errores críticos o mejora una experiencia distintiva podría hacerlo.
No asumas que “a medida” significa reproducir cada hoja de cálculo actual. El desarrollo personalizado amplifica decisiones buenas y malas. Antes de construir, elimina pasos duplicados, define un dueño del proceso y acuerda los indicadores que permitirán saber si la solución mejora el trabajo.
- Resultado de negocio y usuario responsable de cada etapa.
- Requisitos obligatorios, esenciales y opcionales.
- Reglas que realmente diferencian a la empresa.
- Excepciones, aprobaciones y evidencia que debe conservarse.
Si el equipo no puede explicar el proceso y sus excepciones, todavía no está listo para evaluar una demostración ni estimar un desarrollo.
2. Mide el ajuste del SaaS sin dejarte dirigir por la demostración
El software como servicio puede acelerar la adopción porque el proveedor opera una aplicación compartida, administra buena parte de la infraestructura y publica mejoras. La definición de computación en la nube de NIST ayuda a entender el modelo, pero no elimina las responsabilidades del cliente: la empresa sigue decidiendo qué datos cargar, quién puede acceder, cómo configurar el servicio y cómo conectarlo con otros sistemas.
Construye un guion con escenarios reales y pide ejecutar la demostración con ellos. Incluye el caso frecuente, el caso de mayor valor y una excepción difícil. Verifica roles, historial de cambios, exportación, integración, límites de configuración, soporte bilingüe y comportamiento cuando el servicio o una dependencia no está disponible. Las respuestas “se puede personalizar” deben convertirse en una configuración visible, un compromiso escrito o una limitación aceptada.
Diferencia configuración de adaptación riesgosa. Cambiar campos, estados o permisos dentro de mecanismos soportados suele ser mantenible. Encadenar extensiones frágiles, copiar información manualmente o depender de una sola persona para reconciliar sistemas puede convertir una suscripción rápida en deuda operativa. Si el producto cubre los requisitos esenciales con pocos compromisos, SaaS suele ser el punto de partida razonable.
- Prueba guiada por escenarios propios, no por el recorrido comercial.
- Configuración, límites, integraciones y planes disponibles por escrito.
- Administración de identidades, auditoría, respaldo y recuperación.
- Exportación completa y utilizable antes de firmar.
3. Exige al software a medida un caso de producto sostenible
El desarrollo a medida puede encajar con reglas particulares, integrar equipos o fuentes difíciles y evolucionar alrededor de una ventaja propia. También convierte a la empresa en responsable de priorizar un producto: debe decidir alcance, aceptar entregas, gestionar cambios, mantener conocimiento y financiar operación después del lanzamiento. Contratar programadores no transfiere automáticamente esa responsabilidad.
Pide una arquitectura que separe datos, reglas de negocio, integraciones e interfaz. Las prácticas de desarrollo seguro de NIST recomiendan incorporar seguridad al ciclo de vida, no añadirla al final. Esto implica controlar dependencias, revisar cambios, probar funciones sensibles, proteger secretos, corregir vulnerabilidades y conservar evidencia. OWASP ASVS puede servir como base verificable para requisitos de seguridad de una aplicación web, ajustada al riesgo real del sistema.
Evita aprobar un proyecto monolítico con una fecha distante y sin entregas utilizables. Empieza con un flujo estrecho que produzca valor, integra sólo lo necesario y aprende con usuarios reales. El contrato debe aclarar propiedad y acceso al código, repositorio, licencias de componentes, ambientes, documentación, copias de seguridad, tratamiento de incidentes, soporte y transición si cambia el proveedor.
- Dueño interno con autoridad para priorizar y aceptar.
- Entregas pequeñas que puedan probarse en la operación.
- Código, infraestructura, dependencias y documentación bajo control acordado.
- Mantenimiento, seguridad y continuidad presupuestados desde el inicio.
Software “entregado” no equivale a producto sostenible. Debe poder operarse, protegerse, corregirse y transferirse sin depender de memoria informal.
4. Compara costo total, riesgo y capacidad de salida
Una comparación útil usa el mismo horizonte para ambas opciones. En SaaS incluye suscripciones por usuario o uso, implementación, migración, integraciones, capacitación, administración, incrementos contractuales, módulos, soporte y eventual salida. En software a medida incluye descubrimiento, diseño, desarrollo, pruebas, nube, monitoreo, respaldos, seguridad, soporte, nuevas versiones, correcciones y transferencia de conocimiento. No presentes la primera versión como si fuera el costo de toda la vida útil.
Evalúa también la concentración de riesgo. En SaaS, revisa disponibilidad contractual, ubicación y subprocesadores de datos, notificación de incidentes, historial de exportación, autenticación, registros y proceso de terminación. En un desarrollo propio, examina cuántas personas entienden el sistema, qué ocurre si el proveedor desaparece, cómo se recupera un ambiente y quién decide una actualización urgente. CISA promueve que los fabricantes asuman resultados de seguridad en sus productos; aun así, el comprador debe verificar compromisos y configurar el servicio correctamente.
Haz una prueba de salida antes de entrar. Solicita una exportación de muestra con archivos, relaciones, identificadores y registros necesarios. Estima cómo se importaría en otra herramienta y qué funciones no viajarían. Un CSV incompleto no es portabilidad. Para código a medida, confirma acceso reproducible al repositorio, instrucciones para desplegar, inventario de dependencias y restauración probada.
- Costo total bajo un horizonte y supuestos comunes.
- Responsabilidades de seguridad asignadas a una parte concreta.
- Dependencias de personas, proveedor, nube y formatos.
- Ruta de migración probada, no sólo una cláusula genérica.
5. Toma una decisión reversible y basada en evidencia
Crea una matriz corta y ponderada con ajuste funcional, tiempo para obtener valor, integración, seguridad, experiencia del usuario, capacidad interna, costo total y salida. Define la ponderación antes de calificar proveedores para evitar que una demostración atractiva cambie los criterios. Registra supuestos y evidencia: prueba realizada, documento contractual, exportación examinada o referencia técnica. Una opinión sin soporte debe quedar visible como riesgo.
No todas las decisiones tienen que ser puras. Una arquitectura razonable puede usar SaaS para contabilidad, identidad o colaboración y reservar desarrollo propio para el flujo que diferencia al negocio. También puede comenzar con un producto estándar, validar la demanda y construir sólo cuando las limitaciones tengan un costo comprobado. La integración debe reducir transcripción y mantener una fuente definida para cada dato.
Antes de aprobar, realiza un piloto con usuarios representativos y datos controlados. Mide errores, pasos manuales, tiempo de aprendizaje, excepciones y trabajo de soporte; no cargues información sensible innecesaria. Define criterios de continuar, corregir o detener. La mejor opción no es la que acumula más funciones, sino la que resuelve el problema con riesgos y responsabilidades que la pyme puede sostener.
- Criterios ponderados y evidencia comparable.
- Piloto limitado con casos difíciles y usuarios reales.
- Decisión explícita de fuente maestra e integración.
- Revisión programada de costos, ajuste y dependencia.
Preguntas frecuentes
Preguntas que conviene resolver antes de actuar
¿Cuándo debería una pyme descartar el desarrollo a medida?
Cuando el proceso es estándar, existe un SaaS que cubre los requisitos esenciales, la empresa no tiene un dueño de producto o no puede sostener seguridad y mantenimiento. También conviene posponerlo si el problema todavía no se ha validado con usuarios y resultados observables.
¿Tener el código fuente elimina la dependencia del proveedor?
No. También se necesitan derechos claros, repositorio actualizado, instrucciones de despliegue, dependencias identificadas, infraestructura accesible, documentación, copias restaurables y personas capaces de mantenerlo. El código sin contexto puede ser difícil y costoso de transferir.
¿Se puede combinar SaaS con software a medida?
Sí. Es frecuente usar productos administrados para capacidades comunes y desarrollar la parte diferenciadora. La combinación funciona cuando cada dato tiene una fuente maestra, las integraciones son soportadas, los fallos se pueden conciliar y la salida de cada componente está documentada.
