e-Valúame

Category Archives: Estrategia

¿Que pasará en el 2009 con el cloud computing?

 bola-cristal 

 

 

No hay ninguna predicción del 2009 referente a los sistemas de información en la que no aparezca el cloud computing como apartado a tratar y pensando lo bien, ya sería algo destacable incluso si la cosa no pintara bien . A mi entender o de verdad se intuye o se tiene pasta para que “la predicción”  sea en base a encuestas a empresas y responsables de IT, y yo, como no tengo recursos, me tiro a la piscina y siempre tendré la excusa de que Rappel no soy 😉

Saco pues la bola por cada nivel del cloud computing

IaasInfrastructure as a serviceInfraestructura como servicio

En mi opinión, tanto el iaas como el saas serán las dos que más van a explosionar. Amazón lidera el mercado de la infraestructura como servicio y seguramente así seguirá siendo así porque sus precios son muy competitivos. Pero aún hay mucho por hacer en este sector, se puede mejorar la oferta técnica en la parte de computación ( autoescabilidad, performance, monitoring, tipos de máquina, recursos), las oferta SLA, el soporte técnico, las soluciones storage y sobretodo las soluciones de BBDD en la nube. Con lo cual hay hueco para diferenciarse y abrirse camino en este mercado.

Seguro que empresas como IBM, Sun o Dell tendrán algo más que decir en este 2009 porque aunque ya están haciendo algún pinito no parece haber aún una apuesta clara por el cloud computing. Y además estoy convencido de que aparecerán otras más provenientes del mundo hosting y/o ASP y que están acostumbrados a las exigentes condiciones de los clientes con SLA que rondan el 99% de servicio, que tienen acuerdos con proveedores de hardware, que tienen experiencia en como rentabilizarlo, y que creo que ese know-how se puede transformar en una oportunidad de negocio. No digo que la infraestructura de IT y operativa les pueda servir, seguramente deberán reestructurarla pero si opino que ese know-how lo pueden aprovechar. Al menos sé que NTT Europe está apostando en está dirección y estoy seguro de que aparecerán más empresas.

El otro día leí un artículo sobre un empresa que ahora mismo no recuerdo lo que hacen pero en resumen contaban que poseen infraestructura in-house y utilizan la nube para picos demanda de sus aplicaciones. La bola me dice que este tipo de soluciones, aunque no será fácil disponer información de este tipo de demanda, será cada vez más utilizada.

PaasPlatform as a servicePlataforma como servicio

En mi opinión de las tres partes del cloud computing es la que más complicado lo tiene y la que más debe afinar su oferta de servicios. La integración hacia delante por parte del iaas (por ejemplo RackSpace ya lo ha hecho con Mosso) y hacia atrás por el saas, es una amenaza latente y a tener en cuenta en aquellas plataformas como servicio que se montan con lenguajes de programación abiertos y servidores de aplicaciones con frameworks no propietarios como pueden ser .NET, Python, Ruby on Rails, Java,etc. Conozco de varias soluciones saas en desarrollo que pasarán  de utilizar servidores de su propiedad a consumir maquinas EC2 de Amazon sin pasar por ninguna paas. No digo que vayan a morir solo digo que son la que más difícil lo tienen y las que deben tener muchos cuidado con su oferta de servicios y sus precios, por ejemplo una de las paas que me parece de las atractivas y competitivas es Saasgrid .

En mi opinión y en este año 2009, será la parte que menos soluciones dará pero sin embargo cuando hablemos de ella será de las que mas notoriedad tendrá por la repercusión de las actuales paas de Salesforce, Google, Microsoft y Velneo ( por la parte que me toca 😉 ), y de las que espero también tengamos de Sun y quizás de IBM, aunque a esta última mi vena Octavio Acebes la vé solo en la parte Iaas.

SaasSoftware as a serviceSoftware como servicio

Si echamos un vistazo a las encuestas, la falta de soluciones saas, y en general a la falta de mercado, no hace falta ser Rappel para saber que saas será la parte del cloud computing que más se va a desarrollar. Aparecerán soluciones de startup creadoras de saas, versiones saas de empresas propietarias de software tradicional como por ejemplo Sage-Saas, soluciones verticales para pyme (parte del saas aún sin explotar sobretodo en el mercado español) que competirán con las actuales verticales tradicionales y por supuesto aparecerán soluciones saas que no cubre en la actualidad el software in-house y que aunque sería igual de interesante desarrollarlo en in-house, si el target es el mismo, seguro que las soluciones se desarrollarán en saas.

En cuanto a las empresas grandes veremos movimientos llevando sus productos in-house a la nube tal y como ha hecho Microsoft con los MicroSoft Online Services. Empresas como Oracle, SAP con su esperada solución Saas, etc. seguro que nos sorprenderán con alguna que otra noticia acerca de sus productos en la nube.

Por ultimo y en cuanto al saas, es un mercado muy inmaduro, aún con poca credibilidad y en mi opinión las soluciones creadas y adoptadas en ningún caso cubrirán estadios críticos de la empresas adoptivas. Tambien veo necesario que la empresas de comunicación ofrezcan y mantenga una estabilidad continuada y con SLA tan cercano como lo que las empresas del cloud están ofreciendo para que el cloud computing empiece a asentarse y mantenga credibilidad al menos en la disponibilidad de las soluciones.

Nada más, bueno una última, aunque es más un deseo que una predicción, y es que espero y deseo que alguien grande como Amazon o Salesforce no meta la pata más que lo permitido porque una gorda de alguna de estas empresas en plena rampa de salida, puede mandar la tendencia al carajo o al menos puede disminuir el ascenso que está teniendo y del que deseamos que asi continue.

¡¡¡FELIZ 2009!!!

¿Es un buen momento para invertir en saas?

tormentaLa crisis económica nos mantiene alerta y el sentido común nos recomienda que no movamos ni un dedo hasta ver que pasa.  No es broma las previsiones no son nada alentadoras e incluso las señales indican que será la peor crisis de toda la historia y la primera gorda en un mundo globalizado que cuando ha empezado a toser  EEUU se costipó  Europa.

 ¿Hasta cuando durará la crisis? La bola de cristal no la tiene nadie porque aún no se sabe cuál es la dimensión del problema (ver el punto 19). El rango entre los más optimistas y los más pesimistas es alto, y unos dicen que el remonte vendrá a finales del 2009  y otros opinan que tendremos que esperar hasta principios del 2011.

Y ante este panorama, ¿Invertirías en saas? Pues según Carlos Blanco CEO de ITNet , dice que la inversión en Internet es de las mejores opciones en estos momentos y este hombre y su equipo algo sabe de esto. No tengo claro que todo internet sea la mejor opción pero ellos están inviertiendo en el online al igual que DAD liderado por Rodolfo Carpintier y que también incita a la inversión en proyectos de internet. Claro que el problema del saas es que por definición no es precisamente de lo más rentable a corto plazo (una de las recomendaciones que tambien nos da Carlos Blanco) y requiere de pulmón financiero importante hasta que tu masa de clientes te lleve al punto de equilibrio. Aunque también dentro de las recomendaciones, Carlos habla de que lo más interesante es la inversión en proyectos innovadores y desde luego todo el cloud computing lo es. Entonces, ¿Que hacemos? ¿invertimos o no? ¿que pesa más la nueva ola “cloud” o asegurar la rentabilidad a corto plazo?

Si tiramos de las previsiones de adopción de cloud computing para los años venideros, la respuesta de las empresas es bastante positiva y la justificamos porque el cloud computing te ofrece inversión cero, cero mantenimiento y además de otras ventajas, si no te gusta el servicio al mes siguiente dejas el pago y fuera. Es claro que por el momento en que se realizan algunas de encuestas, el resultado no tenia descontado la actual conyuntura económica por tanto no justifico la posible adopción a la crisis. Tampoco tengo duda que la crisis siempre estará a favor del saas o cloud computing, porque en caso de necesidad de software el director de IT trapasa toda la inversión al proveedor de saas. Y tampoco dudo que pasada la crisis, la resaca durará al menos 1 o 2 años e impulsará aún más esta tendencia o modelo de negocio.

