De B2B Commerce Cloud Visual Force a la versión Lightning: ¿cómo abordar este proceso?

Hace poco más de un año que Salesforce lanzó la versión Lightning Experience (LEX) de su B2B Commerce Cloud. Hasta ese momento, este cloud estaba disponible como managed package, con una arquitectura basada en páginas Visual Force (VF) y algunos componentes disponibles en formato Lightning.

Fue un paso esperado, ya que supuso actualizar el B2B a la última tecnología de Salesforce, permitiendo exprimir toda la potencia de Salesforce Platform, ya que en NTT Data nos gusta trabajar con la última tecnología.

Un proceso "casi" inevitable

En la actualidad, ambas versiones coexisten y de hecho están disponibles bajo la misma licencia. Es entonces el cliente quien decide qué versión quiere implementar. A favor de la versión VF inicialmente podía argumentarse que tenía mayor madurez y un mayor abanico de funcionalidades. Sin embargo, estas ventajas están perdiendo peso rápidamente con el paso del tiempo (de hecho, existen capacidades únicamente disponibles en la versión LEX, como los resultados de búsqueda sugeridos por Einstein) y las virtudes inherentes a la arquitectura LEX van cobrando cada vez más fuerza:

  • Integración dentro del CRM, no es un external package (entra dentro del calendario oficial de releases de SFDC y utiliza objetos core, no duplicación en objetos custom)

  • Componentes drag & drop reutilizables

  • Capacidades declarativas de Salesforce Platform (p.e. Checkout flow)

  • Se apoya en Salesforce CMS para informar datos de productos y categorías

  • Soporta mayores volumetrías de datos

Salesforce ha insistido desde el primer momento en que, al menos durante los próximos años, continuarán dando soporte a la versión VF. Sin embargo, todo su esfuerzo innovador está centrado en la versión LEX, donde cada release añade una lista importante de nuevas funcionalidades.

Este escenario aconseja que aquellos clientes que hayan implementado B2B VF deberían considerar la migración al framework LEX a medio plazo. Esta migración no es trivial ni mucho menos, y desde nuestra experiencia en proyectos B2B debería tener en cuenta los siguientes puntos.

Empezamos con los datos.

Como primer paso, será necesario migrar los datos del B2B VF a la nueva versión. En este sentido, el modelo de datos ha sufrido cambios importantes que resumimos a continuación:

  • Productos: Una de las entidades core del modelo, pasa de CC Product al objeto estándar Product2, que ha sido actualizado para dar cobertura a las necesidades del B2B. Aunque ciertos campos se podrán mapear directamente, deberá tenerse en cuenta que los datos tipo “Media” (p.e. imágenes) ahora se gestionan desde el CMS de Salesforce. Importante notar que la licencia de B2B incluye las capacidades del CMS sólo para el contexto B2B (p.e. no se puede utilizar para generar artículos para un blog sin incurrir en coste de licencias). En cuanto a la organización de productos, será necesario migrar de la entidad CC Category a Category, pero conceptualmente se mantiene el mismo modelo.

  • Entitlement: con este concepto se define la autorización del cliente a los productos que puede comprar.

    • Por un lado, tenemos la segmentación de clientes que comparten un mismo entitlement. Este punto esencialmente no ha cambiado más allá de que la entidad agrupadora de Accounts CC Account Group se ha convertido en Buyer Group y que hay que habilitar los Accounts a Buyer Accounts.

    • En segundo lugar, es necesario definir ese entitlement, y aquí sí hay un cambio a destacar. La versión VF se apoyaba en las CC Pricelists para otorgar acceso a un cliente. Es decir, si un producto tenía precio (estaba incluido en una CC Pricelist) y el cliente tenía acceso a esa lista de precios, el cliente podía comprar el producto. Ahora, los precios y el entitlement se gestionan de forma independiente, lo que aporta más flexibilidad al modelo -buenas noticias para aquellos clientes que trabajan con surtidos en SAP R3-. Por un lado, los precios se definen en los Pricebooks estándar de Sales Cloud, mientras que el entitlement se gestiona con el objeto Entitlement Policy, que define reglas de acceso (p.e. ver/no ver producto, ver/no ver precios…) y las relaciona con productos y Buyer Groups. Es decir, para que un cliente pueda comprar un producto, ese producto debe tener informados no sólo un precio sino también un entitlement para el Buyer Group al que pertenece el cliente.

    • Precios: como hemos comentado anteriormente, las CC Pricelists y CC Pricelist Items se transforman al estándar Pricebook y Pricebook Items, que quedan relacionadas con los Buyer Groups (antes CC Account Groups) por lo que cualitativamente se sigue el mismo modelo.

    • Carritos y Pedidos: el nuevo B2B trabaja con los objetos Cart y Order Summary (éste último se relaciona con el estándar Order) pero no existen cambios significativos.

