Puntos clave seleccion aplicaciones SaaS. Artículo - Luis Carrasco

Michael Heiss http://www.flickr.com/people/michaelheiss/

Puntos clave en la selección de aplicaciones de
negocio en modelo SaaS / en la nube

Presentación descargable en: http://www.nodotic.com/?p=1033

Luis Carrasco 1 / 22

Contenidos:
Introducción
Puntos clave
Multi-tenancy
Tecnología
Inicio del Servicio
Evolución del Servicio
Fin del Servicio
Integración
Privacidad
Gobierno del Servicio
Gestión de Costes
Conclusión
Referencias
Sobre el autor
New York rises de Eugene de Salignacs


INTRODUCCIÓN
Mover las aplicaciones de negocio (ERP, CRM, etc.) a la nube (en modo SaaS) es una
tendencia en ascenso entre los responsables de las tecnologías de la información en las
empresas a tenor de los múltiples informes y encuestas de los analistas del sector de las TIC
[1], [2], [3].

No tengo cifras locales concretas, sólo mi experiencia directa hablando con colegas, clientes y
proveedores, pero esta tendencia parece más tímida en nuestro entorno que en otros y es que
por alguna razón aquí siempre somos más precavidos en lo de introducir cambios, por decirlo
amablemente, o quizá no haya aún una oferta suficiente [13].

Ciertamente es comprensible que los responsables de llevar a cabo e impulsar este tipo de
innovaciones en las empresas tengan muchas y serias dudas, dado el riesgo (no
necesariamente mayor que continuar igual, todo sea dicho) que puede suponer un cambio
estratégico de ese calibre en la gestión de la información de sus empresas, pero como estoy
plenamente convencido de que es cuestión de poco tiempo que el modelo dominante de tener
tu ERP, CRM etc. in house se quede obsoleto (*) y con el ánimo de contribuir, en la medida de
mis modestas posibilidades, a romper, mediante información, transparencia y debate, esos
miedos y dudas, me he decidido a escribir este artículo sobre qué es lo que hay que saber
antes de decidir mover las aplicaciones de negocio a un modelo SaaS.

El artículo lo he estructurado alrededor de los siguientes puntos clave:

o Multi-tenancy. Como condición necesaria para que el modelo sea sostenible.
o Tecnología. Consideraciones respecto de la arquitectura tecnológica de la
aplicación SaaS.
o Inicio del Servicio. Qué hemos de tener en cuenta en relación a como se pone en
marcha el servicio.
o Evolución del Servicio. Qué debemos gestionar para asegurar la adaptación de
la aplicación SaaS a los requerimientos cambiantes de nuestra organización.
o Fin del servicio. Elementos importantes en el momento de finalizar la relación con
el proveedor de la aplicación SaaS
o Integración. Consideraciones a la relación de la aplicación SaaS con otras
aplicaciones
o Privacidad. Cómo cumplir la legislación vigente y proteger nuestros datos
sensibles.
o Gobierno del servicio. Gobierno de la relación con el proveedor y gestión de la
calidad del servicio.
o Gestión de costes. Indexación de los costes al uso de la aplicación.


Cada uno de estos puntos se desarrollarán desde el punto de vista de una empresa que está
considerando una estrategia SaaS para sus aplicaciones de negocio y que quiere validar las
capacidades de potenciales proveedores. No obstante, me gustaría que este artículo fuera útil,
no sólo para aquellos responsables de sistemas de información de esa hipotética empresa sino
también también para que proveedores de aplicaciones y servicios comprueben que su oferta
es competitiva y se ajusta a un modelo SaaS de verdad o True SaaS.

[*] Sobre modelos obsoletos siempre me gusta citar a Nicholas Carr, uno de los primeros
visionarios de lo que ahora se ha venido a llamar Cloud Computing,que explica en varios de
sus libros y artículos como principios del siglo XX las empresas industriales tenían sus propios
generadores eléctricos y pozos de agua in house y que al extenderse las redes de distribución
de electricidad y agua se cambiaron a la Energía y Agua as a Service. Modelo que ahora, salvo
contadísimas excepciones, vemos como el único racional y sostenible.


red local a través de Internet, y el paquete se
MULTI-TENANCY vendía en forma de acceso por usuario.

Empiezo con el punto que considero crucial a la Entre las razones técnicas por lo que este modelo
hora de decantarnos por un determinado fracasó, operativa y económicamente, se pueden
proveedor de aplicaciones de negocio SaaS ya contar:
que de alguna manera abarca, o es consecuencia,
del resto de puntos clave que se comentan en el • Velocidad y disponibilidad de Internet
resto del artículo: el multi-tenancy. en esa época.

• La arquitectura física con la que se
En una primera aproximación se podría definir que habían diseñado esas aplicaciones no
una aplicación de gestión SaaS es Multi-tenancy escalaba ni soportaba bien compartir
si: infraestructuras físicas en el lado servidor.
• Puede ser compartida por diferentes clientes. Era ineficiente en el aprovechamiento de
• Es capaz de adaptarse y evolucionar con los recursos hardware y software (la
diferentes requerimientos de cada cliente. virtualización de servidores era una
• Y al mismo tiempo ser viable, técnica y tecnología incipiente, de laboratorio
económicamente, para el proveedor. prácticamente) y el hardware era caro en
esos años.
Estos requisitos veremos más adelante que • La arquitectura del software no estaba
condicionan fuertemente la arquitectura pensada para ser compartida por
tecnológica de una aplicación SaaS y el modelo compañías diferentes. Los datos y tablas
de negocio del proveedor quizá sí (o ni eso) pero una configuración
del software para necesidades específicas
Para entender este concepto fundamental es de una compañía no se podía hacer
necesario conocer los antecedentes a los actuales estanca al resto, por lo que se podían
modelos SaaS, los ASP o Application Service producir colisiones o incompatibilidades
Providers que en los 90 llegaron a tener cierta entre ellas. Las modificaciones que sobre
notoriedad o Hype como se dice ahora. una arquitectura ya desarrollada tenían
que hacerse, complicaban más aún el
La visión de negocio de los ASP era la misma que entorno y lo podían hacer ingestionable
pueden tener los actuales modelos SaaS pero el técnicamente por el proveedor.
estado de la tecnología y madurez de las
empresas que se podrían haber beneficiado no lo • La evolución del software podía ser en la
era. Por ejemplo, uno trivial, la velocidad y práctica inviable. O todos los clientes se
disponibilidad de las líneas de comunicaciones, o coordinaban para cambiar de versión a la
la disposición de las empresas a sacar sus centros vez o no se podía, lo que derivó en que el
de datos fuera de sus paredes (algo a lo que ahora software se quedase atascado en una
están más predispuestas en general). versión o en que se tuviesen que separar
instalaciones por versión – algo
En muchos casos, el concepto ASP acababa en antieconómico y a medio plazo
que una aplicación cliente-servidor, diseñada y insostenible.
construida para ser desplegada dentro de una red • Al haber mucha lógica, incluso datos, en la
local corporativa, se habilitaba para que su parte parte cliente, el despliegue y
servidor pudiera ser accesible desde fuera de la mantenimiento homogéneo de cualquier


