e-Valúame

Tag Archives: Estrategia

Los 10 errores más comunes de una startup de saas

El otro día comentaba Enrique Dans en uno de sus post que Zoho es el más listo de la clase porque entre motivos, ha empezado a utilizar Google Gears antes que el propio google. La verdad es que Zoho no ha parado de poner software online en los 3 años que llevan de vida y lo hacen realmente bien pero para mí, dentro del mundo “as-a-service” , el más listo de la clase siempre ha sido Salesforce, que con su CRM online ha conseguido ser una referencia en este mundo y ahora con Force quieren ser tambien los líderes en el mundo de las platform as a service.

Para promocionar Force están lanzando una campaña de comunicación y ayuda para que aquel emprendedor que quiera focalizar su esfuerzo en el desarrollo del software as a service, tenga toda clase de información a traves de white papers con consejos para su creación y seminarios web online . Por eso digo que son listos y los primeros de la clase porque como comentaba hace algún tiempo estos tios en Force no cobrán al desarrollador, hacen caja con la base instalada de clientes que utiliza su CRM y que ahora pagará si quiere utilizar una de las aplicaciones que estos nuevos proveedores de saas desplegaran en su plataforma.  De ahí que se dediquen a atraer proveedores de saas con sus aplicaciones para hacer un “poco” mas de caja. 

Hace unos dias publiqué un resumen en español de un informe de Salesforce que hablaba sobre las 7 claves a tener en cuenta en la creación de una saas, y ahora dejo otro resumen de este paper sobre los 10 errores más comunes que suelen cometer cuando lanzas una empresa de saas:


Recuerda que el modelo de negocio de saas es diferente

Error 1.- Ejecutar tus procedimientos operativos como si fueras una compañia de software tradicional. Tus beneficios dependen de ingresos paulatinos y no de grandes ventas, por eso debes tener cuidado con tus gastos fijos y monitorizar la renovación de tus suscripciones e indicadores de futuros ingresos.

Error 2.- Gastar demasiado en marketing y fuerza de ventas. El marketing tradicional y en concreto la publicidad puede resultar muy costosa y hay proveedores de saas que han encontrado fórmulas de marketing más economicas e igual de efectivas.

Error 3.- No poner interés en que el cliente use producto. Si conoces el uso de tu producto, el numero de clics que reciben tus páginas, aquellas que no se utilizan entonces intenta sacar provecho de está información para dar al cliente lo que quiere.


Evita errores de marketing comunes

Error 4.- Conformarte con la mentalidad “construido-ya vendrán”. Necesitas tener una estrategia promocional agresiva que identifique a tu target y los diferentes canales de acceso.

Error 5.- Esperar a que tu cliente tenga éxito. Haz lo posible para que tu cliente utilize y saque partido de la aplicación y que obtenga el beneficio que esperaba. Manuales, videos, soporte online, etc…

Error 6.- Subestimar el poder de la referencias de clientes y de los evangelistas. Los testimonios de clientes y comentarios de los evangelistas hace más estable y confiable tu producto.

Error 7.- No poner interés en las comunidades de usuarios. Los foros de usuarios ayudan al clientes a manejar mejor la herramienta y sirven de soporte de la misma, evitando que el cliente necesite el nivel de soporte básico.  Encuentra a los usuarios evangelista más activos, incentivalos y escuchalos.


No tengas en cuenta como se hacen las cosas en el desarrollo tradicional

Error 8.- Utilizar metodologias tradicionales para la entrega de saas. En el desarrollo tradicional hasta que no tengas un número de cambios funcionales importante no empaquetas para en lanzamiento de una nueva versión. En saas no es necesario hacerlo e incluso puede ser contraproducente hacerlo así porque no creas expectación , dinamismo en la aplicación y parece que no escuchas las peticiones de tus clientes.

