Mostrando entradas con la etiqueta saas. Mostrar todas las entradas
Mostrando entradas con la etiqueta saas. Mostrar todas las entradas

13 noviembre 2008

SaaS en la administración

Me han preguntado ultimamente que en dónde veo yo que se podría utilizar las aplicaciones SaaS con mejor resultado.

Creo que la administración pública, en esto tiene los mismos requisitos que las empresas privadas, las aplicaciones SaaS son más adecuadas:
- en los sectores más maduros, donde la evolución de los procesos de negocio es menos necesaria
- cuando la integración con otros sistemas sea limitada
- cuando la capilaridad de los usuarios se grande.

Estas características dejan dentro los ayuntamientos medianos y pequeños, que son un número muy grande, mientras que deja totalmente fuera, ministerios con funcionalidades complejas y cambiantes en función de la legislación, como Hacienda, Seguridad Social, Justicia, entre otros.

11 noviembre 2008

Dificultades en la adopción de SaaS por parte de las empresas

Dando por sentado que las ventajas de SaaS son muy claras y demostrables, también hay que ser claro con los inconvenientes que entraña est modelo de uso de software.

Una de las dificultades que es la cultural, que siempre es complicada de contrarrestar.
El empresario utiliza un software por el que está pagando, pero no ve los ordenadores, ni los cables, todo está en algún lugar remoto, y que probablemente, ni siquiera sabe dónde exactamente. Si la aplicación falla, ¿quién lo va a arreglar? ¿dónde está esa persona? Lo único que puede hacer es llamar a un teléfono donde, con buenas palabras,le toman nota de la incidencia. El compromiso del proveedor de la aplicaión SaaS es mediante un Acuerdo de Nivel de Servicio (SLA por sus siglas en inglés) que puede decir algo así como que "el 95% de las incidencias serán solucionadas en menos de una hora desde que se reporte". Entre esa frase y tener al informático al lado y meterle prisa, hay una diferencia.

La segunda es que la integración de la aplicación SaaS con el resto de los sistemas no-SaaS de la empresa puede resultar complicada, añadir un coste extra y, en el peor de los casos, restar fiabilidad a la aplicación.

Por otro lado, algunos puestos de trabajo podrían peligrar. Los puestos muy técnicos dedicados a tareas operacionales, tales como realización de backup, mantenimiento del software y hardware, ya no son necesarios. En cambio aquellos perfiles informáticos orientados al negocio, son más necesarios. Aquellos que son capaces de enfocar las tecnología para que se adapte a los procesos de negocio y viceversa. Las aplicaciones SaaS tienen un componente de parametrización alto, para dotar de flexibilidad al sistema, esa parametrización y ajuste, debe venir de un análisis de personas de la propia empresa, probablemente, junto con alguna consultora.

Last but not least, se debe tener en cuenta que financieramente, el pago por el uso de un servicio, cualquiera que sea este, se considera un gasto operativo, mientras que la compra de licencias de un software para instalarlo en tus propios servidores es una inversión. Si ese gasto, además se realiza en forma de tarifa plana, como es habitual en estos casos, se considera un gasto fijo y ese es el concepto que más "escuece" a las empresas a la hora de presentar resultados. Por tanto, aunque haya un ahorro, se mueve de partidas en las que las empresas tienen cierto margen, como es la inversión, a otras en donde hay que ajustar lo máximo posible, costes fijos (donde están también los sueldos de los trabajadores de plantilla).

10 noviembre 2008

Integración entre aplicaciones SaaS y no-SaaS

Ya se ha explicado en otras entradas de este blog, las ventajas que tienen las aplicaciones que se usan mediante el paradigma SaaS, pero a la vez, esto entraña un inconveniente que voy a tratar de explicar de la manera más sencilla posible.

Las aplicaciones SaaS, por definición, se utilizan como servicio, es decir, se ofrece un modo de acceso a lo que la aplicación ofrece, pero oculta todo lo demás. Cuando una aplicación SaaS se utiliza de forma aislada, no hay ningún problema, todos los datos y procesos están perfectamente aislados y no hay dependencias.

Pero ¿qué ocurre cuando esa aplicación no está aislada? Lo normal es que los sistemas de las empresas tengan dependencias. Por ejemplo, el sistema donde se almacenan los datos de los clientes de la empresa, debe conocer cuándo se consigue un nuevo cliente, evento que ocurre en el sistema de ventas, cuando el vendedor conseguir cerrar el contrato. Esta interacción puede ocurrir manualmente, o sea, le pedimos al vendedor que cuando cierre un nuevo cliente, que meta sus datos en el sistema de Gestión de Clientes, pero ese procedimiento no es práctico cuando el número de clientes o de comerciales es grande, ya que puede dar lugar a errores y omisiones.

En esos casos, se necesita una “interface” que, automáticamente, pase los nuevos clientes del sistema de ventas al sistema de gestión de clientes. Si los sistemas de explotan de manera tradicional (no-SaaS), se pueden personalizar o programar para que esta transferencia se realice.

Pero, supongamos ahora, que es a donde íbamos, que el sistema de gestión de clientes se utiliza mediante SaaS y, por tanto, no conocemos, la manera de transferir automáticamente datos a ese sistema. Pues que tenemos un problema, pero tranquilos, con solución elegante.

La solución son las interfaces abiertas, aquellas que se consideran estándar en el mercado, en este caso, estaríamos hablando de SOA. Se trata de que las aplicaciones SaaS proporcionen un interface “humana” para que los usuario al utilicen en tiempo real, pero también un interface automático para que otros procesos puedan utilizarla de manera efectiva.

En este caso, la aplicación de Gestión de Clientes SaaS deberá proporcionar un interface SOA que permite añadir nuevos clientes y que se pueda enlazar desde la aplicación de ventas no-SaaS.

