Advertencias sobre el software como servicio

Hasta ahora, el modelo de software como servicio (SaaS) ha sido adoptado en los mundos de automatización del equipo de ventas (SFA) y gestión de las relaciones con los clientes (CRM), donde el èxito que han tenido últimamente NetSuite, Salesforce.com y RightNow ha tenido una influencia sobre los fabricantes de software tradicional para que se ocupen y modifiquen sus carteras de productos. Sin embargo, esos mismos proveedores que trabajan arduamente para habilitar algunas de sus ofertas como SaaS, esperan ganar tiempo haciendo notar que hasta ahora, la implementación de SaaS ha sido una soluciòn comprobada ùnicamente para ciertas necesidades de negocios bien definidas, especialmente en cada departamento de una empresa.

Si desea saber más sobre la tendencia hacia SaaS, consulte El software como servicio.

Segunda parte de la serie El software como servicio.

A pesar del èxito que han tenido las empresas antes mencionadas, mucha gente sigue sin creer en el èxito que puede tener SaaS a largo plazo. Algunos de los problemas que les daràn más vida a las aplicaciones que se encuentran en los locales son la sensibilidad de los datos, la privacidad y la seguridad (fuera del cortafuegos de los usuarios), la flexibilidad del sistema y las preocupaciones sobre las interrupciones de poder que se han dado últimamente y que han sido el objeto de mucha publicidad (que se traducen en preocupaciones generales sobre el desempeño de los sistemas). además de estas preocupaciones, está la cuestión de si las ofertas alojadas por demanda pueden integrarse correctamente con las aplicaciones existentes en los locales, asì como la escepticismo sobre la utilidad de adaptar las soluciones SaaS o por demanda a las pràcticas y los procesos ùnicos de negocios.

Tanto Salesforce.com como otras empresas que defienden SaaS ofrecen soluciones que se pueden adaptar a dichas operaciones de negocios estàndar como la captura de oportunidades y prospectos de ventas. Sin embargo, al usar la arquitectura de varios inquilinos, que permite almacenar grandes volúmenes de datos de varios clientes en una sola instancia de la base de datos en los locales del proveedor (muchos más metadatos que debe mantener el proveedor), dichas aplicaciones no pueden ofrecer a las empresas (especialmente a las grandes empresas que son muy demandantes) los tipos de diferenciadores que necesitan para aumentar sus ventas y sus ganancias u obtener una participación en el mercado. De hecho, los procesos de SFA son rutinarios y por lo general no generan ingresos cuando su funcionalidad se encarga ùnicamente de capturar las opiniones del personal de ventas sobre las oportunidades y de asegurarse de que se apegan a las reglas de los procesos de ventas.

Los equipos de ventas tienen mucha experiencia en aprovechar este modelo de entregas “unitalla”, ya que hasta hora son la funciòn de procesos de negocios menos regulada. Este modelo de entregas permite que cada vendedor implemente una soluciòn ràpidamente porque, según ellos, las herramientas que usan no afectan otras partes de la empresa. Es decir que en dichos ambientes, no tiene caso realizar una personalización extensa del sistema SFA, ya que los detalles del proceso de ventas no son la parte más importante. Por ejemplo, ya que la planeaciòn implica alguna habilidad para influenciar de forma preactiva el resultado, aquellas empresas usuarias que han tratado de integrar la funciòn SFA desconectada con los pronòsticos, la satisfacción y los aspectos contables, han descubierto más retos al tratar de hacerlo con SaaS.

Dicho de otro modo, de forma parecida a la regla “80-20”, SaaS no puede proporcionar ese 20 por ciento final que diferencia a cualquier empresa de sus competidores. La necesidad de diferenciación exige que la empresa busque proveedores más tradicionales que tengan experiencia en esa industria especìfica y huellas funcionales más amplias que les permitan acomodarse a los procesos de negocios interdepartamentales que estàn en evolución. Al menos, la realidad para muchas empresas serà la coexistencia de SaaS con aplicaciones en los locales (Microsoft cita la existencia de modelos duales, en donde una aplicación instalada en una PC puede ser mejorada mediante una funcionalidad en lìnea, como sucediò con reproductores tipo Windows Media Player), asì que SaaS podrà ir más allà de proporcionar una eficacia operativa para tratar de ayudar a que los negocios aumenten su eficiencia. El hecho de dar a los usuarios la capacidad para personalizar los nombres de los campos que aparecen en las pantallas, como sucede con el servicio de Salesforce.com, no representarà la verdadera diferencia. Tampoco lo harà dar a los usuarios la facilidad para escribir JavaScript (o algo similar) y colocar el localizador de recursos universal (URL) para el script en un campo personalizado, o permitir el uso de acceso por pestañas y hojas de estilo, que es lo que Salesforce.com conoce como “personalización”.

