¿Dueños o inquilinos? Sofware propio vs SaaS
Ser el dueño de tu software puede ser tu mayor deuda técnica…
¿Es mejor desarrollar nuestro propio software corporativo o pagar por una suscripción SaaS? ¿Qué impacto tiene esta decisión? ¿Nos da Independencia? ¿O nos estamos comprando un problema de mantenimiento de por vida?
Prácticamente todas las organizaciones necesitan hoy en día de multitud de soluciones tecnológicas para sostener su operativa diaria. Software de gestión de clientes y proveedores, de facturación, de gestión de inventarios, webs a las que acceden los clientes para comprar, software de soporte a los clientes, etc…
¿Qué hacemos con todo esto? ¿Pagamos una suscripción SaaS y nos olvidamos? ¿o construimos nuestro propio software si tenemos capacidad y recursos para ello? Depende de muchas cosas. Por un lado, necesitamos agilidad, pero también, para algunas cosas, necesitamos control, seguridad y soberanía, sin depender de terceros.
Al final, el problema es muy viejo… se trata de cómo quiere la organización distribuir el riesgo y la responsabilidad a largo plazo.
La propiedad frente al TCO
Las grandes empresas, que tienen presupuestos potentes, suelen sentir la tentación de "construir en casa". Se basan en que, si son dueños del código, tienen el control total, la independencia. Pero no todo es blanco o negro.
El SaaS (Software as a Service), ofrece una propuesta de valor imbatible en cuanto a velocidad y eficiencia:
Time-to-Market: nos ofrece una solución testada y lista para usar.
Expertise del proveedor: al pagar SaaS, no solo se paga software, se paga por la especialización. El proveedor es experto en ese tipo de soluciones. Es posible que la organización no tenga ese conocimiento tan profundo en determinados dominios.
Eficiencia financiera: el TCO (Total Cost of Ownership) suele ser más favorable, ya que se elimina el CAPEX necesario al construir soluciones propias. Del mantenimiento se encarga también el proveedor.
Sin embargo, no todo es tan bonito. Existe el riesgo de quedar atados a la solución de un proveedor, o a que nos cambie unilateralmente las condiciones, o el precio en un futuro. También tenemos el problema de la falta de customización del producto, o que el proveedor cambie la hoja de ruta de su producto y eso nos afecte a nuestro negocio. O que nos encontremos con problemas de cumplimiento normativo a la hora de almacenar nuestros datos, o la posibilidad de que se filtren nuestros datos si los maneja un tercero, o si se almacenan en un cloud.
La estrategia. Qué partes del negocio externalizar.
La decisión de una organización no debería ser "SaaS vs. sofware propio". La pregunta estratégica debería ser qué capacidades son el núcleo de tu ventaja competitiva.
Capacidades Core: son los que diferencian a la organización en el mercado. Aquí es donde el desarrollo interno tiene sentido. Una organización no va a querer que su "motor" de modelo de negocio, lo que le da la ventaja competitiva, dependa de la hoja de ruta de un tercero. ¿Qué pasaría si el proveedor dejara de dar soporte a una funcionalidad clave para el negocio?
Capacidades No-Core: hay otras partes del negocio que se pueden considerar de apoyo. Por ejemplo, la parte de CRM, analytics, u otras herramientas operativas. Aquí, externalizar estas funciones con un SaaS podrían permitirle a la organización centrarse en lo que realmente le genera valor, el core del negocio.
Cómo se protegen las empresas
Las empresas no tienen por qué convertirse en "rehenes" de sus proveedores. Para protegerse, las organizaciones no prohíben el SaaS, sino que diseñan un plan de salida antes de entrar.
Si la calidad del software ofrecido por un proveedor SaaS no fuese la acordada, o si la solución dejase de ser competitiva frente a otras opciones del mercado, la organización debería conservar la libertad técnica de revertir la decisión y conectar otra solución de un proveedor diferente con agilidad.
Una estrategia multi-vendor y la diversificación de proveedores es lo más efectivo para no quedarse “atado”. Se pueden crear arquitecturas desacopladas, utilizando APIs, de tal manera que podamos reemplazar un producto de un proveedor y sustituirlo fácilmente por otro. La capa API nos aísla de estas dependencias.
El factor humano. La resistencia.
Entonces, si los números suelen favorecer al SaaS, ¿Por qué se suele encontrar tanta resistencia interna a ir al SaaS?
Los departamentos de IT suelen tener un sesgo natural hacia el control. No es de extrañar. Es su responsabilidad garantizar la estabilidad de los sistemas y el cumplimiento normativo. Para un director de IT, un SaaS es una "caja negra" que introduce variables que él no puede controlar, pero de las que es responsable si algo sale mal. Es decir, un riesgo importante.
Además, también existe un componente que es cultural. El miedo a la pérdida de relevancia. Cuando una capacidad que siempre se ha gestionado internamente dentro de la organización, se intenta externalizar, el equipo puede sentir que pierde poder y relevancia. Pasar de ser los "constructores" a los "gestores de servicios", es un cambio que genera mucha “fricción”.
Conclusión: cómo abordar el cambio
En mi experiencia, la adopción de una solución SaaS no fracasa solamente por cuestiones técnicas, sino también por no gestionar el control, el riesgo y la cultura de la organización.
Debemos fijarnos en qué beneficios nos puede aportar esa solución SaaS: Por ejemplo:
Un riesgo controlado, realizando una evaluación del impacto.
Una velocidad que el desarrollo interno no permita igualar.
Un impacto claro en la cuenta de resultados de la compañía.
Tras hacer un análisis objetivo de costes-beneficios, si el balance es positivo a favor del cambio, la opción del SaaS será percibida como una evolución natural, y habrá menor resistencia.
Estamos viviendo una era en que necesitamos agilidad para ser competitivos. La “soberanía” ya no significa tener el software y los servicios bajo nuestra propiedad, sino en tener la capacidad estratégica de decidir en cada momento quién los va a operar por nosotros.