Error 9.- Invertir en infraestructura más de lo necesario. Esto es directamente “promocional” a Force, pero es completamente cierto que es una ventaja no invertir en Iaas ( infraestructure as a service) cuando hay gente que lo hace bien y es su negocio.

Error 10.- Que te pillen sin un API. Es necesario que el cliente no sienta que sus datos están aislados de su sistema y que tenga la “oportunidad” de sacar sus datos y llevarlos a otro proveedor de saas.

¿Cuales son los requisitos mínimos del Saas?

Desde el punto del cliente que va a adquirir los servicios de una aplicación ofrecida como servicio, existen una serie de requisitos mínimos necesarios que una Saas debe ofrecer:

Rendimiento.- Una saas debe ofrecer un rendimiento mínimo y aceptable para que sea atractiva su adquisición. El problema aquí es definir mínimo y aceptable y aunque es un concepto subjetivo puede ser medible en tiempos de respuesta en el acceso a los datos, de ejecución los procesos de negocio, de comunicación a la propia aplicación ( delay producido por el alojamiento geográfico de esta), etc….

Acuerdo de Nivel de Servicio ( en inglés Service Level Agreement) .- El ISV de la aplicación Saas debe proveerte de varios niveles de servicio al que los cliente pueda adherirse. Habrá clientes que necesiten su aplicación disponible 8×5 (5 dias a la semana, 8 h) y habrá que clientes que necesiten 24 X 7. El ISV deberá instalar en sus sistemas los mecanismos necesarios para poder ofrecer este tipo de acuerdos, esto es, backup,  cluster de alta disponibilidad de datos y aplicación, etc…..

Privacidad en las comunicaciones.- Debido a la importancia de los datos que puedan albergar las aplicaciones en necesario que la comunicacion que se realiza a través de Internet sea segura, esto es, la comunicación debe realizarse a través de https u otra forma de comunicación que asegure la privacidad de las comunicaciones.

Privacidad de los datos.- De igual forma el ISV debe asegurar que los datos esten seguros y accesibles única y exclusivamente por el dueño del dato. Esto debe ser especialmente perseguido en la aplicaciones multitenancy ( nivel 3 y 4 de maduración) que explique en este post.

Monitorización de la aplicación.- El cliente debe saber de alguna forma que es lo que ocurre en su aplicación, por ejemplo: quién accede, a qué procesos, a qué datos,etc. Esto es obligado cuando el pago por el uso de la aplicación se realiza a través de conceptos como horas de utilización de la aplicacion, consumo de espacio de disco, o cualquier otra forma que sea variable.

Acceso de a los datos.- El resto de la aplicaciones de la organización deben acceder a través de APIs o de Web Services , a los datos y lógica de negocio que se utilizan y genera por el uso de la saas, sobretodo, en clientes que tengan adoptado la arquitectura SOA en su sistema de información.

¿Cual es el modelo de saas óptimo?

Cuando nos enfrentamos a elegir qué aplicación saas queremos que cubra cierta funcionalidad para nuestra empresa o area funcional, debemos saber que es lo que nos ofrece el proveedor desde diferentes puntos de vista. Por ejemplo, no es lo mismo que el software te lo ofrezca a tí solo, que lo compartas con otros clientes y tampoco es lo mismo que el recurso que compartes sea el código de la aplicación que la base de datos donde lo almacenas.