Para reforzar un poco más la apuesta, si echamos un ojo a todas la grandes del software , software as a service y del mundo online, Google con Google Docs y Google App Engine, Microsoft con Online Services y Windows Azure, Amazon, Salesforce,etc…parece que esto va a en serio.

Sé poco del business angels, capital riesgo y demás, pero tomado el “feeling” de como está el mercado y su potencial proyección, creo que la inversión dependerá más del perfil del inversor y de la situación actual del mismo que de la viabilidad del cloud computing, porque es claro que lo es. El inversor a largo o que tenga por costumbre la diversificación de su capital, no dudará en apostar por un proyecto saas, y el que necesite o quiera recuperar desde el primer año de la inversión seguro que apuesta por otro tipo de proyectos aunque “a largo” pueda ser menos rentable.  

Aún queda por decidir en qué tipo de software me meto. Yo tiraría del plan de negocio porque  incluirá el estudio de mercado al que apuntan y porque debe de llevar incluida en la rúbrica financiera, la crisis. También podriamos acompañar la decisión de informes tecnológicos como este de Forrester de Febrero del 2007 , que muestra las aplicaciones que serán más demandadas.

forrester1

Yo no soy inversor pero ya he invertido en cloud computing. Este blog no es inversión monetaria  pero requiere dedicación y tiempo y ya veremos cuales serán sus frutos. Pero además he invertido, y está vez si ha sido inversión monetaria, en Velneo  la única paas española que estoy seguro llegará a competir con los más grandes. Animense que estoy seguro de que no se arrepentirán.

Las aplicaciones Zoho podrán ejecutarse en Google App Engine

Pues eso, que cada muy poquito tiempo hacen algo especialmente reseñable y hoy nos sorprenden con un movimiento que puede tener varias interpretaciones. Desde ahora las aplicaciones creadas en Zoho desde creator.zoho.com (el directorio que mantemos Javier y yo, utilizamos creator.zoho.com para el almacenamiento de los soluciones)   podrán desplegarse en la paas (plataforma as a service) de Google, Google App Engine.

google-zoho

Como sabemos en la plataforma de Google,  podemos desplegar las aplicaciones que desarrollemos en Python siempre y cuando utilizemos su SDK que las integra en la plataforma.  Con esta nueva característica Zoho se convierte en un entorno de programación de aplicaciones Python pero con la facilidad de que no tienes que tener ni idea de programar en Python porque te genera el code Python necesario para su ejecución en Google App Engine. Es destacable también que no solo las aplicaciones son exportable a Python, los datos también se exportan a la paas de Google.

Este video explica como se puede hacer este despliegue:

¿A que atiende esta integración Zoho-Google? La verdad es que parece no tener mucho sentido. ¿Crear aplicaciones en Zoho para despues ejecutarlas en Zoho llegando en algún caso a pagar por desplegar en un entorno y en  el otro? Pero si leemos el último párrafo del anuncio:
With our CloudSQL release last month, we let the data free, giving you the control of your data. With this release, we are letting your applications free, offering you alternative deployment options. Welcome to the new ‘open’ model.
Con nuestra utilidad CloudSQL, te dejamos que tengas el control de tus datos. Con esta nueva utilidad, dejamos tus aplicaciones libres y ofreciendote otras  alternativas de despliegue.
“Bienvenido al nuevo modelo abierto“. En mi opinión lo que están haciendo es generar confianza en el desarrollador y el usuario final consumidor de las aplicaciones,  para no quedarse colgados  en un lenguaje de programación y plataforma que nadie conoce y/o que puede adolecer de las capacidades y funcionalidades para cubrir todas las necesidades del clientes o del desarrollador.  Por ejemplo: Pónganse  en el lugar de un cliente que quiere una aplicación en Zoho porque la plataforma tiene un precio realmente interesante pero que  si la plataforma fuera al carajo no sabrá que hacer con un código de lenguaje de programación propietario de Zoho y que  ninguna otra plataforma como servicio puede o sabe ejecutar.  De esta forma Zoho les está diciendo a sus clientes que no tengan miedo en desarrollar aplicaciones en Zoho porque en el caso peor podrán exportarlas a Google App Engine sobre un lenguaje de programación más que conocido y con la posibilidad de ni siquiera tener que utilizar la paas de Google (el código generado puede ser descargado desde la plataforma App Engine).
Hay otras opiniones acerca de este movimiento. Por ejemplo Zoli opina que el motivo es porque Google genera más confianza a la hora de tener tus aplicaciones y datos en manos de un proveedor. Pienso que si asi  fuera,  Zoho se estaría echando piedras sobre su propio tejado.  En CloudAve opinan que Zoho no ofrece servicio de compra de dominio y Google si, y además defiende de alguna forma la explicación que expongo más arriba.
A mi modo de ver, la idea es sencillamente brillante y además lleva implicita que tienen un gran confianza en su plataforma para la generación de aplicaciones , a un precio muy competitivo.

