Michael Heiss http://www.flickr.

com/people/michaelheiss/

Puntos clave en la seleccin de aplicaciones de negocio en modelo SaaS / en la nube

Presentacin descargable en: http://www.nodotic.com/?p=1033

LuisCarrasco

1/22

Contenidos:
Introduccin Puntos clave
Multi-tenancy Tecnologa Inicio del Servicio Evolucin del Servicio Fin del Servicio Integracin Privacidad Gobierno del Servicio Gestin de Costes

Conclusin Referencias Sobre el autor

New York rises de Eugene de Salignacs

LuisCarrasco

2/22

INTRODUCCIN
Mover las aplicaciones de negocio (ERP, CRM, etc.) a la nube (en modo SaaS) es una tendencia en ascenso entre los responsables de las tecnologas de la informacin en las empresas a tenor de los mltiples informes y encuestas de los analistas del sector de las TIC [1], [2], [3]. No tengo cifras locales concretas, slo mi experiencia directa hablando con colegas, clientes y proveedores, pero esta tendencia parece ms tmida en nuestro entorno que en otros y es que por alguna razn aqu siempre somos ms precavidos en lo de introducir cambios, por decirlo amablemente, o quiz no haya an 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 estratgico de ese calibre en la gestin de la informacin de sus empresas, pero como estoy plenamente convencido de que es cuestin 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 informacin, transparencia y debate, esos miedos y dudas, me he decidido a escribir este artculo sobre qu es lo que hay que saber antes de decidir mover las aplicaciones de negocio a un modelo SaaS. El artculo lo he estructurado alrededor de los siguientes puntos clave: o o o o o o o o o Multi-tenancy. Como condicin necesaria para que el modelo sea sostenible. Tecnologa. Consideraciones respecto de la arquitectura tecnolgica de la aplicacin SaaS. Inicio del Servicio. Qu hemos de tener en cuenta en relacin a como se pone en marcha el servicio. Evolucin del Servicio. Qu debemos gestionar para asegurar la adaptacin de la aplicacin SaaS a los requerimientos cambiantes de nuestra organizacin. Fin del servicio. Elementos importantes en el momento de finalizar la relacin con el proveedor de la aplicacin SaaS Integracin. Consideraciones a la relacin de la aplicacin SaaS con otras aplicaciones Privacidad. Cmo cumplir la legislacin vigente y proteger nuestros datos sensibles. Gobierno del servicio. Gobierno de la relacin con el proveedor y gestin de la calidad del servicio. Gestin de costes. Indexacin de los costes al uso de la aplicacin.

LuisCarrasco

3/22

Cada uno de estos puntos se desarrollarn 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 gustara que este artculo fuera til, no slo para aquellos responsables de sistemas de informacin de esa hipottica empresa sino tambin tambin 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 artculos como principios del siglo XX las empresas industriales tenan sus propios generadores elctricos y pozos de agua in house y que al extenderse las redes de distribucin de electricidad y agua se cambiaron a la Energa y Agua as a Service. Modelo que ahora, salvo contadsimas excepciones, vemos como el nico racional y sostenible.

LuisCarrasco

4/22

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 artculo: el multi-tenancy. En una primera aproximacin se podra definir que una aplicacin de gestin 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, tcnica y econmicamente, para el proveedor.

red local a travs de Internet, y el paquete se venda en forma de acceso por usuario. Entre las razones tcnicas por lo que este modelo fracas, operativa y econmicamente, se pueden contar: Velocidad y disponibilidad de Internet en esa poca. La arquitectura fsica con la que se haban diseado esas aplicaciones no escalaba ni soportaba bien compartir infraestructuras fsicas en el lado servidor. Era ineficiente en el aprovechamiento de recursos hardware y software (la virtualizacin de servidores era una tecnologa incipiente, de laboratorio prcticamente) y el hardware era caro en esos aos. La arquitectura del software no estaba pensada para ser compartida por compaas diferentes. Los datos y tablas quiz s (o ni eso) pero una configuracin del software para necesidades especficas de una compaa no se poda hacer estanca al resto, por lo que se podan producir colisiones o incompatibilidades entre ellas. Las modificaciones que sobre una arquitectura ya desarrollada tenan que hacerse, complicaban ms an el entorno y lo podan hacer ingestionable tcnicamente por el proveedor. La evolucin del software poda ser en la prctica inviable. O todos los clientes se coordinaban para cambiar de versin a la vez o no se poda, lo que deriv en que el software se quedase atascado en una versin o en que se tuviesen que separar instalaciones por versin algo antieconmico y a medio plazo insostenible. Al haber mucha lgica, incluso datos, en la parte cliente, el despliegue y mantenimiento homogneo de cualquier

Estos requisitos veremos ms adelante que condicionan fuertemente la arquitectura tecnolgica de una aplicacin 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 visin de negocio de los ASP era la misma que pueden tener los actuales modelos SaaS pero el estado de la tecnologa y madurez de las empresas que se podran haber beneficiado no lo era. Por ejemplo, uno trivial, la velocidad y disponibilidad de las lneas de comunicaciones, o la disposicin de las empresas a sacar sus centros de datos fuera de sus paredes (algo a lo que ahora estn ms predispuestas en general). En muchos casos, el concepto ASP acababa en que una aplicacin cliente-servidor, diseada 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

LuisCarrasco

5/22

implantacin compartida era una tarea muy costosa porque haba que actualizar software en cada estacin de trabajo En conclusin, para que una aplicacin de gestin sea viable en modo SaaS, debe ser capaz de poder conseguir economas de escala al compatibilizar el que los clientes puedan compartir los costes fijos (infraestructuras, implantacin, soporte, mantenimiento, desimplantacin, etc.), cubrir las necesidades comunes y especficas 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 tecnolgicos como la virtualizacin, seguridad, velocidad y ubicuidad de lneas, navegadores rpidos y capaces de incorporar lgica de forma estndar -no propietaria- en local, entornos y metodologas de desarrollo ms avanzados, etc. que permitieron desarrollar productos con arquitecturas tecnolgicas que posibilitaban el Multi-tenancy y desplegar modelos True SaaS. Y como podemos verificar con nuestro proveedor que su aplicacin de gestin es Multi-tenancy y evitar as que en realidad acabemos contratando una aplicacin tradicional en hosting, o lo que es lo mismo que seamos un Single-tenancy ms en sus infraestructuras? Pues deberemos hacerle preguntas como: Todos los clientes estn en la misma versin del software? Todos los clientes deberan correr la misma versin del cdigo, sin customizaciones de cdigo. De esta forma cualquier configuracin propia del cliente no acabar afectando al resto de clientes ni, a su vez, se ver afectada por personalizaciones de cdigo del resto de clientes Cunto se tarda en hacer un cambio de versin?

Qu tiene que hacer el cliente si se actualiza la versin del software? Los clientes no se deberan preocupar de tener que actualizar el software, para ellos debera ser transparente, en un extremo ni enterarse. As la actualizacin es para todos los clientes a la vez y cualquier configuracin especfica del cliente no debera condicionar el poder actualizar el software al resto Podras hacer maana mismo un cambio de versin sin avisar a tus clientes? Con qu periodicidad se actualiza el software? No debera haber versiones en el sentido tradicional sino frecuentes mejoras incrementales (un ejemplo seran las aplicaciones de Google) Cuntos cambios de versin/upgrades/mejoras has hecho en el ltimo ao? Cmo va a cubrir la aplicacin mis requerimientos funcionales clave [eljanse varios cuidadosamente] y que son especficos de mi compaa/negocio/sector? Si el proveedor contesta que debe adaptar/cambiar el software es probable que ste ya no sea una opcin adecuada (al menos en modo SaaS) para el cliente. De alguna forma la arquitectura de la aplicacin debe estar construida de forma que se puedan diferenciar las diferentes compaas cliente en el momento de ejecucin de la aplicacin. En los modelos ASP esto se consegua con el cdigo de compaa/unidad organizativa, pero un modeloTrue SaaS debe ir ms all, con codificaciones que permitan que en modo de ejecucin la aplicacin pueda distinguir entre compaas clientes, hacer uso de clusters o agrupaciones de unidades organizativas por compaa cliente o por criterios de localizacin geogrfica para temas de normativas locales por ejemplo. Con estos requisitos, en mi modesta opinin, veo muy difcil, por no decir imposible, que una aplicacin que no ha sido tcnicamente diseada y concebida desde cero con un enfoque de ser Multi-Tenancy, pueda serlo, ya

LuisCarrasco

6/22