Para decidir que es lo que más nos interesa desde el punto de cliente, antes veremos que es lo que actualmente nos podemos encontrar en el mercado tomando como referencia lo que Microsoft definió y llamó el modelo de madurez de saas. Este gráfico nos ayudará a entender los niveles de maduración que a continuación se describen (puntualización: cuando se habla de instancia se refiere a lógica de negocio y datos, no solo a código):

  • El primer nivel de madurez es similar al tradicional Aplicación Service Provider (ASP), modelo de entrega de software, que se remonta a la década de 1990. En este nivel, cada cliente tiene su propia versión personalizada de la aplicación , y cuenta con su propia instancia de la aplicación en los servidores del proveedor de saas.
  • En el segundo nivel de madurez, el proveedor del software ofrece una instancia para cada cliente (o inquilino) pero a diferencia del primer nivel donde cada cliente tiene su propia versión, en este nivel, todos los instancias utilizan la misma versión de la aplicación, y el proveedor cumple con las necesidades de los clientes mediante las opciones de configuración.
  • En el tercer nivel de madurez, el proveedor a traves de una única instancia da servicio a todos los clientes, ofreciendo la posibilidad de cada uno pueda configurar la metaestructura de la aplicación para personalizarla . Las políticas de autorización y seguridad permiten que cada cliente mantenga sus datos separados de los de otros clientes y, desde el punto de vista del usuario , no hay indicios de que la instancia esté siendo compartida entre varios clientes. Como varios clientes comparten una instancia, los datos de cada cliente son lógicamente separados de la de otros clientes.
  • En el cuarto y último nivel de madurez, el proveedor da servicio a varios clientes a traves de varias instancias de nivel 3 balanceando la carga ( clientes conectados a cada instancia) de cada instancia . Cada instancia puede dar servicio a varios clientes desde máquinas distintas ofreciendo este nivel un alto grado de escalabilidad , ya que el número de servidores pueden ser aumentados o disminuidos, según sea necesario para satisfacer la demanda, sin necesidad de rediseño de la aplicación. Salesforce ofrece un nivel 4 de madurez con posibilidad de configurar tus propias tablas compartiendo la misma BBDD.

Como se puede ver a medida que aumenta el nivel de madurez se obtiene un mayor aprovechamiento de las economías de escala provinientes de la reducción en cada nivel de los recursos necesarios que componen la solución y por tanto del menor mantenimiento.

Desde el punto de vista del proveedor el nivel de madurez elegido para su aplicación Saas dependerá del compromiso entre el coste de la solución y el beneficio a obtener a corto,medio y largo plazo. Tambien dependerá de los productos propietarios del proveedor que rodean a la solución saas, por ejemplo si el proveedor dispone de un servidor de aplicaciones propietario, rapido, estable y consume pocos recursos de la máquina, es posible que le merezca la pena quedarse en el primer o segundo nivel de madurez y ofrecer un servidor de aplicaciones para cada instancia o quizás no porque el mantenimiento de tener varios servidores de aplicaciones es mayor.

Desde el punto de vista del cliente, además de saber cual es el nivel de madurez que ofrece el proveedor ( hay que tener en cuenta que en todo momento hemos hablado a nivel de instancia) me parece importante que además informe de las posibilidades que tengo en cuanto a infraestructura, por ejemplo:

  • ¿ Puedo tener mi aplicación en una máquina en exclusividad?
  • ¿Puedo tener mi aplicación en un servidor de aplicaciones en exclusividad?
  • ¿Comparto el servidor de aplicaciones con varias instancias por cada cliente?
  • ¿Comparto la BBDD de Datos con otros clientes?
  • Si me ofrece un nivel 3 de madurez y comparto la BBDD. ¿A que nivel se comparte? ¿a nivel de tablas o nivel de esquema de usuario?