implantación compartida era una tarea ¿Qué tiene que hacer el cliente si se actualiza
muy costosa porque había que actualizar la versión del software? Los clientes no se
software en cada estación de trabajo deberían preocupar de tener que actualizar el
software, para ellos debería ser transparente, en
En conclusión, para que una aplicación de un extremo ni enterarse. Así la actualización es
gestión sea viable en modo SaaS, debe ser para todos los clientes a la vez y cualquier
capaz de poder conseguir economías de escala configuración específica del cliente no debería
al compatibilizar el que los clientes puedan condicionar el poder actualizar el software al resto
compartir los costes fijos (infraestructuras, – ¿Podrías hacer mañana mismo un cambio de
implantación, soporte, mantenimiento, des- versión sin avisar a tus clientes?
implantación, etc.), cubrir las necesidades
comunes y específicas de esos clientes y al ¿Con qué periodicidad se actualiza el
mismo tiempo poder evolucionar para software? No debería haber versiones en el
acomodarse a los cambios en esas sentido tradicional sino frecuentes mejoras
necesidades de cada uno. Es decir que sea incrementales (un ejemplo serían las aplicaciones
Multi-tenancy. de Google) – ¿Cuántos cambios de
versión/upgrades/mejoras has hecho en el último
Afortunadamente esta posibilidad llegó de la mano año?
de avances tecnológicos como la virtualización,
seguridad, velocidad y ubicuidad de líneas, ¿Cómo va a cubrir la aplicación mis
navegadores rápidos y capaces de incorporar requerimientos funcionales clave [elíjanse
lógica de forma estándar -no propietaria- en local, varios cuidadosamente] y que son específicos
entornos y metodologías de desarrollo más de mi compañía/negocio/sector? Si el proveedor
avanzados, etc. que permitieron desarrollar contesta que debe adaptar/cambiar el software es
productos con arquitecturas tecnológicas que probable que éste ya no sea una opción adecuada
posibilitaban el Multi-tenancy y desplegar modelos (al menos en modo SaaS) para el cliente. De
True SaaS. alguna forma la arquitectura de la aplicación debe
estar construida de forma que se puedan
¿Y como podemos verificar con nuestro proveedor diferenciar las diferentes compañías cliente en el
que su aplicación de gestión es Multi-tenancy y momento de ejecución de la aplicación. En los
evitar así que en realidad acabemos contratando modelos ASP esto se conseguía con el código de
una aplicación tradicional en hosting, o lo que es lo compañía/unidad organizativa, pero un
mismo que seamos un Single-tenancy más en sus modeloTrue SaaS debe ir más allá, con
infraestructuras? codificaciones que permitan que en modo de
ejecución la aplicación pueda distinguir entre
Pues deberemos hacerle preguntas como: compañías clientes, hacer uso de clusters o
agrupaciones de unidades organizativas por
¿Todos los clientes están en la misma versión compañía cliente o por criterios de localización
del software? Todos los clientes deberían correr geográfica para temas de normativas locales por
la misma versión del código, sin “customizaciones” ejemplo.
de código. De esta forma cualquier configuración
propia del cliente no acabará afectando al resto de Con estos requisitos, en mi modesta opinión, veo
clientes ni, a su vez, se verá afectada por muy difícil, por no decir imposible, que una
personalizaciones de código del resto de clientes - aplicación que no ha sido técnicamente
¿Cuánto se tarda en hacer un cambio de versión? diseñada y concebida desde cero con un
enfoque de ser Multi-Tenancy, pueda serlo, ya


que las modificaciones a posteriori que una • Conectividad. Será más fácil acceder a la
aplicación tradicional requiera para ser Multi- aplicación desde cualquier ubicación con
tenancy acabarán haciéndola compleja y costosa acceso a Internet.
de gestionar y mantener, es decir inviable • Facilidad de despliegue. En la
económicamente. implantación no se debería tener que invertir
en hardware de terminal de usuario ni
En conclusión, hay que prestar atención a los tiempo de instalación.
provedores con productos tradicionales • Facilidad de evolución. La aplicación podrá
reetiquetados como SaaS que realmente no son evolucionar desde el lado de servidor sin
Multi-tenancy. tener que actualizar nada en los clientes –
facilitando así al proveedor el mantener una
versión única de su aplicación para todos
TECNOLOGÍA sus clientes
Un tema colateral importante aquí es la
Como ya se ha comentado anteriormente, la conectividad de dispositivos locales como
tecnología ha desempeñado un importante papel impresoras, PLCs, sensores industriales, etc. pero
en el desarrollo viable de los modelos SaaS por lo lo trataremos en el punto de integración.
que, para asegurarnos que nuestro proveedor
SaaS tiene un modelo de negocio sostenible, es Escalabilidad de la plataforma tecnológica
importante poder contrastar con él cosas como:
Hemos de partir de la premisa de que la
plataforma tecnológica en la que estará alojada la
Acceso con Browser as a Platform. El acceso a
aplicación SaaS será compartida y deberá poder
la aplicación debería poder hacerse sin necesidad
crecer de forma más o menos lineal según el uso
de instalaciones de software específico en local o
que le de la propia empresa y las empresas
al menos que el proceso de instalación y
vecinas. Parece pues muy razonable interesarnos
actualización se automatice de forma que sea
por las herramientas y tecnologías que el
transparente para el usuario (aunque entonces
proveedor va a utilizar para asegurarnos esa
habrá que gestionar los permisos en las
escalabilidad. Concretamente habría que
estaciones de trabajo, algo que en determinadas
preguntarle por temas como:
organizaciones puede ser un impedimento
importante)
• Qué productos/tecnologías va a utilizar
para gestionar su plataforma Cloud:
Lo habitual, y en mi opinión mejor opción, es que
virtualización, despliegues de aplicaciones
sea a través de un navegador estándar (mejor
(nuevos clientes y/o versiones/parches),
que no se dependa de uno en concreto) con AJAX,
creación de nuevos entornos/instancias,
HTML5 y como máximo algún plug-in tipo ActiveX,
gestión de los cambios de versión de
Applet. También es de esperar que avances
productos base (sistema operativo, bases de
recientes en protocolos a nivel de aplicación como
datos, …), sincronización entre entornos de
SPDY y Web Sockets de HTML5 mejoren
desarrollo, test y producción, compaginar
latencias y rendimiento de los actuales protocolos
instalaciones compartidas con dedicadas,
HTTP… pero esto ahora está saliendo
etc.
tímidamente de los laboratorios.
• Si la plataforma física es propia o de un
tercero proveedor de PaaS (Force.com,
De esta forma se consigue:
Google App por ejemplo) o IaaS (Amazon
AWS, Microsoft Azure, IBM, etc.). Este punto,


