Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Loading in …3
×

Check these out next

1 of 22 Ad
1 of 22 Ad

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

Download to read offline

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

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

Advertisement
Advertisement

More Related Content

Similar to Puntos clave seleccion aplicaciones SaaS. Artículo - Luis Carrasco (20)

Advertisement

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 autor New York rises de Eugene de Salignacs Luis Carrasco  2 / 22 
  3. 3.           INTRODUCCIÓN Mover las aplicaciones de negocio (ERP, CRM, etc.) a la nube (en modo SaaS) es una tendencia en ascenso entre los responsables de las tecnologías de la información en las empresas a tenor de los múltiples informes y encuestas de los analistas del sector de las TIC [1], [2], [3]. No tengo cifras locales concretas, sólo mi experiencia directa hablando con colegas, clientes y proveedores, pero esta tendencia parece más tímida en nuestro entorno que en otros y es que por alguna razón aquí siempre somos más precavidos en lo de introducir cambios, por decirlo amablemente, o quizá no haya aún una oferta suficiente [13]. Ciertamente es comprensible que los responsables de llevar a cabo e impulsar este tipo de innovaciones en las empresas tengan muchas y serias dudas, dado el riesgo (no necesariamente mayor que continuar igual, todo sea dicho) que puede suponer un cambio estratégico de ese calibre en la gestión de la información de sus empresas, pero como estoy plenamente convencido de que es cuestión de poco tiempo que el modelo dominante de tener tu ERP, CRM etc. in house se quede obsoleto (*) y con el ánimo de contribuir, en la medida de mis modestas posibilidades, a romper, mediante información, transparencia y debate, esos miedos y dudas, me he decidido a escribir este artículo sobre qué es lo que hay que saber antes de decidir mover las aplicaciones de negocio a un modelo SaaS. El artículo lo he estructurado alrededor de los siguientes puntos clave: o Multi-tenancy. Como condición necesaria para que el modelo sea sostenible. o Tecnología. Consideraciones respecto de la arquitectura tecnológica de la aplicación SaaS. o Inicio del Servicio. Qué hemos de tener en cuenta en relación a como se pone en marcha el servicio. o Evolución del Servicio. Qué debemos gestionar para asegurar la adaptación de la aplicación SaaS a los requerimientos cambiantes de nuestra organización. o Fin del servicio. Elementos importantes en el momento de finalizar la relación con el proveedor de la aplicación SaaS o Integración. Consideraciones a la relación de la aplicación SaaS con otras aplicaciones o Privacidad. Cómo cumplir la legislación vigente y proteger nuestros datos sensibles. o Gobierno del servicio. Gobierno de la relación con el proveedor y gestión de la calidad del servicio. o Gestión de costes. Indexación de los costes al uso de la aplicación. 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 las capacidades de potenciales proveedores. No obstante, me gustaría que este artículo fuera útil, no sólo para aquellos responsables de sistemas de información de esa hipotética empresa sino también también para que proveedores de aplicaciones y servicios comprueben que su oferta es competitiva y se ajusta a un modelo SaaS de verdad o True SaaS. [*] Sobre modelos obsoletos siempre me gusta citar a Nicholas Carr, uno de los primeros visionarios de lo que ahora se ha venido a llamar Cloud Computing,que explica en varios de sus libros y artículos como principios del siglo XX las empresas industriales tenían sus propios generadores eléctricos y pozos de agua in house y que al extenderse las redes de distribución de electricidad y agua se cambiaron a la Energía y Agua as a Service. Modelo que ahora, salvo contadísimas excepciones, vemos como el único racional y sostenible. Luis Carrasco  4 / 22 
  5. 5.           red local a través de Internet, y el paquete se MULTI-TENANCY vendía en forma de acceso por usuario. Empiezo con el punto que considero crucial a la Entre las razones técnicas por lo que este modelo hora de decantarnos por un determinado fracasó, operativa y económicamente, se pueden proveedor de aplicaciones de negocio SaaS ya contar: que de alguna manera abarca, o es consecuencia, del resto de puntos clave que se comentan en el • Velocidad y disponibilidad de Internet resto del artículo: el multi-tenancy. en esa época. • La arquitectura física con la que se En una primera aproximación se podría definir que habían diseñado esas aplicaciones no una aplicación de gestión SaaS es Multi-tenancy escalaba ni soportaba bien compartir si: infraestructuras físicas en el lado servidor. • Puede ser compartida por diferentes clientes. Era ineficiente en el aprovechamiento de • Es capaz de adaptarse y evolucionar con los recursos hardware y software (la diferentes requerimientos de cada cliente. virtualización de servidores era una • Y al mismo tiempo ser viable, técnica y tecnología incipiente, de laboratorio económicamente, para el proveedor. prácticamente) y el hardware era caro en esos años. Estos requisitos veremos más adelante que • La arquitectura del software no estaba condicionan fuertemente la arquitectura pensada para ser compartida por tecnológica de una aplicación SaaS y el modelo compañías diferentes. Los datos y tablas de negocio del proveedor quizá sí (o ni eso) pero una configuración del software para necesidades específicas Para entender este concepto fundamental es de una compañía no se podía hacer necesario conocer los antecedentes a los actuales estanca al resto, por lo que se podían modelos SaaS, los ASP o Application Service producir colisiones o incompatibilidades Providers que en los 90 llegaron a tener cierta entre ellas. Las modificaciones que sobre notoriedad o Hype como se dice ahora. una arquitectura ya desarrollada tenían que hacerse, complicaban más aún el La visión de negocio de los ASP era la misma que entorno y lo podían hacer ingestionable pueden tener los actuales modelos SaaS pero el técnicamente por el proveedor. estado de la tecnología y madurez de las empresas que se podrían haber beneficiado no lo • La evolución del software podía ser en la era. Por ejemplo, uno trivial, la velocidad y práctica inviable. O todos los clientes se disponibilidad de las líneas de comunicaciones, o coordinaban para cambiar de versión a la la disposición de las empresas a sacar sus centros vez o no se podía, lo que derivó en que el de datos fuera de sus paredes (algo a lo que ahora software se quedase atascado en una están más predispuestas en general). versión o en que se tuviesen que separar instalaciones por versión – algo En muchos casos, el concepto ASP acababa en antieconómico y a medio plazo que una aplicación cliente-servidor, diseñada y insostenible. construida para ser desplegada dentro de una red • Al haber mucha lógica, incluso datos, en la local corporativa, se habilitaba para que su parte parte cliente, el despliegue y servidor pudiera ser accesible desde fuera de la mantenimiento homogéneo de cualquier 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, en En conclusión, para que una aplicación de un extremo ni enterarse. Así la actualización es gestión sea viable en modo SaaS, debe ser para todos los clientes a la vez y cualquier capaz de poder conseguir economías de escala configuración específica del cliente no debería al compatibilizar el que los clientes puedan condicionar el poder actualizar el software al resto compartir los costes fijos (infraestructuras, – ¿Podrías hacer mañana mismo un cambio de implantación, soporte, mantenimiento, des- versión sin avisar a tus clientes? implantación, etc.), cubrir las necesidades comunes y específicas de esos clientes y al ¿Con qué periodicidad se actualiza el mismo tiempo poder evolucionar para software? No debería haber versiones en el acomodarse a los cambios en esas sentido tradicional sino frecuentes mejoras necesidades de cada uno. Es decir que sea incrementales (un ejemplo serían las aplicaciones Multi-tenancy. de Google) – ¿Cuántos cambios de versión/upgrades/mejoras has hecho en el último Afortunadamente esta posibilidad llegó de la mano año? de avances tecnológicos como la virtualización, seguridad, velocidad y ubicuidad de líneas, ¿Cómo va a cubrir la aplicación mis navegadores rápidos y capaces de incorporar requerimientos funcionales clave [elíjanse lógica de forma estándar -no propietaria- en local, varios cuidadosamente] y que son específicos entornos y metodologías de desarrollo más de mi compañía/negocio/sector? Si el proveedor avanzados, etc. que permitieron desarrollar contesta que debe adaptar/cambiar el software es productos con arquitecturas tecnológicas que probable que éste ya no sea una opción adecuada posibilitaban el Multi-tenancy y desplegar modelos (al menos en modo SaaS) para el cliente. De True SaaS. alguna forma la arquitectura de la aplicación debe estar construida de forma que se puedan ¿Y como podemos verificar con nuestro proveedor diferenciar las diferentes compañías cliente en el que su aplicación de gestión es Multi-tenancy y momento de ejecución de la aplicación. En los evitar así que en realidad acabemos contratando modelos ASP esto se conseguía con el código de una aplicación tradicional en hosting, o lo que es lo compañía/unidad organizativa, pero un mismo que seamos un Single-tenancy más en sus modeloTrue SaaS debe ir más allá, con infraestructuras? codificaciones que permitan que en modo de ejecución la aplicación pueda distinguir entre Pues deberemos hacerle preguntas como: compañías clientes, hacer uso de clusters o agrupaciones de unidades organizativas por ¿Todos los clientes están en la misma versión compañía cliente o por criterios de localización del software? Todos los clientes deberían correr geográfica para temas de normativas locales por la misma versión del código, sin “customizaciones” ejemplo. de código. De esta forma cualquier configuración propia del cliente no acabará afectando al resto de Con estos requisitos, en mi modesta opinión, veo clientes ni, a su vez, se verá afectada por muy difícil, por no decir imposible, que una personalizaciones de código del resto de clientes - aplicación que no ha sido técnicamente ¿Cuánto se tarda en hacer un cambio de versión? diseñada y concebida desde cero con un enfoque de ser Multi-Tenancy, pueda serlo, ya Luis Carrasco  6 / 22 
  7. 7.           que las modificaciones a posteriori que una • Conectividad. Será más fácil acceder a la aplicación tradicional requiera para ser Multi- aplicación desde cualquier ubicación con tenancy acabarán haciéndola compleja y costosa acceso a Internet. de gestionar y mantener, es decir inviable • Facilidad de despliegue. En la económicamente. implantación no se debería tener que invertir en hardware de terminal de usuario ni En conclusión, hay que prestar atención a los tiempo de instalación. provedores con productos tradicionales • Facilidad de evolución. La aplicación podrá reetiquetados como SaaS que realmente no son evolucionar desde el lado de servidor sin Multi-tenancy. tener que actualizar nada en los clientes – facilitando así al proveedor el mantener una versión única de su aplicación para todos TECNOLOGÍA sus clientes Un tema colateral importante aquí es la Como ya se ha comentado anteriormente, la conectividad de dispositivos locales como tecnología ha desempeñado un importante papel impresoras, PLCs, sensores industriales, etc. pero en el desarrollo viable de los modelos SaaS por lo lo trataremos en el punto de integración. que, para asegurarnos que nuestro proveedor SaaS tiene un modelo de negocio sostenible, es Escalabilidad de la plataforma tecnológica importante poder contrastar con él cosas como: Hemos de partir de la premisa de que la plataforma tecnológica en la que estará alojada la Acceso con Browser as a Platform. El acceso a aplicación SaaS será compartida y deberá poder la aplicación debería poder hacerse sin necesidad crecer de forma más o menos lineal según el uso de instalaciones de software específico en local o que le de la propia empresa y las empresas al menos que el proceso de instalación y vecinas. Parece pues muy razonable interesarnos actualización se automatice de forma que sea por las herramientas y tecnologías que el transparente para el usuario (aunque entonces proveedor va a utilizar para asegurarnos esa habrá que gestionar los permisos en las escalabilidad. Concretamente habría que estaciones de trabajo, algo que en determinadas preguntarle por temas como: organizaciones puede ser un impedimento importante) • Qué productos/tecnologías va a utilizar para gestionar su plataforma Cloud: Lo habitual, y en mi opinión mejor opción, es que virtualización, despliegues de aplicaciones sea a través de un navegador estándar (mejor (nuevos clientes y/o versiones/parches), que no se dependa de uno en concreto) con AJAX, creación de nuevos entornos/instancias, HTML5 y como máximo algún plug-in tipo ActiveX, gestión de los cambios de versión de Applet. También es de esperar que avances productos base (sistema operativo, bases de recientes en protocolos a nivel de aplicación como datos, …), sincronización entre entornos de SPDY y Web Sockets de HTML5 mejoren desarrollo, test y producción, compaginar latencias y rendimiento de los actuales protocolos instalaciones compartidas con dedicadas, HTTP… pero esto ahora está saliendo etc. tímidamente de los laboratorios. • Si la plataforma física es propia o de un tercero proveedor de PaaS (Force.com, De esta forma se consigue: Google App por ejemplo) o IaaS (Amazon AWS, Microsoft Azure, IBM, etc.). Este punto, 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 de Disponibilidad y seguridad física de la la plataforma? Lo mejor es que el proveedor plataforma tecnológica pueda enseñaros su centro de control y que Teniendo en cuenta que al ser una aplicación de os explique qué herramientas de control y negocio vamos a utilizar la plataforma tecnológica gestión de alarmas utiliza y cómo os vais a del proveedor para gestionar nuestras operaciones enterar si hay una incidencia. Volveremos es obvio que tenemos que asegurarnos de que sobre esto en el punto de gestión del esta plataforma va a estar disponible cuando la servicio. necesitamos. Es por eso que nos deberá interesar conocer: Seguridad de Datos Los datos de clientes, sus pedidos, la información • Contingencia. ¿Qué pasa si hay una de tu inventario, la facturación… toda esta incidencia que hace que las instalaciones (o información no se puede perder; en general, no la parte de ellas) donde residen las puede ver cualquiera y en algún caso la empresa infraestructuras dejan de estar operativas o está obligada a protegerla. Se ha de tener claro al incluso son destruidas?, ¿Cómo lo ha menos: previsto el proveedor y cómo se integra en nuestra estrategia de recuperación del • ¿Cómo se gestionan las copias de negocio en caso de desastre (tiene un seguridad: Periodicidad (diaria, cierre de Disaster Business Recovery Plan)?, ¿Hay periodo/ejercicio, …), quién lo hace, dónde redundancia de equipamientos como líneas se gestionan/almacenan las copias, control de comunicaciones, alimentación de acceso,…? eléctrica, generador/grupo electrógeno, • ¿Cómo es la sincronización con posibles etc.?, ¿Dispone el proveedor, o nosotros, de centros de respaldo? una instalación de respaldo alternativa • ¿Se cifra la información sensible (más sobre para el caso de un desastre total, y en ese esto en el punto sobre privacidad)? caso cómo se efectuaría la transición?, ¿y la • ¿Cómo se controla el acceso a la aplicación, sincronización de datos entre a la base de datos, etc. tanto accediendo instalaciones principal-respaldo? desde dentro como desde fuera del • Rendimiento ante picos de actividad, firewall/perímetro de seguridad? algunos predecibles y otros no, 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én responsabilidad social, ¿por qué no preguntar por operativas de forma rápida y poder ir las políticas de eficiencia energética y prácticas de afinándolas en ciclos cortos también. protección del medio ambiente, etc.? Aunque sea • La Configuración (set up de entorno, sólo sea por el interés propio en que el proveedor seguridad, alta de usuarios, etc.) sea rápida, reduzca sus gastos operativos para dar un servicio con asistentes (tipo siguiente-siguiente) y competitivo y sostenible – hay informes [4] que aceleradores tales como un catálogo de indican que entre un tercio y la mitad de los costes plantillas de procesos sectoriales y operativos de un centro de proceso de datos horizontales ya preconfigurados, opciones corresponden a la factura de energía. de activación/desactivación de funcionalidades pre-existentes a demanda, etc. INICIO DEL SERVICIO • La puesta en marcha la puedan liderar usuarios no técnicos (a.k.a. de negocio) no Uno de los atractivos de utilizar un modelo SaaS necesariamente expertos de producto. pasa por la premisa de que en general todo tiene que ser más rápido y sencillo. Es una hipótesis Se podrá objetar y con razón, que excepto el de partida porque de no ser así el modelo no es primero, los anteriores puntos no tienen por qué sostenible ni viable y debemos, por tanto, prestar ser exclusivos de un modelo SaaS. Cierto pero, atención a todos los elementos que nuestro ¿no es verdad que suenan a ciencia ficción en el proveedor pueda aportar en este sentido. caso de los productos tradicionales? – ¿por qué debería ser diferente en el caso de un modelo Rapidez y sencillez en que: SaaS? Pues se me ocurren al menos dos razones: • No sea necesario realizar instalaciones de • Ya lo he comentado al principio, si no es así infraestructura hardware y software en las el modelo SaaS no se aguanta, por lo que instalaciones de la empresa, lo que ya de si un proveedor no nos está ofreciendo este entrada debería acortar el tiempo de puesta tipo de facilidades hay que verificar muy bien en marcha y eliminar las necesidades el coste-beneficio que esperamos obtener. adicionales (espacio, seguridad, • Estos elementos deberían ser más climatización,… por ejemplo) para acomodar fácilmente exigibles a una aplicación SaaS nuevas infraestructuras o instalaciones verdadera que a una tradicional ya que, locales de software en los equipos de como ya se comentó anteriormente en el usuario. punto de Multi-tenancy, su arquitectura ya 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 sistema Dentro de los puntos clave no podía faltar el en producción. relativo a asegurar la evolución adecuada del servicio que esperamos recibir una vez puesto en Todos estos puntos no son exclusivos de una marcha dicho servicio, o dicho de otra forma, de la aplicación SaaS evidentemente pero es de esperar elasticidad de la aplicación para adaptarse a que sean más asequibles que en las aplicaciones las necesidades cambiantes que seguro va a tradicionales por lo ya mencionado anteriormente tener nuestra empresa. de que la arquitectura de la aplicación SaaS ya debería haber sido diseñada con estas Por eso deberemos pedirle al proveedor de la consideraciones. aplicación información sobre: Escalabilidad/rendimiento de infraestructuras: Evolución de funcionalidades: Hay que considerar que al ser un modelo SaaS Cómo nos va a asegurar el proveedor que su vamos a tener que compartir las infraestructuras aplicación evoluciona tecnológica y funcionalmente con otras empresas. Debemos por tanto con el mercado/sector y con nuestras necesidades asegurarnos de conocer qué medios, tecnologías, específicas. Concretamente: metodologías, etc. tiene el proveedor para acomodar picos en el número de transacciones en • Qué plan de producto, road map, tiene el sistema, ya sean las previsibles (por ejemplo establecido: módulos, funcionalidades cierres de mes, facturaciones masivas mensuales, nuevas, etc. Atención a la frecuencia de etc.) como las no previstas (un nuevo cliente por actualización que, como ya se mencionó en ejemplo). la entrada de esta serie correspondiente a Multi-tenancy, debería ser mayor que la de Otra vez hay que recordar que tenemos que estar una aplicación tradicional. seguros que el modelo tecnológico del proveedor es sostenible y viable, no sólo desde • Qué garantías nos da de adaptación a el punto de vista tecnológico sino también desde cambios a la legislación vigente, algo el punto de vista económico. especialmente importante en aplicaciones financieras y de RRHH. A nadie le va a gustar que se caiga el sistema, o • Respecto a la evolución de las vaya lento, porque la empresa de al lado ha funcionalidades específicas de nuestra lanzado su proceso de facturación mensual o el empresa (ya sea mantenimiento evolutivo o proveedor entre en riesgo de quiebra por las despliegue de nuevos módulos y/o inversiones que tiene que realizar para funcionalidades) hay que pedir que, como se acomodarse al volumen de transacciones que trae comentó en la entrada correspondiente al un nuevo cliente. Por eso modelos de inicio del servicio, pueda ser liderado por la infraestructura elásticos basados en IaaS de propia empresa, preferentemente por terceros serán recomendables en principio ya que usuarios del negocio -sin dependencias de permitirán esa escalabilidad de forma lineal personal del área de IT, por ejemplo (aunque no olvidemos los temas legales, como se mediante la disponibilidad de un catálogo de Luis Carrasco  10 / 22 
  11. 11.           comentará posteriormente en el punto Aunque la empresa cliente tendrá acceso correspondiente a privacidad) restringido a las infraestructuras y depende en última instancia del proveedor para que le Escalabilidad de usuarios: entregue sus propios datos, no se debería aceptar Otro elemento a atar en corto es cómo se gestiona ninguna restricción por parte del proveedor a el crecimiento y decrecimiento de usuarios de la acceder a tus datos en cualquier momento. aplicación para acomodarse a la dinámica de la empresa. Un ejemplo extremo sería el de una Por supuesto que debe haber reglas (seguridad de empresa sujeta a una alta temporalidad, donde en acceso, formatos, tiempos de preaviso, etc.) pero la temporada alta sube el número de usuarios. es un derecho inalienable del cliente el poder extraer su información cuando la necesite y las Debemos por tanto tener controlados aspectos facilidades que éste tenga van a ser un como: indicador inestimable de la bondad del proveedor y de su aplicación. • Como varían los costes según el nº de usuarios (me extenderé más sobre esto en El tema se puede complicar si además hay una el punto correspondiente a costes) externalización de procesos (BPO) donde los procesos son efectuados directamente por el • Facilidad de replicar/desactivar usuarios, propio proveedor ya que entonces será más difícil roles, etc. No tendría mucho sentido en un para el cliente conocer la estructura en detalle de entorno dinámico y ágil, como el que se los datos que se quiere llevar. supone que es un entorno SaaS, que poner en marcha un nuevo usuario sea costoso. Concretamente, habrá que averiguar del proveedor qué plan de salida ofrece en caso de Y es que nunca hemos de perder de vista que si cese del servicio, con especial atención a: estamos barajando una aplicación SaaS es porque nos preocupa, entre otras cosas, la elasticidad de • Formato de los datos para su portabilidad. la solución, tanto para crecer como para Archivos planos, Exports de tablas de las decrecer. bases de datos, … un tema bastante tecnológico que deberá conocerse bien para FIN DEL SERVICIO identificar las posibles limitaciones que pudiera haber. • Punto de corte: es decir en qué momento En la Salida o Finalización del Servicio es se hace la foto de los datos para su fundamental que nos aseguremos de la facilidad y portabilidad. Una posibilidad, para estar rapidez de salida en el caso en que haya seguros de que el conjunto de datos es problemas, y así no quedarte atrapado por tu coherente, es pedir una copia de seguridad proveedor [6]. Este punto está bastante estudiado portable en cada cierre de periodo. En (vendor lock-in le llaman en la literatura teoría, al menos a nivel de datos, serás libre especializada) y es una de los puntos que más se de irte al final de cada periodo con un citan como impedimentos y reticencias a los conjunto coherente de datos. modelos SaaS A mi parecer, se ha de tener en cuenta: Control y portabilidad de los datos: Luis Carrasco  11 / 22 
  12. 12.           Control y portabilidad de la aplicación: alguna manera, está basada o respaldada por Si el proveedor quiebra o desaparece, o algún tipo de herramienta BPM, que implemente simplemente decido irme, ¿podré llevarme la definiciones de los procesos en formatos aplicación y los datos a otro sitio? ¿Lo puedo fijar estandarizados tipo BPEL, BPMN, XPDL, etc. por contrato? Estas preguntas son de difícil respuesta en según que casos, sobre todo si el De esta manera, al menos en teoría, se podrían software es propietario (o la tecnología en la que importar la definición de los procesos a otras fue desarrollado) y desde luego no es algo aplicaciones de la misma manera que se habitualmente previsto en los contratos que se ven importarán los datos. Soy consciente de que esta por ahí (no me lo imagino con gigantes como posibilidad es, a día de hoy, remota por el estado Salesforce.com o NetSuite por ejemplo). A este de madurez de las herramientas BPM [13] pero no respecto pues y en principio, será interesante la descartaría a medio plazo. poder optar por aplicaciones Open Source o propietarias con derecho a descarga y modificación de los fuentes para uso exclusivo de INTEGRACIÓN la empresa cliente. Es muy probable que la aplicación SaaS que Conocimiento queramos poner en marcha no sea la única de las Adicionalmente tendremos que considerar no sólo aplicaciones de la empresa y que necesitemos la disponibilidad/portabilidad de la aplicación. interconectarlas e integrarlas entre ellas. Tener la aplicación no basta, hay que tener los recursos y el conocimiento (nosotros o terceros) La dificultad adicional que tenemos que para que funcione. gestionar es que la aplicación SaaS va a estar en un entorno que no está siendo gestionado Es por esto que aunque deleguemos totalmente la por nosotros, por lo que se añaden gestión de aplicación en el proveedor SaaS, complejidades de índole técnica y operativa mantengamos personas dentro de nuestra que no se pueden desdeñar: necesidad de organización con el conocimiento necesario para traspasar un firewall que se supone muy exigente gestinar, aunque sea temporalmente y bajo de un tercero, no control de las ventanas mínimos, la aplicación hasta que finalice la temporales y mecanismos de integración si ésta es transición a otro proveedor/aplicación. asíncrona o batch, restricciones de seguridad y técnicas a la hora de hacer una integración en Condiciones y operativa de salida tiempo real, rigideces en formatos de Es decir fechas de preaviso, posibles archivos/mensajes de integración,etc. penalizaciones y calendarios mínimos (que habrá que acabar de negociar durante la negociación del Concretando, deberemos tener en cuenta contrato), coste de servicios adicionales en caso elementos como: de ser necesarios, etc. No me extenderé sobre algo que está bastante explicado [6] Integración con aplicaciones externas Tales como una Web de ventas, aplicación de Y para rizar el rizo, ¿Por qué no intentar la nómina, herramientas de BI y/o reporting, EDI, … Portabilidad de Procesos? para las que como ya se ha mencionado antes hay En la práctica consiste en poder llevarte contigo la restricciones operativas y técnicas que dificultan la definición de los procesos de negocio soportados integración. Hay que enterarse muy bien de las por la aplicación, que sólo será posible si ésta, de vías estándar como APIs, Web Services, herramientas, metodologías, etc. que el proveedor Luis Carrasco  12 / 22 
  13. 13.           va a poner a nuestra disposición para facilitarnos esta integración desde y hacia fuera de su firewall. PRIVACIDAD Con ofimática Llegamos al tema, nada trivial por los aspectos Hay que rendirse a la evidencia de que los legales y de procedimiento que hay detrás, de la usuarios trabajan con archivos de ofimática de seguridad y privacidad. Vaya por delante que forma intensiva y que cada vez más a las trasciende el propósito de este artículo hacer una aplicaciones de negocio se les requiere trabajar descripción exhaustiva de la legislación que debe con información no estructurada, como los aplicarse, y como no tengo la formación ni la documentos ofimáticos, integrada con la experiencia en temas legales requerida para ello, transaccional propia de la aplicación. Y hemos de me limitaré a los aspectos técnicos y operativos y tener en cuenta que los documentos normalmente a proporcionar una lista de elementos a contrastar están/salen de la red local, del equipo de usuario o con el proveedor, que he podido recopilar. de un gestor documental, y que muchas veces esos documentos son pesados, lo que va a Dicho de forma muy sintetizada: hay que suponer un reto para el ancho de banda disponible asegurarse de que nuestros datos sensibles y el rendimiento en general de la aplicación. Otra (entendiendo como sensibles, datos de tipo opción, que me parece muy interesante, es la de personal o los propios secretos de la empresa) usar ofimática en la nube. En ese sentido apunta van a ser almacenados y tratados de una forma la decisión de SAP de integrar SAP Business que se cumpla la legislación vigente en materia ByDesign con las aplicaciones de negocio de de privacidad y seguridad, lo que acabará Google [7] afectando a cualquier elemento del servicio relacionado con: Dispositivos locales: Como impresoras, PLCs/Sensores en entornos • Ubicación de los datos industriales, controles de presencia, etc. • Seguridad de acceso y almacenamiento Tendremos que verificar cuidadosamente los • Tratamiento automatizado requerimientos técnicos de estos equipos para estar integrados con la aplicación SaaS en Concretamente, tendremos que comprobar (y que cuestión. Si por esta razón se han de cambiar se refleje de alguna manera en el contrato con el equipos, el Business Case de la operación se proveedor) al menos lo siguiente: puede resentir. ¿Realmente nuestro proveedor SaaS va tener Hemos de ser consciente pues que una báscula que almacenar/tratar datos sensibles? que vuelca datos al ERP, una impresora de código Datos personales, según se definan en la de barras o térmica, un PLC controlado desde el legislación vigente, que nos comprometen como ERP, etc. pueden ser dispositivos más empresa y para los que hay diversos niveles de complicados de integrar en un entorno Cloud. sensibilidad- No es lo mismo una nómina que una factura, y ya no digamos datos médicos de un empleado. Datos propios de la empresa “secretos”: propiedad intelectual, i+d, fórmulas, listas de inversores,… Será una tarea clave la identificación de estos datos y los controles que deberemos acordar con Luis Carrasco  13 / 22 
  14. 14.           el proveedor para garantizar el cumplimiento, tanto Obviamente tendremos que conocer hasta el final de nuestros requisitos de seguridad como el de los la cadena de proveedores y tenerlo en cuenta en legales. el contrato (por ejemplo que sea necesaria la autorización previa para cualquier subcontratación ¿Cuál es la ubicación de los servidores? o cesión del servicio a un tercero por parte de En la legislación española sobre datos de caracter nuestro proveedor SaaS ) personal, si los servidores van a estar fuera de las fronteras españolas aplica el concepto de ¿Como nos afecta la legislación específica, por “transferencia internacional” de los datos, lo que ejemplo la LOPD en el caso de España? obliga a comprobar que el país destino está Es fundamental conocer de acuerdo a la “homologado” por las autoridades españolas como legislación, el responsable último es siempre la ubicación “aceptable”. Actualmente es aceptado empresa, por lo que se deberá acotar muy bien en cualquier país del Espacio Económico Europeo o el contrato, aparte de todo lo mencionado de aquellos que la Agencia de Protección de Datos anteriormente, los límites y salvaguardas en el tiene en su lista de Países con un nivel adecuado tratamiento de los datos: fines de ese tratamiento, de protección. Atención también a los como se devolverán y destruirán, etc. proveedores de nuestro proveedor. …y si, los seguramente super-exigentes, ¿Qué tipo de seguridad, física, respaldo, abogados del BBVA no ven ningún problema en procedimientos, acceso a servidores, etc. tiene que información tan sensible como la que manejan activada el proveedor? los empleados del banco esté en la nube…[8] qué Sin ánimo de extenderme en este tema, el podemos decir aquí. proveedor debería poder mostrar qué medidas de seguridad tiene implementadas. Lo más fácil es Para acabar este apartado, recomiendo la lectura que pueda acreditar tales medidas mediante de las referencias [9] respecto a privacidad que se certificaciones del tipo ISO27001, SAS 70 type II o relacionan en la sección de referencias. equivalente y que pase las auditorías específicas pertinentes que marcan esas certificaciones. GOBIERNO DEL SERVICIO ¿Cómo se accede y “viajan” los datos? ¿El acceso, presumiblemente vía Web, es Si vamos a utilizar una aplicación en modo SaaS – seguro,vía https/SSL o VPN, o equivalente? ¿Se Software as a Service - tendremos que gestionar cifran los datos sensibles, que lo requieran, al ese as a Service y la manera habitual de gestionar viajar y ser almacenados? cualquier servicio externalizado es mediante acuerdos sobre la calidad del servicio que ¿Quién puede acceder y tratar los datos espera recibir el cliente del proveedor o, en la sensibles? jerga del sector, SLAs [10] (Service Level Aparte del proveedor principal, ¿hay Agreement) ligados a la QoS (Quality of Service). subcontratados o terceros que pueden acceder y/o tratar nuestros datos? Esta entrada no pretende cubrir en detalle qué es un SLA ni como se negocia/acuerda, hay mucha Debe tenerse en cuenta que es posible que literatura, y buena, disponible, sino en los puntos nuestro proveedor SaaS esté utilizando recursos e particulares que pueda tener la gestión y medición infraestructuras de terceros, por ejemplo una del servicio en el caso de aplicaciones SaaS de aplicación que corra en los servidores de Amazon. gestión. 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 de atender, al menos, a los siguientes puntos: tiempo y excluye los tiempos dedicados a mantenimiento de la plataforma. No olvidar Niveles de servicio por capas. especificar el periodo de medición de esa disponibilidad (no es lo mismo el 99,9% de Teniendo en cuenta la arquitectura típica de este disponibilidad mensual que anual). tipo de aplicaciones es conveniente conocer los • No disponibilidad del servicio por niveles de servicio para las distintas capas mantenimiento. Ya sé que se ha dicho tecnológicas que la conforman: antes que en una aplicación true SaaS el cliente ni se tiene que enterar de un cambio • Aplicación de versión pero entiendo que la plataforma • Integración/Middleware requerirá paradas por mantenimiento. Hay • Infraestructuras que prestar atención a tiempos de preaviso y horarios (no es lo mismo no tener disponible En principio los niveles de servicio que más hemos la plataforma el día que lanzas la facturación de controlar directamente son los de Aplicación. mensual que no tenerla un domingo) El resto pueden ser relevantes si hay terceros • Tiempos de puesta en marcha de nuevas proveedores, por ejemplo en la capa de funcionalidades. Si la aplicación, como infraestructuras. Y si ese es el caso leer bien los debería una True SaaS, permite SLAs ofrecidos por ese tercero no vaya a ser que activar/desactivar funcionalidades, será no estés cubierto adecuadamente [11] conveniente especificar el tiempo de activación/desactivación operativa. Niveles de servicio por tipo Ligados a los procesos de negocio Los niveles de servicio se pueden definir de varios tipos. En este contexto no debería faltar: Ya se ha apuntado antes pero lo recalco. Estamos en un contexto de aplicaciones de gestión • Rendimiento de la aplicación. Estos empresarial. Cualquier parámetro de gestión del niveles de servicio no es aconsejable que servicio/sistema ha de tener como referente los sean genéricos y se han de intentar definir procesos de negocio cuando se traten temas para las transacciones que consideremos de disponibilidad, horarios, rendimientos, más importantes – por ejemplo tiempo que velocidad, tiempos de ejecución,… aunque se tarda en finalizar la entrada de un pedido hemos de ser conscientes del reto que puede de cliente. Es recomendable que cada suponer para el proveedor trabajar en ese modo. empresa revise su caso particular y no acepte por defecto las estándares (si las Hay más elementos a tener en cuenta a la hora de hubiere, que es poco probable). Otro tema negociar los SLAs pero no veo que tengan es como se mide. particularidades relevantes con respecto a un • Tiempos/calidad de respuesta al soporte. SaaS de aplicaciones de gestión. No obstante no Tiempos relacionados con consultas, nos olvidemos de temas como: incidencias, etc. de los usuarios finales o de los técnicos. Aparte de estos tiempos hay 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 o No se me escapa que este punto ha quedado esporádicamente, otros que utilizan una bastante genérico pero es que es un tema muy funcionalidad determinada de forma extenso. He intentado al menos citar los puntos intensiva, los que se conectan sólo para más importantes. consultar, … lo habitual es que se establezcan diferencias a nivel de tarificación entre estos diferentes tipos de GESTIÓN DE COSTES usuario. • Por módulos / funcionalidad activada / No puede faltar en este repaso de los puntos clave desactivada. Es decir por el tipo de uso que a considerar al seleccionar una aplicación de se hace de la aplicación. A considerar en negocio SaaS, el de los costes. Y es que uno de este caso, la facilidad que deberemos los atractivos que posiblemente busquemos al requerir de nuestro proveedor para tener optar por un modelo SaaS es el de variabilizar los una gestión ágil de este uso tal como se ha costes totales de propiedad de la aplicación de mencionado en el apartado sobre evolución. gestión. • Transacciones por periodo. Este modelo puede ser muy ventajoso si se liga a Esta variabilización se conseguirá al utilizarse un transacciones que suponen ingresos ya que modelo de suscripción/pago de una cuota el coste del servicio se liga al ingreso. Por periódica relacionada con el uso que se hace ejemplo por número de pedidos de clientes del sistema y que incluye todo (licencias, entrados, facturas emitidas, clientes a los infraestructuras, help-desk, nuevas versiones, etc.). que se le factura en el mes,… o incluso un porcentaje de la facturación. Y ese “relacionada con el uso que hace del • Consumo de recursos de computación. sistema“ es clave en toda la gestión de costes: Esto, que se llegó a hacer en los albores de 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 cuenta que puede haber límites inferiores (mínimos de uso) y superiores, normalmente asociados a limitaciones por consumo de recursos como ancho de banda, ocupación disco, consumo de CPU, etc. Concluyendo, está claro que, independientemente del modelo que ofrezca el proveedor, habrá que hacer un estudio minucioso de cómo se va a usar la aplicación y prever que tengamos la capacidad de ir ajustando dinámica y elásticamente nuestras necesidades. Luis Carrasco  17 / 22 
  18. 18.           CONCLUSIÓN: En este artículo he intentado hacer una cobertura a alto nivel de todos los puntos que considero claves en la selección de una aplicación de gestión en la nube o SaaS y que puedan ser de ayuda tanto a la empresa que se está planteando comprar como a la que vende, o quiere vender, este tipo de aplicaciones. Espero haber cubierto este objetivo dentro de mis modestas posibilidades y si te ha gustado el artículo te agradecería su difusión entre tus contactos profesionales, en redes sociales y colegas de trabajo que creas que les pueda interesar - sobre todo si son CEOs, CIOs, CFOs, CxOs en general …☺ Los puntos cubiertos en el artículo deben considerarse como una guía de partida, una especie de check-list y nunca deberían ser sin más el único elemento para tomar una decisión. Si crees que necesitas una ayuda más adecuada a tus necesidades específicas no dudes en contactarme. Luis Carrasco  18 / 22 
  19. 19.           REFERENCIAS: [1] How Cloud Computing And ERP Mobility Are Reordering Gartner’s Hype Cycle for ERP http://softwarestrategiesblog.com/2012/01/02/how-cloud-computing-and-erp-mobility-are- reordering-gartners-hype-cycle-for-erp/ [2] Roundup of Cloud Computing Forecasts and Market Estimates, 2012. http://softwarestrategiesblog.com/2012/01/17/roundup-of-cloud-computing-forecasts-and- market-estimates-2012/ [3] Gartner Executive Programs' Worldwide Survey of More Than 2,300 CIOs Shows Flat IT Budgets in 2012, but IT Organizations Must Deliver on Multiple Priorities. http://www.gartner.com/it/page.jsp?id=1897514 [4] Building data startups: Fast, big, and focused. Low costs and cloud tools are empowering new data startups. http://radar.oreilly.com/2011/08/building-data-startups.html [5] Webinar en el Project Management Institute sobre la utilización de métodos ágiles en la implantación de ERPs http://www.nodotic.com/?p=539 [6] Atrapado por tu proveedor. Post en nodoTIC.com sobre los elementos a gestionar para evitar quedar bloqueado por tu proveedor de servicios http://www.nodotic.com/?p=679 [7] SAP Integration with Google Apps. SAP and Google recently announced plans to integrate SAP Business ByDesign and Google Apps for Business. http://en.sap.info/apps-google-bydesign/64640 [8] One of the most influential banks in the world adopts Google’s technology as a part of its innovation strategy. BBVA banks on the Google cloud http://press.bbva.com/latest-contents/press-releases/spain/bbva-banks-on-the-google- cloud(9882-22-101-c-92220).html [9] Varias referencias en relación a legislación sobre privacidad de datos Reforma/actualización que propone la Comisión Europea sobre el marco de 1995 http://ec.europa.eu/justice/newsroom/data-protection/news/120125_en.htm LOPD y Cloud Computing: http://www.gpn6.com/2011/11/lopd-y-cloud-computing/ Consulta pública de la Agencia Española de Protección de Datos sobre Cloud Computing (es posible que este enlace caduque, si es así buscar en la misma Web http://www.servicios.agpd.es/AGPD/inicio_encuesta.seam?cid=960 Guía Cloud del Instituto Nacional de Tecnologías de la comunicación INTECO http://www.inteco.es/Seguridad/Observatorio/guias/Guia_Cloud Aspectos contractuales y marco regulador del cloud computing http://www.gesdatos.com/el-rincon-del-dato/aspectos-legales-en-cloud-computing.html 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 SLA http://www.nodotic.com/index.php?s=sla [11] Amazon SLAs Didn't Cover Major Outage. Customers affected by the recent EC2 outage were compensated by Amazon, but not because the terms of the SLA required it. http://www.informationweek.com/news/cloud-computing/software/229403086 [12] Shelfware. Software purchased but not used. http://en.wiktionary.org/wiki/shelfware [13] Presentación en el Internet Global Congress de Barcelona de 2006 sobre herramientas BPM. http://www.slideshare.net/luiscu/13-1-carrasco-delphin-phaq-presentation [13] Encuesta en nodoTIC sobre ERP SaaS disponible en España http://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 y sistemas de información para la gestión empresarial. Luis es editor de www.nodoTIC.com, blog sobre sobre tendencias en sistemas de información de gestión empresarial. También podéis encontrarle en diversas redes sociales: http://www.linkedin.com/in/luiscu @nodotic https://plus.google.com/u/0/111838161734108867236/about Luis Carrasco  21 / 22 
  22. 22.           DISCLAIMER: Este artículo se ha publicado bajo licencia Creative Commons sa-by, lo que básicamente significa que puedes utilizarlo como quieras siempre que menciones a su autor y que compartas de la misma forma cualquier obra derivada en la que lo hayas utilizado. Para los detalles puedes visitar la Web de creative commons: http://creativecommons.org/licenses/by-sa/3.0/deed.es En la redacción de este artículo me he inspirado en múltiples lecturas y he utilizado recursos gráficos que he intentado referenciar y atribuir a sus autores. Si crees que hay algo en el artículo que debería ser cambiado, añadido o modificado házmelo saber. Luis Carrasco  22 / 22 

×