Continuamos con las funcionalidades.

Una vez se dispone de todos los datos migrados, puede abordarse el traspaso de las funcionalidades. Para ello, será necesario mapear tanto las funcionalidades estándar como las customizaciones de la plataforma origen al nuevo B2B LEX.

Es importante comprobar en el momento de la migración qué funcionalidades están disponibles en la versión LEX y el roadmap a corto plazo, ya que como hemos comentado hay novedades importantes en cada release de SFDC que no sólo igualan las capacidades de la versión VF sino que en muchos casos son nuevas. Especial atención a las promociones comerciales -un requerimiento habitual de los clientes- y que no existen la versión VF, ya que en la Summer ’21 se lanzó esta funcionalidad a modo de piloto para el B2B LEX.

Un aspecto a comentar: en muchos proyectos de B2B VF es habitual la necesidad de dotar al portal de funcionalidades de auto-servicio para el cliente, más allá de lo que es estrictamente el proceso de compra (p.e. consulta/pago de facuras, casos, documentación, pedidos de otros canales, etc.). El enfoque habitual es desarrollar estas capacidades con componentes Lightning sobre un site independiente a la tienda, para poder reaprovecharlos y evitar la customización de páginas VF, que es costosa.

Este enfoque presenta el problema de la posible fricción que puede experimentar el cliente al pasar de un site a otro, aunque lógicamente siempre se trabaja para minimizarla y asegurar una buena experiencia de usuario. Con la versión LEX, la opción de construir tanto la tienda como el portal de autoservicio sobre el mismo site es más viable, por lo que es aconsejable tener en cuenta el impacto de este planteamiento desde un inicio.

Be agile, my friend.

Dada la diferencia importante en arquitectura de las dos versiones (también a nivel de servicios backend), en general será más eficiente y menos arriesgado desarrollar la nueva tienda desde cero que intentar aprovechar y adaptar desarrollos existentes. Aquí es aconsejable seguir un proceso iterativo de implementación, empezando por las funcionalidades más core (flujo básico de compra de un producto y validación de datos migrados) y priorizando el resto en base al valor que aporten, dependencias y complejidad.

Será necesario también tener claro si el proceso de migración se realizará sobre un roadmap “cerrado” o quiere aprovecharse para involucrar al negocio y replantear ciertos aspectos de la tienda. En este último caso, una metodología Agile será la mejor herramienta para gestionar la complejidad de un proyecto de estas características.

En cualquier caso, y una vez hechas las anteriores recomendaciones generales, hay que tener claro que un proyecto de migración de esta magnitud debe abordarse siempre de una forma totalmente personalizada al contexto del cliente. Desde NTT Data, como líderes en la implantación de proyectos B2B Commerce Cloud de Salesforce en España, estaremos encantados de atender cualquier consulta de aquellos clientes que se estén planteando migrar o realizar una nueva implantación de esta tecnología.

 

 

 

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA