...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
                                                                                                                          ...
Upcoming SlideShare
Loading in...5
×

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

1,191

Published on

http://www.nodotic.com/?p=162
https://plus.google.com/111838161734108867236?rel=author
http://www.box.com/s/dtrrbyxbx9kifh0jl72z

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,191
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1.           Michael Heiss http://www.flickr.com/people/michaelheiss/Puntos clave en la selección de aplicaciones de negocio en modelo SaaS / en la nube Presentación descargable en: http://www.nodotic.com/?p=1033 Luis Carrasco  1 / 22 
  2. 2.          Contenidos: Introducción Puntos clave Multi-tenancy Tecnología Inicio del Servicio Evolución del Servicio Fin del Servicio Integración Privacidad Gobierno del Servicio Gestión de Costes Conclusión Referencias Sobre el autorNew York rises de Eugene de Salignacs Luis Carrasco  2 / 22 
  3. 3.          INTRODUCCIÓNMover las aplicaciones de negocio (ERP, CRM, etc.) a la nube (en modo SaaS) es unatendencia en ascenso entre los responsables de las tecnologías de la información en lasempresas 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 yproveedores, pero esta tendencia parece más tímida en nuestro entorno que en otros y es quepor alguna razón aquí siempre somos más precavidos en lo de introducir cambios, por decirloamablemente, o quizá no haya aún una oferta suficiente [13].Ciertamente es comprensible que los responsables de llevar a cabo e impulsar este tipo deinnovaciones en las empresas tengan muchas y serias dudas, dado el riesgo (nonecesariamente mayor que continuar igual, todo sea dicho) que puede suponer un cambioestratégico de ese calibre en la gestión de la información de sus empresas, pero como estoyplenamente convencido de que es cuestión de poco tiempo que el modelo dominante de tenertu ERP, CRM etc. in house se quede obsoleto (*) y con el ánimo de contribuir, en la medida demis modestas posibilidades, a romper, mediante información, transparencia y debate, esosmiedos y dudas, me he decidido a escribir este artículo sobre qué es lo que hay que saberantes 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. Luis Carrasco  3 / 22 
  4. 4.          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 lascapacidades 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 sinotambién también para que proveedores de aplicaciones y servicios comprueben que su ofertaes 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 primerosvisionarios de lo que ahora se ha venido a llamar Cloud Computing,que explica en varios desus libros y artículos como principios del siglo XX las empresas industriales tenían sus propiosgeneradores eléctricos y pozos de agua in house y que al extenderse las redes de distribuciónde electricidad y agua se cambiaron a la Energía y Agua as a Service. Modelo que ahora, salvocontadísimas excepciones, vemos como el único racional y sostenible. Luis Carrasco  4 / 22 
  5. 5.           red local a través de Internet, y el paquete seMULTI-TENANCY vendía en forma de acceso por usuario.Empiezo con el punto que considero crucial a la Entre las razones técnicas por lo que este modelohora de decantarnos por un determinado fracasó, operativa y económicamente, se puedenproveedor de aplicaciones de negocio SaaS ya contar:que de alguna manera abarca, o es consecuencia,del resto de puntos clave que se comentan en el • Velocidad y disponibilidad de Internetresto del artículo: el multi-tenancy. en esa época. • La arquitectura física con la que seEn una primera aproximación se podría definir que habían diseñado esas aplicaciones nouna aplicación de gestión SaaS es Multi-tenancy escalaba ni soportaba bien compartirsi: infraestructuras físicas en el lado servidor. • Puede ser compartida por diferentes clientes. Era ineficiente en el aprovechamiento de • Es capaz de adaptarse y evolucionar con los recursos hardware y software (la diferentes requerimientos de cada cliente. virtualización de servidores era una • Y al mismo tiempo ser viable, técnica y tecnología incipiente, de laboratorio económicamente, para el proveedor. prácticamente) y el hardware era caro en esos años.Estos requisitos veremos más adelante que • La arquitectura del software no estabacondicionan fuertemente la arquitectura pensada para ser compartida portecnológica de una aplicación SaaS y el modelo compañías diferentes. Los datos y tablasde negocio del proveedor quizá sí (o ni eso) pero una configuración del software para necesidades específicasPara entender este concepto fundamental es de una compañía no se podía hacernecesario conocer los antecedentes a los actuales estanca al resto, por lo que se podíanmodelos SaaS, los ASP o Application Service producir colisiones o incompatibilidadesProviders que en los 90 llegaron a tener cierta entre ellas. Las modificaciones que sobrenotoriedad o Hype como se dice ahora. una arquitectura ya desarrollada tenían que hacerse, complicaban más aún elLa visión de negocio de los ASP era la misma que entorno y lo podían hacer ingestionablepueden tener los actuales modelos SaaS pero el técnicamente por el proveedor.estado de la tecnología y madurez de lasempresas que se podrían haber beneficiado no lo • La evolución del software podía ser en laera. Por ejemplo, uno trivial, la velocidad y práctica inviable. O todos los clientes sedisponibilidad de las líneas de comunicaciones, o coordinaban para cambiar de versión a lala disposición de las empresas a sacar sus centros vez o no se podía, lo que derivó en que elde datos fuera de sus paredes (algo a lo que ahora software se quedase atascado en unaestán más predispuestas en general). versión o en que se tuviesen que separar instalaciones por versión – algoEn muchos casos, el concepto ASP acababa en antieconómico y a medio plazoque una aplicación cliente-servidor, diseñada y insostenible.construida para ser desplegada dentro de una red • Al haber mucha lógica, incluso datos, en lalocal corporativa, se habilitaba para que su parte parte cliente, el despliegue yservidor pudiera ser accesible desde fuera de la mantenimiento homogéneo de cualquier Luis Carrasco  5 / 22 
  6. 6.           implantación compartida era una tarea ¿Qué tiene que hacer el cliente si se actualiza muy costosa porque había que actualizar la versión del software? Los clientes no se software en cada estación de trabajo deberían preocupar de tener que actualizar el software, para ellos debería ser transparente, enEn conclusión, para que una aplicación de un extremo ni enterarse. Así la actualización esgestión sea viable en modo SaaS, debe ser para todos los clientes a la vez y cualquiercapaz de poder conseguir economías de escala configuración específica del cliente no deberíaal compatibilizar el que los clientes puedan condicionar el poder actualizar el software al restocompartir los costes fijos (infraestructuras, – ¿Podrías hacer mañana mismo un cambio deimplantación, soporte, mantenimiento, des- versión sin avisar a tus clientes?implantación, etc.), cubrir las necesidadescomunes y específicas de esos clientes y al ¿Con qué periodicidad se actualiza elmismo tiempo poder evolucionar para software? No debería haber versiones en elacomodarse a los cambios en esas sentido tradicional sino frecuentes mejorasnecesidades de cada uno. Es decir que sea incrementales (un ejemplo serían las aplicacionesMulti-tenancy. de Google) – ¿Cuántos cambios de versión/upgrades/mejoras has hecho en el últimoAfortunadamente esta posibilidad llegó de la mano año?de avances tecnológicos como la virtualización,seguridad, velocidad y ubicuidad de líneas, ¿Cómo va a cubrir la aplicación misnavegadores rápidos y capaces de incorporar requerimientos funcionales clave [elíjanselógica de forma estándar -no propietaria- en local, varios cuidadosamente] y que son específicosentornos y metodologías de desarrollo más de mi compañía/negocio/sector? Si el proveedoravanzados, etc. que permitieron desarrollar contesta que debe adaptar/cambiar el software esproductos con arquitecturas tecnológicas que probable que éste ya no sea una opción adecuadaposibilitaban el Multi-tenancy y desplegar modelos (al menos en modo SaaS) para el cliente. DeTrue SaaS. alguna forma la arquitectura de la aplicación debe estar construida de forma que se puedan¿Y como podemos verificar con nuestro proveedor diferenciar las diferentes compañías cliente en elque su aplicación de gestión es Multi-tenancy y momento de ejecución de la aplicación. En losevitar así que en realidad acabemos contratando modelos ASP esto se conseguía con el código deuna aplicación tradicional en hosting, o lo que es lo compañía/unidad organizativa, pero unmismo que seamos un Single-tenancy más en sus modeloTrue SaaS debe ir más allá, coninfraestructuras? codificaciones que permitan que en modo de ejecución la aplicación pueda distinguir entrePues deberemos hacerle preguntas como: compañías clientes, hacer uso de clusters o agrupaciones de unidades organizativas por¿Todos los clientes están en la misma versión compañía cliente o por criterios de localizacióndel software? Todos los clientes deberían correr geográfica para temas de normativas locales porla misma versión del código, sin “customizaciones” ejemplo.de código. De esta forma cualquier configuraciónpropia del cliente no acabará afectando al resto de Con estos requisitos, en mi modesta opinión, veoclientes ni, a su vez, se verá afectada por muy difícil, por no decir imposible, que unapersonalizaciones de código del resto de clientes - aplicación que no ha sido técnicamente¿Cuánto se tarda en hacer un cambio de versión? diseñada y concebida desde cero con un enfoque de ser Multi-Tenancy, pueda serlo, ya Luis Carrasco  6 / 22 
  7. 7.          que las modificaciones a posteriori que una • Conectividad. Será más fácil acceder a laaplicación tradicional requiera para ser Multi- aplicación desde cualquier ubicación contenancy acabarán haciéndola compleja y costosa acceso a Internet.de gestionar y mantener, es decir inviable • Facilidad de despliegue. En laeconómicamente. implantación no se debería tener que invertir en hardware de terminal de usuario niEn conclusión, hay que prestar atención a los tiempo de instalación.provedores con productos tradicionales • Facilidad de evolución. La aplicación podráreetiquetados como SaaS que realmente no son evolucionar desde el lado de servidor sinMulti-tenancy. tener que actualizar nada en los clientes – facilitando así al proveedor el mantener una versión única de su aplicación para todosTECNOLOGÍA sus clientes Un tema colateral importante aquí es laComo ya se ha comentado anteriormente, la conectividad de dispositivos locales comotecnología ha desempeñado un importante papel impresoras, PLCs, sensores industriales, etc. peroen el desarrollo viable de los modelos SaaS por lo lo trataremos en el punto de integración.que, para asegurarnos que nuestro proveedorSaaS tiene un modelo de negocio sostenible, es Escalabilidad de la plataforma tecnológicaimportante poder contrastar con él cosas como: Hemos de partir de la premisa de que la plataforma tecnológica en la que estará alojada laAcceso con Browser as a Platform. El acceso a aplicación SaaS será compartida y deberá poderla aplicación debería poder hacerse sin necesidad crecer de forma más o menos lineal según el usode instalaciones de software específico en local o que le de la propia empresa y las empresasal menos que el proceso de instalación y vecinas. Parece pues muy razonable interesarnosactualización se automatice de forma que sea por las herramientas y tecnologías que eltransparente para el usuario (aunque entonces proveedor va a utilizar para asegurarnos esahabrá que gestionar los permisos en las escalabilidad. Concretamente habría queestaciones de trabajo, algo que en determinadas preguntarle por temas como:organizaciones puede ser un impedimentoimportante) • Qué productos/tecnologías va a utilizar para gestionar su plataforma Cloud:Lo habitual, y en mi opinión mejor opción, es que virtualización, despliegues de aplicacionessea a través de un navegador estándar (mejor (nuevos clientes y/o versiones/parches),que no se dependa de uno en concreto) con AJAX, creación de nuevos entornos/instancias,HTML5 y como máximo algún plug-in tipo ActiveX, gestión de los cambios de versión deApplet. También es de esperar que avances productos base (sistema operativo, bases derecientes en protocolos a nivel de aplicación como datos, …), sincronización entre entornos deSPDY y Web Sockets de HTML5 mejoren desarrollo, test y producción, compaginarlatencias y rendimiento de los actuales protocolos instalaciones compartidas con dedicadas,HTTP… pero esto ahora está saliendo etc.tímidamente de los laboratorios. • Si la plataforma física es propia o de un tercero proveedor de PaaS (Force.com,De esta forma se consigue: Google App por ejemplo) o IaaS (Amazon AWS, Microsoft Azure, IBM, etc.). Este punto, Luis Carrasco  7 / 22 
  8. 8.           además tiene relevancia a efectos legales, inestabilidad del entorno por el cambio como veremos más adelante. continuo, … ¿Qué tecnologías va a utilizar el • Si dispone de herramientas o tecnologías proveedor para garantizar el rendimiento de específicas para la gestión de grandes la plataforma, velocidad de las líneas, uso volúmenes de datos o cómo va a asegurar de recursos de CPU, …? De la misma forma la escalabilidad de un entorno de datos que que con la escalabilidad de datos, las al ser compartido va crecer más y de forma estrategias y arquitecturas tecnológicas que menos previsible de lo que lo hace en un se han venido utilizando en instalaciones escenario no compartido. Sin llegar a los single-tenancy es probable que no sean las extremos de tener que disponer de más adecuadas. tecnologías de Big Data pero creo que no • Seguridad física. ¿Cómo se controla el vale el enfoque por el que se optaría en una acceso físico a las instalaciones?, ¿Quién instalación monocliente (el Multy-tenancy tendrá acceso?, ¿Sistemas de aparece otra vez) al ser potencialmente un vigilancia/registro/grabación?, … entorno menos predecible y planificable. • Monitorización. ¿Cómo va a controlar el proveedor el rendimiento y disponibilidad deDisponibilidad y seguridad física de la la plataforma? Lo mejor es que el proveedorplataforma tecnológica pueda enseñaros su centro de control y queTeniendo en cuenta que al ser una aplicación de os explique qué herramientas de control ynegocio vamos a utilizar la plataforma tecnológica gestión de alarmas utiliza y cómo os vais adel proveedor para gestionar nuestras operaciones enterar si hay una incidencia. Volveremoses obvio que tenemos que asegurarnos de que sobre esto en el punto de gestión delesta plataforma va a estar disponible cuando la servicio.necesitamos. Es por eso que nos deberá interesarconocer: Seguridad de Datos Los datos de clientes, sus pedidos, la información • Contingencia. ¿Qué pasa si hay una de tu inventario, la facturación… toda esta incidencia que hace que las instalaciones (o información no se puede perder; en general, no la parte de ellas) donde residen las puede ver cualquiera y en algún caso la empresa infraestructuras dejan de estar operativas o está obligada a protegerla. Se ha de tener claro al incluso son destruidas?, ¿Cómo lo ha menos: previsto el proveedor y cómo se integra en nuestra estrategia de recuperación del • ¿Cómo se gestionan las copias de negocio en caso de desastre (tiene un seguridad: Periodicidad (diaria, cierre de Disaster Business Recovery Plan)?, ¿Hay periodo/ejercicio, …), quién lo hace, dónde redundancia de equipamientos como líneas se gestionan/almacenan las copias, control de comunicaciones, alimentación de acceso,…? eléctrica, generador/grupo electrógeno, • ¿Cómo es la sincronización con posibles etc.?, ¿Dispone el proveedor, o nosotros, de centros de respaldo? una instalación de respaldo alternativa • ¿Se cifra la información sensible (más sobre para el caso de un desastre total, y en ese esto en el punto sobre privacidad)? caso cómo se efectuaría la transición?, ¿y la • ¿Cómo se controla el acceso a la aplicación, sincronización de datos entre a la base de datos, etc. tanto accediendo instalaciones principal-respaldo? desde dentro como desde fuera del • Rendimiento ante picos de actividad, firewall/perímetro de seguridad? algunos predecibles y otros no, Luis Carrasco  8 / 22 
  9. 9.           • ¿Se registra/audita la actividad de acceso a • Haya disponibilidad de herramientas de datos? Qué, quién y cuándo se carga, depuración, comparación, etc. de modifican/leen/borran los datos datos orientadas a acelerar la migración y • ¿Cómo se asegura que otros clientes no ven conversión de información y la gestión de mis datos? paralelos. • etc. no me extiendo más en este punto • Se utilicen Metodologías de puesta en porque entiendo que hay disponible marcha ágiles [5], colaborativas, iterativas, abundante documentación al respecto. etc con entornos preconfigurados para la captura rápida e incremental de requisitos,Green/Eficiencia Energética aprender pronto para ajustar también pronto,Y para empresas con sensibilidad y disponer de funcionalidades que esténresponsabilidad social, ¿por qué no preguntar por operativas de forma rápida y poder irlas políticas de eficiencia energética y prácticas de afinándolas en ciclos cortos también.protección del medio ambiente, etc.? Aunque sea • La Configuración (set up de entorno,sólo sea por el interés propio en que el proveedor seguridad, alta de usuarios, etc.) sea rápida,reduzca sus gastos operativos para dar un servicio con asistentes (tipo siguiente-siguiente) ycompetitivo y sostenible – hay informes [4] que aceleradores tales como un catálogo deindican que entre un tercio y la mitad de los costes plantillas de procesos sectoriales yoperativos de un centro de proceso de datos horizontales ya preconfigurados, opcionescorresponden a la factura de energía. de activación/desactivación de funcionalidades pre-existentes a demanda, etc.INICIO DEL SERVICIO • La puesta en marcha la puedan liderar usuarios no técnicos (a.k.a. de negocio) noUno de los atractivos de utilizar un modelo SaaS necesariamente expertos de producto.pasa por la premisa de que en general todo tieneque ser más rápido y sencillo. Es una hipótesis Se podrá objetar y con razón, que excepto elde partida porque de no ser así el modelo no es primero, los anteriores puntos no tienen por quésostenible ni viable y debemos, por tanto, prestar ser exclusivos de un modelo SaaS. Cierto pero,atención a todos los elementos que nuestro ¿no es verdad que suenan a ciencia ficción en elproveedor pueda aportar en este sentido. caso de los productos tradicionales? – ¿por qué debería ser diferente en el caso de un modeloRapidez y sencillez en que: SaaS? Pues se me ocurren al menos dos razones: • No sea necesario realizar instalaciones de • Ya lo he comentado al principio, si no es así infraestructura hardware y software en las el modelo SaaS no se aguanta, por lo que instalaciones de la empresa, lo que ya de si un proveedor no nos está ofreciendo este entrada debería acortar el tiempo de puesta tipo de facilidades hay que verificar muy bien en marcha y eliminar las necesidades el coste-beneficio que esperamos obtener. adicionales (espacio, seguridad, • Estos elementos deberían ser más climatización,… por ejemplo) para acomodar fácilmente exigibles a una aplicación SaaS nuevas infraestructuras o instalaciones verdadera que a una tradicional ya que, locales de software en los equipos de como ya se comentó anteriormente en el usuario. punto de Multi-tenancy, su arquitectura ya Luis Carrasco  9 / 22 
  10. 10.           debería haberse diseñado incluyendo plantillas de procesos sectoriales y estas premisas y requerimientos. horizontales que puedan ser desplegadas por usuarios no técnicos, activación y desactivación de funcionalidades pre-EVOLUCIÓN DEL SERVICIO existentes a demanda y con un Sandbox para pruebas para así no afectar al sistemaDentro de los puntos clave no podía faltar el en producción.relativo a asegurar la evolución adecuada delservicio que esperamos recibir una vez puesto en Todos estos puntos no son exclusivos de unamarcha dicho servicio, o dicho de otra forma, de la aplicación SaaS evidentemente pero es de esperarelasticidad de la aplicación para adaptarse a que sean más asequibles que en las aplicacioneslas necesidades cambiantes que seguro va a tradicionales por lo ya mencionado anteriormentetener nuestra empresa. de que la arquitectura de la aplicación SaaS ya debería haber sido diseñada con estasPor eso deberemos pedirle al proveedor de la consideraciones.aplicación información sobre: Escalabilidad/rendimiento de infraestructuras:Evolución de funcionalidades: Hay que considerar que al ser un modelo SaaSCómo nos va a asegurar el proveedor que su vamos a tener que compartir las infraestructurasaplicación evoluciona tecnológica y funcionalmente con otras empresas. Debemos por tantocon el mercado/sector y con nuestras necesidades asegurarnos de conocer qué medios, tecnologías,específicas. Concretamente: metodologías, etc. tiene el proveedor para acomodar picos en el número de transacciones en • Qué plan de producto, road map, tiene el sistema, ya sean las previsibles (por ejemplo establecido: módulos, funcionalidades cierres de mes, facturaciones masivas mensuales, nuevas, etc. Atención a la frecuencia de etc.) como las no previstas (un nuevo cliente por actualización que, como ya se mencionó en ejemplo). la entrada de esta serie correspondiente a Multi-tenancy, debería ser mayor que la de Otra vez hay que recordar que tenemos que estar una aplicación tradicional. seguros que el modelo tecnológico del proveedor es sostenible y viable, no sólo desde • Qué garantías nos da de adaptación a el punto de vista tecnológico sino también desde cambios a la legislación vigente, algo el punto de vista económico. especialmente importante en aplicaciones financieras y de RRHH. A nadie le va a gustar que se caiga el sistema, o • Respecto a la evolución de las vaya lento, porque la empresa de al lado ha funcionalidades específicas de nuestra lanzado su proceso de facturación mensual o el empresa (ya sea mantenimiento evolutivo o proveedor entre en riesgo de quiebra por las despliegue de nuevos módulos y/o inversiones que tiene que realizar para funcionalidades) hay que pedir que, como se acomodarse al volumen de transacciones que trae comentó en la entrada correspondiente al un nuevo cliente. Por eso modelos de inicio del servicio, pueda ser liderado por la infraestructura elásticos basados en IaaS de propia empresa, preferentemente por terceros serán recomendables en principio ya que usuarios del negocio -sin dependencias de permitirán esa escalabilidad de forma lineal personal del área de IT, por ejemplo (aunque no olvidemos los temas legales, como se mediante la disponibilidad de un catálogo de Luis Carrasco  10 / 22 
  11. 11.          comentará posteriormente en el punto Aunque la empresa cliente tendrá accesocorrespondiente a privacidad) restringido a las infraestructuras y depende en última instancia del proveedor para que leEscalabilidad de usuarios: entregue sus propios datos, no se debería aceptarOtro elemento a atar en corto es cómo se gestiona ninguna restricción por parte del proveedor ael crecimiento y decrecimiento de usuarios de la acceder a tus datos en cualquier momento.aplicación para acomodarse a la dinámica de laempresa. Un ejemplo extremo sería el de una Por supuesto que debe haber reglas (seguridad deempresa sujeta a una alta temporalidad, donde en acceso, formatos, tiempos de preaviso, etc.) perola temporada alta sube el número de usuarios. es un derecho inalienable del cliente el poder extraer su información cuando la necesite y lasDebemos por tanto tener controlados aspectos facilidades que éste tenga van a ser uncomo: indicador inestimable de la bondad del proveedor y de su aplicación. • Como varían los costes según el nº de usuarios (me extenderé más sobre esto en El tema se puede complicar si además hay una el punto correspondiente a costes) externalización de procesos (BPO) donde los procesos son efectuados directamente por el • Facilidad de replicar/desactivar usuarios, propio proveedor ya que entonces será más difícil roles, etc. No tendría mucho sentido en un para el cliente conocer la estructura en detalle de entorno dinámico y ágil, como el que se los datos que se quiere llevar. supone que es un entorno SaaS, que poner en marcha un nuevo usuario sea costoso. Concretamente, habrá que averiguar del proveedor qué plan de salida ofrece en caso deY es que nunca hemos de perder de vista que si cese del servicio, con especial atención a:estamos barajando una aplicación SaaS es porquenos preocupa, entre otras cosas, la elasticidad de • Formato de los datos para su portabilidad.la solución, tanto para crecer como para Archivos planos, Exports de tablas de lasdecrecer. bases de datos, … un tema bastante tecnológico que deberá conocerse bien paraFIN DEL SERVICIO identificar las posibles limitaciones que pudiera haber. • Punto de corte: es decir en qué momentoEn la Salida o Finalización del Servicio es se hace la foto de los datos para sufundamental que nos aseguremos de la facilidad y portabilidad. Una posibilidad, para estarrapidez de salida en el caso en que haya seguros de que el conjunto de datos esproblemas, y así no quedarte atrapado por tu coherente, es pedir una copia de seguridadproveedor [6]. Este punto está bastante estudiado portable en cada cierre de periodo. En(vendor lock-in le llaman en la literatura teoría, al menos a nivel de datos, serás libreespecializada) y es una de los puntos que más se de irte al final de cada periodo con uncitan como impedimentos y reticencias a los conjunto coherente de datos.modelos SaaSA mi parecer, se ha de tener en cuenta:Control y portabilidad de los datos: Luis Carrasco  11 / 22 
  12. 12.          Control y portabilidad de la aplicación: alguna manera, está basada o respaldada porSi el proveedor quiebra o desaparece, o algún tipo de herramienta BPM, que implementesimplemente decido irme, ¿podré llevarme la definiciones de los procesos en formatosaplicación y los datos a otro sitio? ¿Lo puedo fijar estandarizados tipo BPEL, BPMN, XPDL, etc.por contrato? Estas preguntas son de difícilrespuesta en según que casos, sobre todo si el De esta manera, al menos en teoría, se podríansoftware es propietario (o la tecnología en la que importar la definición de los procesos a otrasfue desarrollado) y desde luego no es algo aplicaciones de la misma manera que sehabitualmente previsto en los contratos que se ven importarán los datos. Soy consciente de que estapor ahí (no me lo imagino con gigantes como posibilidad es, a día de hoy, remota por el estadoSalesforce.com o NetSuite por ejemplo). A este de madurez de las herramientas BPM [13] pero norespecto pues y en principio, será interesante la descartaría a medio plazo.poder optar por aplicaciones Open Source opropietarias con derecho a descarga ymodificación de los fuentes para uso exclusivo de INTEGRACIÓNla empresa cliente. Es muy probable que la aplicación SaaS queConocimiento queramos poner en marcha no sea la única de lasAdicionalmente tendremos que considerar no sólo aplicaciones de la empresa y que necesitemosla disponibilidad/portabilidad de la aplicación. interconectarlas e integrarlas entre ellas.Tener la aplicación no basta, hay que tener losrecursos y el conocimiento (nosotros o terceros) La dificultad adicional que tenemos quepara que funcione. gestionar es que la aplicación SaaS va a estar en un entorno que no está siendo gestionadoEs por esto que aunque deleguemos totalmente la por nosotros, por lo que se añadengestión de aplicación en el proveedor SaaS, complejidades de índole técnica y operativamantengamos personas dentro de nuestra que no se pueden desdeñar: necesidad deorganización con el conocimiento necesario para traspasar un firewall que se supone muy exigentegestinar, aunque sea temporalmente y bajo de un tercero, no control de las ventanasmínimos, la aplicación hasta que finalice la temporales y mecanismos de integración si ésta estransición a otro proveedor/aplicación. asíncrona o batch, restricciones de seguridad y técnicas a la hora de hacer una integración enCondiciones y operativa de salida tiempo real, rigideces en formatos deEs decir fechas de preaviso, posibles archivos/mensajes de integración,etc.penalizaciones y calendarios mínimos (que habráque acabar de negociar durante la negociación del Concretando, deberemos tener en cuentacontrato), coste de servicios adicionales en caso elementos como:de ser necesarios, etc. No me extenderé sobrealgo que está bastante explicado [6] Integración con aplicaciones externas Tales como una Web de ventas, aplicación deY para rizar el rizo, ¿Por qué no intentar la nómina, herramientas de BI y/o reporting, EDI, …Portabilidad de Procesos? para las que como ya se ha mencionado antes hayEn la práctica consiste en poder llevarte contigo la restricciones operativas y técnicas que dificultan ladefinición de los procesos de negocio soportados integración. Hay que enterarse muy bien de laspor la aplicación, que sólo será posible si ésta, de vías estándar como APIs, Web Services, herramientas, metodologías, etc. que el proveedor Luis Carrasco  12 / 22 
  13. 13.          va a poner a nuestra disposición para facilitarnosesta integración desde y hacia fuera de su firewall. PRIVACIDADCon ofimática Llegamos al tema, nada trivial por los aspectosHay que rendirse a la evidencia de que los legales y de procedimiento que hay detrás, de lausuarios trabajan con archivos de ofimática de seguridad y privacidad. Vaya por delante queforma intensiva y que cada vez más a las trasciende el propósito de este artículo hacer unaaplicaciones de negocio se les requiere trabajar descripción exhaustiva de la legislación que debecon información no estructurada, como los aplicarse, y como no tengo la formación ni ladocumentos ofimáticos, integrada con la experiencia en temas legales requerida para ello,transaccional propia de la aplicación. Y hemos de me limitaré a los aspectos técnicos y operativos ytener en cuenta que los documentos normalmente a proporcionar una lista de elementos a contrastarestán/salen de la red local, del equipo de usuario o con el proveedor, que he podido recopilar.de un gestor documental, y que muchas vecesesos documentos son pesados, lo que va a Dicho de forma muy sintetizada: hay quesuponer un reto para el ancho de banda disponible asegurarse de que nuestros datos sensiblesy el rendimiento en general de la aplicación. Otra (entendiendo como sensibles, datos de tipoopción, que me parece muy interesante, es la de personal o los propios secretos de la empresa)usar ofimática en la nube. En ese sentido apunta van a ser almacenados y tratados de una formala decisión de SAP de integrar SAP Business que se cumpla la legislación vigente en materiaByDesign con las aplicaciones de negocio de de privacidad y seguridad, lo que acabaráGoogle [7] afectando a cualquier elemento del servicio relacionado con:Dispositivos locales:Como impresoras, PLCs/Sensores en entornos • Ubicación de los datosindustriales, controles de presencia, etc. • Seguridad de acceso y almacenamientoTendremos que verificar cuidadosamente los • Tratamiento automatizadorequerimientos técnicos de estos equipos paraestar integrados con la aplicación SaaS en Concretamente, tendremos que comprobar (y quecuestión. Si por esta razón se han de cambiar se refleje de alguna manera en el contrato con elequipos, el Business Case de la operación se proveedor) al menos lo siguiente:puede resentir. ¿Realmente nuestro proveedor SaaS va tenerHemos de ser consciente pues que una báscula que almacenar/tratar datos sensibles?que vuelca datos al ERP, una impresora de código Datos personales, según se definan en lade barras o térmica, un PLC controlado desde el legislación vigente, que nos comprometen comoERP, etc. pueden ser dispositivos más empresa y para los que hay diversos niveles decomplicados de integrar en un entorno Cloud. sensibilidad- No es lo mismo una nómina que una factura, y ya no digamos datos médicos de un empleado. Datos propios de la empresa “secretos”: propiedad intelectual, i+d, fórmulas, listas de inversores,… Será una tarea clave la identificación de estos datos y los controles que deberemos acordar con Luis Carrasco  13 / 22 
  14. 14.          el proveedor para garantizar el cumplimiento, tanto Obviamente tendremos que conocer hasta el finalde nuestros requisitos de seguridad como el de los la cadena de proveedores y tenerlo en cuenta enlegales. el contrato (por ejemplo que sea necesaria la autorización previa para cualquier subcontratación¿Cuál es la ubicación de los servidores? o cesión del servicio a un tercero por parte deEn la legislación española sobre datos de caracter nuestro proveedor SaaS )personal, si los servidores van a estar fuera de lasfronteras españolas aplica el concepto de ¿Como nos afecta la legislación específica, por“transferencia internacional” de los datos, lo que ejemplo la LOPD en el caso de España?obliga a comprobar que el país destino está Es fundamental conocer de acuerdo a la“homologado” por las autoridades españolas como legislación, el responsable último es siempre laubicación “aceptable”. Actualmente es aceptado empresa, por lo que se deberá acotar muy bien encualquier país del Espacio Económico Europeo o el contrato, aparte de todo lo mencionadode aquellos que la Agencia de Protección de Datos anteriormente, los límites y salvaguardas en eltiene en su lista de Países con un nivel adecuado tratamiento de los datos: fines de ese tratamiento,de protección. Atención también a los como se devolverán y destruirán, etc.proveedores de nuestro proveedor. …y si, los seguramente super-exigentes,¿Qué tipo de seguridad, física, respaldo, abogados del BBVA no ven ningún problema enprocedimientos, acceso a servidores, etc. tiene que información tan sensible como la que manejanactivada el proveedor? los empleados del banco esté en la nube…[8] quéSin ánimo de extenderme en este tema, el podemos decir aquí.proveedor debería poder mostrar qué medidas deseguridad tiene implementadas. Lo más fácil es Para acabar este apartado, recomiendo la lecturaque pueda acreditar tales medidas mediante de las referencias [9] respecto a privacidad que secertificaciones del tipo ISO27001, SAS 70 type II o relacionan en la sección de referencias.equivalente y que pase las auditorías específicaspertinentes que marcan esas certificaciones. GOBIERNO DEL SERVICIO¿Cómo se accede y “viajan” los datos?¿El acceso, presumiblemente vía Web, es Si vamos a utilizar una aplicación en modo SaaS –seguro,vía https/SSL o VPN, o equivalente? ¿Se Software as a Service - tendremos que gestionarcifran los datos sensibles, que lo requieran, al ese as a Service y la manera habitual de gestionarviajar y ser almacenados? cualquier servicio externalizado es mediante acuerdos sobre la calidad del servicio que¿Quién puede acceder y tratar los datos espera recibir el cliente del proveedor o, en lasensibles? jerga del sector, SLAs [10] (Service LevelAparte del proveedor principal, ¿hay Agreement) ligados a la QoS (Quality of Service).subcontratados o terceros que pueden acceder y/otratar nuestros datos? Esta entrada no pretende cubrir en detalle qué es un SLA ni como se negocia/acuerda, hay muchaDebe tenerse en cuenta que es posible que literatura, y buena, disponible, sino en los puntosnuestro proveedor SaaS esté utilizando recursos e particulares que pueda tener la gestión y medicióninfraestructuras de terceros, por ejemplo una del servicio en el caso de aplicaciones SaaS deaplicación que corra en los servidores de Amazon. gestión. Luis Carrasco  14 / 22 
  15. 15.          Dicho esto, cuando estemos negociando con que definir tipos de incidencia/consulta,nuestro proveedor de aplicaciones SaaS de prioridades, etc.gestión cómo se va a gestionar,medir y gobernar • Disponibilidad de la aplicación.el servicio que nos quiere vender, tendremos que Normalmente se expresa en porcentajes deatender, al menos, a los siguientes puntos: tiempo y excluye los tiempos dedicados a mantenimiento de la plataforma. No olvidarNiveles de servicio por capas. especificar el periodo de medición de esa disponibilidad (no es lo mismo el 99,9% deTeniendo en cuenta la arquitectura típica de este disponibilidad mensual que anual).tipo de aplicaciones es conveniente conocer los • No disponibilidad del servicio porniveles de servicio para las distintas capas mantenimiento. Ya sé que se ha dichotecnológicas que la conforman: antes que en una aplicación true SaaS el cliente ni se tiene que enterar de un cambio • Aplicación de versión pero entiendo que la plataforma • Integración/Middleware requerirá paradas por mantenimiento. Hay • Infraestructuras que prestar atención a tiempos de preaviso y horarios (no es lo mismo no tener disponibleEn principio los niveles de servicio que más hemos la plataforma el día que lanzas la facturaciónde controlar directamente son los de Aplicación. mensual que no tenerla un domingo)El resto pueden ser relevantes si hay terceros • Tiempos de puesta en marcha de nuevasproveedores, por ejemplo en la capa de funcionalidades. Si la aplicación, comoinfraestructuras. Y si ese es el caso leer bien los debería una True SaaS, permiteSLAs ofrecidos por ese tercero no vaya a ser que activar/desactivar funcionalidades, seráno estés cubierto adecuadamente [11] conveniente especificar el tiempo de activación/desactivación operativa.Niveles de servicio por tipo Ligados a los procesos de negocioLos niveles de servicio se pueden definir de variostipos. En este contexto no debería faltar: Ya se ha apuntado antes pero lo recalco. Estamos en un contexto de aplicaciones de gestión • Rendimiento de la aplicación. Estos empresarial. Cualquier parámetro de gestión del niveles de servicio no es aconsejable que servicio/sistema ha de tener como referente los sean genéricos y se han de intentar definir procesos de negocio cuando se traten temas para las transacciones que consideremos de disponibilidad, horarios, rendimientos, más importantes – por ejemplo tiempo que velocidad, tiempos de ejecución,… aunque se tarda en finalizar la entrada de un pedido hemos de ser conscientes del reto que puede de cliente. Es recomendable que cada suponer para el proveedor trabajar en ese modo. empresa revise su caso particular y no acepte por defecto las estándares (si las Hay más elementos a tener en cuenta a la hora de hubiere, que es poco probable). Otro tema negociar los SLAs pero no veo que tengan es como se mide. particularidades relevantes con respecto a un • Tiempos/calidad de respuesta al soporte. SaaS de aplicaciones de gestión. No obstante no Tiempos relacionados con consultas, nos olvidemos de temas como: incidencias, etc. de los usuarios finales o de los técnicos. Aparte de estos tiempos hay Luis Carrasco  15 / 22 
  16. 16.           • Ajuste/renegociación de SLA. Hay que ¿Cómo nos va a medir el uso del sistema prever la posibilidad de ajustar nuestro proveedor? periódicamente los parámetros que miden la calidad del servicio Pues mejor temprano que tarde tendremos que • Monitorización. ¿Cómo va el cliente a ver conocer bien su modelo de indexación del en tiempo real los parámetros de medición servicio, que habitualmente viene dado por uno o de la calidad del servicio y problemas que una combinación de los siguientes elementos: puedan haber? • Nº de Usuarios de la aplicación, ya sean • Reporting. Forma, periodicidad, formato de concurrentes (sólo cuentan los que estén la información, etc. que el proveedor va a conectados en un momento dado) o poner a disposición del cliente para el nominales (cuentan se conecten o no – seguimiento de la calidad del servicio. ¡pero cuidado con el shelfware! [12]). En el • Penalizaciones/incentivos si las caso de concurrentes tendríamos modelos expectativas no se cumplen o se cumplen dinámicos donde se pueden conectar todos mejor de lo previsto los que quieren y luego te facturan o con un • Mecanismos para la mejora continua. tope, donde si éste es “n”, el usuario “n+1″ Cómo incorporar las lecciones aprendidas y que se quiera conectar no puede. el conocimiento adquirido de errores en • Tipos de usuario: No todos los usuarios mejorar la gestión y el servicio son iguales. Por ejemplo los hay que utilizan todas las funciones, intensiva oNo se me escapa que este punto ha quedado esporádicamente, otros que utilizan unabastante genérico pero es que es un tema muy funcionalidad determinada de formaextenso. He intentado al menos citar los puntos intensiva, los que se conectan sólo paramás importantes. consultar, … lo habitual es que se establezcan diferencias a nivel de tarificación entre estos diferentes tipos deGESTIÓN DE COSTES usuario. • Por módulos / funcionalidad activada /No puede faltar en este repaso de los puntos clave desactivada. Es decir por el tipo de uso quea considerar al seleccionar una aplicación de se hace de la aplicación. A considerar ennegocio SaaS, el de los costes. Y es que uno de este caso, la facilidad que deberemoslos atractivos que posiblemente busquemos al requerir de nuestro proveedor para teneroptar por un modelo SaaS es el de variabilizar los una gestión ágil de este uso tal como se hacostes totales de propiedad de la aplicación de mencionado en el apartado sobre evolución.gestión. • Transacciones por periodo. Este modelo puede ser muy ventajoso si se liga aEsta variabilización se conseguirá al utilizarse un transacciones que suponen ingresos ya quemodelo de suscripción/pago de una cuota el coste del servicio se liga al ingreso. Porperiódica relacionada con el uso que se hace ejemplo por número de pedidos de clientesdel sistema y que incluye todo (licencias, entrados, facturas emitidas, clientes a losinfraestructuras, help-desk, nuevas versiones, etc.). que se le factura en el mes,… o incluso un porcentaje de la facturación.Y ese “relacionada con el uso que hace del • Consumo de recursos de computación.sistema“ es clave en toda la gestión de costes: Esto, que se llegó a hacer en los albores de Luis Carrasco  16 / 22 
  17. 17.           la informática cuando gigantes como IBM te alquilaban ciclos de CPU, no es un modelo que para aplicaciones de gestión tenga mucho sentido ya que es muy poco predecible. No lo veo en un entorno de aplicaciones de gestión pero si alguien tiene una mejor opinión que comente.Adicionalmente tendremos que tener en cuentaque puede haber límites inferiores (mínimos deuso) y superiores, normalmente asociados alimitaciones por consumo de recursos como anchode banda, ocupación disco, consumo de CPU, etc.Concluyendo, está claro que, independientementedel modelo que ofrezca el proveedor, habrá quehacer un estudio minucioso de cómo se va a usarla aplicación y prever que tengamos lacapacidad de ir ajustando dinámica yelásticamente nuestras necesidades. Luis Carrasco  17 / 22 
  18. 18.          CONCLUSIÓN:En este artículo he intentado hacer una cobertura a alto nivel de todos los puntos queconsidero claves en la selección de una aplicación de gestión en la nube o SaaS y que puedanser de ayuda tanto a la empresa que se está planteando comprar como a la que vende, oquiere vender, este tipo de aplicaciones. Espero haber cubierto este objetivo dentro de mismodestas posibilidades y si te ha gustado el artículo te agradecería su difusión entre tuscontactos profesionales, en redes sociales y colegas de trabajo que creas que les puedainteresar - 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 especiede check-list y nunca deberían ser sin más el único elemento para tomar una decisión. Si creesque necesitas una ayuda más adecuada a tus necesidades específicas no dudes encontactarme. Luis Carrasco  18 / 22 
  19. 19.          REFERENCIAS:[1] How Cloud Computing And ERP Mobility Are Reordering Gartner’s Hype Cycle for ERPhttp://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 ITBudgets 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 empoweringnew 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 laimplantación de ERPshttp://www.nodotic.com/?p=539[6] Atrapado por tu proveedor. Post en nodoTIC.com sobre los elementos a gestionar paraevitar quedar bloqueado por tu proveedor de servicioshttp://www.nodotic.com/?p=679[7] SAP Integration with Google Apps. SAP and Google recently announced plans to integrateSAP 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 itsinnovation strategy. BBVA banks on the Google cloudhttp://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 Luis Carrasco  19 / 22 
  20. 20.           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 SLAhttp://www.nodotic.com/index.php?s=sla[11] Amazon SLAs Didnt Cover Major Outage. Customers affected by the recent EC2 outagewere compensated by Amazon, but not because the terms of the SLA required it.http://www.informationweek.com/news/cloud-computing/software/229403086[12] Shelfware. Software purchased but not used.http://en.wiktionary.org/wiki/shelfware[13] Presentación en el Internet Global Congress de Barcelona de 2006 sobre herramientas BPM.http://www.slideshare.net/luiscu/13-1-carrasco-delphin-phaq-presentation[13] Encuesta en nodoTIC sobre ERP SaaS disponible en Españahttp://www.nodotic.com/?p=701 Luis Carrasco  20 / 22 
  21. 21.          SOBRE EL AUTOR: Luis Carrasco es Ingeniero de Telecomunicación por la Universidad Politécnica de Cataluña, y Executive MBA por EAE Barcelona. Actualmente es gerente en Delphin Project Hunting, donde, como consultor y project manager, lidera iniciativas para sus clientes de mejoras organizativas, de procesos ysistemas de información para la gestión empresarial.Luis es editor de www.nodoTIC.com, blog sobre sobre tendencias en sistemasde 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 Luis Carrasco  21 / 22 
  22. 22.          DISCLAIMER:Este artículo se ha publicado bajo licencia Creative Commons sa-by, lo quebásicamente significa que puedes utilizarlo como quieras siempre quemenciones a su autor y que compartas de la misma forma cualquier obraderivada en la que lo hayas utilizado. Para los detalles puedes visitar la Web decreative commons: http://creativecommons.org/licenses/by-sa/3.0/deed.esEn la redacción de este artículo me he inspirado en múltiples lecturas y heutilizado 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 omodificado házmelo saber. Luis Carrasco  22 / 22 

×