además tiene relevancia a efectos legales, inestabilidad del entorno por el cambio
como veremos más adelante. continuo, … ¿Qué tecnologías va a utilizar el
• Si dispone de herramientas o tecnologías proveedor para garantizar el rendimiento de
específicas para la gestión de grandes la plataforma, velocidad de las líneas, uso
volúmenes de datos o cómo va a asegurar de recursos de CPU, …? De la misma forma
la escalabilidad de un entorno de datos que que con la escalabilidad de datos, las
al ser compartido va crecer más y de forma estrategias y arquitecturas tecnológicas que
menos previsible de lo que lo hace en un se han venido utilizando en instalaciones
escenario no compartido. Sin llegar a los single-tenancy es probable que no sean las
extremos de tener que disponer de más adecuadas.
tecnologías de Big Data pero creo que no • Seguridad física. ¿Cómo se controla el
vale el enfoque por el que se optaría en una acceso físico a las instalaciones?, ¿Quién
instalación monocliente (el Multy-tenancy tendrá acceso?, ¿Sistemas de
aparece otra vez) al ser potencialmente un vigilancia/registro/grabación?, …
entorno menos predecible y planificable. • Monitorización. ¿Cómo va a controlar el
proveedor el rendimiento y disponibilidad de
Disponibilidad y seguridad física de la la plataforma? Lo mejor es que el proveedor
plataforma tecnológica pueda enseñaros su centro de control y que
Teniendo en cuenta que al ser una aplicación de os explique qué herramientas de control y
negocio vamos a utilizar la plataforma tecnológica gestión de alarmas utiliza y cómo os vais a
del proveedor para gestionar nuestras operaciones enterar si hay una incidencia. Volveremos
es obvio que tenemos que asegurarnos de que sobre esto en el punto de gestión del
esta plataforma va a estar disponible cuando la servicio.
necesitamos. Es por eso que nos deberá interesar
conocer: Seguridad de Datos
Los datos de clientes, sus pedidos, la información
• Contingencia. ¿Qué pasa si hay una de tu inventario, la facturación… toda esta
incidencia que hace que las instalaciones (o información no se puede perder; en general, no la
parte de ellas) donde residen las puede ver cualquiera y en algún caso la empresa
infraestructuras dejan de estar operativas o está obligada a protegerla. Se ha de tener claro al
incluso son destruidas?, ¿Cómo lo ha menos:
previsto el proveedor y cómo se integra en
nuestra estrategia de recuperación del • ¿Cómo se gestionan las copias de
negocio en caso de desastre (tiene un seguridad: Periodicidad (diaria, cierre de
Disaster Business Recovery Plan)?, ¿Hay periodo/ejercicio, …), quién lo hace, dónde
redundancia de equipamientos como líneas se gestionan/almacenan las copias, control
de comunicaciones, alimentación de acceso,…?
eléctrica, generador/grupo electrógeno, • ¿Cómo es la sincronización con posibles
etc.?, ¿Dispone el proveedor, o nosotros, de centros de respaldo?
una instalación de respaldo alternativa • ¿Se cifra la información sensible (más sobre
para el caso de un desastre total, y en ese esto en el punto sobre privacidad)?
caso cómo se efectuaría la transición?, ¿y la • ¿Cómo se controla el acceso a la aplicación,
sincronización de datos entre a la base de datos, etc. tanto accediendo
instalaciones principal-respaldo? desde dentro como desde fuera del
• Rendimiento ante picos de actividad, firewall/perímetro de seguridad?
algunos predecibles y otros no,


• ¿Se registra/audita la actividad de acceso a • Haya disponibilidad de herramientas de
datos? Qué, quién y cuándo se carga, depuración, comparación, etc. de
modifican/leen/borran los datos datos orientadas a acelerar la migración y
• ¿Cómo se asegura que otros clientes no ven conversión de información y la gestión de
mis datos? paralelos.
• etc. no me extiendo más en este punto • Se utilicen Metodologías de puesta en
porque entiendo que hay disponible marcha ágiles [5], colaborativas, iterativas,
abundante documentación al respecto. etc con entornos preconfigurados para la
captura rápida e incremental de requisitos,
Green/Eficiencia Energética aprender pronto para ajustar también pronto,
Y para empresas con sensibilidad y disponer de funcionalidades que estén
responsabilidad social, ¿por qué no preguntar por operativas de forma rápida y poder ir
las políticas de eficiencia energética y prácticas de afinándolas en ciclos cortos también.
protección del medio ambiente, etc.? Aunque sea • La Configuración (set up de entorno,
sólo sea por el interés propio en que el proveedor seguridad, alta de usuarios, etc.) sea rápida,
reduzca sus gastos operativos para dar un servicio con asistentes (tipo siguiente-siguiente) y
competitivo y sostenible – hay informes [4] que aceleradores tales como un catálogo de
indican que entre un tercio y la mitad de los costes plantillas de procesos sectoriales y
operativos de un centro de proceso de datos horizontales ya preconfigurados, opciones
corresponden a la factura de energía. de activación/desactivación de
funcionalidades pre-existentes a demanda,
etc.
INICIO DEL SERVICIO
• La puesta en marcha la puedan liderar
usuarios no técnicos (a.k.a. de negocio) no
Uno de los atractivos de utilizar un modelo SaaS necesariamente expertos de producto.
pasa por la premisa de que en general todo tiene
que ser más rápido y sencillo. Es una hipótesis Se podrá objetar y con razón, que excepto el
de partida porque de no ser así el modelo no es primero, los anteriores puntos no tienen por qué
sostenible ni viable y debemos, por tanto, prestar ser exclusivos de un modelo SaaS. Cierto pero,
atención a todos los elementos que nuestro ¿no es verdad que suenan a ciencia ficción en el
proveedor pueda aportar en este sentido. caso de los productos tradicionales? – ¿por qué
debería ser diferente en el caso de un modelo
Rapidez y sencillez en que: SaaS? Pues se me ocurren al menos dos razones:

