Opinión, Saas, software as a service, Software como servicio

Haz Saas, no SoSaas

por

Por inercia y hambre de negocio, uno de las preguntas más comunes que aparecen cuando la palabra saas o software como servicio empieza a tenerse en cuenta en las empresas de desarrollo de producto es: «¿y por que no colocamos nuestro software en la nube?«. Es normal, ya tienes un software incluso puede que funcione via web, ¿Por qué no?. Pues a esto precisamente es lo que le han puesto el nombre de SoSaas en inglés «Same Old Software, as a service» y en español, «El mismo software viejo, puesto como servicio».

En la última conferencia Saas organizada por IDC a la que tuve la ocasión de asistir, lo explicó perfectamente el Director Técnico de A3Software. A3Software tuvo claro que Saas y SoSaas no es lo mismo, abrió una línea de negoció nueva donde las operaciones (marketing, ventas, desarrollo, soporte, mantenimiento, roadmap del producto) y la cultura estuvieran completamente separada de la línea de producto tradicional, y desarrollaron un software para entregarlo como servicio aprovechando parte de su viejo software pero sin hacer SoSaas.  Además aprovecharón su presentación para sibilinamente «saludar» a los de SAGE, que tambien andaban por allí, porque al parecer SAGE vende «Citrix + Su aplicación» como si fuera Saas.

Este error tan común y comprensible, ha sido centro de debate de algunos bloggers y gente relacionada del sector como Abe Sultan (que estuvo por aqúí para hacerme una demo sobre SaasGrid)  que en su post «Como fallar miserablemente como Compañía Saas» explica algunos de los errores más comunes relacionados con el SoSaas o con empresas tradicionales que se aventuran con el saas. De este y otros, he extraído algunos de los errores que a continuación detallo  :

1.- No cuidar tus ventas de licencias de software tradicional

Ya consigas un aplicación saas tal y como la venden el equipo de A3 o si estas haciendo SoSaas, como tengas el más mínimo éxito puedes tener problemas con la ventas de licencias de software tradicional que fueron las que te llevaron hasta aquí y a priori tu vaca. Es decir, puedes llegar a canabalizar tu producto vaca. Ten cuidado con el público objetivo del saas, con la funcionalidad de la saas frente a la funcionalidad de tu software tradicional y los precios.

2.- Ignorar tus operaciones

Ya hemos hablado de ello. Añadir que los indicadores clave que medían cada una de las partes de tu empresa (operativas o staff) tampoco te servirán para medir como lo estás haciendo con tu saas. Deben ser más dinámicos y deben tener muy en cuenta las necesidades nuevas del usuario final (que no cliente), los ingresos mensuales, las bajas, los cobros, etc. Dicen que en el saas si sientes el dolor, quizás sea demasiado tarde.

3.- Ignorar la arquitectura, servicios, entornos y fiabilidad

No solo eres un desarrollador de producto, no solo instalas, no solo das soporte, ahora también mantienes la infraestructura y la aplicación.  Es decir, ahora ofreces un servicio y debes tener mucho cuidado con la infraestructura hardware y software para dar soporte a miles de usuarios. Asimismo, una decisión errónea en la elección de la arquitectura de tu aplicación, productos o hardware puede acabar con tu nueva aventura antes de tiempo.

4.- Ignorar el usuario final

El saas te permite mantener contacto directo y diario con el usuario final, desaprovecharlo es perder una de las ventajas competitivas que el saas te da frente al software tradicional. Si además tu competencia saas si le tiene en cuenta y explota esa información, no te cuento lo que te queda.

5.- Aplicar RoadMap tradicional

Históricamente, el roadmap de software tradicional propone versiones cada un tiempo bastante notable (6 meses, 1 año, etc) y normalmente incluye gran cantidad de cambios.  Esto atiende a una razón principal: un cliente no actualiza su software con menos periodicidad porque supone un coste de instalación y mantenimiento poco asumible. Pero el saas te permite que esto que tu roadmap sea más corto porque eres tú el que mantiene la infraestructura. Desaprovechar la oportunidad de darle al cliente sus peticiones y de arreglar los bugs en el menor tiempo posible, es perder otras de las ventajas competitivas del saas.

6.- Confundir Multitenancy con ASP

Este es otro de los errores  que apuntaba al principio del post cuando hacíamos referencia a SAGE.  Saas es multitenancy, es decir, misma aplicación y misma versión para todos los usuarios de tu sistema, y esto te lleva a obtener economías de escala que harán ofrecer la aplicación aun precio competitivo.  Intentar mantener distintas versiones o distintas ejecuciones por cada cliente o por cada conjunto de clientes te puede ir bien al principio mientras no tengas competencia, pero en cuanto la tengas no podrás competir con el precio del saas.  Y solo conseguirás sobrevivir si este servicio personalizado ofrecido a un precio mayor aporta  un verdadero valor para tus clientes.

7.- Versión Free para testear el mercado

Esta me ha gustado, y ocurre tanto si haces Saas como SoSaas.  El fremium es algo tan extendido en Internet que la tendencia natural es pensar: «ponemos una parte free y enseguida enganchamos al cliente con la parte premium«. Y esto está bien para determinadas aplicaciones, quizás aquellas muy tecnológicas que necesiten de buzz,  y sobretodo para aquellos (pocos) que pueden costear la parte free con publicidad , pero para el resto el free es un problema porque cuesta dinero, ya sea por recursos hardware, software como humanos.  La solución: versión de prueba de 30 o 60 días que seguro es mas que  suficiente para probar tu solución.

8.- Construir un producto completo para la primera versión

Muy relacionado con aplicar el RoadMap tradicional. Esperar a tener un producto completo tiene varios problemas: tiempo al mercado largo, retorno de la inversión más  largo, gran posibilidad de desarrollar funcionalidades que no son demandadas, etc. Si unes esto a que el en el software tradicional el usuario no quiere actualizaciones constantes, es lógico que se caiga en tener un producto más completo y terminado. Las condiciones de entrega del saas te permiten no tener que terminar tu producto para ponerlo en el  mercado. Puedes sacarlo con una funcionalidad mínima aceptable y poco a poco actualizar la aplicación tomando como base las peticiones de tus clientes.

Si juntamos estos errores con estos otros 10 errores más comunes de una startup de saas, ya tenemos una buena colección para no meter la pata. ¿La meteremos? Seguro.

Entradas relacionadas: