Puntos clave en la selección de aplicaciones SaaS de gestión (artículo)

Puntos clave en la selección de aplicaciones SaaS de gestión (artículo)

Transcript

1. Luis Carrasco 1 / 22 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
2. Luis Carrasco 2 / 22 Contenidos: New York rises de Eugene de Salignacs Introducción Puntos clave Multi-tenancy Tecnología Inicio del Servicio Evolución del Servicio Fin del Servicio Integración Privacidad Gobierno del Servicio Gestión de Costes Conclusión Referencias Sobre el autor
3. Luis Carrasco 3 / 22 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.
4. Luis Carrasco 4 / 22 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.
5. Luis Carrasco 5 / 22 MULTI-TENANCY Empiezo con el punto que considero crucial a la hora de decantarnos por un determinado proveedor de aplicaciones de negocio SaaS ya que de alguna manera abarca, o es consecuencia, del resto de puntos clave que se comentan en el resto del artículo: el multi-tenancy. En una primera aproximación se podría definir que una aplicación de gestión SaaS es Multi-tenancy si: • Puede ser compartida por diferentes clientes. • Es capaz de adaptarse y evolucionar con los diferentes requerimientos de cada cliente. • Y al mismo tiempo ser viable, técnica y económicamente, para el proveedor. Estos requisitos veremos más adelante que condicionan fuertemente la arquitectura tecnológica de una aplicación SaaS y el modelo de negocio del proveedor Para entender este concepto fundamental es necesario conocer los antecedentes a los actuales modelos SaaS, los ASP o Application Service Providers que en los 90 llegaron a tener cierta notoriedad o Hype como se dice ahora. La visión de negocio de los ASP era la misma que pueden tener los actuales modelos SaaS pero el estado de la tecnología y madurez de las empresas que se podrían haber beneficiado no lo era. Por ejemplo, uno trivial, la velocidad y disponibilidad de las líneas de comunicaciones, o la disposición de las empresas a sacar sus centros de datos fuera de sus paredes (algo a lo que ahora están más predispuestas en general). En muchos casos, el concepto ASP acababa en que una aplicación cliente-servidor, diseñada y construida para ser desplegada dentro de una red local corporativa, se habilitaba para que su parte servidor pudiera ser accesible desde fuera de la red local a través de Internet, y el paquete se vendía en forma de acceso por usuario. Entre las razones técnicas por lo que este modelo fracasó, operativa y económicamente, se pueden contar: • Velocidad y disponibilidad de Internet en esa época. • La arquitectura física con la que se habían diseñado esas aplicaciones no escalaba ni soportaba bien compartir infraestructuras físicas en el lado servidor. Era ineficiente en el aprovechamiento de recursos hardware y software (la virtualización de servidores era una tecnología incipiente, de laboratorio prácticamente) y el hardware era caro en esos años. • La arquitectura del software no estaba pensada para ser compartida por compañías diferentes. Los datos y tablas quizá sí (o ni eso) pero una configuración del software para necesidades específicas de una compañía no se podía hacer estanca al resto, por lo que se podían producir colisiones o incompatibilidades entre ellas. Las modificaciones que sobre una arquitectura ya desarrollada tenían que hacerse, complicaban más aún el entorno y lo podían hacer ingestionable técnicamente por el proveedor. • La evolución del software podía ser en la práctica inviable. O todos los clientes se coordinaban para cambiar de versión a la vez o no se podía, lo que derivó en que el software se quedase atascado en una versión o en que se tuviesen que separar instalaciones por versión – algo antieconómico y a medio plazo insostenible. • Al haber mucha lógica, incluso datos, en la parte cliente, el despliegue y mantenimiento homogéneo de cualquier
6. Luis Carrasco 6 / 22 implantación compartida era una tarea muy costosa porque había que actualizar software en cada estación de trabajo En conclusión, para que una aplicación de gestión sea viable en modo SaaS, debe ser capaz de poder conseguir economías de escala al compatibilizar el que los clientes puedan compartir los costes fijos (infraestructuras, implantación, soporte, mantenimiento, des- implantación, etc.), cubrir las necesidades comunes y específicas de esos clientes y al mismo tiempo poder evolucionar para acomodarse a los cambios en esas necesidades de cada uno. Es decir que sea Multi-tenancy. Afortunadamente esta posibilidad llegó de la mano de avances tecnológicos como la virtualización, seguridad, velocidad y ubicuidad de líneas, navegadores rápidos y capaces de incorporar lógica de forma estándar -no propietaria- en local, entornos y metodologías de desarrollo más avanzados, etc. que permitieron desarrollar productos con arquitecturas tecnológicas que posibilitaban el Multi-tenancy y desplegar modelos True SaaS. ¿Y como podemos verificar con nuestro proveedor que su aplicación de gestión es Multi-tenancy y evitar así que en realidad acabemos contratando una aplicación tradicional en hosting, o lo que es lo mismo que seamos un Single-tenancy más en sus infraestructuras? Pues deberemos hacerle preguntas como: ¿Todos los clientes están en la misma versión del software? Todos los clientes deberían correr la misma versión del código, sin “customizaciones” de código. De esta forma cualquier configuración propia del cliente no acabará afectando al resto de clientes ni, a su vez, se verá afectada por personalizaciones de código del resto de clientes - ¿Cuánto se tarda en hacer un cambio de versión? ¿Qué tiene que hacer el cliente si se actualiza la versión del software? Los clientes no se deberían preocupar de tener que actualizar el software, para ellos debería ser transparente, en un extremo ni enterarse. Así la actualización es para todos los clientes a la vez y cualquier configuración específica del cliente no debería condicionar el poder actualizar el software al resto – ¿Podrías hacer mañana mismo un cambio de versión sin avisar a tus clientes? ¿Con qué periodicidad se actualiza el software? No debería haber versiones en el sentido tradicional sino frecuentes mejoras incrementales (un ejemplo serían las aplicaciones de Google) – ¿Cuántos cambios de versión/upgrades/mejoras has hecho en el último año? ¿Cómo va a cubrir la aplicación mis requerimientos funcionales clave [elíjanse varios cuidadosamente] y que son específicos de mi compañía/negocio/sector? Si el proveedor contesta que debe adaptar/cambiar el software es probable que éste ya no sea una opción adecuada (al menos en modo SaaS) para el cliente. De alguna forma la arquitectura de la aplicación debe estar construida de forma que se puedan diferenciar las diferentes compañías cliente en el momento de ejecución de la aplicación. En los modelos ASP esto se conseguía con el código de compañía/unidad organizativa, pero un modeloTrue SaaS debe ir más allá, con codificaciones que permitan que en modo de ejecución la aplicación pueda distinguir entre compañías clientes, hacer uso de clusters o agrupaciones de unidades organizativas por compañía cliente o por criterios de localización geográfica para temas de normativas locales por ejemplo. Con estos requisitos, en mi modesta opinión, veo muy difícil, por no decir imposible, que una aplicación que no ha sido técnicamente diseñada y concebida desde cero con un enfoque de ser Multi-Tenancy, pueda serlo, ya
7. Luis Carrasco 7 / 22 que las modificaciones a posteriori que una aplicación tradicional requiera para ser Multi- tenancy acabarán haciéndola compleja y costosa de gestionar y mantener, es decir inviable económicamente. En conclusión, hay que prestar atención a los provedores con productos tradicionales reetiquetados como SaaS que realmente no son Multi-tenancy. TECNOLOGÍA Como ya se ha comentado anteriormente, la tecnología ha desempeñado un importante papel en el desarrollo viable de los modelos SaaS por lo que, para asegurarnos que nuestro proveedor SaaS tiene un modelo de negocio sostenible, es importante poder contrastar con él cosas como: Acceso con Browser as a Platform. El acceso a la aplicación debería poder hacerse sin necesidad de instalaciones de software específico en local o al menos que el proceso de instalación y actualización se automatice de forma que sea transparente para el usuario (aunque entonces habrá que gestionar los permisos en las estaciones de trabajo, algo que en determinadas organizaciones puede ser un impedimento importante) Lo habitual, y en mi opinión mejor opción, es que sea a través de un navegador estándar (mejor que no se dependa de uno en concreto) con AJAX, HTML5 y como máximo algún plug-in tipo ActiveX, Applet. También es de esperar que avances recientes en protocolos a nivel de aplicación como SPDY y Web Sockets de HTML5 mejoren latencias y rendimiento de los actuales protocolos HTTP… pero esto ahora está saliendo tímidamente de los laboratorios. De esta forma se consigue: • Conectividad. Será más fácil acceder a la aplicación desde cualquier ubicación con acceso a Internet. • Facilidad de despliegue. En la implantación no se debería tener que invertir en hardware de terminal de usuario ni tiempo de instalación. • Facilidad de evolución. La aplicación podrá evolucionar desde el lado de servidor sin tener que actualizar nada en los clientes – facilitando así al proveedor el mantener una versión única de su aplicación para todos sus clientes Un tema colateral importante aquí es la conectividad de dispositivos locales como impresoras, PLCs, sensores industriales, etc. pero lo trataremos en el punto de integración. Escalabilidad de la plataforma tecnológica Hemos de partir de la premisa de que la plataforma tecnológica en la que estará alojada la aplicación SaaS será compartida y deberá poder crecer de forma más o menos lineal según el uso que le de la propia empresa y las empresas vecinas. Parece pues muy razonable interesarnos por las herramientas y tecnologías que el proveedor va a utilizar para asegurarnos esa escalabilidad. Concretamente habría que preguntarle por temas como: • Qué productos/tecnologías va a utilizar para gestionar su plataforma Cloud: virtualización, despliegues de aplicaciones (nuevos clientes y/o versiones/parches), creación de nuevos entornos/instancias, gestión de los cambios de versión de productos base (sistema operativo, bases de datos, …), sincronización entre entornos de desarrollo, test y producción, compaginar instalaciones compartidas con dedicadas, etc. • Si la plataforma física es propia o de un tercero proveedor de PaaS (Force.com, Google App por ejemplo) o IaaS (Amazon AWS, Microsoft Azure, IBM, etc.). Este punto,
8. Luis Carrasco 8 / 22 además tiene relevancia a efectos legales, como veremos más adelante. • Si dispone de herramientas o tecnologías específicas para la gestión de grandes volúmenes de datos o cómo va a asegurar la escalabilidad de un entorno de datos que al ser compartido va crecer más y de forma menos previsible de lo que lo hace en un escenario no compartido. Sin llegar a los extremos de tener que disponer de tecnologías de Big Data pero creo que no vale el enfoque por el que se optaría en una instalación monocliente (el Multy-tenancy aparece otra vez) al ser potencialmente un entorno menos predecible y planificable. Disponibilidad y seguridad física de la plataforma tecnológica Teniendo en cuenta que al ser una aplicación de negocio vamos a utilizar la plataforma tecnológica del proveedor para gestionar nuestras operaciones es obvio que tenemos que asegurarnos de que esta plataforma va a estar disponible cuando la necesitamos. Es por eso que nos deberá interesar conocer: • Contingencia. ¿Qué pasa si hay una incidencia que hace que las instalaciones (o parte de ellas) donde residen las infraestructuras dejan de estar operativas o incluso son destruidas?, ¿Cómo lo ha previsto el proveedor y cómo se integra en nuestra estrategia de recuperación del negocio en caso de desastre (tiene un Disaster Business Recovery Plan)?, ¿Hay redundancia de equipamientos como líneas de comunicaciones, alimentación eléctrica, generador/grupo electrógeno, etc.?, ¿Dispone el proveedor, o nosotros, de una instalación de respaldo alternativa para el caso de un desastre total, y en ese caso cómo se efectuaría la transición?, ¿y la sincronización de datos entre instalaciones principal-respaldo? • Rendimiento ante picos de actividad, algunos predecibles y otros no, inestabilidad del entorno por el cambio continuo, … ¿Qué tecnologías va a utilizar el proveedor para garantizar el rendimiento de la plataforma, velocidad de las líneas, uso de recursos de CPU, …? De la misma forma que con la escalabilidad de datos, las estrategias y arquitecturas tecnológicas que se han venido utilizando en instalaciones single-tenancy es probable que no sean las más adecuadas. • Seguridad física. ¿Cómo se controla el acceso físico a las instalaciones?, ¿Quién tendrá acceso?, ¿Sistemas de vigilancia/registro/grabación?, … • Monitorización. ¿Cómo va a controlar el proveedor el rendimiento y disponibilidad de la plataforma? Lo mejor es que el proveedor pueda enseñaros su centro de control y que os explique qué herramientas de control y gestión de alarmas utiliza y cómo os vais a enterar si hay una incidencia. Volveremos sobre esto en el punto de gestión del servicio. Seguridad de Datos Los datos de clientes, sus pedidos, la información de tu inventario, la facturación… toda esta información no se puede perder; en general, no la puede ver cualquiera y en algún caso la empresa está obligada a protegerla. Se ha de tener claro al menos: • ¿Cómo se gestionan las copias de seguridad: Periodicidad (diaria, cierre de periodo/ejercicio, …), quién lo hace, dónde se gestionan/almacenan las copias, control de acceso,…? • ¿Cómo es la sincronización con posibles centros de respaldo? • ¿Se cifra la información sensible (más sobre esto en el punto sobre privacidad)? • ¿Cómo se controla el acceso a la aplicación, a la base de datos, etc. tanto accediendo desde dentro como desde fuera del firewall/perímetro de seguridad?
9. Luis Carrasco 9 / 22 • ¿Se registra/audita la actividad de acceso a datos? Qué, quién y cuándo se modifican/leen/borran los datos • ¿Cómo se asegura que otros clientes no ven mis datos? • etc. no me extiendo más en este punto porque entiendo que hay disponible abundante documentación al respecto. Green/Eficiencia Energética Y para empresas con sensibilidad y responsabilidad social, ¿por qué no preguntar por las políticas de eficiencia energética y prácticas de protección del medio ambiente, etc.? Aunque sea sólo sea por el interés propio en que el proveedor reduzca sus gastos operativos para dar un servicio competitivo y sostenible – hay informes [4] que indican que entre un tercio y la mitad de los costes operativos de un centro de proceso de datos corresponden a la factura de energía. INICIO DEL SERVICIO Uno de los atractivos de utilizar un modelo SaaS pasa por la premisa de que en general todo tiene que ser más rápido y sencillo. Es una hipótesis de partida porque de no ser así el modelo no es sostenible ni viable y debemos, por tanto, prestar atención a todos los elementos que nuestro proveedor pueda aportar en este sentido. Rapidez y sencillez en que: • No sea necesario realizar instalaciones de infraestructura hardware y software en las instalaciones de la empresa, lo que ya de entrada debería acortar el tiempo de puesta en marcha y eliminar las necesidades adicionales (espacio, seguridad, climatización,… por ejemplo) para acomodar nuevas infraestructuras o instalaciones locales de software en los equipos de usuario. • Haya disponibilidad de herramientas de carga, depuración, comparación, etc. de datos orientadas a acelerar la migración y conversión de información y la gestión de paralelos. • Se utilicen Metodologías de puesta en marcha ágiles [5], colaborativas, iterativas, etc con entornos preconfigurados para la captura rápida e incremental de requisitos, aprender pronto para ajustar también pronto, disponer de funcionalidades que estén operativas de forma rápida y poder ir afinándolas en ciclos cortos también. • La Configuración (set up de entorno, seguridad, alta de usuarios, etc.) sea rápida, con asistentes (tipo siguiente-siguiente) y aceleradores tales como un catálogo de plantillas de procesos sectoriales y horizontales ya preconfigurados, opciones de activación/desactivación de funcionalidades pre-existentes a demanda, etc. • La puesta en marcha la puedan liderar usuarios no técnicos (a.k.a. de negocio) no necesariamente expertos de producto. Se podrá objetar y con razón, que excepto el primero, los anteriores puntos no tienen por qué ser exclusivos de un modelo SaaS. Cierto pero, ¿no es verdad que suenan a ciencia ficción en el caso de los productos tradicionales? – ¿por qué debería ser diferente en el caso de un modelo SaaS? Pues se me ocurren al menos dos razones: • Ya lo he comentado al principio, si no es así el modelo SaaS no se aguanta, por lo que si un proveedor no nos está ofreciendo este tipo de facilidades hay que verificar muy bien el coste-beneficio que esperamos obtener. • Estos elementos deberían ser más fácilmente exigibles a una aplicación SaaS verdadera que a una tradicional ya que, como ya se comentó anteriormente en el punto de Multi-tenancy, su arquitectura ya
10. Luis Carrasco 10 / 22 debería haberse diseñado incluyendo estas premisas y requerimientos. EVOLUCIÓN DEL SERVICIO Dentro de los puntos clave no podía faltar el relativo a asegurar la evolución adecuada del servicio que esperamos recibir una vez puesto en marcha dicho servicio, o dicho de otra forma, de la elasticidad de la aplicación para adaptarse a las necesidades cambiantes que seguro va a tener nuestra empresa. Por eso deberemos pedirle al proveedor de la aplicación información sobre: Evolución de funcionalidades: Cómo nos va a asegurar el proveedor que su aplicación evoluciona tecnológica y funcionalmente con el mercado/sector y con nuestras necesidades específicas. Concretamente: • Qué plan de producto, road map, tiene establecido: módulos, funcionalidades nuevas, etc. Atención a la frecuencia de actualización que, como ya se mencionó en la entrada de esta serie correspondiente a Multi-tenancy, debería ser mayor que la de una aplicación tradicional. • Qué garantías nos da de adaptación a cambios a la legislación vigente, algo especialmente importante en aplicaciones financieras y de RRHH. • Respecto a la evolución de las funcionalidades específicas de nuestra empresa (ya sea mantenimiento evolutivo o despliegue de nuevos módulos y/o funcionalidades) hay que pedir que, como se comentó en la entrada correspondiente al inicio del servicio, pueda ser liderado por la propia empresa, preferentemente por usuarios del negocio -sin dependencias de personal del área de IT, por ejemplo mediante la disponibilidad de un catálogo de plantillas de procesos sectoriales y horizontales que puedan ser desplegadas por usuarios no técnicos, activación y desactivación de funcionalidades pre- existentes a demanda y con un Sandbox para pruebas para así no afectar al sistema en producción. Todos estos puntos no son exclusivos de una aplicación SaaS evidentemente pero es de esperar que sean más asequibles que en las aplicaciones tradicionales por lo ya mencionado anteriormente de que la arquitectura de la aplicación SaaS ya debería haber sido diseñada con estas consideraciones. Escalabilidad/rendimiento de infraestructuras: Hay que considerar que al ser un modelo SaaS vamos a tener que compartir las infraestructuras con otras empresas. Debemos por tanto asegurarnos de conocer qué medios, tecnologías, metodologías, etc. tiene el proveedor para acomodar picos en el número de transacciones en el sistema, ya sean las previsibles (por ejemplo cierres de mes, facturaciones masivas mensuales, etc.) como las no previstas (un nuevo cliente por ejemplo). Otra vez hay que recordar que tenemos que estar seguros que el modelo tecnológico del proveedor es sostenible y viable, no sólo desde el punto de vista tecnológico sino también desde el punto de vista económico. A nadie le va a gustar que se caiga el sistema, o vaya lento, porque la empresa de al lado ha lanzado su proceso de facturación mensual o el proveedor entre en riesgo de quiebra por las inversiones que tiene que realizar para acomodarse al volumen de transacciones que trae un nuevo cliente. Por eso modelos de infraestructura elásticos basados en IaaS de terceros serán recomendables en principio ya que permitirán esa escalabilidad de forma lineal (aunque no olvidemos los temas legales, como se
11. Luis Carrasco 11 / 22 comentará posteriormente en el punto correspondiente a privacidad) Escalabilidad de usuarios: Otro elemento a atar en corto es cómo se gestiona el crecimiento y decrecimiento de usuarios de la aplicación para acomodarse a la dinámica de la empresa. Un ejemplo extremo sería el de una empresa sujeta a una alta temporalidad, donde en la temporada alta sube el número de usuarios. Debemos por tanto tener controlados aspectos como: • Como varían los costes según el nº de usuarios (me extenderé más sobre esto en el punto correspondiente a costes) • Facilidad de replicar/desactivar usuarios, roles, etc. No tendría mucho sentido en un entorno dinámico y ágil, como el que se supone que es un entorno SaaS, que poner en marcha un nuevo usuario sea costoso. Y es que nunca hemos de perder de vista que si estamos barajando una aplicación SaaS es porque nos preocupa, entre otras cosas, la elasticidad de la solución, tanto para crecer como para decrecer. FIN DEL SERVICIO En la Salida o Finalización del Servicio es fundamental que nos aseguremos de la facilidad y rapidez de salida en el caso en que haya problemas, y así no quedarte atrapado por tu proveedor [6]. Este punto está bastante estudiado (vendor lock-in le llaman en la literatura especializada) y es una de los puntos que más se citan como impedimentos y reticencias a los modelos SaaS A mi parecer, se ha de tener en cuenta: Control y portabilidad de los datos: Aunque la empresa cliente tendrá acceso restringido a las infraestructuras y depende en última instancia del proveedor para que le entregue sus propios datos, no se debería aceptar ninguna restricción por parte del proveedor a acceder a tus datos en cualquier momento. Por supuesto que debe haber reglas (seguridad de acceso, formatos, tiempos de preaviso, etc.) pero es un derecho inalienable del cliente el poder extraer su información cuando la necesite y las facilidades que éste tenga van a ser un indicador inestimable de la bondad del proveedor y de su aplicación. El tema se puede complicar si además hay una externalización de procesos (BPO) donde los procesos son efectuados directamente por el propio proveedor ya que entonces será más difícil para el cliente conocer la estructura en detalle de los datos que se quiere llevar. Concretamente, habrá que averiguar del proveedor qué plan de salida ofrece en caso de cese del servicio, con especial atención a: • Formato de los datos para su portabilidad. Archivos planos, Exports de tablas de las bases de datos, … un tema bastante tecnológico que deberá conocerse bien para identificar las posibles limitaciones que pudiera haber. • Punto de corte: es decir en qué momento se hace la foto de los datos para su portabilidad. Una posibilidad, para estar seguros de que el conjunto de datos es coherente, es pedir una copia de seguridad portable en cada cierre de periodo. En teoría, al menos a nivel de datos, serás libre de irte al final de cada periodo con un conjunto coherente de datos.
12. Luis Carrasco 12 / 22 Control y portabilidad de la aplicación: Si el proveedor quiebra o desaparece, o simplemente decido irme, ¿podré llevarme la aplicación y los datos a otro sitio? ¿Lo puedo fijar por contrato? Estas preguntas son de difícil respuesta en según que casos, sobre todo si el software es propietario (o la tecnología en la que fue desarrollado) y desde luego no es algo habitualmente previsto en los contratos que se ven por ahí (no me lo imagino con gigantes como Salesforce.com o NetSuite por ejemplo). A este respecto pues y en principio, será interesante poder optar por aplicaciones Open Source o propietarias con derecho a descarga y modificación de los fuentes para uso exclusivo de la empresa cliente. Conocimiento Adicionalmente tendremos que considerar no sólo la disponibilidad/portabilidad de la aplicación. Tener la aplicación no basta, hay que tener los recursos y el conocimiento (nosotros o terceros) para que funcione. Es por esto que aunque deleguemos totalmente la gestión de aplicación en el proveedor SaaS, mantengamos personas dentro de nuestra organización con el conocimiento necesario para gestinar, aunque sea temporalmente y bajo mínimos, la aplicación hasta que finalice la transición a otro proveedor/aplicación. Condiciones y operativa de salida Es decir fechas de preaviso, posibles penalizaciones y calendarios mínimos (que habrá que acabar de negociar durante la negociación del contrato), coste de servicios adicionales en caso de ser necesarios, etc. No me extenderé sobre algo que está bastante explicado [6] Y para rizar el rizo, ¿Por qué no intentar la Portabilidad de Procesos? En la práctica consiste en poder llevarte contigo la definición de los procesos de negocio soportados por la aplicación, que sólo será posible si ésta, de alguna manera, está basada o respaldada por algún tipo de herramienta BPM, que implemente definiciones de los procesos en formatos estandarizados tipo BPEL, BPMN, XPDL, etc. De esta manera, al menos en teoría, se podrían importar la definición de los procesos a otras aplicaciones de la misma manera que se importarán los datos. Soy consciente de que esta posibilidad es, a día de hoy, remota por el estado de madurez de las herramientas BPM [13] pero no la descartaría a medio plazo. INTEGRACIÓN Es muy probable que la aplicación SaaS que queramos poner en marcha no sea la única de las aplicaciones de la empresa y que necesitemos interconectarlas e integrarlas entre ellas. La dificultad adicional que tenemos que gestionar es que la aplicación SaaS va a estar en un entorno que no está siendo gestionado por nosotros, por lo que se añaden complejidades de índole técnica y operativa que no se pueden desdeñar: necesidad de traspasar un firewall que se supone muy exigente de un tercero, no control de las ventanas temporales y mecanismos de integración si ésta es asíncrona o batch, restricciones de seguridad y técnicas a la hora de hacer una integración en tiempo real, rigideces en formatos de archivos/mensajes de integración,etc. Concretando, deberemos tener en cuenta elementos como: Integración con aplicaciones externas Tales como una Web de ventas, aplicación de nómina, herramientas de BI y/o reporting, EDI, … para las que como ya se ha mencionado antes hay restricciones operativas y técnicas que dificultan la integración. Hay que enterarse muy bien de las vías estándar como APIs, Web Services, herramientas, metodologías, etc. que el proveedor
13. Luis Carrasco 13 / 22 va a poner a nuestra disposición para facilitarnos esta integración desde y hacia fuera de su firewall. Con ofimática Hay que rendirse a la evidencia de que los usuarios trabajan con archivos de ofimática de forma intensiva y que cada vez más a las aplicaciones de negocio se les requiere trabajar con información no estructurada, como los documentos ofimáticos, integrada con la transaccional propia de la aplicación. Y hemos de tener en cuenta que los documentos normalmente están/salen de la red local, del equipo de usuario o de un gestor documental, y que muchas veces esos documentos son pesados, lo que va a suponer un reto para el ancho de banda disponible y el rendimiento en general de la aplicación. Otra opción, que me parece muy interesante, es la de usar ofimática en la nube. En ese sentido apunta la decisión de SAP de integrar SAP Business ByDesign con las aplicaciones de negocio de Google [7] Dispositivos locales: Como impresoras, PLCs/Sensores en entornos industriales, controles de presencia, etc. Tendremos que verificar cuidadosamente los requerimientos técnicos de estos equipos para estar integrados con la aplicación SaaS en cuestión. Si por esta razón se han de cambiar equipos, el Business Case de la operación se puede resentir. Hemos de ser consciente pues que una báscula que vuelca datos al ERP, una impresora de código de barras o térmica, un PLC controlado desde el ERP, etc. pueden ser dispositivos más complicados de integrar en un entorno Cloud. PRIVACIDAD Llegamos al tema, nada trivial por los aspectos legales y de procedimiento que hay detrás, de la seguridad y privacidad. Vaya por delante que trasciende el propósito de este artículo hacer una descripción exhaustiva de la legislación que debe aplicarse, y como no tengo la formación ni la experiencia en temas legales requerida para ello, me limitaré a los aspectos técnicos y operativos y a proporcionar una lista de elementos a contrastar con el proveedor, que he podido recopilar. Dicho de forma muy sintetizada: hay que asegurarse de que nuestros datos sensibles (entendiendo como sensibles, datos de tipo personal o los propios secretos de la empresa) van a ser almacenados y tratados de una forma que se cumpla la legislación vigente en materia de privacidad y seguridad, lo que acabará afectando a cualquier elemento del servicio relacionado con: • Ubicación de los datos • Seguridad de acceso y almacenamiento • Tratamiento automatizado Concretamente, tendremos que comprobar (y que se refleje de alguna manera en el contrato con el proveedor) al menos lo siguiente: ¿Realmente nuestro proveedor SaaS va tener que almacenar/tratar datos sensibles? Datos personales, según se definan en la legislación vigente, que nos comprometen como empresa y para los que hay diversos niveles de sensibilidad- No es lo mismo una nómina que una factura, y ya no digamos datos médicos de un empleado. Datos propios de la empresa “secretos”: propiedad intelectual, i+d, fórmulas, listas de inversores,… Será una tarea clave la identificación de estos datos y los controles que deberemos acordar con
14. Luis Carrasco 14 / 22 el proveedor para garantizar el cumplimiento, tanto de nuestros requisitos de seguridad como el de los legales. ¿Cuál es la ubicación de los servidores? En la legislación española sobre datos de caracter personal, si los servidores van a estar fuera de las fronteras españolas aplica el concepto de “transferencia internacional” de los datos, lo que obliga a comprobar que el país destino está “homologado” por las autoridades españolas como ubicación “aceptable”. Actualmente es aceptado cualquier país del Espacio Económico Europeo o de aquellos que la Agencia de Protección de Datos tiene en su lista de Países con un nivel adecuado de protección. Atención también a los proveedores de nuestro proveedor. ¿Qué tipo de seguridad, física, respaldo, procedimientos, acceso a servidores, etc. tiene activada el proveedor? Sin ánimo de extenderme en este tema, el proveedor debería poder mostrar qué medidas de seguridad tiene implementadas. Lo más fácil es que pueda acreditar tales medidas mediante certificaciones del tipo ISO27001, SAS 70 type II o equivalente y que pase las auditorías específicas pertinentes que marcan esas certificaciones. ¿Cómo se accede y “viajan” los datos? ¿El acceso, presumiblemente vía Web, es seguro,vía https/SSL o VPN, o equivalente? ¿Se cifran los datos sensibles, que lo requieran, al viajar y ser almacenados? ¿Quién puede acceder y tratar los datos sensibles? Aparte del proveedor principal, ¿hay subcontratados o terceros que pueden acceder y/o tratar nuestros datos? Debe tenerse en cuenta que es posible que nuestro proveedor SaaS esté utilizando recursos e infraestructuras de terceros, por ejemplo una aplicación que corra en los servidores de Amazon. Obviamente tendremos que conocer hasta el final la cadena de proveedores y tenerlo en cuenta en el contrato (por ejemplo que sea necesaria la autorización previa para cualquier subcontratación o cesión del servicio a un tercero por parte de nuestro proveedor SaaS ) ¿Como nos afecta la legislación específica, por ejemplo la LOPD en el caso de España? Es fundamental conocer de acuerdo a la legislación, el responsable último es siempre la empresa, por lo que se deberá acotar muy bien en el contrato, aparte de todo lo mencionado anteriormente, los límites y salvaguardas en el tratamiento de los datos: fines de ese tratamiento, como se devolverán y destruirán, etc. …y si, los seguramente super-exigentes, abogados del BBVA no ven ningún problema en que información tan sensible como la que manejan los empleados del banco esté en la nube…[8] qué podemos decir aquí. Para acabar este apartado, recomiendo la lectura de las referencias [9] respecto a privacidad que se relacionan en la sección de referencias. GOBIERNO DEL SERVICIO Si vamos a utilizar una aplicación en modo SaaS – Software as a Service - tendremos que gestionar ese as a Service y la manera habitual de gestionar cualquier servicio externalizado es mediante acuerdos sobre la calidad del servicio que espera recibir el cliente del proveedor o, en la jerga del sector, SLAs [10] (Service Level Agreement) ligados a la QoS (Quality of Service). Esta entrada no pretende cubrir en detalle qué es un SLA ni como se negocia/acuerda, hay mucha literatura, y buena, disponible, sino en los puntos particulares que pueda tener la gestión y medición del servicio en el caso de aplicaciones SaaS de gestión.
15. Luis Carrasco 15 / 22 Dicho esto, cuando estemos negociando con nuestro proveedor de aplicaciones SaaS de gestión cómo se va a gestionar,medir y gobernar el servicio que nos quiere vender, tendremos que atender, al menos, a los siguientes puntos: Niveles de servicio por capas. Teniendo en cuenta la arquitectura típica de este tipo de aplicaciones es conveniente conocer los niveles de servicio para las distintas capas tecnológicas que la conforman: • Aplicación • Integración/Middleware • Infraestructuras En principio los niveles de servicio que más hemos de controlar directamente son los de Aplicación. El resto pueden ser relevantes si hay terceros proveedores, por ejemplo en la capa de infraestructuras. Y si ese es el caso leer bien los SLAs ofrecidos por ese tercero no vaya a ser que no estés cubierto adecuadamente [11] Niveles de servicio por tipo Los niveles de servicio se pueden definir de varios tipos. En este contexto no debería faltar: • Rendimiento de la aplicación. Estos niveles de servicio no es aconsejable que sean genéricos y se han de intentar definir para las transacciones que consideremos más importantes – por ejemplo tiempo que se tarda en finalizar la entrada de un pedido de cliente. Es recomendable que cada empresa revise su caso particular y no acepte por defecto las estándares (si las hubiere, que es poco probable). Otro tema es como se mide. • Tiempos/calidad de respuesta al soporte. Tiempos relacionados con consultas, incidencias, etc. de los usuarios finales o de los técnicos. Aparte de estos tiempos hay que definir tipos de incidencia/consulta, prioridades, etc. • Disponibilidad de la aplicación. Normalmente se expresa en porcentajes de tiempo y excluye los tiempos dedicados a mantenimiento de la plataforma. No olvidar especificar el periodo de medición de esa disponibilidad (no es lo mismo el 99,9% de disponibilidad mensual que anual). • No disponibilidad del servicio por mantenimiento. Ya sé que se ha dicho antes que en una aplicación true SaaS el cliente ni se tiene que enterar de un cambio de versión pero entiendo que la plataforma requerirá paradas por mantenimiento. Hay que prestar atención a tiempos de preaviso y horarios (no es lo mismo no tener disponible la plataforma el día que lanzas la facturación mensual que no tenerla un domingo) • Tiempos de puesta en marcha de nuevas funcionalidades. Si la aplicación, como debería una True SaaS, permite activar/desactivar funcionalidades, será conveniente especificar el tiempo de activación/desactivación operativa. Ligados a los procesos de negocio Ya se ha apuntado antes pero lo recalco. Estamos en un contexto de aplicaciones de gestión empresarial. Cualquier parámetro de gestión del servicio/sistema ha de tener como referente los procesos de negocio cuando se traten temas de disponibilidad, horarios, rendimientos, velocidad, tiempos de ejecución,… aunque hemos de ser conscientes del reto que puede suponer para el proveedor trabajar en ese modo. Hay más elementos a tener en cuenta a la hora de negociar los SLAs pero no veo que tengan particularidades relevantes con respecto a un SaaS de aplicaciones de gestión. No obstante no nos olvidemos de temas como:
16. Luis Carrasco 16 / 22 • Ajuste/renegociación de SLA. Hay que prever la posibilidad de ajustar periódicamente los parámetros que miden la calidad del servicio • Monitorización. ¿Cómo va el cliente a ver en tiempo real los parámetros de medición de la calidad del servicio y problemas que puedan haber? • Reporting. Forma, periodicidad, formato de la información, etc. que el proveedor va a poner a disposición del cliente para el seguimiento de la calidad del servicio. • Penalizaciones/incentivos si las expectativas no se cumplen o se cumplen mejor de lo previsto • Mecanismos para la mejora continua. Cómo incorporar las lecciones aprendidas y el conocimiento adquirido de errores en mejorar la gestión y el servicio No se me escapa que este punto ha quedado bastante genérico pero es que es un tema muy extenso. He intentado al menos citar los puntos más importantes. GESTIÓN DE COSTES No puede faltar en este repaso de los puntos clave a considerar al seleccionar una aplicación de negocio SaaS, el de los costes. Y es que uno de los atractivos que posiblemente busquemos al optar por un modelo SaaS es el de variabilizar los costes totales de propiedad de la aplicación de gestión. Esta variabilización se conseguirá al utilizarse un modelo de suscripción/pago de una cuota periódica relacionada con el uso que se hace del sistema y que incluye todo (licencias, infraestructuras, help-desk, nuevas versiones, etc.). Y ese “relacionada con el uso que hace del sistema“ es clave en toda la gestión de costes: ¿Cómo nos va a medir el uso del sistema nuestro proveedor? Pues mejor temprano que tarde tendremos que conocer bien su modelo de indexación del servicio, que habitualmente viene dado por uno o una combinación de los siguientes elementos: • Nº de Usuarios de la aplicación, ya sean concurrentes (sólo cuentan los que estén conectados en un momento dado) o nominales (cuentan se conecten o no – ¡pero cuidado con el shelfware! [12]). En el caso de concurrentes tendríamos modelos dinámicos donde se pueden conectar todos los que quieren y luego te facturan o con un tope, donde si éste es “n”, el usuario “n+1″ que se quiera conectar no puede. • Tipos de usuario: No todos los usuarios son iguales. Por ejemplo los hay que utilizan todas las funciones, intensiva o esporádicamente, otros que utilizan una funcionalidad determinada de forma intensiva, los que se conectan sólo para consultar, … lo habitual es que se establezcan diferencias a nivel de tarificación entre estos diferentes tipos de usuario. • Por módulos / funcionalidad activada / desactivada. Es decir por el tipo de uso que se hace de la aplicación. A considerar en este caso, la facilidad que deberemos requerir de nuestro proveedor para tener una gestión ágil de este uso tal como se ha mencionado en el apartado sobre evolución. • Transacciones por periodo. Este modelo puede ser muy ventajoso si se liga a transacciones que suponen ingresos ya que el coste del servicio se liga al ingreso. Por ejemplo por número de pedidos de clientes entrados, facturas emitidas, clientes a los que se le factura en el mes,… o incluso un porcentaje de la facturación. • Consumo de recursos de computación. Esto, que se llegó a hacer en los albores de
17. Luis Carrasco 17 / 22 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.
18. Luis Carrasco 18 / 22 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.
19. Luis Carrasco 19 / 22 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
20. Luis Carrasco 20 / 22 Un ejemplo de condiciones de privacidad de un proveedor (SalesForce) http://www.salesforce.com/company/privacy/ Un ejemplo de condiciones de disponibilidad (Netsuite) http://www.netsuite.com/portal/infrastructure/availability.shtml Lista de 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
21. Luis Carrasco 21 / 22 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
22. Luis Carrasco 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.