Puntos Clave Selección Aplicaciones SaaS - NODOTIC [ES]

Ayudamos a nuestros clientes
en sus iniciativas de mejora de su
organización, procesos de negocio y tecnología
Nodotic, Asesoría Tecnológica y Gestión de Proyectos SL 1 / 22
www.nodotic.com
Michael Heiss http://www.flickr.com/people/michaelheiss/
Puntos clave en la selección de aplicaciones de
negocio en modelo SaaS / en la nube

www.nodotic.com
Contenidos:
New York rises de Eugene de Salignacs
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
Disclaimer

www.nodotic.com
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.

www.nodotic.com
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.

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

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

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

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

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

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

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

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

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

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

www.nodotic.com
Dicho esto, cuando estemos negociando con
nuestro proveedor de aplicaciones SaaS de
gestión cómo se va a gestionar,medir y gobernar
el servicio que nos quiere vender, tendremos que
atender, al menos, a los siguientes puntos:
Niveles de servicio por capas.
Teniendo en cuenta la arquitectura típica de este
tipo de aplicaciones es conveniente conocer los
niveles de servicio para las distintas capas
tecnológicas que la conforman:
Aplicación
Integración/Middleware
Infraestructuras
En principio los niveles de servicio que más hemos
de controlar directamente son los de Aplicación.
El resto pueden ser relevantes si hay terceros
proveedores, por ejemplo en la capa de
infraestructuras. Y si ese es el caso leer bien los
SLAs ofrecidos por ese tercero no vaya a ser que
no estés cubierto adecuadamente [11]
Niveles de servicio por tipo
Los niveles de servicio se pueden definir de varios
tipos. En este contexto no debería faltar:
Rendimiento de la aplicación. Estos
niveles de servicio no es aconsejable que
sean genéricos y se han de intentar definir
para las transacciones que consideremos
más importantes – por ejemplo tiempo que
se tarda en finalizar la entrada de un pedido
de cliente. Es recomendable que cada
empresa revise su caso particular y no
acepte por defecto las estándares (si las
hubiere, que es poco probable). Otro tema
es como se mide.
Tiempos/calidad de respuesta al soporte.
Tiempos relacionados con consultas,
incidencias, etc. de los usuarios finales o de
los técnicos. Aparte de estos tiempos hay
que definir tipos de incidencia/consulta,
prioridades, etc.
Disponibilidad de la aplicación.
Normalmente se expresa en porcentajes de
tiempo y excluye los tiempos dedicados a
mantenimiento de la plataforma. No olvidar
especificar el periodo de medición de esa
disponibilidad (no es lo mismo el 99,9% de
disponibilidad mensual que anual).
No disponibilidad del servicio por
mantenimiento. Ya sé que se ha dicho
antes que en una aplicación true SaaS el
cliente ni se tiene que enterar de un cambio
de versión pero entiendo que la plataforma
requerirá paradas por mantenimiento. Hay
que prestar atención a tiempos de preaviso y
horarios (no es lo mismo no tener disponible
la plataforma el día que lanzas la facturación
mensual que no tenerla un domingo)
Tiempos de puesta en marcha de nuevas
funcionalidades. Si la aplicación, como
debería una True SaaS, permite
activar/desactivar funcionalidades, será
conveniente especificar el tiempo de
activación/desactivación operativa.
Ligados a los procesos de negocio
Ya se ha apuntado antes pero lo recalco. Estamos
en un contexto de aplicaciones de gestión
empresarial. Cualquier parámetro de gestión del
servicio/sistema ha de tener como referente los
procesos de negocio cuando se traten temas
de disponibilidad, horarios, rendimientos,
velocidad, tiempos de ejecución,… aunque
hemos de ser conscientes del reto que puede
suponer para el proveedor trabajar en ese modo.
Hay más elementos a tener en cuenta a la hora de
negociar los SLAs pero no veo que tengan
particularidades relevantes con respecto a un
SaaS de aplicaciones de gestión. No obstante no
nos olvidemos de temas como:

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

www.nodotic.com
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.

www.nodotic.com
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.

www.nodotic.com
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
http://www.nodotic.com/?p=679
[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

www.nodotic.com
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 el blog de nodoTIC sobre ERP SaaS disponible en España
http://www.blog.nodotic.com/?p=701

www.nodotic.com
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 y socio fundador de Nodotic,
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.blog.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

www.nodotic.com
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 Selección Aplicaciones SaaS - NODOTIC [ES]

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Puntos Clave Selección Aplicaciones SaaS - NODOTIC [ES]

Similaire à Puntos Clave Selección Aplicaciones SaaS - NODOTIC [ES] (20)

Dernier

Dernier (20)

Puntos Clave Selección Aplicaciones SaaS - NODOTIC [ES]