Microsoft Exchange y Sharepoint entran en producción

En el dia de hoy Microsoft ha anunciado que los servicios online Exchange Online y Sharepoint Online han salido de la Beta y ya es posible disfrutar de estos dos productos, junto con Live meeting y Comunication Online, por un precio de 15$ al mes por usuario. Además es posible probar sus servicios durante un mes sin coste alguno.

La verdad es que no han tardado mucho en liberar el producto porque fué en Julio de este año cuando anunciaban la apertura de la beta y adelantaban los precios de los online services que como podemos ver sus precios no han variado desde aquel anuncio.

El acuerdo del nivel de servicio para las suit de productos online en lo que se refiere al pago por incumplimiento del acuerdo se puede ver en la tabla de abajo y al menos es capaz de devolver el 100% en créditos (=esto es lo mismo que cuando te dan un vale en un tienda y solo lo puedes canjear en la misma tienda), cosa que Amazon ni siquiera se plantea.

    i.     Uptime Service Levels

Monthly Uptime Percentage

Service Credit

 < 99.9%

25%

 < 99%

50%

< 95%

100%

El posicionamiento que quieren hacer del conjunto de productos es tan ambicioso como en muchos de sus productos: apuntar  a cualquier tamaño de empresa aunque bajo mi punto de vista productos como comunication online y Sharepoint solo los veo para empresas de al menos tamaño medio.

Esta claro que Microsoft ve en la nube una nueva fuente de ingresos y no quiere dejar escapar esta nueva tendencia del cloud computing.  La prueba está en que en un breve espacio de tiempo han anunciado SQL Data Service,  la plataforma como servicio Windows Azure, el nuevo Office que estará en la nube y estos servicios. Atrás quedan los días donde en Microsoft defendían el software + servicios en una estrategía más de comunicación y reorientación de sus mismos productos que de seguir la arquitectura de desarrollo (multitenancy) y modelo de negocio del software as a service. Veremos cual es el siguiente paso de este gigante.

¿Y si me quedo sin internet?

Antes de ayer , a través de los comentarios me hicieron una pregunta que cuando empecé a contestar pensé que mucha gente se hará la misma pregunta y vi que el tema tenía tanta “chicha” como escribir un post. Pego el comentario:

En primer lugar, enhorabuena por el blog me parece super interesante. Trabajo en una multinacional de Software con un programa de contabilidad muy conocido y usado por las pymes españolas. Mi opinión es, que realmente el modelo SaaS es muy interesante y es más, hemos conseguido que lo comprendan (hace unos años era impensable), realmente la pyme siente desconfianza por las comunicaciones. El otro día me comentaba un cliente lo siguiente: “me parece muy bien lo que me has explicado refiriéndose al modelo SaaS, pero si dices que se basa en nternet tengo dudas porque se me puede paralizar mi negocio y me contaba como Telefónica le dejó una semana sin Internet”.

Ante esto mi pregunta es, ¿Cómo lo véis?¿Creéis que las comunicaciones actuales pueden ser un obstáculo al modelo SaaS?