que las modificaciones a posteriori que una aplicacin tradicional requiera para ser Multitenancy acabarn hacindola compleja y costosa de gestionar y mantener, es decir inviable econmicamente. En conclusin, hay que prestar atencin a los provedores con productos tradicionales reetiquetados como SaaS que realmente no son Multi-tenancy.

TECNOLOGA
Como ya se ha comentado anteriormente, la tecnologa ha desempeado 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 aplicacin debera poder hacerse sin necesidad de instalaciones de software especfico en local o al menos que el proceso de instalacin y actualizacin 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 opinin mejor opcin, es que sea a travs de un navegador estndar (mejor que no se dependa de uno en concreto) con AJAX, HTML5 y como mximo algn plug-in tipo ActiveX, Applet. Tambin es de esperar que avances recientes en protocolos a nivel de aplicacin como SPDY y Web Sockets de HTML5 mejoren latencias y rendimiento de los actuales protocolos HTTP pero esto ahora est saliendo tmidamente de los laboratorios. De esta forma se consigue:

Conectividad. Ser ms fcil acceder a la aplicacin desde cualquier ubicacin con acceso a Internet. Facilidad de despliegue. En la implantacin no se debera tener que invertir en hardware de terminal de usuario ni tiempo de instalacin. Facilidad de evolucin. La aplicacin podr evolucionar desde el lado de servidor sin tener que actualizar nada en los clientes facilitando as al proveedor el mantener una versin nica de su aplicacin 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 integracin. Escalabilidad de la plataforma tecnolgica Hemos de partir de la premisa de que la plataforma tecnolgica en la que estar alojada la aplicacin SaaS ser compartida y deber poder crecer de forma ms o menos lineal segn el uso que le de la propia empresa y las empresas vecinas. Parece pues muy razonable interesarnos por las herramientas y tecnologas que el proveedor va a utilizar para asegurarnos esa escalabilidad. Concretamente habra que preguntarle por temas como: Qu productos/tecnologas va a utilizar para gestionar su plataforma Cloud: virtualizacin, despliegues de aplicaciones (nuevos clientes y/o versiones/parches), creacin de nuevos entornos/instancias, gestin de los cambios de versin de productos base (sistema operativo, bases de datos, ), sincronizacin entre entornos de desarrollo, test y produccin, compaginar instalaciones compartidas con dedicadas, etc. Si la plataforma fsica 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,

LuisCarrasco

7/22

adems tiene relevancia a efectos legales, como veremos ms adelante. Si dispone de herramientas o tecnologas especficas para la gestin de grandes volmenes de datos o cmo va a asegurar la escalabilidad de un entorno de datos que al ser compartido va crecer ms 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 tecnologas de Big Data pero creo que no vale el enfoque por el que se optara en una instalacin monocliente (el Multy-tenancy aparece otra vez) al ser potencialmente un entorno menos predecible y planificable.

Disponibilidad y seguridad fsica de la plataforma tecnolgica Teniendo en cuenta que al ser una aplicacin de negocio vamos a utilizar la plataforma tecnolgica 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?, Cmo lo ha previsto el proveedor y cmo se integra en nuestra estrategia de recuperacin del negocio en caso de desastre (tiene un Disaster Business Recovery Plan)?, Hay redundancia de equipamientos como lneas de comunicaciones, alimentacin elctrica, generador/grupo electrgeno, etc.?, Dispone el proveedor, o nosotros, de una instalacin de respaldo alternativa para el caso de un desastre total, y en ese caso cmo se efectuara la transicin?, y la sincronizacin de datos entre instalaciones principal-respaldo? Rendimiento ante picos de actividad, algunos predecibles y otros no,

inestabilidad del entorno por el cambio continuo, Qu tecnologas va a utilizar el proveedor para garantizar el rendimiento de la plataforma, velocidad de las lneas, uso de recursos de CPU, ? De la misma forma que con la escalabilidad de datos, las estrategias y arquitecturas tecnolgicas que se han venido utilizando en instalaciones single-tenancy es probable que no sean las ms adecuadas. Seguridad fsica. Cmo se controla el acceso fsico a las instalaciones?, Quin tendr acceso?, Sistemas de vigilancia/registro/grabacin?, Monitorizacin. Cmo va a controlar el proveedor el rendimiento y disponibilidad de la plataforma? Lo mejor es que el proveedor pueda ensearos su centro de control y que os explique qu herramientas de control y gestin de alarmas utiliza y cmo os vais a enterar si hay una incidencia. Volveremos sobre esto en el punto de gestin del servicio.

Seguridad de Datos Los datos de clientes, sus pedidos, la informacin de tu inventario, la facturacin toda esta informacin no se puede perder; en general, no la puede ver cualquiera y en algn caso la empresa est obligada a protegerla. Se ha de tener claro al menos: Cmo se gestionan las copias de seguridad: Periodicidad (diaria, cierre de periodo/ejercicio, ), quin lo hace, dnde se gestionan/almacenan las copias, control de acceso,? Cmo es la sincronizacin con posibles centros de respaldo? Se cifra la informacin sensible (ms sobre esto en el punto sobre privacidad)? Cmo se controla el acceso a la aplicacin, a la base de datos, etc. tanto accediendo desde dentro como desde fuera del firewall/permetro de seguridad?

LuisCarrasco

8/22

Se registra/audita la actividad de acceso a datos? Qu, quin y cundo se modifican/leen/borran los datos Cmo se asegura que otros clientes no ven mis datos? etc. no me extiendo ms en este punto porque entiendo que hay disponible abundante documentacin al respecto.

Haya disponibilidad de herramientas de carga, depuracin, comparacin, etc. de datos orientadas a acelerar la migracin y conversin de informacin y la gestin de paralelos. Se utilicen Metodologas de puesta en marcha giles [5], colaborativas, iterativas, etc con entornos preconfigurados para la captura rpida e incremental de requisitos, aprender pronto para ajustar tambin pronto, disponer de funcionalidades que estn operativas de forma rpida y poder ir afinndolas en ciclos cortos tambin. La Configuracin (set up de entorno, seguridad, alta de usuarios, etc.) sea rpida, con asistentes (tipo siguiente-siguiente) y aceleradores tales como un catlogo de plantillas de procesos sectoriales y horizontales ya preconfigurados, opciones de activacin/desactivacin de funcionalidades pre-existentes a demanda, etc. La puesta en marcha la puedan liderar usuarios no tcnicos (a.k.a. de negocio) no necesariamente expertos de producto.

Green/Eficiencia Energtica Y para empresas con sensibilidad y responsabilidad social, por qu no preguntar por las polticas de eficiencia energtica y prcticas de proteccin del medio ambiente, etc.? Aunque sea slo sea por el inters 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 energa.

INICIO DEL SERVICIO

Uno de los atractivos de utilizar un modelo SaaS pasa por la premisa de que en general todo tiene que ser ms rpido y sencillo. Es una hiptesis de partida porque de no ser as el modelo no es sostenible ni viable y debemos, por tanto, prestar atencin 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 debera acortar el tiempo de puesta en marcha y eliminar las necesidades adicionales (espacio, seguridad, climatizacin, por ejemplo) para acomodar nuevas infraestructuras o instalaciones locales de software en los equipos de usuario.

Se podr objetar y con razn, 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 ficcin en el caso de los productos tradicionales? por qu debera 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 deberan ser ms fcilmente exigibles a una aplicacin SaaS verdadera que a una tradicional ya que, como ya se coment anteriormente en el punto de Multi-tenancy, su arquitectura ya

LuisCarrasco

9/22

debera haberse diseado incluyendo estas premisas y requerimientos.

EVOLUCIN DEL SERVICIO