La otra dirección de la integración también se puede plantear, aunque a priori, parece más complicada. Imaginemos que un cliente no satisfecho hace una llamada poniendo una queja, que queda reflejada en el sistema de Gestión de Clientes SaaS y queremos que esto derive en una tarea para el comercial a cargo de ese cliente, que consista en visitarlo para hablar con él de su queja.

Este proceso implica que se debería modificar la aplicación SaaS para que realice esta transferencia de información a la aplicación no-SaaS. Estas modificaciones, aunque se pueden realizar, normalmente conllevan un coste extra y disminuyen la fiabilidad de la aplicación, ya que no es exactamente la misma que utilizan todos los demás, sino que es una versión específica.

Otra aproximación sería hacer que las aplicaciones SaaS tengan “user-exit” o programas que se ejecuten ante determinados eventos – como la entrada de una queja en nuestro ejemplo – y que mediante interfaces estándar tipo SOA puedan realizar la integración con el sistema no-SaaS. Aunque complicado, es posible.



Dos de los ejemplos de aplicaciones comerciales que se ofrecen mediante SaaS:

- SugarCRM

- Salesforce.com



24 mayo 2008

Consolidación CPDs

¿Como se relaciona la consolidación de CPDs con el tema objetivo de este blog que es la Democratización de la informática para las PyMEs?

Fácil, como ya se ha comentado anteriormente aquí, el uso del software recomendado para estas empresas es mediante SaaS (Software as a Service) con lo que todos los servidores, almacenamiento e infraestructura de estas empresas estarán en CPDs remotos y no en sus propias oficinas. Este punto hace que los CPDs vayan a crecer y crecer. En este trabajo se indican las razones para que los CPDs estén consolidados y, preferiblemente, sea uno solo para toda la infraestructura. También se recomienda una plantilla de planificación para los proyectos de consolidación, es decir, cuando se tengan varios CPDs que se quieran consolidar en uno solo.

El mecanismo SaaS para el uso del software se están también implantando con las aplicaciones llamadas Web 2.0 como Facebook, Twitter, Linkedin, de las que soy "heavy user" y que refuerzan el posicionamiento de enormes CPDs con largas granjas de servidores y discos.
Una curiosidad es que el consumo eléctrico es tan grande a estos niveles, que los CPDs se sitúan en las regiones donde el coste de la electricidad es menor (en USA que se ve que varía por regiones (aquí yo creo que es el mismo en todo el país). En particular, el CPD de Google está junto al río Colorado que es el sitio donde más barata se comercializa la electricidad en USA.

Si estáis interesados en el detalle de este tema (cosa altamente improbable) podéis ver la presentación y si sois valientes y queréis más podéis ver el documento. Si quisierais el ppt o el doc (no alcanzo a imaginarme porqué) me lo dejáis como comentario y os lo paso.

Todo vuestro !!!

18 mayo 2008

¿Por qué SaaS?

Como le han cambiado el nombre varias veces, parece que SaaS es algo nuevo y, que va, los que tenemos kilometraje en esto, nos acordamos muy bien de los ASP (Application Service Providers) y de cuando Salesforce.com se posicionó como plataforma "on demand" para las medianas empresas.

¿Qué es SaaS? ¿Cuáles son sus ámbitos es de aplicación? ¿Cuáles son sus ventajas? ¿Quién se verá beneficiado? Por partes ...

¿Qué es SaaS?
SaaS es una manera de que los usuarios accedan al software sin tener que tener una infraestructura informática propia, esto es, servidores, bases de datos, etc. El acceso se realiza a través de internet, se necesita únicamente un explorador y una buena conexión a internet. Estas dos requisitos los cumplen en la actualidad la mayoría de las empresas.
¿Cuáles son sus ámbitos es de aplicación?
Aplicaciones software que no requieran una fuerte integración a nivel de servidor. Es decir, si una empresa tiene un sistema de gestión de clientes y otro para calcular la facturación, la integración entre ambos es fuerte, ya que, por ejemplo, un cambio en los productos contratados por un cliente, se debe ver reflejado en ambos sistemas.
¿Cuáles son sus ventajas?
Al tratarse, de alguna manera, de una externalización de la operación de los sistemas de información, hace que se simpliquen las responsabilidades informáticas de las empresas. Permite que la empresa se centre en su negocio y que otra empresa, especialista en eso, aloje y opere sus sistemas.
¿Quién se verá beneficiado?
Todas las partes implicadas obtendrán beneficio, ya se han comentado los beneficios para las empresas usuarias y, además, la empresa que aloje y opere los sistemas, obtendrá mayor volumen de negocio. Las economías de escala aplican en estos casos y el coste de operar dos sistemas como conjunto es menos del doble del coste de operarlos separadamente. La empresa anfitrona (la que aloja y opera los sistemas) no repercutirá todo ese ahorra de costes a las empresas usuarias, pero si, al menos una parte.
Tendencias
Las aplicaciones de internet tipo Facebook, Linkedin, Twitter (de las que soy heavy user) y otras similares, ya proporcionan una funcionalidad relativamente elaborada utilizando SaaS, ya no se trata de alojar páginas web más o menos complejas, como blogs o noticias, sino que ya hay unas reglas de negocio, workflows ...
Google lanzó no hace mucho su servicio Google Code que permite desarrollar aplicaciones en el lenguaje de programación Python y, una vez terminadas, alojarlas gratuitamente en modo SaaS.
Que Google haya realizado esta apuesta, es determinante para mí, el número de veces que Google se ha equivocado en sus decisiones estratégicas desde que se creó como empresa, ha sido, exactamente cero. También es cierto que a Google no le afectaría mucho perder unos cuantos millones de dolares en esto, si se hubiese equivocado.