Software a medida o SaaS: cómo decidir

Define el proceso antes de elegir la herramienta

Describe el recorrido desde que aparece una necesidad hasta confirmar su resolución: quién interviene, qué datos necesita y qué sucede si falta información o se rechaza una solicitud. Una lista de funciones como «reportes» o «aprobaciones» no demuestra que una aplicación resuelva tu proceso.

Distingue las reglas indispensables de las preferencias. Pregunta qué condición protege una decisión del negocio y qué hábito podría cambiar sin afectar el resultado. Evita exigir desarrollo propio solo para conservar una forma de trabajar que el equipo puede revisar.

• Recorrido principal: evento de inicio, participantes y resultado verificable.
• Excepciones: rechazo, corrección, ausencia de un responsable y datos incompletos.
• Sistemas involucrados: dónde se crea la información y dónde debe quedar registrada.

Compara comprar, configurar, integrar y construir

En SaaS utilizas aplicaciones del proveedor en infraestructura cloud, como describe la definición de NIST. Comprueba qué incluye el plan evaluado y qué necesita configuración, módulos adicionales o integración. El software a medida se diseña para un alcance acordado y requiere decidir quién lo opera y mantiene después de la entrega.

Considera también una solución mixta: conservar una plataforma que cubre el trabajo habitual y desarrollar la pieza que falta. Si el problema está en un sistema existente, una mejora o integración acotada merece evaluarse junto con su reemplazo. Compara alternativas completas, incluyendo el esfuerzo que seguirá realizando tu equipo.

Ejemplo hipotético: solicitudes de compra con excepciones

Imagina una empresa que recibe solicitudes de compra, pide aprobación y registra el resultado en su ERP. Este ejemplo es hipotético; no describe a un cliente ni un resultado de Digital Dev. El equipo encuentra un SaaS que resuelve solicitudes simples, pero todavía debe comprobar cómo trata una aprobación delegada y una solicitud que vuelve para corrección.

La prueba útil recorre esas situaciones con datos ficticios y termina verificando el registro en el destino. Si la configuración cubre las reglas y existe un acceso de integración adecuado, comprar y conectar puede ser una opción. Si las diferencias son relevantes, compara una extensión acotada con desarrollar el flujo completo. Una pantalla similar a la que imaginas no demuestra que las excepciones estén resueltas.

Usa los mismos criterios para todas las propuestas

Entrega a cada proveedor el mismo recorrido y pide identificar qué resuelve hoy, qué necesita trabajo y qué queda fuera. Registra también las dependencias: acceso al ERP, limpieza de datos, participación de usuarios o autorización de otro proveedor. Marca como pendiente lo que todavía no tiene evidencia; no lo trates como una capacidad confirmada.

• Cobertura: reglas y excepciones demostradas, configurables o pendientes de construir.
• Integración: acceso disponible, campos, permisos, fallas y reintentos sin duplicación.
• Costo de operación: licencias, alojamiento, consumo, soporte y trabajo interno aplicables al alcance.
• Evolución: quién puede cambiar el flujo y cómo se revisan las modificaciones.
• Continuidad: respaldo, recuperación, documentación y responsables de incidentes.
• Salida: formatos de exportación, acceso a datos y condiciones acordadas para código y transferencia.

Qué evidencias conviene reunir

Forma una carpeta de decisión pequeña, con antecedentes que puedan revisar negocio y tecnología. Para explorar alternativas puedes usar muestras ficticias o anonimizadas; los accesos reales se acuerdan según el trabajo necesario. Anota quién confirmó cada condición y cuáles siguen abiertas.

• Un mapa del recorrido y ejemplos de sus excepciones, validados por quien ejecuta el proceso.
• Una demostración del producto sobre esos ejemplos, indicando versión y módulos evaluados.
• Documentación de APIs y una comprobación del acceso necesario para integrar.
• Una propuesta con entregables, exclusiones, responsabilidades y componentes del costo.
• Criterios de aceptación y condiciones de operación, entrega de datos y eventual salida.

Elige una primera entrega que resuelva la duda principal

Cuando dos alternativas parecen viables, identifica la incertidumbre que podría cambiar la decisión. Puede ser una regla de aprobación, el acceso a una API o la calidad de los datos. Define una validación centrada en esa duda antes de ampliar el proyecto, con un resultado esperado y una persona responsable de revisarlo.

Documenta por qué elegiste comprar, integrar o desarrollar y qué condiciones harían reconsiderarlo. Define el problema de la primera entrega y qué solicitudes esperarán. Digital Dev puede revisar ese alcance contigo para preparar una propuesta basada en tus restricciones y evidencias.

Prepara la conversación con tu equipo y el proveedor

El caso de software presupuestario corporativo de Digital Dev permite conocer una aplicación con revisiones y consolidación entre áreas. Es una referencia de trabajo a medida, con cliente reservado; no demuestra que esa opción sea la adecuada para todos los procesos. Usa los casos para preguntar por el problema, el alcance y las responsabilidades de cada entrega.

Completa el brief con tu recorrido, alternativas revisadas y evidencia pendiente. Si estás considerando IA, separa esa tarea y su evaluación de la decisión sobre la aplicación.