Antetodo tengo que agradecer a Aurea sus halagadoras palabras.

A la pregunta de Aurea, mi respuesta es que sin duda , la perdida de conexión a través de internet y por tanto la indisponibilidad de la aplicación, es una de las barreras de entrada al saas junto con el de la seguridad y privacidad. No olvidemos que a parte de perder el servicio de internet, el proveedor del saas puede tambien tener problemas en su infraestructura pero tampoco hay que olvidar que en la soluciónes tradicionales, nuestra infraestructura tambien puede darnos disgustos, con tiempos de respuesta y soluciones peores en comparación con los proveedores externos.

En el caso que nos plantea Aurea de su cliente, la mejor forma de resolver sus dudas es ayudarle a descubrir las posibles soluciones que existen ante la perdida del servicio de internet, y valorar si sigue siendo interesante el saas o por el contrario es preferible la aplicación tradicional.

Como cliente, lo primero que haría sería valorar el impacto que mi negocio o  mi gestión sufriría si pierdo alguna de la aplicaciones y las probabilidades de que ocurra. Preguntas como: ¿No puedo seguir con la operativa? ¿No puedo continuar con la tareas de mantenimiento o gestión (contabilidad, nóminas,etc.)? ¿Durante cuanto tiempo puedo estar sin la aplicación? ¿Qué perdida ecónomica me puede suponer? ¿Como son de importantes los datos para el funcionamiento de mi negocio?, etc.

Lo segundo sería ver qué posibles soluciones tenemos tanto por el lado del proveedor y por el lado del cliente:

  1. Podemos elegir una aplicación utilice Google Gears o otro tipo de herramienta para que el cliente pueda trabajar mientras no tiene conexión. Por ejemplo, Zoho Writer y Zoho Mail utiliza Google Gears y permite utilizar la aplicación aunque no tengas conexión. De momento en el mercado no hay muchas pero seguro que aparecerán más.
  2. Acceso a través de RTB o RDSI. Hasta no hace mucho utilizabamos el modem para conectarnos a internet, asi que una solución sería que el cliente contrate una linea RTB o RDSI  que en caso de perdida de ADSL permita su conexión a internet y por tanto a la aplicación. Si tenemos que la perdida de internet puede ser debido a problema de tu proveedor de comunicaciones convendría que la linea se contrate a otro proveedor. Al hilo de esto, no conozco proveedor de saas que permita acceso a la aplicación a través de RTB o RDSI (cabeceras de 8 ó 10 lineas) y puede que resulte interesante para determinas situaciones de perdida puntual de ADSL.
  3. Instalar otra linea de Internet con otro proveedor de ADSL pudiendo ser de menos capacidad y por tanto más barata.
  4. Comprar un acceso 3G con conexión al PC a través de USB y pago por consumo.

En tercer lugar para cada escenario encontrado en el primer punto, aplicaría una solución u otra en función de la criticidad de las aplicaciones y datos, los riesgos potenciales y tiempo máximo de indisponibilidad.

Y el cuarto y más importante,¿saas si o saas no?

Por ejemplo, pongamos un escenario donde para una gestoría con mucha actividad tiene una aplicación de contabilidad que se ha identificado como crítica, donde como mucho tenemos 2h como máximo de inactividad, donde las probabilidades de quedarnos sin ADSL son moderadamente posibles y finalmente el acceso a la aplicación debe ser rápido sin perdidas de rendimiento. Tenemos dos posibles soluciones: nueva linea ADSL y el acceso 3G , pero sabemos que la cobertura 3G en nuestra empresa no es la ideal y que hemos decidido poner otra linea ADSL con otro proveedor de comunicaciones.

Además ya contamos con 2 PCs para dos 2 usuarios que deben acceder a la aplicación sin que sea necesario ,en caso de emergencia,  que operen a la vez. Esto es lo que nos salé cuando comparamos uno y otro modelo (las cantidades son aproximadas pero pueden ser perfectamente válidas):

  In-House Software SaaS
Inversión Inicial Lo normal es que deberíamos comprar un servidor para localizar nuestra aplicación y datos y que ambos  PC´s accedan y almacenen en el mismo sitio. Coste linfraestructura(PC+red): 1.500€ – Coste aplicación: 400€ Nueva linea ADSL 
Gastos de mantenimiento Coste mes nueva infraestructura:30€ – Coste mes aplicación:50€ Coste: 30€/mensuales – Coste aplicación por 2 usuarios/mes: 80€
Riesgo de adopción Alto riesgo por la inversión Bajo, no tienes inversión
Acceso a al aplicacion y datos Desde la empresa Desde cualquier punto, incluso tu casa.
La carga operacional recae sobre La infraestructura del cliente Proveedor de la Solución Saas
Tiempo de desarrollo o configuración Alto Medio
Facilidad de migración de las versiones Requiere una planificación Corre a cargo del proveedor del Saas
Disponibilidad de la aplicación Total Total
Retorno de la Inversión Lento debido a la inversion inicial Rápido y más predecible
Posbilidad de errores durante la implantación Alta Ninguna, accedes a traves del navegador
Capacidad añadir o eliminar usuarios Dependiendo de la licencia Si, rápidamente.
Seguridad de los datos(Backup, Accesibilidad,etc) A cargo del cliente A cargo del proveedor del Saas
Facilidad de despliegue de la aplicación a los usuarios Depende del tipo de aplicación Tan rápido como conectarse al proveedor del Saas
Precio mes 80€ mensuales 110€ mensuales

 y ahora sopesando inversión, ventajas y desventajas, y precio mensual, solo hay que contestar a la pregunta . ¿saas si o saas no?

¿Es realmente interesante el saas para la PYME?

saaspyme1Ya sabemos las ventajas y desventajas que el software as a service nos ofrece. En general el saas nos reporta ahorro de la inversión en infraestructura porque no necesitas instalar el software en servidores dedicados, ahorro en mantenimiento de la instalación y de las versiones, un precio bajo y relacionado con quien y/o cuanto usas la aplicación, backups incluidos en el precio, soporte y arreglo rápido de los bugs que puedan aparecer en la aplicación y podriamos añadir algunos más pero estos son los  que más destacan y para lo que quiero exponer es suficiente.

Todo esto esta muy bien pero si de lo que hablamos es de micropymes podría cambiar la cosa. El otro día hablando con mi hermana, ex-empresaria y ahora contable de una asesoría,  me decía: “a mi todo esto me parece muy bien pero para nosotros esto no es interesante”. Yo firme defensor del saas y del matrimonio pyme-saas, muy en mi sitio y casi ofendido le dije que me lo explicara y me dijo:

Pues no, porque yo no tengo infraestructura. No tengo el software en ningún servidor, con lo cual no me ahorro en infraestructura y su mantenimiento. Hacemos backup a diario en CDs de lo que realmente nos interesa porque una empresa les asesoró cuando se hizo la instalación de los PC´s. El software que yo utilizo, osea,  un programa contable, lo tuvimos que renovar este año por el cambio de legislación pero llevaban años con el mismo software y no necesitaban más. Es un software comercial que nos han recomendado con un coste de 400€ y tu me hablas de 10  a 20 euros por mes en el mejor de los casos. ¿Que me soluciona el saas ese a mi?

Evidentemente es un ejemplo muy concreto pero si es cierto que hay cierto tipo de software que no renuevas anualmente, que es estable y por tanto merece la pena hacer cálculos y sopesar el precio del software in-house y el precio saas.

No obstante a mi modo de ver hay tres cosas con las que no contó mi hermana. La primera de ellas es que no es ella la que tenia que desembolsar el dinero y que no solo tenían una aplicación para la contabilidad; tambien tienen aplicaciones para nóminas, facturación, gestión de cobros, etc  y todos estos productos pueden sumar un cantidad importante que a lo mejor el empresario no puede hacer frente y le es más cómodo “pagarlo a plazos” aprovechando las ventajas adicionales del saas.

La segunda es que quizás y solo quizás, al igual que lees el correo de Gmail, Yahoo o Terra desde cualquier punto del planeta, si fueras empresario, te surgiera alguna duda sobre algo de tu empresa y tuvieras la oportunidad de conectarte a internet y consultarlo (sin tener que instalarte nada en tu PC), a lo mejor esa noche duermes mejor. Por si acaso, alguien se lo pregunta. ¿Quien mejor que un profesional de la seguridad, almacenamiento y disponibilidad de la información para que guarde y vele por tus datos? Es un cambio de mentalidad y visión dificil de llevar pero ¿No me digas que el dinero lo guardas debajo del colchón? 😉 Bueno Stallman seguro que utiliza el método del colchón pero el resto de los humanos tiramos del banco.

La tercera y la que me parece más importante son:  los fallos. A mi hermana la instalación del software en su PC le fue bien pero ¿cuantas veces nos hemos encontrado con problemas en la instalación del software por tener otras instalaciones en el mismo PC? Además hay que tener en cuenta los fallos en el software que en general te los arreglan durante el primer año pero después o pagas mantenimiento o adiós muy buenas. Y otra más gorda que no te acuerdas de ella hasta que te pasa: ¿Tienes la completa seguridad de que puedes recuperar tus datos si tu disco duro se va al carajo?

En resumen, que no todo es oro lo que reluce ni en el saas , ni en el  in-house y como en todo hay que estudiarlo,  ver los pros y los contras de cada situación y empresa para poder tomar la mejor decisión que rentabilice nuestra inversión.

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.

Siete claves para un proyecto saas de éxito

Esta mañana revisando el blog de Force me he encontrado con esta entrada que me ha encandilado porque en sus referencias aparecía este whitepaper que explica qué debe tener en cuenta una empresa de saas de reciente creación para que concluya y mantega su éxito. No estoy seguro de cuando se liberó el pdf pero es igual de interesante por los puntos que destaca y porque aparecen unas cuantas referencias de empresas (con declaraciones de su CEO) acerca de cómo y porqué les fué y les va viento en popa en este nuevo mundo. 

Una de la cosas que más me ha llamado la atención es que el software tradicional y el software as a service se gestionan de diferente manera (desde su captación hasta su entrega al cliente)  y muchas de la prácticas y procedimientos comumemente aceptados en la creación del software in-house no tienen sentido en el saas. Esta la típica chorrada que cuando te la dicen, la afirmas como obvia pero que en tu día a día no dejas de hacerla, por eso me gusta destacarla.  

Resumo las siete claves para que un proyecto Saas tenga éxito: 

  1. Busca líderes del proyecto responsables. El proyecto debe tener un líder que entienda la solución saas y que acepte las  diferencias entre la creación de software tradicional y el modelo saas. Además debe intentar encontrar las métricas correctas para evaluar el estado del proyecto (tasa de adopción, utilización del sistema, desgaste de la solución) , asi como de su comunicación dentro de la compañia y los responsables de cada métrica.
  2. Haz aplicaciones que tus usuarios necesiten. Debes intentar deleitar a tus usuarios para que vuelva a utilizar tu aplicación con nuevas actualizaciones, interfaces intuitivos, upgrades automáticos que no fastidien sus personalizaciones. Además de tener la posibilidad de escuchar a tus usuarios(chat,tablon de sugerencias), de informales sobre actualizaciones y futuras mejoras, de saber que es lo que más utilizan y que no, etc. En definitiva crear expectación, darles lo que quieren y disponibilidad.
  3. Genera demanda las 24h del día. Apoyándote en la información que tienes de tus usuarios intenta generar demanda con actuaciones como accesos free a una parte de la aplicación, eventos, seminarios, videos, promociones,etc..
  4. Vendes servicio, no producto. Vendes un servicio completo, esto es entrega de producto, soporte y mantenimiento. Esto impacta en tu equipo de ventas y en tu equipo de desarrollo porque a diferencia del software tradicional, la fijacion de precio, el cumplimiento del mismo, la fidelidad del cliente, el mantenimiento de la aplicacion, el acuerdo del nivel de servicio(SLA), infraestructura para el cumplimiento del SLA,etc..  se tiene diferente tratamiento. No es lo mismo dejar un proveedor intermediario que mantega el código o que el propio cliente lo mantenga a que recaiga sobre el proveedor Saas. 
  5. Haz una religión del éxito de tu cliente. Ganar-ganar, si tu cliente gana tu ganas. Intenta destacar éxitos de tus clientes para obtener la atención de futuros clientes, realiza encuentas de satisfación y resuelve las quejas cuanto antes para fidelizar clientes, intenta crear grupos de clientes exitosos para enseñar a nuevos clientes, etc.. En definitiva el cliente debe renover suscripción y debes intentar hacer lo que sea para que vuelva a probar tu aplicación. 
  6. Desarrolla buenos procesos financieros. Debido a que los ingresos recibidos en el saas son incrementales y dependientes de las renovaciones, el tratamiento de la finanzas de la empresa saas es uno de los factores críticos a tener en cuenta.  Hay que tener especial  cuidado con el cash-flow, con los gastos fijos iniciales debido a la infraestructura, intentar poner medio de cobro automáticos, aprovechar el conocimiento del crecimiento de uso de aplicacion para prever futuras inversiones,etc.
  7. Encuentra tu sitio en el Universo “mashup. Busca alianzas o utiliza webs de “remezcla” que potencien el uso de tu aplicación. Esto es un oda a “Force” como plataforma de aplicaciones (Paas– platform as a service) pero es una opción más a tener en cuenta para que tus potenciales clientes conozcan tu saas. 
