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

http://www.google.com/apps/intl/es/business/index.html

http://www.google.com/apps/intl/es/business/index.html




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

http://www.nodotic.com/?tag=saas




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

http://ec.europa.eu/justice/newsroom/data-protection/news/120125_en.htm

http://www.gpn6.com/2011/11/lopd-y-cloud-computing/

http://www.servicios.agpd.es/AGPD/inicio_encuesta.seam?cid=960

http://www.agpd.es/

http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Cloud

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

http://www.salesforce.com/company/privacy/

http://www.netsuite.com/portal/infrastructure/availability.shtml

https://www.agpd.es/portalwebAGPD/canalresponsable/transferencias_internacionales/index-ides-idphp.php

http://www.slideshare.net/luiscu/13-1-carrasco-delphin-phaq-presentation

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

http://www.blog.nodotic.com/

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

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.

http://creativecommons.org/licenses/by-sa/3.0/deed.es

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

Business

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