Esto se parece a la idea “ajà” de la “experiencia de usuario iPod”, en la que los usuarios pueden escuchar y organizar la mùsica a su gusto. Las empresas deben llevar sus procesos de negocios de forma diferente a como lo han hecho en el pasado si quieren diferenciarse de los demás; esto incluye crear funciones nuevas y flujos entre empresas o departamentos. Asì, queda por ver si Apex de Salesforce.com, el lenguaje interpretativo de varios inquilinos que acaba de revelar el proveedor, serà de utilidad en este sentido. Apex, que es un motor de funcionamiento con sintaxis tipo Java y la funcionalidad de lenguaje de consultas estructurado por lenguaje de procedimientos (PLSQL) (ya que la base de datos subyacente de Salesforce.com es Oracle), se diseñò para funcionar con la interfaz de programación de aplicaciones (API) de Salesforce.com. La funcionalidad de Apex es limitada y sòlo puede hacer lo que se pensò harìa al diseñarla (habilitadores especiales de bases de datos y procedimientos almacenados, por ejemplo), y en realidad no es el lenguaje de programación de efectos generales que se necesita para adaptarse a una programación personalizada importante. Nuevamente, las ventajas de tener un ambiente controlado tienen su lado negativo, que son modificaciones limitadas. Las empresas tambièn quieren tener más control sobre sus aplicaciones, ya que constantemente deben cambiar sus configuraciones para agregar productos nuevos, desarrollar una integración más estrecha entre sus sistemas e introducir los mejores procesos de negocios.

Por estas razones, hasta Salesforce.com está tratando de romper el esquema tan estrecho en el que iniciò como empresa CRM/SFA. Sus esfuerzos más agresivos se concentran en su plataforma de socios AppExchange y el ecosistema de aplicaciones de terceros, para aumentar su alcance funcional y crear procesos de negocios que representen una diferencia mayor y vayan desde la oportunidad de ventas hasta la orden. El tiempo dirà si esta estrategia funciona con los socios de integración de datos y analìtica y business intelligence (BI) (algunos de los cuales son empresas importantes, como Business Objects, Informatica o Pervasive Software); socios de gestión de los incentivos empresariales (EIM) como Centive, Xactly Corporation, Cellarstone o Perks.com (cuyas capacidades funcionales y procesos de planeaciòn de simulaciones deben ser capaces de influenciar el comportamiento de los equipos de venas ante los aumentos en los ingresos); configuración de productos y gestión de las relaciones con los socios (PRM)/gestión de la cadena de demanda (DCM) (como Selectica, Comergent, Webcom Inc., Big Machines, Firepond, etc.); socios de automatización de la mercadotecnia y analìtica, etc. además, algunos socios de AppXchange se han enfocado últimamente en desarrollar el segmento vertical de servicios financieros y crear posteriormente una estrategia para sus àreas más cercanas, como seguros, medios, banca, etc.

En cuanto a Apex, tambièn está creada en una arquitectura de varios inquilinos, es decir que el còdigo de cada cliente está segregado de los còdigos de los demás clientes, aunque todos los clientes funcionan en la misma instancia de Salesforce.com. Si bien esta segregación de còdigos debe aumentar la capacidad que tiene cada cliente para personalizar su sistema, algunos socios de AppXchange se han demostrado preocupados por que puede masacrar sus negocios y la necesidad de sus soluciones.

Hace poco, a mediados de diciembre de 2006, Salesforce.com anunciò su estrategia de visiòn y monetizaciòn AppStore para el mercado de AppExchange (Apex). Los clientes podràn usar AppStore como fuente ùnica para tratar, comprar e implementar aplicaciones por demanda en AppExchange. Eventualmente AppStore ofrecerà un paquete completo de servicios comerciales y programas de repartición de ganancias para los desarrolladores y los socios (un modelo de ventas sin toque, administrado por completo por Salesforce.com). Entonces los desarrolladores y los socios podràn usar AppStore como red de distribución global para comercializar, vender, facturar y entregar las aplicaciones que han creado usando el lenguaje de programación y la plataforma Apex que obtuvieron a travès de AppExchange. Se espera que AppStore sea el catalizador que libere el valor de Apex y AppExchange, y que acelere la visiòn para la creación, la entrega y el èxito de prácticamente cualquier aplicación por demanda. La idea es que AppStore debe hacer que la compra de aplicaciones por demanda se tan fácil para los clientes como comprar mùsica en iTunes, mientras que para los socios, se espera que AppStore los libere del peso y los gastos de crear un canal de distribución y ventas. además, los incubadores globales de AppExchange ayudaràn a que las empresas desarrollen productos nuevos en la plataforma Apex, y ayudaràn a acelerar el èxito de los socios AppExchange existentes. Ya hay diez empresas que han firmado el programa incubador de AppExchange, y algunas son Appirio, Avankia, Centive, Convenos, DomoDomain, InsideView, InvisibleCRM, Right90, VerticalResponse y Xactly.