• No sea necesario realizar instalaciones de • Ya lo he comentado al principio, si no es así
infraestructura hardware y software en las el modelo SaaS no se aguanta, por lo que
instalaciones de la empresa, lo que ya de si un proveedor no nos está ofreciendo este
entrada debería acortar el tiempo de puesta tipo de facilidades hay que verificar muy bien
en marcha y eliminar las necesidades el coste-beneficio que esperamos obtener.
adicionales (espacio, seguridad,
• Estos elementos deberían ser más
climatización,… por ejemplo) para acomodar
fácilmente exigibles a una aplicación SaaS
nuevas infraestructuras o instalaciones
verdadera que a una tradicional ya que,
locales de software en los equipos de
como ya se comentó anteriormente en el
usuario.
punto de Multi-tenancy, su arquitectura ya


debería haberse diseñado incluyendo plantillas de procesos sectoriales y
estas premisas y requerimientos. horizontales que puedan ser desplegadas
por usuarios no técnicos, activación y
desactivación de funcionalidades pre-
EVOLUCIÓN DEL SERVICIO existentes a demanda y con un Sandbox
para pruebas para así no afectar al sistema
Dentro de los puntos clave no podía faltar el en producción.
relativo a asegurar la evolución adecuada del
servicio que esperamos recibir una vez puesto en Todos estos puntos no son exclusivos de una
marcha dicho servicio, o dicho de otra forma, de la aplicación SaaS evidentemente pero es de esperar
elasticidad de la aplicación para adaptarse a que sean más asequibles que en las aplicaciones
las necesidades cambiantes que seguro va a tradicionales por lo ya mencionado anteriormente
tener nuestra empresa. de que la arquitectura de la aplicación SaaS ya
debería haber sido diseñada con estas
Por eso deberemos pedirle al proveedor de la consideraciones.
aplicación información sobre:
Escalabilidad/rendimiento de infraestructuras:
Evolución de funcionalidades: Hay que considerar que al ser un modelo SaaS
Cómo nos va a asegurar el proveedor que su vamos a tener que compartir las infraestructuras
aplicación evoluciona tecnológica y funcionalmente con otras empresas. Debemos por tanto
con el mercado/sector y con nuestras necesidades asegurarnos de conocer qué medios, tecnologías,
específicas. Concretamente: metodologías, etc. tiene el proveedor para
acomodar picos en el número de transacciones en
• Qué plan de producto, road map, tiene el sistema, ya sean las previsibles (por ejemplo
establecido: módulos, funcionalidades cierres de mes, facturaciones masivas mensuales,
nuevas, etc. Atención a la frecuencia de etc.) como las no previstas (un nuevo cliente por
actualización que, como ya se mencionó en ejemplo).
la entrada de esta serie correspondiente a
Multi-tenancy, debería ser mayor que la de Otra vez hay que recordar que tenemos que estar
una aplicación tradicional. seguros que el modelo tecnológico del
proveedor es sostenible y viable, no sólo desde
• Qué garantías nos da de adaptación a
el punto de vista tecnológico sino también desde
cambios a la legislación vigente, algo
el punto de vista económico.
especialmente importante en aplicaciones
financieras y de RRHH.
A nadie le va a gustar que se caiga el sistema, o
• Respecto a la evolución de las vaya lento, porque la empresa de al lado ha
funcionalidades específicas de nuestra lanzado su proceso de facturación mensual o el
empresa (ya sea mantenimiento evolutivo o proveedor entre en riesgo de quiebra por las
despliegue de nuevos módulos y/o inversiones que tiene que realizar para
funcionalidades) hay que pedir que, como se acomodarse al volumen de transacciones que trae
comentó en la entrada correspondiente al un nuevo cliente. Por eso modelos de
inicio del servicio, pueda ser liderado por la infraestructura elásticos basados en IaaS de
propia empresa, preferentemente por terceros serán recomendables en principio ya que
usuarios del negocio -sin dependencias de permitirán esa escalabilidad de forma lineal
personal del área de IT, por ejemplo (aunque no olvidemos los temas legales, como se
mediante la disponibilidad de un catálogo de


comentará posteriormente en el punto Aunque la empresa cliente tendrá acceso
correspondiente a privacidad) restringido a las infraestructuras y depende en
última instancia del proveedor para que le
Escalabilidad de usuarios: entregue sus propios datos, no se debería aceptar
Otro elemento a atar en corto es cómo se gestiona ninguna restricción por parte del proveedor a
el crecimiento y decrecimiento de usuarios de la acceder a tus datos en cualquier momento.
aplicación para acomodarse a la dinámica de la
empresa. Un ejemplo extremo sería el de una Por supuesto que debe haber reglas (seguridad de
empresa sujeta a una alta temporalidad, donde en acceso, formatos, tiempos de preaviso, etc.) pero
la temporada alta sube el número de usuarios. es un derecho inalienable del cliente el poder
extraer su información cuando la necesite y las
Debemos por tanto tener controlados aspectos facilidades que éste tenga van a ser un
como: indicador inestimable de la bondad del
proveedor y de su aplicación.
• Como varían los costes según el nº de
usuarios (me extenderé más sobre esto en El tema se puede complicar si además hay una
el punto correspondiente a costes) externalización de procesos (BPO) donde los
procesos son efectuados directamente por el
• Facilidad de replicar/desactivar usuarios,
propio proveedor ya que entonces será más difícil
roles, etc. No tendría mucho sentido en un
para el cliente conocer la estructura en detalle de
entorno dinámico y ágil, como el que se
los datos que se quiere llevar.
supone que es un entorno SaaS, que poner
en marcha un nuevo usuario sea costoso.
Concretamente, habrá que averiguar del
proveedor qué plan de salida ofrece en caso de
Y es que nunca hemos de perder de vista que si
cese del servicio, con especial atención a:
estamos barajando una aplicación SaaS es porque
nos preocupa, entre otras cosas, la elasticidad de
• Formato de los datos para su portabilidad.
la solución, tanto para crecer como para
Archivos planos, Exports de tablas de las
decrecer.
bases de datos, … un tema bastante
tecnológico que deberá conocerse bien para
FIN DEL SERVICIO identificar las posibles limitaciones que
pudiera haber.
• Punto de corte: es decir en qué momento
En la Salida o Finalización del Servicio es
se hace la foto de los datos para su
fundamental que nos aseguremos de la facilidad y
portabilidad. Una posibilidad, para estar
rapidez de salida en el caso en que haya
seguros de que el conjunto de datos es
problemas, y así no quedarte atrapado por tu
coherente, es pedir una copia de seguridad
proveedor [6]. Este punto está bastante estudiado
portable en cada cierre de periodo. En
(vendor lock-in le llaman en la literatura
teoría, al menos a nivel de datos, serás libre
especializada) y es una de los puntos que más se
de irte al final de cada periodo con un
citan como impedimentos y reticencias a los
conjunto coherente de datos.
modelos SaaS

A mi parecer, se ha de tener en cuenta:

Control y portabilidad de los datos:


Control y portabilidad de la aplicación: alguna manera, está basada o respaldada por
Si el proveedor quiebra o desaparece, o algún tipo de herramienta BPM, que implemente
simplemente decido irme, ¿podré llevarme la definiciones de los procesos en formatos
aplicación y los datos a otro sitio? ¿Lo puedo fijar estandarizados tipo BPEL, BPMN, XPDL, etc.
por contrato? Estas preguntas son de difícil
respuesta en según que casos, sobre todo si el De esta manera, al menos en teoría, se podrían
software es propietario (o la tecnología en la que importar la definición de los procesos a otras
fue desarrollado) y desde luego no es algo aplicaciones de la misma manera que se
habitualmente previsto en los contratos que se ven importarán los datos. Soy consciente de que esta
por ahí (no me lo imagino con gigantes como posibilidad es, a día de hoy, remota por el estado
Salesforce.com o NetSuite por ejemplo). A este de madurez de las herramientas BPM [13] pero no
respecto pues y en principio, será interesante la descartaría a medio plazo.
poder optar por aplicaciones Open Source o
propietarias con derecho a descarga y
modificación de los fuentes para uso exclusivo de
INTEGRACIÓN
la empresa cliente.
Es muy probable que la aplicación SaaS que
Conocimiento queramos poner en marcha no sea la única de las
Adicionalmente tendremos que considerar no sólo aplicaciones de la empresa y que necesitemos
la disponibilidad/portabilidad de la aplicación. interconectarlas e integrarlas entre ellas.
Tener la aplicación no basta, hay que tener los
recursos y el conocimiento (nosotros o terceros) La dificultad adicional que tenemos que
para que funcione. gestionar es que la aplicación SaaS va a estar
en un entorno que no está siendo gestionado
Es por esto que aunque deleguemos totalmente la por nosotros, por lo que se añaden
gestión de aplicación en el proveedor SaaS, complejidades de índole técnica y operativa
mantengamos personas dentro de nuestra que no se pueden desdeñar: necesidad de
organización con el conocimiento necesario para traspasar un firewall que se supone muy exigente
gestinar, aunque sea temporalmente y bajo de un tercero, no control de las ventanas
mínimos, la aplicación hasta que finalice la temporales y mecanismos de integración si ésta es
transición a otro proveedor/aplicación. asíncrona o batch, restricciones de seguridad y
técnicas a la hora de hacer una integración en
Condiciones y operativa de salida tiempo real, rigideces en formatos de
Es decir fechas de preaviso, posibles archivos/mensajes de integración,etc.
penalizaciones y calendarios mínimos (que habrá
que acabar de negociar durante la negociación del Concretando, deberemos tener en cuenta
contrato), coste de servicios adicionales en caso elementos como:
de ser necesarios, etc. No me extenderé sobre
algo que está bastante explicado [6] Integración con aplicaciones externas
Tales como una Web de ventas, aplicación de
Y para rizar el rizo, ¿Por qué no intentar la nómina, herramientas de BI y/o reporting, EDI, …
Portabilidad de Procesos? para las que como ya se ha mencionado antes hay
En la práctica consiste en poder llevarte contigo la restricciones operativas y técnicas que dificultan la
definición de los procesos de negocio soportados integración. Hay que enterarse muy bien de las
por la aplicación, que sólo será posible si ésta, de vías estándar como APIs, Web Services,
herramientas, metodologías, etc. que el proveedor


va a poner a nuestra disposición para facilitarnos
esta integración desde y hacia fuera de su firewall. PRIVACIDAD

Con ofimática Llegamos al tema, nada trivial por los aspectos
Hay que rendirse a la evidencia de que los legales y de procedimiento que hay detrás, de la
usuarios trabajan con archivos de ofimática de seguridad y privacidad. Vaya por delante que
forma intensiva y que cada vez más a las trasciende el propósito de este artículo hacer una
aplicaciones de negocio se les requiere trabajar descripción exhaustiva de la legislación que debe
con información no estructurada, como los aplicarse, y como no tengo la formación ni la
documentos ofimáticos, integrada con la experiencia en temas legales requerida para ello,
transaccional propia de la aplicación. Y hemos de me limitaré a los aspectos técnicos y operativos y
tener en cuenta que los documentos normalmente a proporcionar una lista de elementos a contrastar
están/salen de la red local, del equipo de usuario o con el proveedor, que he podido recopilar.
de un gestor documental, y que muchas veces
esos documentos son pesados, lo que va a Dicho de forma muy sintetizada: hay que
suponer un reto para el ancho de banda disponible asegurarse de que nuestros datos sensibles
y el rendimiento en general de la aplicación. Otra (entendiendo como sensibles, datos de tipo
opción, que me parece muy interesante, es la de personal o los propios secretos de la empresa)
usar ofimática en la nube. En ese sentido apunta van a ser almacenados y tratados de una forma
la decisión de SAP de integrar SAP Business que se cumpla la legislación vigente en materia
ByDesign con las aplicaciones de negocio de de privacidad y seguridad, lo que acabará
Google [7] afectando a cualquier elemento del servicio
relacionado con:
Dispositivos locales:
Como impresoras, PLCs/Sensores en entornos • Ubicación de los datos
industriales, controles de presencia, etc. • Seguridad de acceso y almacenamiento
Tendremos que verificar cuidadosamente los • Tratamiento automatizado
requerimientos técnicos de estos equipos para
estar integrados con la aplicación SaaS en Concretamente, tendremos que comprobar (y que
cuestión. Si por esta razón se han de cambiar se refleje de alguna manera en el contrato con el
equipos, el Business Case de la operación se proveedor) al menos lo siguiente:
puede resentir.
¿Realmente nuestro proveedor SaaS va tener
Hemos de ser consciente pues que una báscula que almacenar/tratar datos sensibles?
que vuelca datos al ERP, una impresora de código Datos personales, según se definan en la
de barras o térmica, un PLC controlado desde el legislación vigente, que nos comprometen como
ERP, etc. pueden ser dispositivos más empresa y para los que hay diversos niveles de
complicados de integrar en un entorno Cloud. sensibilidad- No es lo mismo una nómina que una
factura, y ya no digamos datos médicos de un
empleado.

Datos propios de la empresa “secretos”: propiedad
intelectual, i+d, fórmulas, listas de inversores,…

Será una tarea clave la identificación de estos
datos y los controles que deberemos acordar con


el proveedor para garantizar el cumplimiento, tanto Obviamente tendremos que conocer hasta el final
de nuestros requisitos de seguridad como el de los la cadena de proveedores y tenerlo en cuenta en
legales. el contrato (por ejemplo que sea necesaria la
autorización previa para cualquier subcontratación
¿Cuál es la ubicación de los servidores? o cesión del servicio a un tercero por parte de
En la legislación española sobre datos de caracter nuestro proveedor SaaS )
personal, si los servidores van a estar fuera de las
fronteras españolas aplica el concepto de ¿Como nos afecta la legislación específica, por
“transferencia internacional” de los datos, lo que ejemplo la LOPD en el caso de España?
obliga a comprobar que el país destino está Es fundamental conocer de acuerdo a la
“homologado” por las autoridades españolas como legislación, el responsable último es siempre la
ubicación “aceptable”. Actualmente es aceptado empresa, por lo que se deberá acotar muy bien en
cualquier país del Espacio Económico Europeo o el contrato, aparte de todo lo mencionado
de aquellos que la Agencia de Protección de Datos anteriormente, los límites y salvaguardas en el
tiene en su lista de Países con un nivel adecuado tratamiento de los datos: fines de ese tratamiento,
de protección. Atención también a los como se devolverán y destruirán, etc.
proveedores de nuestro proveedor.
…y si, los seguramente super-exigentes,
¿Qué tipo de seguridad, física, respaldo, abogados del BBVA no ven ningún problema en
procedimientos, acceso a servidores, etc. tiene que información tan sensible como la que manejan
activada el proveedor? los empleados del banco esté en la nube…[8] qué
Sin ánimo de extenderme en este tema, el podemos decir aquí.
proveedor debería poder mostrar qué medidas de
seguridad tiene implementadas. Lo más fácil es Para acabar este apartado, recomiendo la lectura
que pueda acreditar tales medidas mediante de las referencias [9] respecto a privacidad que se
certificaciones del tipo ISO27001, SAS 70 type II o relacionan en la sección de referencias.
equivalente y que pase las auditorías específicas
pertinentes que marcan esas certificaciones.
GOBIERNO DEL SERVICIO
¿Cómo se accede y “viajan” los datos?
¿El acceso, presumiblemente vía Web, es Si vamos a utilizar una aplicación en modo SaaS –
seguro,vía https/SSL o VPN, o equivalente? ¿Se Software as a Service - tendremos que gestionar
cifran los datos sensibles, que lo requieran, al ese as a Service y la manera habitual de gestionar
viajar y ser almacenados? cualquier servicio externalizado es mediante
acuerdos sobre la calidad del servicio que
¿Quién puede acceder y tratar los datos espera recibir el cliente del proveedor o, en la
sensibles? jerga del sector, SLAs [10] (Service Level
Aparte del proveedor principal, ¿hay Agreement) ligados a la QoS (Quality of Service).
subcontratados o terceros que pueden acceder y/o
tratar nuestros datos? Esta entrada no pretende cubrir en detalle qué es
un SLA ni como se negocia/acuerda, hay mucha
Debe tenerse en cuenta que es posible que literatura, y buena, disponible, sino en los puntos
nuestro proveedor SaaS esté utilizando recursos e particulares que pueda tener la gestión y medición
infraestructuras de terceros, por ejemplo una del servicio en el caso de aplicaciones SaaS de
aplicación que corra en los servidores de Amazon. gestión.


Dicho esto, cuando estemos negociando con que definir tipos de incidencia/consulta,
nuestro proveedor de aplicaciones SaaS de prioridades, etc.
gestión cómo se va a gestionar,medir y gobernar • Disponibilidad de la aplicación.
el servicio que nos quiere vender, tendremos que Normalmente se expresa en porcentajes de
atender, al menos, a los siguientes puntos: tiempo y excluye los tiempos dedicados a
mantenimiento de la plataforma. No olvidar
Niveles de servicio por capas. especificar el periodo de medición de esa
disponibilidad (no es lo mismo el 99,9% de
Teniendo en cuenta la arquitectura típica de este disponibilidad mensual que anual).
tipo de aplicaciones es conveniente conocer los
• No disponibilidad del servicio por
niveles de servicio para las distintas capas
mantenimiento. Ya sé que se ha dicho
tecnológicas que la conforman:
antes que en una aplicación true SaaS el
cliente ni se tiene que enterar de un cambio
• Aplicación
de versión pero entiendo que la plataforma
• Integración/Middleware
requerirá paradas por mantenimiento. Hay
• Infraestructuras que prestar atención a tiempos de preaviso y
horarios (no es lo mismo no tener disponible
En principio los niveles de servicio que más hemos la plataforma el día que lanzas la facturación
de controlar directamente son los de Aplicación. mensual que no tenerla un domingo)
El resto pueden ser relevantes si hay terceros
• Tiempos de puesta en marcha de nuevas
proveedores, por ejemplo en la capa de
funcionalidades. Si la aplicación, como
infraestructuras. Y si ese es el caso leer bien los
debería una True SaaS, permite
SLAs ofrecidos por ese tercero no vaya a ser que
activar/desactivar funcionalidades, será
no estés cubierto adecuadamente [11]
conveniente especificar el tiempo de
activación/desactivación operativa.
Niveles de servicio por tipo