Por tanto, vistos los niveles de madurez y la posibles combinaciones de infraestructura que nos pueden ofrecer, estos serán los factores que intervendrán a la hora de adoptar la solución:

  • Seguridad de los datos, habrá clientes que prefieran un nivel de madurez bajo para que sus instancias ( logica y datos) esten separadas del resto de instancias correspondientes a los otros clientes por miedo que sus datos puedan ser vistos por otros clientes.
  • Rendimiento, de igual forma habrá clientes que prefieran que sus instancias esten separadas para que el rendimiento no sea dependiente del numero de clientes que se conecten a la instancia, incluso preferiran que el servidor de aplicaciones sea diferente.
  • Escalabilidad, el potencial crecimiento de uso de la aplicación puede tambien ser determinante y los niveles bajos ofrecen soluciones menos optimas para el proveedor y por tanto más caras que los altos.
  • Nivel de servicio (disponibilidad de la aplicación), por ejemplo un nivel 4 de madurez nos garantiza un nivel cercano al 100% de servicio de la aplicación y posiblemente un coste reducido por el uso del mismo.
  • Coste del saas, a priori un nivel bajo de saas debería ser más caro que un nivel alto de saas y por tanto esto influirá en la decisión del cliente. Digo que debería porque un saas con un nivel de madurez alto requiere mayor diseño y desarrollo que uno bajo y por tanto requerirá mayor inversión ( aunque tambien se aprovechan de las economías de escala) y esto puede revertir en el precio al cliente final. Este dato es dificil de obtener y costoso de comparar.

Resumiendo, debemos tener en cuenta tanto los niveles de madurez como la infraestructura donde corren estos niveles y elegir qué solución es la que más nos adecuada que engancha con nuestra cultura de empresa, que cubrá nuestra necesidades de funcionalidad y que cumpla con nuestros requerimientos de seguridad , servicio de aplicación y rendimiento.

¿Cuales son las diferencias entre ASP y Saas?

Desde hace unos días me rondaba la cabeza escribir un post sobre las diferencias entre ASP y Saas y ayer finalmente decidí que lo tenía que hacer a consecuencia de un mail que recibí de uno de los lectores de este humilde blog. En el mail me hacía una serie de preguntas utilizando el acrónimo asp y otras utilizando el acrónimo saas, y no llegué a identificar si era un problema de utilización del acrónimo correcto o es que de verdad se estaban confundiendo los significados.

Si buscamos información del termino ASP y Saas e incluso si buscamos “diferencias entre ASP y Saas” aparecen muchas entradas que intentan explicar los terminos pero la mayoría de las comparaciones confunden el termino ASP con Hosting y a partir de ahí la comparación con Saas no sirve para nada. Me gustaría aclarar primero qué es ASP y qué es Hosting apoyándome en estas definiciones que encontré:

  • En modo ASP se paga una cuota periódica por alquilar la plataforma. Dentro de esta única cuota estarían incluidas las licencias, hosting, mantenimiento, etc.
  • En régimen de Hosting pagas licencias y/o el proyecto y puedes alojarlo en servidores de tu propiedad o quizá del proveedor.

Creo que queda claro que con ASP se paga por uso y con Hosting pagas licencias de los productos que usen y las máquinas pueden ser tuyas o alquiladas pero se encuentran en casa del proveedor. Aclarados estos conceptos intentemos aclarar las diferencias entre ASP y Saas.

ASP significa Application Service Provider ( en español Proveedor de servicios de aplicaciones ) y como explica la wikipedia en su primer párrafo, proporciona servicios de software. El resto ( lo pego para no tener que acudir) dice lo siguiente:

“Entre los factores que caracterizan a un PSA se destacan la amplia difusión del uso de Internet, la capacidad de acelerar el despliegue y puesta en marcha de aplicaciones y la posibilidad de transferir servicios y operaciones a terceros. La barrera principal para un PSA radica en convencer a sus clientes de que su información en manos de un tercero permanece segura. Por otro lado, son dueños y operadores del hadware y el software y rentan a los clientes el uso de aplicaciones de la computadora.”

Veamos ahora a la definición que la wiki hace de Saas:

“Software como Servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software en donde la compañía de IT provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. En otras palabras es tener la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software. En palabras simples: El cliente tiene el sistema hospedado en la compañía de IT. Es software donde el acceso es vía Internet. No necesariamente se da por medio de navegadores Web, la lógica de negocio reside en la localidad central del proveedor.”

Y la verdad, esta escrito con distintas palabras pero hay muy pocas diferencias :

  • Se accede a través de Internet.
  • En un servicio de uso y de mantenimiento.
  • Se paga por uso, no por licencia.
  • Los datos y la lógica de negocio en casa del proveedor.
  • Las aplicaciones no necesariamente se ofrecen a través de navegadores y por tanto a veces será necesario instalar software en el cliente y otras no.

Y entonces ¿Cuales son la diferencias entre ASP y Saas?. Pues aunque no lo parezca si hay diferencias:

  • ASP es un alojador de software propietario de otros ISV. En el modelo Saas son los propios ISV( los creadores del software) los que ofrecen el hosting y el software en un solo paquete.
  • Muchas de las aplicaciones que corren o corrían en los ASP no están preparadas para dar acceso a través de internet. He visto acuerdos del 2002, 2003 de HP, SAP, etc, con ASP para ofrecer a través de internet las mismas aplicaciones que fueron diseñadas para correr in-house.
  • Estas mismas aplicaciones tampoco fueron diseñadas para dar servicio a múltiples clientes de distintas empresas, es más, se ejecuta una instancia por cada cliente del ASP. La mayoría aplicaciones como servicio (modelo saas) si están diseñadas para ofrecer la aplicación a varios clientes a través de una sola instancia (multitenancy)
  • Relacion con lo anterior, al proveer una instancia cobertura varios clientes a la vez es necesario que la aplicación tenga un alto nivel personalización para cada cliente.
  • Aunque hemos visto que no necesariamente las aplicaciones ofrecidas como servicio ( modelo saas) se consumen a través de un navegador y por tanto no requieren instalación en el cliente, en verdad la mayoría de ellas se consumen a través del navegador. De hecho no conozco ninguna Saas que no sea así. Las aplicaciones que corren en ASP pueden o no ejecutarse a través del navegador y por tanto requerían de una instalación adicional en el cliente ( un emulador de windows o de unix, el escritorio remoto, terminal server, citrix).
  • Relacionado con lo anterior, ASP puede ofrecerte distintas aplicaciones y de diferentes tipos dependiendo de los acuerdos que llegue con las compañías propietarias de software. Esto sin embargo es más complicado que se consiga en el modelo saas, normalmente el ISV te ofrece un solo software aunque tambien tenemos ejemplos coomo google apps o zoho que ofrecen más una.
  • Por ultimo, algo más que evidente es que en el modelo saas podemos disfrutar de un soporte directo, más personalizado, y sin intermediarios que puedan escurrir el bulto ante un problemas del software.

Espero que el post haya despejado más dudas que añadirlas y que en todo caso genere polémica suficiente para que lleguemos a aclarar los términos.

Informe del saas para el 2008

Las empresas y gerentes de TI han clasificado el software como servicio y la arquitectura SOA como las tendencias más importantes en la industria del software por tercer año consecutivo, según la encuesta anual de McKinsey & Co y Sand Hill Group, que se ha presentado en la Interop / Software 2008 celebrada en Las Vegas durante los días 28 y 29 de Abril.
En una encuesta a 857 gerentes, el 23% de ellos opina que SaaS será la tecnología más importante para sus negocios durante el 2008, dato ligeramente superior al 21% del año pasado, pero menor que el 30% del 2006. Uno de cada cuatro encuestados clasificaron los servicios Web / SOA como la más importante, frente al 18% en 2007 y el 24% en 2006. Por detrás de estas tendencias estuvieron el software libre, el offshore outsourcing, y la consolidación de la industria del software.

SaaS continua apuntando a las pequeñas empresas. En las empresas de entre 1000 y 25000 empleados, un promedio del 11% de los presupuestos de software se dedicaron a SaaS, y el 70% o más de los presupuestos tradicionales se dirigieron a las licencias de software y mantenimiento. En contraste, los encuestados con menos de 100 empleados gastan el 26% de sus presupuestos en  SaaS, mientras que aquellos de entre 100-1000 empleados gastan un 17%. Entre las empresas con menos de 1 millon de dolarés en ingresos anuales, 46% había comprado al menos una aplicación SaaS.

