Selección de aplicaciones SaaS.Puntos clave

 

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 (en este último informe que he leído, por ejemplo, lo explican muy bien).

No tengo cifras locales concretas (si alguien las tiene que comente), 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 una oferta suficiente.

Aunque 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 siempre 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.

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 una serie de entradas sobre qué es lo que hay que saber antes de decidir mover las aplicaciones de negocio a un modelo SaaS.

La serie, que iré publicando paulatinamente en los próximos días, la he estructurado alrededor de los siguientes puntos clave:

  1. Multi-tenancy. Como condición necesaria para que el modelo sea sostenible.
  2. Tecnología. Consideraciones respecto de la arquitectura tecnológica de la aplicación SaaS.
  3. Inicio del Servicio. Qué hemos de tener en cuenta en relación a como se pone en marcha el servicio.
  4. 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.
  5. Fin del servicio. Elementos importantes en el momento de finalizar la relación con el proveedor de la aplicación SaaS
  6. Integración. Consideraciones a la relación de la aplicación SaaS con otras aplicaciones
  7. Privacidad. Cómo cumplir la legislación vigente y proteger nuestros datos sensibles.
  8. Gestión del servicio. Gobierno de la relación con el proveedor y gestión de la calidad del servicio.
  9. Costes. Qué elementos de coste hemos de vigilar.

Cada uno de los temas 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 esta serie 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.

Para acabar esta primera entrada, los puntos cubiertos en la serie, por genéricos, deben considerarse como una guía de partida, una especie de check-list, 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 🙂

El resto de la serie y otras entradas relacionadas: Selección de aplicaciones de negocio SaaS. Puntos clave

 

[ *] 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.

 

Foto: Michael Heiss

 

Actualización 23/1/2012:

En la línea de que los modelos SaaS avanzan en su implantación, enlazo este post que recoge una serie de pronósticos de relevantes analistas.

 

Actualización 25/1/2012:

En la encuesta del 2012 que Gartner hace a  CIOs de todo el mundo, de las 10 prioridades tecnológicas, el Cloud Computing (SaaS, PaaS, IaaS) es la tercera, la modernización de Legacy Systems es la sexta y las aplicaciones ERP la novena.

 

 

 

Transición a SaaS para fabricantes e integradores

Es relativamente fácil encontrar literatura acerca de las dificultades y barreras de adopción del modelo SaaS por parte de las empresas (lado demanda) y menos fácil encontrarlo sobre esas dificultades en el lado de la oferta (fabricantes e integradores) para poder ofrecer ese modelo a sus clientes.

Por ello me ha parecido interesante ordenar una serie de reflexiones que he venido leyendo y comentando en diferentes foros (*) sobre qué factores dificultan a las empresas proveedoras a  hacer la transición desde un modelo tradicional (venta de licencias + servicios + mantenimientos) a ese modelo SaaS.

Pero antes creo aconsejable precisar que entiendo que una aplicación sigue un modelo true SaaS cuando cumple los siguientes requisitos: Continuar leyendo

Multitenancy, ese difuso concepto

 

 

Según la definición que más me gusta del concepto Multitenancy, una aplicación de gestión SaaS además es Multitenancy si cumple simultáneamente:

  • 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.

 

Multitenancy, al mismo  tiempo que piedra angular que sostiene todo modelo viable de delivery SaaS de una aplicación de gestión, es un concepto que habitualmente se maneja con poco rigor y que puede ser confuso, porque, en mi opinión, no es un término absoluto sino relativo: una aplicación SaaS no es que, SI o NO, sea Multitenancy, sino que lo es más o menos en relación a otras con las que se compare.

 

Y ello es así por varias razones:

  • Adaptarse a diferentes requerimientos, manteniendo compatibilidades, tiene siempre un límite para una determinada aplicación. Entre dos aplicaciones SaaS, cuanto más lejos esté ese límite en una aplicación con respecto a otra, más Multitenancy es la primera. Soy consciente de que ese más lejos, en esta afirmación hay que definirlo bien en cada caso o comparación.
  • La viabilidad (capacidad de que sea rentable económicamente) para el proveedor vendrá dada, no sólo por la tecnología que use, sino también por lo buenos que sean sus procesos internos. Un proveedor SaaS podrá permitirse tener una tecnología menos preparada para el Multitenancy si es muy eficiente en sus metodologías y procesos de desarrollo, servicio al cliente, despliegue de versiones, etc.
  • Influye mucho las dispersión de funcionalidades requeridas por sus clientes. Cuanto más homogéneas y comunes, más fácil de compartir que será la aplicación. Es decir, en un entorno homogéneo las exigencias Multitenancy serán menores. Por eso las aplicaciones SaaS que quieran ser muy Multitenancy (siempre en términos relativos) deberán tender a verticalizarse, es decir a especializarse por funciones o sectores.

 

En conclusión, cuando evalúes una aplicación SaaS, la pregunta correcta no es si es o no Multitenancy, sino en qué grado lo es en relación al conjunto de aplicaciones evaluadas.

Novedades sobre SAP Business ByDesign

Me acabo de enterar por una persona de SAP que en breve se va a anunciar (por fin) el lanzamiento de SAP Business ByDesign para el tercer trimestre de este año.

El producto, buque insignia de SAP en su estrategia SaaS de ERP en la nube – ya escribí algo al respecto en 2007, cuando aún se le conocía por su nombre en clave A1S… ¡pasa el tiempo rápido! – lleva funcionando desde hace unos años en algunos países (EEUU, Alemania, India, Australia, …)  y ya parece que lo tienen preparado para que pueda ser comercializado en España.

Vale la pena recordar rápidamente algunas de las características clave del producto (¿o deberíamos llamarle servicio ya directamente?)

  • Se licencia por usuario (con un mínimo de 10) en diferentes modalidades o sabores (CRM, Finanzas+RRHH, Producción, Gestión por Proyectos, …) y en el rango de 11$ a 199$ por usuario y mes, dependiendo de módulos, tipo de uso, etc. En este enlace se muestra un buen resumen, pero cuidado, esos precios son los del mercado USA.
  • Es un producto nuevo, reescrito desde cero, sin lastres de código del producto SAP de toda la vida. No he tenido la oportunidad de comprobarlo personalmente pero otros analistas y bloggers hablan de funcionalidades comparables a las de su hermano mayor.
  • Para su despliegue rápido trae la metodología/herramienta de configuración Business Configuration Implementation Methodology.
  • Para el desarrollo de adaptaciones, integración con otras aplicaciones e incluso programación de nuevas aplicaciones dispone de una plataforma de desarrollo PaaS (no podía ser de otra forma)  llamada ByDesign Studio.
  • Hasta donde yo sé, se despliega en Data Centers del propio SAP en EEUU y Alemania, pero me gustaría poder contrastarlo.

 

Espero poder recoger más información porque tengo muchas dudas:

  • Precio en España.
  • Qué Partners de SAP son capaces de implantarlo.
  • Empresas target, teniendo en cuenta que MidMarket en EEUU es ya una empresa grande en España y probablemente ya tenga un ERP consolidado e incluso que este ya sea SAP R/3.
  • Grado de cobertura de funcionalidades específicas del mercado español, sobre todo en el área de RRHH y financiera-contable.
  • Cómo van a evitar que canibalice a otros productos como SAP Business One o SAP All-In-One. Será interesante ver la reacción de los partners tradicionales, sobre todo los que ya se han embarcado en poner esos productos tradicionales en modalidad de pago por uso y desplegados en Cloud (algo que no es SaaS necesariamente – recordemos que todo SaaS es Cloud pero no todo lo Cloud es SaaS).
  • Cómo se implanta, metodologías, tiempos, tareas, …

 

Otras entradas relacionadas:

 

Antes de implantar un ERP…

Eres el CEO (o el CIO, el CFO, da igual) de una compañía que ha crecido mucho, y notas que hay cosas que ya no funcionan como antes: pedidos que pierdes o se sirven mal, cargas administrativas que retardan decisiones y acciones, clientes que se quejan, equipo desbordado de trabajo, horas extras, … !los procesos de tu empresa no escalan!

Después de analizar sesudamente la situación, leer blogs como este, hablar con colegas… llegas a una brillante conclusion: ¡necesito in ERP!

Te convences de que un sistema de gestión adecuado mecanizará tus procesos manuales, conducirá las tareas de tus equipos, te dará información a tiempo, guiará tus decisiones, te traerá un café cada día cuando llegues a la oficina,… bueno eso no.

Investigas sobre tendencias, te pones a buscar, incluso ya empiezas a pensar en el ERP como un servicio, ves que lo puedes implantar de forma ágil, inicias el proceso de selección

Pero mejor que no vayas tan rápido. Antes de embarcarte en un proyecto de implantación de un ERP deberías reflexionar sobre los siguientes puntos, al menos:

  • ¿Cómo son tus cadenas de decisión? Es posible que con el nuevo sistema alguna no tenga sentido y reproducirlas en el nuevo sistema no sea práctico o te sobren niveles. ¿Estás preparado para reorganizarlas? ¿Para eliminarlas incluso?
  • ¿Cómo te relacionas con clientes y proveedores?  ¿Qué información intercambias, con qué periodicidad, en qué formato? ¿Esos intercambios de información serán necesarios? ¿Serán suficientes?
  • ¿Qué «papel» estás produciendo/utilizando/recibiendo? Suele dar buenas pistas de por donde empezar a mejorar.
  • ¿Gestionas transacciones por «lotes» o «una a una»? ¿Secuenciales o en paralelo? ¿Trabajas con transacciones estándares, con poca variabilidad? ¿Bajo pedido?  ¿Sobre inventario – podrías cambiar eso si fueses más rápido fabricando? ¿o no valdría la pena?… en definitiva ¿realmente conoces cómo funcionan los procesos y transacciones de tu organización?
  • ¿Cómo es tu equipo? ¿Está listo para un cambio ahora? ¿Es el equipo que necesitas?
  • ¿Qué procesos son críticos? ¿Cuáles se pueden quedar parados una hora como máximo? ¿Cuántos un día? ¿Y una semana?
  • ¿Qué información confidencial/sensible se gestiona?  ¿Podrás «meterla» en un ordenador?
  • ¿A quién de tu organización le va a impactar más el cambio? ¿Podrá asumirlo? ¿Podrá sacar su día a día y además involucrarse en la implantación del nuevo sistema? Si no es así piénsatelo otra vez.
  • ¿Conoces los tiempos de tu negocio? ¿Qué tiempo transcurre entre que inicias una acción comercial y recibes el primer pedido?
  • ¿Cuánto tiempo tienes para que el ERP esté operativo? ¿Sabías que sobre la mitad de implantaciones de ERPs acaban más tarde de lo planificado y gastando  más de lo presupuestado si se plantean «a lo grande»? ¿Podrías implantarlo de manera gradual, empezando con lo básico o lo necesitas todo el primer día?
  • ¿Con un ERP tendrás suficiente? ¿O incluso, es el ERP lo más importante o quizá necesites otro tipo de sistema antes, un CRM por ejemplo?

 

Son sólo unas preguntas y no están todas, pero si te las haces a tiempo te pueden ayudar a que tu proyecto de implantación pueda empezar ya con buen pie.

***

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.
Si necesitas ayuda o soporte en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.

 

SAP Business ByDesign

th00123Bueno, aprovechando mi viaje diario de vuelta a casa en cercanías y sacrificando algunos minutos de sueño (¿pero no era esto del blog un hobby?), he podido digerir la nota oficial de lanzamiento de Business ByDesign (antes conocido por A1S) y leer las primeras crónicas y reacciones (por cierto, puedo constatar y constato que los blogs han ganado por goleada a los medios on-line)

(Recordatorio: A1S, ahora ya conocido como Business ByDesign, es como ha denominado SAP a su nuevo producto/servicio ERP destinado a cuentas medianas y bajo un modelo SaaS – pago por uso que incluye licencias de software, servicios, mantenimiento, gestión de infraestructuras y éstas alojadas en un centro fuera de la empresa cliente).

Hoy era el gran día donde SAP, en una esperada conferencia en Nueva York, anunciaba los detalles sobre A1S, ahora ya Business byDesign y éste que sigue es el pequeño y modesto resumen que he podido preparar. Como estoy cansado y tengo ganas de irme a la cama no me detendré en adornar demasiado la prosa y redactaré en forma telegráfica (es lo que tiene ser un amateur):
Definición oficial.
On-demand software solution with built-in service and support (Solución bajo demanda que incorpora servicio y soporte incorporado). Complementa a la oferta actual de SAP para la pequeña y mediana empresa (SAP Business One y SAP All-In-One).

Historia y hoja de ruta.
Fruto del esfuerzo de alrededor de 1.000 empleados de SAP durante cuatro años y alrededor de 350 millones de euros (¿sólo?). Lleva probándose desde seis meses antes del anuncio con clientes seleccionados de Alemania y EEUU (20 ya en producción y 45 en pruebas todavía). En los próximos meses se incorporarán al club de los elegidos compañías del Reino Unido. En España llegará durante el 2008 – también con clientes seleccionados.