Salesforce.com se compromete a prorpocionar servicios de AppStore a los socios por un porcentaje de repartición de las ganancias sobre los negocios cerrados, que variarà dependiendo del nivel de servicios proporcionados. Actualmente los servicios de AppStore estàn programados para ofrecerse por etapas a lo largo de 2007: Standard Referral en el primer trimestre de 2007, Premium Referral en el tercer trimestre y AppStore Checkout en el cuarto. Los clientes que compren las aplicaciones de Salesforce.com deberàn tomar sus decisiones de compra con base en las funciones que ya estàn disponibles en la plataforma Apex actual, y no deberàn pagar cargos adicionales por usar los servicios de AppStore. Como se anunciò antes, la siguiente versión de la plataforma Apex estarà disponible junto con el lanzamiento de Salesforce Winter 07, y el lenguaje de programación de Apex estarà disponible durante la primera mitad de 2007.

más advertencias

Volviendo a la lista de limitaciones reales o percibidas de SaaS, existen dos preocupaciones importantes, que son còmo encaminar y manejar de forma segura la integración entre el contenido y los datos en los locales y fuera de ellos (SaaS), y què sucederà con la riqueza de datos sensibles e información acumulada cuando el cliente cancele el acuerdo SaaS con el proveedor. Asimismo, muchos gerentes regionales de tecnología de la información (TI) no estaràn contentos con la idea de dejar de controlar ciertas partes de TI y tener que depender de que un anfitrión externo pueda operar sus centros de datos de forma impecable, aún cuando el anfitrión sea un negocio viable. Al final, la pregunta principal sigue siendo si las implementaciones de SaaS estàn listas para dar soporte a empresas globales complejas sin parar y con acuerdos estrictos de nivel de servicios.

Estos problemas, combinados con una nueva y creciente consciencia del mercado, pueden ser la explicación a los resultados de algunos estudios recientes que indican que más del 60 por ciento de las empresas siguen prefiriendo el modelo de licencias perpetuas en sus locales en lugar de las opciones por suscripción. De hecho, la mayor parte de los socios de AppXchange de Salesfortce.com siguen teniendo negocios sòlidos en sus locales, y generalmente afirman que sòlo entre el 10 y el 30 por ciento (màximo) de sus ingresos provienen de la alianza con Salesforce.com. además, la mayorìa de los proveedores de SaaS se estàn posicionando como empresas de software aún cuando estèn mezclando software y servicios de consultorìa, por lo que la comprensión de estos servicios y su economía (tanto los del proveedor maestro como los de su ecosistema de socios) se sigue concibiendo. Por el momento, este posicionamiento tiene la forma de tarifas de consultorìa y de preparación fijas antes de que el cliente pueda iniciar un servicio por suscripción puro. La relación de Accenture con Salesforce.com es tanto una bendición como una maldición, ya que este socio representa un patrocinio serio del modelo de entrega SaaS, pero podemos esperar que la consultoría tenga un precio para ciertas implicaciones aún en el ambiente de SaaS.

En cuanto a las licencias de software, la forma más común actualmente sigue siendo que el cliente pague una tarifa fija de acuerdo al poder de procesamiento de la máquina (o máquinas) que se usa, mientras que la otra alternativa que se usa mucho es aquélla en la que la empresa paga una tarifa fija según el número de usuarios que tienen acceso al software (consulte New Approaches to Software Pricing).

Pero seamos justos, ambos enfoques son relativamente estables; el cliente puede establecer su presupuesto usando una fórmula, mientras que el proveedor recibe una buena parte de ingresos por licencias de forma directa y un flujo constante de ingresos por mantenimiento anual (generalmente entre el 15 y el 20 por ciento) posteriormente. Es un modelo constante y rentable que tanto los clientes como los inversionistas entienden, y los hábitos no se rompen fácilmente.

Otra desventaja del modelo alojado es el costo que el cliente debe asumir a largo plazo de “arrendamiento” del servicio. Una de las ventajas principales del alojamiento es la negación inicial de los costos directos relacionados con (hay que limpiar los datos, probar e integrar los sistemas, capacitar a los usuarios, etc.) una implementación más rápida de un sistema de producción. De hecho, SaaS elimina la necesidad de tener hardware o alojamiento distinto para el servidor, y reduce los costos de actualización, al igual que reduce el costo de resolución de errores y aplicación de programas secundarios, afinación y demás mantenimiento y soporte llevado a cabo generalmente por el personal de TI de la empresa misma. Sin embargo, después de cierto periodo, el sistema al que se está suscrito empezará a costar más que un sistema de producción interno, además, el cliente no posee cosa alguna. El atractivo de SaaS es la gratificación inmediata, aunada a una reducción en los dolores de cabeza financieros iniciales, como sucedería con la renta y no la compra de una vivienda, los muebles o los electrodomésticos.