La investigación de McKinsey también reveló la maduración del SaaS en las pequeñas empresas. El 36% de las pequeñas y medianas empresas están utilizando múltiples aplicaciones SaaS. Sólo el 12% de los encuestados dijeron que habían adoptado su primera aplicación SaaS en el 2007, en comparación con un tercio de los encuestados que han adoptado su primera SaaS en el 2006.

“El pico de adopción ocurrió en el 2006, y ahora es una cuestión de profunda penetración de SaaS”, dijo Junaid Mohiuddin, un software consultor en McKinsey & Co.

El estudio de McKinsey y Sand Hill incluyó  el almacenamiento online y los servicios de seguridad. Los encuestados declararon que el almacenamiento online fue una de las soluciones SaaS mas utilizadas, seguida de la copia de seguridad online, servicios de seguridad, mantenimiento de redes y sistemas y el CRM.

Los principales criterios de selección de proveedores de SaaS son la velocidad del despliegue de la solucion y la facilidad de integración, seguido por la experiencia del proveedor de la solución SaaS, y los costos.

En resumen, el estudio demuestra que la tendencia saas sigue en alza y se considera como una oportunidad de negocio para las empresas proveedoras de productos software y empresas desarrolladoras y de uso para el usuario final que consume el software as a service.

SOA y SAAS

Al buscar información en la blogosfera acerca de Saas en numerosas ocasiones he visto este acrónimo asociado al SOA. En la wikipedia está muy bien explicado el concepto SOA, por tanto solo quiero mostrar mi opinión sobre porqué creo que SOA y Saas están íntimamente relacionadas.

Hay algo que si quisiera destacar de SOA que no aparece explícitamente destacado en la definición de la wikipedia y es que la decisión de que tu sistemas de información adopten el modelo SOA es claramente estratégica y debemos tener claro cual es el beneficio que queremos obtener de esta decisión. Saas sin embargo solo es una aplicación más que debe estar integrada en este modelo y por tanto cae fuera de las decisiones estratégicas de la empresa, al menos de momento ya que parece complicado que la empresas se planteen poner sus datos y lógica de negocio críticos en la nube.

En las empresas donde los sistemas de información de la compañías siguieran la arquitectura orientada a servicios por definición implicaría que las aplicaciones o mejor las funciones de negocio de la empresa deberían presentarse como servicios, ya sea a través de web services o api. Si a este modelo le añadimos el concepto saas, sería de obligado cumplimiento que las aplicaciones como servicio expongan las funciones o lógica de negocio a través de web services o de apis y además no solo la lógica de negocio también los datos que esas aplicaciones almacenan.

Pero la realidad es que por lo que hasta ahora conozco , no hay muchas aplicaciones como servicio a las que se pueda acceder a su lógica de negocio  y a sus datos a través de web services. Salesforce es una de ellas y quizás por ser la pionera en entornos saas e instalada en más 41.000 empresas que demandaran este tipo de acceso  de la aplicación on-demand.

La verdad es que tiene algo de guasa, porque si el saas es un servicio, ya le podían poner la palabra web y asunto arreglado, pero claro es que la acepción de servicio en este caso se refiere más al uso o consumo de la aplicación que a la forma de acceder a él que es lo que nos interesa en este caso.

Mi opinión es que ambos conceptos prácticamente acaban de ver la luz y al ser SOA un modelo que arrastra a toda la compañía y por experiencia difícil de implantar, no hay muchas empresas que tengan su sistema de información orientado a servicios y quizás por ello no es de vital importancia que las aplicaciones saas que hay en el mercado no cubran está necesidad, pero estoy seguro que las mismas irán incorporando este requerimiento esencial para la incorporación al modelo SOA.