Dentro de los puntos clave no poda faltar el relativo a asegurar la evolucin adecuada del servicio que esperamos recibir una vez puesto en marcha dicho servicio, o dicho de otra forma, de la elasticidad de la aplicacin para adaptarse a las necesidades cambiantes que seguro va a tener nuestra empresa. Por eso deberemos pedirle al proveedor de la aplicacin informacin sobre: Evolucin de funcionalidades: Cmo nos va a asegurar el proveedor que su aplicacin evoluciona tecnolgica y funcionalmente con el mercado/sector y con nuestras necesidades especficas. Concretamente: Qu plan de producto, road map, tiene establecido: mdulos, funcionalidades nuevas, etc. Atencin a la frecuencia de actualizacin que, como ya se mencion en la entrada de esta serie correspondiente a Multi-tenancy, debera ser mayor que la de una aplicacin tradicional. Qu garantas nos da de adaptacin a cambios a la legislacin vigente, algo especialmente importante en aplicaciones financieras y de RRHH. Respecto a la evolucin de las funcionalidades especficas de nuestra empresa (ya sea mantenimiento evolutivo o despliegue de nuevos mdulos 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 catlogo de

plantillas de procesos sectoriales y horizontales que puedan ser desplegadas por usuarios no tcnicos, activacin y desactivacin de funcionalidades preexistentes a demanda y con un Sandbox para pruebas para as no afectar al sistema en produccin. Todos estos puntos no son exclusivos de una aplicacin SaaS evidentemente pero es de esperar que sean ms asequibles que en las aplicaciones tradicionales por lo ya mencionado anteriormente de que la arquitectura de la aplicacin SaaS ya debera haber sido diseada 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, tecnologas, metodologas, etc. tiene el proveedor para acomodar picos en el nmero 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 tecnolgico del proveedor es sostenible y viable, no slo desde el punto de vista tecnolgico sino tambin desde el punto de vista econmico. 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 facturacin 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 elsticos basados en IaaS de terceros sern recomendables en principio ya que permitirn esa escalabilidad de forma lineal (aunque no olvidemos los temas legales, como se

LuisCarrasco

10/22

comentar posteriormente correspondiente a privacidad) Escalabilidad de usuarios:

en

el

punto

Otro elemento a atar en corto es cmo se gestiona el crecimiento y decrecimiento de usuarios de la aplicacin para acomodarse a la dinmica de la empresa. Un ejemplo extremo sera el de una empresa sujeta a una alta temporalidad, donde en la temporada alta sube el nmero de usuarios. Debemos por tanto tener controlados aspectos como: Como varan los costes segn el n de usuarios (me extender ms sobre esto en el punto correspondiente a costes) Facilidad de replicar/desactivar usuarios, roles, etc. No tendra mucho sentido en un entorno dinmico y gil, como el que se supone que es un entorno SaaS, que poner en marcha un nuevo usuario sea costoso.

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 debera aceptar ninguna restriccin 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 informacin cuando la necesite y las facilidades que ste tenga van a ser un indicador inestimable de la bondad del proveedor y de su aplicacin. El tema se puede complicar si adems hay una externalizacin de procesos (BPO) donde los procesos son efectuados directamente por el propio proveedor ya que entonces ser ms difcil 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 atencin a: Formato de los datos para su portabilidad. Archivos planos, Exports de tablas de las bases de datos, un tema bastante tecnolgico 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 teora, al menos a nivel de datos, sers libre de irte al final de cada periodo con un conjunto coherente de datos.

Y es que nunca hemos de perder de vista que si estamos barajando una aplicacin SaaS es porque nos preocupa, entre otras cosas, la elasticidad de la solucin, tanto para crecer como para decrecer.

FIN DEL SERVICIO

En la Salida o Finalizacin 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 ms 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:

LuisCarrasco

11/22

Control y portabilidad de la aplicacin: Si el proveedor quiebra o desaparece, o simplemente decido irme, podr llevarme la aplicacin y los datos a otro sitio? Lo puedo fijar por contrato? Estas preguntas son de difcil respuesta en segn que casos, sobre todo si el software es propietario (o la tecnologa 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 modificacin de los fuentes para uso exclusivo de la empresa cliente. Conocimiento Adicionalmente tendremos que considerar no slo la disponibilidad/portabilidad de la aplicacin. Tener la aplicacin no basta, hay que tener los recursos y el conocimiento (nosotros o terceros) para que funcione. Es por esto que aunque deleguemos totalmente la gestin de aplicacin en el proveedor SaaS, mantengamos personas dentro de nuestra organizacin con el conocimiento necesario para gestinar, aunque sea temporalmente y bajo mnimos, la aplicacin hasta que finalice la transicin a otro proveedor/aplicacin. Condiciones y operativa de salida Es decir fechas de preaviso, posibles penalizaciones y calendarios mnimos (que habr que acabar de negociar durante la negociacin 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 prctica consiste en poder llevarte contigo la definicin de los procesos de negocio soportados por la aplicacin, que slo ser posible si sta, de

alguna manera, est basada o respaldada por algn tipo de herramienta BPM, que implemente definiciones de los procesos en formatos estandarizados tipo BPEL, BPMN, XPDL, etc. De esta manera, al menos en teora, se podran importar la definicin de los procesos a otras aplicaciones de la misma manera que se importarn los datos. Soy consciente de que esta posibilidad es, a da de hoy, remota por el estado de madurez de las herramientas BPM [13] pero no la descartara a medio plazo.

INTEGRACIN
Es muy probable que la aplicacin 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 aplicacin SaaS va a estar en un entorno que no est siendo gestionado por nosotros, por lo que se aaden complejidades de ndole tcnica y operativa que no se pueden desdear: necesidad de traspasar un firewall que se supone muy exigente de un tercero, no control de las ventanas temporales y mecanismos de integracin si sta es asncrona o batch, restricciones de seguridad y tcnicas a la hora de hacer una integracin en tiempo real, rigideces en formatos de archivos/mensajes de integracin,etc. Concretando, deberemos elementos como: tener en cuenta

Integracin con aplicaciones externas Tales como una Web de ventas, aplicacin de nmina, herramientas de BI y/o reporting, EDI, para las que como ya se ha mencionado antes hay restricciones operativas y tcnicas que dificultan la integracin. Hay que enterarse muy bien de las vas estndar como APIs, Web Services, herramientas, metodologas, etc. que el proveedor

LuisCarrasco

12/22

va a poner a nuestra disposicin para facilitarnos esta integracin desde y hacia fuera de su firewall. Con ofimtica Hay que rendirse a la evidencia de que los usuarios trabajan con archivos de ofimtica de forma intensiva y que cada vez ms a las aplicaciones de negocio se les requiere trabajar con informacin no estructurada, como los documentos ofimticos, integrada con la transaccional propia de la aplicacin. Y hemos de tener en cuenta que los documentos normalmente estn/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 aplicacin. Otra opcin, que me parece muy interesante, es la de usar ofimtica en la nube. En ese sentido apunta la decisin 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 tcnicos de estos equipos para estar integrados con la aplicacin SaaS en cuestin. Si por esta razn se han de cambiar equipos, el Business Case de la operacin se puede resentir. Hemos de ser consciente pues que una bscula que vuelca datos al ERP, una impresora de cdigo de barras o trmica, un PLC controlado desde el ERP, etc. pueden ser dispositivos ms complicados de integrar en un entorno Cloud.

PRIVACIDAD
Llegamos al tema, nada trivial por los aspectos legales y de procedimiento que hay detrs, de la seguridad y privacidad. Vaya por delante que trasciende el propsito de este artculo hacer una descripcin exhaustiva de la legislacin que debe aplicarse, y como no tengo la formacin ni la experiencia en temas legales requerida para ello, me limitar a los aspectos tcnicos 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 legislacin vigente en materia de privacidad y seguridad, lo que acabar afectando a cualquier elemento del servicio relacionado con: Ubicacin 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, segn se definan en la legislacin vigente, que nos comprometen como empresa y para los que hay diversos niveles de sensibilidad- No es lo mismo una nmina que una factura, y ya no digamos datos mdicos de un empleado. Datos propios de la empresa secretos: propiedad intelectual, i+d, frmulas, listas de inversores, Ser una tarea clave la identificacin de estos datos y los controles que deberemos acordar con

LuisCarrasco

13/22

el proveedor para garantizar el cumplimiento, tanto de nuestros requisitos de seguridad como el de los legales. Cul es la ubicacin de los servidores? En la legislacin espaola sobre datos de caracter personal, si los servidores van a estar fuera de las fronteras espaolas aplica el concepto de transferencia internacional de los datos, lo que obliga a comprobar que el pas destino est homologado por las autoridades espaolas como ubicacin aceptable. Actualmente es aceptado cualquier pas del Espacio Econmico Europeo o de aquellos que la Agencia de Proteccin de Datos tiene en su lista de Pases con un nivel adecuado de proteccin. Atencin tambin a los proveedores de nuestro proveedor. Qu tipo de seguridad, fsica, respaldo, procedimientos, acceso a servidores, etc. tiene activada el proveedor? Sin nimo de extenderme en este tema, el proveedor debera poder mostrar qu medidas de seguridad tiene implementadas. Lo ms fcil es que pueda acreditar tales medidas mediante certificaciones del tipo ISO27001, SAS 70 type II o equivalente y que pase las auditoras especficas pertinentes que marcan esas certificaciones. Cmo se accede y viajan los datos? El acceso, presumiblemente va Web, es seguro,va https/SSL o VPN, o equivalente? Se cifran los datos sensibles, que lo requieran, al viajar y ser almacenados? Quin 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 aplicacin 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 autorizacin previa para cualquier subcontratacin o cesin del servicio a un tercero por parte de nuestro proveedor SaaS ) Como nos afecta la legislacin especfica, por ejemplo la LOPD en el caso de Espaa? Es fundamental conocer de acuerdo a la legislacin, 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 lmites y salvaguardas en el tratamiento de los datos: fines de ese tratamiento, como se devolvern y destruirn, etc. y si, los seguramente super-exigentes, abogados del BBVA no ven ningn problema en que informacin 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 seccin de referencias.

GOBIERNO DEL SERVICIO

Si vamos a utilizar una aplicacin 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 gestin y medicin del servicio en el caso de aplicaciones SaaS de gestin.

LuisCarrasco

14/22

Dicho esto, cuando estemos negociando con nuestro proveedor de aplicaciones SaaS de gestin cmo 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 tpica de este tipo de aplicaciones es conveniente conocer los niveles de servicio para las distintas capas tecnolgicas que la conforman: Aplicacin Integracin/Middleware Infraestructuras

que definir tipos de incidencia/consulta, prioridades, etc. Disponibilidad de la aplicacin. Normalmente se expresa en porcentajes de tiempo y excluye los tiempos dedicados a mantenimiento de la plataforma. No olvidar especificar el periodo de medicin 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 aplicacin true SaaS el cliente ni se tiene que enterar de un cambio de versin pero entiendo que la plataforma requerir paradas por mantenimiento. Hay que prestar atencin a tiempos de preaviso y horarios (no es lo mismo no tener disponible la plataforma el da que lanzas la facturacin mensual que no tenerla un domingo) Tiempos de puesta en marcha de nuevas funcionalidades. Si la aplicacin, como debera una True SaaS, permite activar/desactivar funcionalidades, ser conveniente especificar el tiempo de activacin/desactivacin operativa.

En principio los niveles de servicio que ms hemos de controlar directamente son los de Aplicacin. 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 ests cubierto adecuadamente [11] Niveles de servicio por tipo Los niveles de servicio se pueden definir de varios tipos. En este contexto no debera faltar: Rendimiento de la aplicacin. Estos niveles de servicio no es aconsejable que sean genricos y se han de intentar definir para las transacciones que consideremos ms 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 estndares (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 tcnicos. Aparte de estos tiempos hay

Ligados a los procesos de negocio Ya se ha apuntado antes pero lo recalco. Estamos en un contexto de aplicaciones de gestin empresarial. Cualquier parmetro de gestin del servicio/sistema ha de tener como referente los procesos de negocio cuando se traten temas de disponibilidad, horarios, rendimientos, velocidad, tiempos de ejecucin, aunque hemos de ser conscientes del reto que puede suponer para el proveedor trabajar en ese modo. Hay ms 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 gestin. No obstante no nos olvidemos de temas como:

LuisCarrasco

15/22

Ajuste/renegociacin de SLA. Hay que prever la posibilidad de ajustar peridicamente los parmetros que miden la calidad del servicio Monitorizacin. Cmo va el cliente a ver en tiempo real los parmetros de medicin de la calidad del servicio y problemas que puedan haber? Reporting. Forma, periodicidad, formato de la informacin, etc. que el proveedor va a poner a disposicin 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. Cmo incorporar las lecciones aprendidas y el conocimiento adquirido de errores en mejorar la gestin y el servicio

Cmo nos va a medir el uso del sistema nuestro proveedor? Pues mejor temprano que tarde tendremos que conocer bien su modelo de indexacin del servicio, que habitualmente viene dado por uno o una combinacin de los siguientes elementos: N de Usuarios de la aplicacin, ya sean concurrentes (slo cuentan los que estn conectados en un momento dado) o nominales (cuentan se conecten o no pero cuidado con el shelfware! [12]). En el caso de concurrentes tendramos modelos dinmicos 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 espordicamente, otros que utilizan una funcionalidad determinada de forma intensiva, los que se conectan slo para consultar, lo habitual es que se establezcan diferencias a nivel de tarificacin entre estos diferentes tipos de usuario. Por mdulos / funcionalidad activada / desactivada. Es decir por el tipo de uso que se hace de la aplicacin. A considerar en este caso, la facilidad que deberemos requerir de nuestro proveedor para tener una gestin gil de este uso tal como se ha mencionado en el apartado sobre evolucin. 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 nmero de pedidos de clientes entrados, facturas emitidas, clientes a los que se le factura en el mes, o incluso un porcentaje de la facturacin. Consumo de recursos de computacin. Esto, que se lleg a hacer en los albores de

No se me escapa que este punto ha quedado bastante genrico pero es que es un tema muy extenso. He intentado al menos citar los puntos ms importantes.

GESTIN DE COSTES
No puede faltar en este repaso de los puntos clave a considerar al seleccionar una aplicacin 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 aplicacin de gestin. Esta variabilizacin se conseguir al utilizarse un modelo de suscripcin/pago de una cuota peridica 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 gestin de costes:

LuisCarrasco

16/22

la informtica cuando gigantes como IBM te alquilaban ciclos de CPU, no es un modelo que para aplicaciones de gestin tenga mucho sentido ya que es muy poco predecible. No lo veo en un entorno de aplicaciones de gestin pero si alguien tiene una mejor opinin que comente. Adicionalmente tendremos que tener en cuenta que puede haber lmites inferiores (mnimos de uso) y superiores, normalmente asociados a limitaciones por consumo de recursos como ancho de banda, ocupacin disco, consumo de CPU, etc. Concluyendo, est claro que, independientemente del modelo que ofrezca el proveedor, habr que hacer un estudio minucioso de cmo se va a usar la aplicacin y prever que tengamos la capacidad de ir ajustando dinmica y elsticamente nuestras necesidades.

LuisCarrasco

17/22

CONCLUSIN:
En este artculo he intentado hacer una cobertura a alto nivel de todos los puntos que considero claves en la seleccin de una aplicacin de gestin 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 artculo te agradecera su difusin 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 artculo deben considerarse como una gua de partida, una especie de check-list y nunca deberan ser sin ms el nico elemento para tomar una decisin. Si crees que necesitas una ayuda ms adecuada a tus necesidades especficas no dudes en contactarme.

LuisCarrasco

18/22

REFERENCIAS:
[1] How Cloud Computing And ERP Mobility Are Reordering Gartners Hype Cycle for ERP http://softwarestrategiesblog.com/2012/01/02/how-cloud-computing-and-erp-mobility-arereordering-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-andmarket-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 utilizacin de mtodos giles en la implantacin 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 Googles 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-googlecloud(9882-22-101-c-92220).html [9] Varias referencias en relacin a legislacin sobre privacidad de datos
Reforma/actualizacin que propone la Comisin 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 pblica de la Agencia Espaola de Proteccin 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 Gua Cloud del Instituto Nacional de Tecnologas de la comunicacin 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

LuisCarrasco

19/22

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 pases 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] Presentacin en el Internet Global Congress de Barcelona de 2006 sobre herramientas BPM. http://www.slideshare.net/luiscu/13-1-carrasco-delphin-phaq-presentation [13] Encuesta en nodoTIC sobre ERP SaaS disponible en Espaa http://www.nodotic.com/?p=701

LuisCarrasco

20/22

SOBRE EL AUTOR:
Luis Carrasco es Ingeniero de Telecomunicacin por la Universidad Politcnica de Catalua, y Executive MBA por EAE Barcelona. Actualmente es gerente en Delphin Project Hunting, donde, como consultor y project manager, lidera iniciativas para sus clientes de mejoras organizativas, de procesos y sistemas de informacin para la gestin empresarial. Luis es editor de www.nodoTIC.com, blog sobre sobre tendencias en sistemas de informacin de gestin empresarial. Tambin podis encontrarle en diversas redes sociales: http://www.linkedin.com/in/luiscu @nodotic https://plus.google.com/u/0/111838161734108867236/about

LuisCarrasco

21/22

DISCLAIMER:
Este artculo se ha publicado bajo licencia Creative Commons sa-by, lo que bsicamente 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 redaccin de este artculo me he inspirado en mltiples lecturas y he utilizado recursos grficos que he intentado referenciar y atribuir a sus autores. Si crees que hay algo en el artculo que debera ser cambiado, aadido o modificado hzmelo saber.

LuisCarrasco

22/22