El paper son 16 hojas y esto es un breve resumen, y aunque es un poco pesada la lectura en inglés la aconsejo porque me parece realmente interesante. 

¿Saas para aplicaciones críticas?

Cierto es que el software as a service tiene unas cuantas ventajas y otras desventajas pero cuando nos plateamos la posibilidad que nuestros datos y la lógica de nuestro negocio quede fuera de las cuatro paredes de la empresa, la ventajas y desventajas van cogiendo y disminuyendo peso para justificar las decisiones. Si además los datos que manejará la aplicación saas, son datos críticos para el funcionamiento de nuestra empresa, la decisión hacia la adopción del Saas aun se complica más, y si encima la disponibilidad de estos datos debe ser 24×7 (24h, 7 dias a la semana) la adopción del Saas practicamente desaparece.

Para intentar paliar esto y dar confianza a sus clientes, muchos proveedores de Saas que ofrecen acuerdos de nivel de servicio (SLA) de 24X7, como por ejemplo Salesforce, con un porcentaje de perdida de servicio realmente pequeño y que podria servirnos para cubrir nuestras necesidades de disponibilidad, pero sabemos que este tipo de consumo de software se realiza a través de internet y nos obliga a que el proveedor de comunicaciones nos ofrezca un nivel de servicio parecido que el de la aplicación Saas. Esto puede ser realmente costoso disminuyendo el peso de uno de los principales factores de compra: la reducción de costes e inversión.

Por otro lado, la edad de la empresa tambien es importante e influirá a la hora de tomar esa decisión. No es lo mismo que la decisión se esté formando desde una start-up donde aún no tenga su sistema de información asentado  que de una empresa consolidada y con años en su mercado  que tenga su sistema de información en marcha y en casa.

Otro factor importante que puede influir en la decisión de compra es la cultura de la empresa, esto es, una empresa conservadora con dificultades históricas en la adopción de tecnología será mucha más reticente que la empresas dinámicas, emprendedoras y que no les importa el cambio. Este post de Enrique Dans me ayuda a explicar el concepto .

Y por supuesto la reducción de costes e inversiones en empresas con problemas financieros puede ser determinante pero tambien lo es para para aplicaciones no críticas.

En mi opinión de todo lo expuesto lo que realmente frenará la entrada de saas en aplicaciones críticas será Internet y quizás sea cuestión de tiempo, de fiabilidad y de confianza , como la luz y el agua de los que nadie duda de su disponibilidad.

 

¿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.

Noticias como servicio – 5 al 11 Mayo

Estas son las noticias que más me han llamado la atención en esta última semana:

¿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.