La factura de SaaS muestra lo que pagas al proveedor. No muestra cuánto tiempo invierte tu equipo en hacer que el software encaje con el trabajo.
Para una función estándar que ya responde a la forma de operar de una empresa, SaaS puede ser una muy buena opción. Está listo para usar, el proveedor opera el servicio y las actualizaciones llegan a través de un producto compartido. Microsoft describe esa ventaja en su experiencia al llevar Dynamics 365 a SaaS: un problema puede corregirse una vez y la mejora llegar a todos los clientes, sin que cada uno administre una base de código distinta.
El desajuste aparece en los bordes. Un equipo puede ingresar información en un sistema, copiarla a otro, sostener una hoja de cálculo para las excepciones y depender de la memoria de un compañero para saber qué paso sigue. La suscripción parece predecible. El trabajo adicional se convierte en parte del costo operativo.
La suscripción es solo una línea de la comparación
Una comparación justa considera la vida completa de cada opción, con el mismo horizonte de decisión y volumen de trabajo. Una guía del Gobierno británico sobre costo total de propiedad incluye licencias, integraciones, migración, mantenimiento, actualizaciones, soporte, capacitación, personalización y transición al final de vida. Aunque es un documento antiguo, su principio sigue siendo útil: comparar lo que cuesta adquirir, operar, cambiar y eventualmente dejar un sistema, no solo su precio inicial. HM Government, Total Cost of Ownership: Things to Consider.
Para una opción SaaS, incluye la suscripción y los niveles de usuarios, consumo o funciones que apliquen. Suma la implementación y la capacitación, los módulos pagos, las integraciones y la administración. Después estima el tiempo del equipo dedicado a ingresar datos varias veces, conciliarlos, tramitar aprobaciones manuales y gestionar excepciones fuera del sistema. Si es posible que la empresa migre, incluye también ese trabajo de transición.
Para el software a la medida, incluye el descubrimiento y la implementación, además del alojamiento, los servicios de terceros, las integraciones, el mantenimiento, el soporte y la evolución prevista. Un sistema a la medida y gestionado también tiene costos recurrentes. Lo que cambia es qué se financia con ellos: mantener una capacidad importante alineada con el proceso de la empresa, en vez de adaptar continuamente el proceso a un producto general.
Compara las opciones según los resultados que el proceso debe lograr: tiempo de resolución, retrabajo, relevos perdidos, errores, capacidad o visibilidad para tomar decisiones. Si la brecha casi no afecta la operación, crear software propio puede no justificar su costo. Pero si se repite a diario en un proceso del que depende el negocio, mirar únicamente el precio de la licencia subestima lo que cuesta seguir igual.
Cuándo el software a la medida puede justificar la inversión
El software a la medida tiene más sentido cuando el proceso importa para el negocio y sus reglas no caben bien en un producto estándar. Puede tratarse de aprobaciones que dependen del contexto, excepciones que cambian por cliente o ubicación, o información que debe circular entre sistemas antes de que alguien pueda decidir.
Una capacidad hecha a la medida puede incorporar esas reglas, mostrar a cada rol la información y las acciones que necesita y conectar los sistemas que ya funcionan. No tiene que reemplazar un ERP, CRM u otra plataforma SaaS madura. La guía de AWS para decidir entre comprar y construir propone una distinción similar: preferir una solución existente cuando requiere pocos cambios, y evaluar la construcción cuando se necesita más agilidad, integrar varios sistemas o cubrir una capacidad que la opción estándar no ofrece, siempre considerando si el equipo y el presupuesto pueden sostenerla. AWS Well-Architected Government Lens.
Por eso, “a la medida” debe describir el ajuste a la operación, no solo la apariencia. Cambiar la paleta de colores no elimina el trabajo duplicado. Un sistema diseñado alrededor del proceso puede hacer visibles sus reglas, responsables, estados y excepciones. Para identificar esa brecha con más detalle, consulta Cuándo el software debe adaptarse a la operación.
Compra lo estándar; construye alrededor de lo que es propio
SaaS ofrece ventajas reales. Compartir infraestructura puede reducir los costos de operación del proveedor, y un producto compartido permite mantener una sola versión y distribuir las actualizaciones de forma amplia. La documentación de Microsoft sobre arquitectura SaaS también explica el equilibrio: los requisitos específicos de cada cliente pueden afectar el costo, la complejidad y el aislamiento. Conviene diseñarlos y evaluarlos, en vez de asumir que no tienen costo.
Así, la decisión es más precisa que “SaaS o software a la medida”. Conserva los productos que resuelven bien el trabajo común. Construye solo la capacidad que cierra una brecha operativa importante e intégrala con los sistemas que deben seguir funcionando. Microsoft presenta la arquitectura multiinquilino como una forma de buscar eficiencia de costos mientras se equilibran las necesidades del cliente, el trabajo operativo y el aislamiento. La respuesta correcta depende de las necesidades reales, no de preferir una arquitectura por principio.
Un sistema a la medida necesita un equipo responsable después del lanzamiento
La empresa seguirá cambiando después de poner el software en marcha. Aparecerán aprobaciones, cambiarán los compromisos con clientes, los equipos adoptarán nuevas herramientas y se harán visibles otras excepciones. Sin soporte y sin una forma de priorizar los cambios, el sistema puede perder ajuste con el tiempo, igual que un producto SaaS.
Por eso importa la relación de servicio. Blaxline comienza por entender el proceso, define una capacidad de producción acotada, la construye y la integra, y después opera, observa y evoluciona el sistema gestionado dentro del alcance acordado. El acuerdo debe dejar claros el soporte, el mantenimiento, los costos de terceros y la capacidad de evolución; un proceso nuevo o una ampliación importante puede requerir otro alcance. El valor está en tener un equipo que conoce por qué funciona el sistema y puede mantenerlo alineado mientras el negocio avanza.
Además, “a la medida” no significa automáticamente que el cliente sea dueño de cada componente o archivo de código. Los derechos sobre los datos, el software reutilizable, los límites del soporte y las condiciones de salida deben definirse antes de comenzar.
La mejor opción no es la que muestra la menor mensualidad ni la que promete construirlo todo. Es la que tiene un costo total razonable para la importancia del trabajo que sostiene. Compra software para lo que es estándar. Invierte en software a la medida gestionado cuando un proceso importante necesita encajar mejor y un equipo que mantenga ese ajuste vigente.
FUENTES Y REFERENCIAS
Para profundizar
- Costo total de propiedad: aspectos para considerar
HM Government
- Metodología de diseño para cargas SaaS en Azure
Microsoft Azure Well-Architected Framework
- El camino a SaaS: Dynamics 365
Microsoft Azure Architecture Center
- Replantear el modelo operativo
AWS Well-Architected Framework
Alex trabaja en la intersección entre negocio y tecnología para ayudar a las organizaciones a identificar dónde el software puede crear una ventaja operativa duradera.