Es relativamente fácil encontrar literatura acerca de las dificultades y barreras de adopción del modelo SaaS por parte de las empresas (lado demanda) y menos fácil encontrarlo sobre esas dificultades en el lado de la oferta (fabricantes e integradores) para poder ofrecer ese modelo a sus clientes.
Por ello me ha parecido interesante ordenar una serie de reflexiones que he venido leyendo y comentando en diferentes foros (*) sobre qué factores dificultan a las empresas proveedoras a hacer la transición desde un modelo tradicional (venta de licencias + servicios + mantenimientos) a ese modelo SaaS.
Pero antes creo aconsejable precisar que entiendo que una aplicación sigue un modelo true SaaS cuando cumple los siguientes requisitos:
- Multitenancy: es decir que se pueda compartir de forma fácil entre varios clientes, ya hemos hablado sobre este concepto varias veces, por lo que para no repetirme invito a quien lo crea necesario a que lo repase en esta serie de posts.
- Pago por uso y/o subscripción, es decir el cliente paga una cuota periódica en base al uso de la aplicación (medida en usuarios, transacciones, funcionalidades, etc…).
- Con bajas barreras de acceso, entrada y de salida, es decir con mínimas necesidades a nivel de estación de trabajo (un navegador), acceso por Internet y fácil de suscribir y cancelar la suscripción, … (más info aquí y aquí).
- Sostenible para el proveedor, es decir que el modelo sea viable económicamente.
Y ya centrándonos en el tema del post, estos son los factores que creo que debe considerar un fabricante o integrador de aplicaciones de gestión que quiera hacer una transición a un modelo SaaS desde un modelo tradicional:
Arquitectura de aplicación
Obviamente un cambio necesario para poder ofrecer una aplicación en modo SaaS es adecuar la plataforma y arquitectura tecnológica (modelo de datos para que sea multitenancy, seguridad, accesible vía navegador Web, facilidad de integración con aplicaciones externas, etc. ) pero lo que no me parece tan obvio, y no por ello poco impactante, es el efecto colateral que se produce como consecuencia de necesidad de integración con terceros (apertura de APIs, disponibilidad del código, modelo de datos, seguridad, etc.) , porque ¿quién concibe hoy en día una aplicación en Internet que no se pueda conectar con otros servicios Web?
Y esto último es lo que quiero destacar, lo que empieza como un tema técnico acaba derivando e impactando en tu modelo de alianzas y negociación con terceros, algunos muy potentes, que obligará a hacer la plataforma menos propietaria y más amigable a la integración débil (ocasional, con pocos volúmenes, menos transaccional, …) con otras aplicaciones (la integración fuerte, la que se tiene con las otras aplicaciones de negocio del cliente ya cuento que persista). Ejemplos que se me ocurren al respecto es la integración del software de gestión con aplicaciones como Evernote, las Apps de Google, Dropbox, herramientas de colaboración y gestión de proyectos, etc.
Operaciones:
Las aplicaciones true SaaS están en lo que se denomina (de forma quizá exagerada a mi parecer) beta continua, es decir que el software está en estado de cambio continuo, con entregas frecuentes, y en pequeños incrementos (¡o decrementos!) de funcionalidad, en oposición a la entrega tradicional por versiones un par de veces al año en el mejor de los casos. Es decir, de grandes cambios poco frecuentes al cambio continuo.
Las consecuencias en las operaciones del fabricante del software son tremendas, porque le obliga a trabajar de otra forma, con enfoques ágiles, equipos poco jerarquizados y autogestionados para posibilitar decisiones rápìdas, con un reto relevante en la coordinación de recursos internos, externos y con los clientes, con procesos de construcción de software muy afinados y automatizados (Priorización de peticiones, test & deployment, …), distribución push y control de cambios, … os podéis imaginar muy bien los que habéis participado en proyectos de desarrollo lo que significa liberar nuevas funcionalidades de forma continua en instalaciones ya consolidades.
Si el impacto en como se organizan las operaciones en el fabricante es alto, el que se produce en integrador o partner es lo siguiente a tremendo, ya que a estos no les queda más remedio que cambiar de un modelo basado en proyectos de implantación grandes y luego proyectos recurrentes de cambio de versión, a modelos más centrados en exprimir la funcionalidad estándar de la aplicación (los desarrollos de cliente para personalizar el software se reducen drásticamente sino desaparecen) y además en proyectos mucho más cortos (con una salvedad quizá y es que en el mejor de los casos podrían incluso crecer los servicios alrededor de la integración con aplicaciones de terceros). En resumen y si me permitís un símil castrense, los integradores pasan de estar organizados como escuadrones de una división a serlo como comandos, de acción rápida.
Como el trozo de pastel que se llevaban los integradores en el modelo tradicional ahora se hace previsiblemente mucho más pequeño, ya no sólo por el tipo de proyectos sino porque se reducirá la dependencia del cliente del integrador en favor del fabricante, estos integradores no pueden estar muy contentos con el cambio y esta es, en mi opinión, una razón clave (quizá la principal por encima de la canibalización de sus productos tradicionales) por la que los fabricantes, presionados por sus partners, se muestran tan reacios o perezosos en abrazar el modelo SaaS.
Finanzas:
Al pasar desde un modelo donde, tanto en fabricantes como integradores, se producía inicialmente un ingreso relativamente grande (licencias y proyecto de implantación) y luego ingresos regulares (mantenimientos y proyectos de mejoras/cambios de versión) a otro modelo con ingresos más aplanados en concepto de suscripción, la gestión financiera tiene que cambiar, con todas las consecuencias que eso tiene sobre los planes de inversión y mejora de producto por ejemplo.
En cierto modo, y asumiendo que al menos en el caso del fabricante los ingresos por cliente se mantienen en su tiempo total de permanencia, la gestión financiera se puede facilitar al tenerse un modelo más plano de ingresos.
***
Hasta aquí, lo que, como ya he mencionado antes, es una compilación de reflexiones que he venido leyendo en diferentes foros. Me encantaría conocer las tuyas en los comentarios.
(*) sobre todo en nodoERP, el grupo de LinkedIn que modero, y donde si no lo has hecho ya, te recomiendo encarecidamente que te suscribas.
* * *
Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.
Si necesitas ayuda o soporte en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.