Ligados a los procesos de negocio
Los niveles de servicio se pueden definir de varios
tipos. En este contexto no debería faltar:
Ya se ha apuntado antes pero lo recalco. Estamos
en un contexto de aplicaciones de gestión
• Rendimiento de la aplicación. Estos
empresarial. Cualquier parámetro de gestión del
niveles de servicio no es aconsejable que
servicio/sistema ha de tener como referente los
sean genéricos y se han de intentar definir
procesos de negocio cuando se traten temas
para las transacciones que consideremos
de disponibilidad, horarios, rendimientos,
más importantes – por ejemplo tiempo que
velocidad, tiempos de ejecución,… aunque
se tarda en finalizar la entrada de un pedido
hemos de ser conscientes del reto que puede
de cliente. Es recomendable que cada
suponer para el proveedor trabajar en ese modo.
empresa revise su caso particular y no
acepte por defecto las estándares (si las
Hay más elementos a tener en cuenta a la hora de
hubiere, que es poco probable). Otro tema
negociar los SLAs pero no veo que tengan
es como se mide.
particularidades relevantes con respecto a un
• Tiempos/calidad de respuesta al soporte. SaaS de aplicaciones de gestión. No obstante no
Tiempos relacionados con consultas, nos olvidemos de temas como:
incidencias, etc. de los usuarios finales o de
los técnicos. Aparte de estos tiempos hay


• Ajuste/renegociación de SLA. Hay que ¿Cómo nos va a medir el uso del sistema
prever la posibilidad de ajustar nuestro proveedor?
periódicamente los parámetros que miden la
calidad del servicio Pues mejor temprano que tarde tendremos que
• Monitorización. ¿Cómo va el cliente a ver conocer bien su modelo de indexación del
en tiempo real los parámetros de medición servicio, que habitualmente viene dado por uno o
de la calidad del servicio y problemas que una combinación de los siguientes elementos:
puedan haber?
• Nº de Usuarios de la aplicación, ya sean
• Reporting. Forma, periodicidad, formato de
concurrentes (sólo cuentan los que estén
la información, etc. que el proveedor va a
conectados en un momento dado) o
poner a disposición del cliente para el
nominales (cuentan se conecten o no –
seguimiento de la calidad del servicio.
¡pero cuidado con el shelfware! [12]). En el
• Penalizaciones/incentivos si las caso de concurrentes tendríamos modelos
expectativas no se cumplen o se cumplen dinámicos donde se pueden conectar todos
mejor de lo previsto los que quieren y luego te facturan o con un
• Mecanismos para la mejora continua. tope, donde si éste es “n”, el usuario “n+1″
Cómo incorporar las lecciones aprendidas y que se quiera conectar no puede.
el conocimiento adquirido de errores en • Tipos de usuario: No todos los usuarios
mejorar la gestión y el servicio son iguales. Por ejemplo los hay que utilizan
todas las funciones, intensiva o
No se me escapa que este punto ha quedado esporádicamente, otros que utilizan una
bastante genérico pero es que es un tema muy funcionalidad determinada de forma
extenso. He intentado al menos citar los puntos intensiva, los que se conectan sólo para
más importantes. consultar, … lo habitual es que se
establezcan diferencias a nivel de
tarificación entre estos diferentes tipos de
GESTIÓN DE COSTES usuario.
• Por módulos / funcionalidad activada /
No puede faltar en este repaso de los puntos clave desactivada. Es decir por el tipo de uso que
a considerar al seleccionar una aplicación de se hace de la aplicación. A considerar en
negocio SaaS, el de los costes. Y es que uno de este caso, la facilidad que deberemos
los atractivos que posiblemente busquemos al requerir de nuestro proveedor para tener
optar por un modelo SaaS es el de variabilizar los una gestión ágil de este uso tal como se ha
costes totales de propiedad de la aplicación de mencionado en el apartado sobre evolución.
gestión.
• Transacciones por periodo. Este modelo
puede ser muy ventajoso si se liga a
Esta variabilización se conseguirá al utilizarse un
transacciones que suponen ingresos ya que
modelo de suscripción/pago de una cuota
el coste del servicio se liga al ingreso. Por
periódica relacionada con el uso que se hace
ejemplo por número de pedidos de clientes
del sistema y que incluye todo (licencias,
entrados, facturas emitidas, clientes a los
infraestructuras, help-desk, nuevas versiones, etc.).
que se le factura en el mes,… o incluso un
porcentaje de la facturación.
Y ese “relacionada con el uso que hace del
• Consumo de recursos de computación.
sistema“ es clave en toda la gestión de costes:
Esto, que se llegó a hacer en los albores de


la informática cuando gigantes como IBM te
alquilaban ciclos de CPU, no es un modelo
que para aplicaciones de gestión tenga
mucho sentido ya que es muy poco
predecible. No lo veo en un entorno de
aplicaciones de gestión pero si alguien tiene
una mejor opinión que comente.

Adicionalmente tendremos que tener en cuenta
que puede haber límites inferiores (mínimos de
uso) y superiores, normalmente asociados a
limitaciones por consumo de recursos como ancho
de banda, ocupación disco, consumo de CPU, etc.

Concluyendo, está claro que, independientemente
del modelo que ofrezca el proveedor, habrá que
hacer un estudio minucioso de cómo se va a usar
la aplicación y prever que tengamos la
capacidad de ir ajustando dinámica y
elásticamente nuestras necesidades.


CONCLUSIÓN:
En este artículo he intentado hacer una cobertura a alto nivel de todos los puntos que
considero claves en la selección de una aplicación de gestión en la nube o SaaS y que puedan
ser de ayuda tanto a la empresa que se está planteando comprar como a la que vende, o
quiere vender, este tipo de aplicaciones. Espero haber cubierto este objetivo dentro de mis
modestas posibilidades y si te ha gustado el artículo te agradecería su difusión entre tus
contactos profesionales, en redes sociales y colegas de trabajo que creas que les pueda
interesar - sobre todo si son CEOs, CIOs, CFOs, CxOs en general …☺

Los puntos cubiertos en el artículo deben considerarse como una guía de partida, una especie
de check-list y nunca deberían ser sin más el único elemento para tomar una decisión. Si crees
que necesitas una ayuda más adecuada a tus necesidades específicas no dudes en
contactarme.


REFERENCIAS:
[1] How Cloud Computing And ERP Mobility Are Reordering Gartner’s Hype Cycle for ERP
http://softwarestrategiesblog.com/2012/01/02/how-cloud-computing-and-erp-mobility-are-
reordering-gartners-hype-cycle-for-erp/

[2] Roundup of Cloud Computing Forecasts and Market Estimates, 2012.
http://softwarestrategiesblog.com/2012/01/17/roundup-of-cloud-computing-forecasts-and-
market-estimates-2012/

[3] Gartner Executive Programs' Worldwide Survey of More Than 2,300 CIOs Shows Flat IT
Budgets in 2012, but IT Organizations Must Deliver on Multiple Priorities.
http://www.gartner.com/it/page.jsp?id=1897514

[4] Building data startups: Fast, big, and focused. Low costs and cloud tools are empowering
new data startups.
http://radar.oreilly.com/2011/08/building-data-startups.html

[5] Webinar en el Project Management Institute sobre la utilización de métodos ágiles en la
implantación de ERPs
http://www.nodotic.com/?p=539

[6] Atrapado por tu proveedor. Post en nodoTIC.com sobre los elementos a gestionar para
evitar quedar bloqueado por tu proveedor de servicios

[7] SAP Integration with Google Apps. SAP and Google recently announced plans to integrate
SAP Business ByDesign and Google Apps for Business.
http://en.sap.info/apps-google-bydesign/64640

[8] One of the most influential banks in the world adopts Google’s technology as a part of its
innovation strategy. BBVA banks on the Google cloud
http://press.bbva.com/latest-contents/press-releases/spain/bbva-banks-on-the-google-
cloud(9882-22-101-c-92220).html

[9] Varias referencias en relación a legislación sobre privacidad de datos
Reforma/actualización que propone la Comisión Europea sobre el marco de 1995
http://ec.europa.eu/justice/newsroom/data-protection/news/120125_en.htm
LOPD y Cloud Computing:
http://www.gpn6.com/2011/11/lopd-y-cloud-computing/
Consulta pública de la Agencia Española de Protección de Datos sobre Cloud Computing (es posible que este
enlace caduque, si es así buscar en la misma Web
http://www.servicios.agpd.es/AGPD/inicio_encuesta.seam?cid=960
Guía Cloud del Instituto Nacional de Tecnologías de la comunicación INTECO
http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Cloud
Aspectos contractuales y marco regulador del cloud computing
http://www.gesdatos.com/el-rincon-del-dato/aspectos-legales-en-cloud-computing.html


Un ejemplo de condiciones de privacidad de un proveedor (SalesForce)
http://www.salesforce.com/company/privacy/
Un ejemplo de condiciones de disponibilidad (Netsuite)
http://www.netsuite.com/portal/infrastructure/availability.shtml
Lista de países considerados “Seguros”
https://www.agpd.es/portalwebAGPD/canalresponsable/transferencias_internacionales/index-ides-idphp.php

[10] Posts en nodoTIC.com sobre el concepto de SLA
http://www.nodotic.com/index.php?s=sla

[11] Amazon SLAs Didn't Cover Major Outage. Customers affected by the recent EC2 outage
were compensated by Amazon, but not because the terms of the SLA required it.
http://www.informationweek.com/news/cloud-computing/software/229403086

[12] Shelfware. Software purchased but not used.
http://en.wiktionary.org/wiki/shelfware

[13] Presentación en el Internet Global Congress de Barcelona de 2006 sobre herramientas BPM.
http://www.slideshare.net/luiscu/13-1-carrasco-delphin-phaq-presentation

[13] Encuesta en nodoTIC sobre ERP SaaS disponible en España


SOBRE EL AUTOR:

Luis Carrasco es Ingeniero de Telecomunicación por la
Universidad Politécnica de Cataluña, y Executive MBA por
EAE Barcelona.

Actualmente es gerente en Delphin Project Hunting, donde,
como consultor y project manager, lidera iniciativas para
sus clientes de mejoras organizativas, de procesos y
sistemas de información para la gestión empresarial.

Luis es editor de www.nodoTIC.com, blog sobre sobre tendencias en sistemas
de información de gestión empresarial.

También podéis encontrarle en diversas redes sociales:

http://www.linkedin.com/in/luiscu

@nodotic

https://plus.google.com/u/0/111838161734108867236/about


DISCLAIMER:

Este artículo se ha publicado bajo licencia Creative Commons sa-by, lo que
básicamente significa que puedes utilizarlo como quieras siempre que
menciones a su autor y que compartas de la misma forma cualquier obra
derivada en la que lo hayas utilizado. Para los detalles puedes visitar la Web de
creative commons: http://creativecommons.org/licenses/by-sa/3.0/deed.es

En la redacción de este artículo me he inspirado en múltiples lecturas y he
utilizado recursos gráficos que he intentado referenciar y atribuir a sus autores.
Si crees que hay algo en el artículo que debería ser cambiado, añadido o
modificado házmelo saber.


Puntos clave seleccion aplicaciones SaaS. Artículo - Luis Carrasco

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Puntos clave seleccion aplicaciones SaaS. Artículo - Luis Carrasco

Ähnlich wie Puntos clave seleccion aplicaciones SaaS. Artículo - Luis Carrasco (20)

Mehr von Luis Carrasco

Mehr von Luis Carrasco (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Puntos clave seleccion aplicaciones SaaS. Artículo - Luis Carrasco