Testimonio.
Kevin Flanagan (nombre que induce al chiste por estos pagos, by the way), el CEO de Compass Pharma Services LLC, una de las compañías que ya lo tiene en producción, afirma ufano y entusiasmado que esperan reducir su presupuesto actual de IT en menos del 25% del actual (sí, eso es lo que dice, no has leído mal)… ¡buff!

Mercado objetivo.
Empresas medias de 100 a 500 empleados que crezcan muy rápido y que aún no han invertido en un gran ERP. SAP estima que hay, sólo en Alemania y EEUU, alrededor de 60.000 compañías con ese retrato robot. En España, si escalas en número de usuarios – por ejemplo de 10 a 50 usuarios – hay un montón.

Funcionalidad.
Este punto es clave. El alcance funcional es Finanzas, Operaciones (no se precisa más) y Recursos Humanos (menos nómina). No van a contemplar funcionalidades verticales (de un sector concreto) y se va a intentar tener una funcionalidad estándar lo más amplia posible (en contraposición al modelo actual de tener una funcionalidad horizontal básica y extenderla con módulos verticalizados – adaptados a cada sector).
El objetivo es que NO haya adaptaciones – funcionalidad estándar para todos. Es coherente con el modelo SaaS de forma que se puedan compartir las infraestructuras entre los clientes y las implantaciones se puedan hacer como churros de una forma rápida y repetitiva.

Estrategia de Partners.
Otro punto clave y que SAP no ha clarificado – es la incógnita estrella en estos momentos. Está claro que el modelo actual, para este producto, no sirve ya que se basa en que el Partner hace negocio con servicios alrededor de la implantación del ERP (la relación típica es de 3 euros de servicios por cada euro de licencias).
Ha trascendido que han llegado a un acuerdo con ADP (empresa con soluciones de nómina, que ya ofrece sus productos en modo SaaS desde hace años)

Tecnología.
El producto se ha desarrollado desde cero utilizando la plataforma tecnológica de SAP NetWeaver. No tengo más detalles

Precio.
El precio en EEUU empieza desde 149$ por usuario/mes con funcionalidad completa y con un mínimo de 25 usuarios (este número de usuarios mínimo lo tendrán que cambiar en España seguro).
Hay paquetes para 5 usuarios con funcionalidad reducida (una única función de negocio) a partir de 54$ por mes – esta es una buena estrategia.

 

* * * * *

Incógnitas.

A bote pronto ya se me ocurren las siguientes:

  • ¿Qué pasa con los partners actuales? – especialmente con los que se dedican al mercado de medianas empresas. Van a tener que pasar de un modelo de negocio basado en servicios de implantación e integración (donde los ingresos por horas triplican como poco a los ingresos por venta de licencias) a un modelo que nadie se ha atrevido a explicar todavía. De pocos proyectos y largos, a muchos proyectos y cortos – es fácil ver que es todo un cambio estructural
  • ¿Lo podrá digerir SAP? – Es un cambio de modelo de negocio que requerirá cambios organizativos y de perfil de su personal.
  • ¿Será suficiente la funcionalidad estándar para todos? – independientemente del sector.
  • ¿Cómo se integrará la nueva aplicación con otras aplicaciones de las empresas? – si hay funcionalidades no cubiertas se tendrán que cubrir con otras aplicaciones, y se requerirá una integración.
  • ¿Cómo va a responder la competencia? – y aquí hay que distinguir a la competencia que ya es SaaS (NetSuite, Salesforce, …) de la tradicional (Microsoft, Oracle, …). Es de esperar movimientos interesantes.

Si has llegado hasta aquí es que el tema te interesa bastante, por lo que a lo mejor te son útiles los siguientes enlaces:

Nota Oficial de SAP

La grabación del anuncio

Página oficial de producto

La opinión de Nic Carr

Los blogs de ZDNet

Nota: pido disculpas por lo sintética, acelerada y atropellada que es esta entrada, pero he priorizado la velocidad en dar la información a la forma.

****

Actualización: Hoy (21/9) he hablado con un gerente de uno de los partners de SAP en España que se pueden ver más afectados a medio plazo. Para mi sorpresa y estupefacción, no tenía ni p… idea de lo que le estaba hablando.

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies