¿Cómo migrar de SAP a commercetools?
Si la versión de SAP en la que corre tu comercio electrónico ya no puede respaldar tus objetivos comerciales, probablemente es hora de migrarte a un nuevo sistema de comercio en lugar de cambiar a una versión diferente de SAP.
Efectivamente, puede ser complicado y llevar mucho tiempo, pero solo necesitas una inversión inicial y ¡nunca más tendrás que cambiar de plataforma! Quedarte en una plataforma de comercio electrónico obsoleta hará más daño que bien a largo plazo.
Si tu negocio actualmente corre SAP Hybris o SAP CCV1, puedes enfrentarte a actualizaciones obligatorias para cambiar a SAP CCV2. Incluso sin una actualización obligatoria, puede que sepas que la versión de SAP en tus instalaciones está llegando al final de su vida útil o que tu versión es tan antigua que sientes la necesidad de cambiarte lo más pronto posible.
Una razón aún más convincente para no "actualizar" a SAP CCV2 es que en realidad no es una actualización en absoluto. Básicamente es volver a implementar la misma solución.
Si has personalizado tu implementación de SAP en tus instalaciones o SAP CCV1, esa migración se vuelve aún más costosa y lleva más tiempo - o incluso puede ser imposible. La mayoría de las veces, tu integrador de sistemas tendrá que reescribir toda la personalización desde cero para migraciones grandes o complejas de SAP Hybris a SAP CCV2.
Además, SAP requerirá que primero actualices a la versión 2205 antes de iniciar el largo camino de migración.
Aunque decidas migrar a SAP Commerce Cloud y tengas una implementación exitosa, las mejoras y beneficios que obtendrás serán débiles.
Las características y funcionalidades de esta “nueva versión” son en gran parte las mismas, y se mantienen los desafíos inherentes de las plataformas monolíticas. SAP queda a deber muchas características pendientes, como la extensibilidad lado a lado, los servicios de dominio y más.
commercetools: solución moderna de comercio electrónico
commercetools decidió convertirse en una herramienta de comercio flexible para las empresas desde 2013, cuando era una pequeña empresa emergente que lanzaba un Headless Commerce.
Al presentar su producto Headless, las marcas necesitaron tiempo para comprender los beneficios de separar el frontend y el backend de su comercio electrónico. Esta estructura daba la flexibilidad a los equipos de marketing de optimizar su experiencia de interfaz y usuario sin afectar los procesos que corrían en el backend.
El hecho de que el producto fuera agnóstico en cuanto al lenguaje, la programación y el canal, y capaz de proporcionar funcionalidades de autoscaling y actualizaciones continuas (gracias a la nube) también era un tema desconocido.
En última instancia, una vez que se les mostró cómo una mayor flexibilidad, extensibilidad y escalabilidad se traduce en resultados tangibles, la comprensión de la tecnología detrás de la solución se volvió menos importante para los clientes potenciales.
Después de que su plataforma de ecommerce headless estableció una sólida reputación por dar a las marcas la libertad de crear experiencias encantadoras para los clientes y adaptarse continuamente a sus necesidades, commercetools escaló rápidamente en los rangos entre los analistas y revisores de la industria.
Para apoyar aún más las necesidades de los clientes y ofrecer más valor a los mismos, en 2021, la compañía adquirió Frontastic, una solución headless líder en su clase. Rebautizada como commercetools Frontend, se comercializa como un producto independiente, así como parte de una solución de comercio completa, commercetools Composable Commerce y Frontend.
Hoy en día, Commercetools ocupa posiciones de liderazgo en el espacio de comercio digital tanto en el Forrester Wave, como en el Cuadrante Mágico de Gartner(R). Actualmente, la empresa alimenta el comercio para grandes marcas de todo el mundo, incluyendo nombres conocidos como Audi, Bang & Olufsen, LEGO y H&M.
Roadmap para migrar de SAP a commercetools
SAP ofrece un servicio para implementar migraciones a nuevas soluciones para sus clientes.
Si tu negocio desea hacerlo manualmente, existen herramientas de importación/exportación que se pueden utilizar, aunque puede ser un proceso complicado y que consume tiempo. Para migraciones de datos desde SAP a commercetools, se puede exportar los datos en un archivo CSV que coincida con el formato de commercetools y luego proceder con la migración.
Estos son los pasos típicos de una migración desde una perspectiva de planificación de proyectos.
Migración de SAP a commercetools
No hay una interpretación exacta de lo que significa una migración de plataforma de comercio. Para la mayoría de las personas, el resultado ideal sería una solución que tenga exactamente las mismas funcionalidades que la versión anterior.
En la mayoría de los casos, esta expectativa no es práctica; al planificar la migración, esta es la oportunidad perfecta para eliminar la sobrecarga y, en general, apuntar a una solución más eficiente.
Lo que estamos sugiriendo aquí es dividir un proyecto existente en dominios empresariales y transferir la funcionalidad y los datos respectivos fuera de SAP a una infraestructura de primera calidad con commercetools en su núcleo.
En la mayoría de los casos, esto significa: pasar de un monolito local a una solución cloud headless orientada a servicios, con todo lo que está conectado a este proyecto. También recomendamos una migración escalonada (en lugar de un enfoque de golpe grande) para minimizar las interrupciones en las operaciones y mitigar los riesgos en la mayor medida posible.
Paso 1: Descubrimiento y análisis de brechas
En este primer paso, se pueden estructurar tus tareas de la siguiente manera:
1.- Haciendo inventario: ¿Qué ofrece la plataforma actual, qué tipos de funcionalidades permite, qué historias de usuario admite, qué procesos se ejecutan en segundo plano?
Estas preguntas pueden sonar obvias o triviales, pero con una base de código que tiene algunos años, siempre hay casos límite individuales que pueden no haber sido documentados adecuadamente o que las personas simplemente han olvidado.
Además, se recomienda encarecidamente no cambiar todo tu negocio digital de una vez: céntrate primero en los activos menos importantes, como un idioma menos relevante, antes de abordar el negocio principal.
2.- Establecer prioridades: Crea una lista de todos esos procesos y casos límite y decide cuáles de ellos deben migrarse de inmediato, y cuáles pueden abordarse en una etapa posterior, o incluso eliminarse por completo.
Asegúrate de ver estos elementos desde una perspectiva empresarial y determinar qué valor agregan a tu negocio. (Y aunque te sientas tentado de quedarte con esa función que tardó mucho en implementarse y que todo el equipo está orgulloso de ella: si no agrega valor, probablemente no debería estar en la lista).
3.- Análisis de brechas: Usa esta lista priorizada de funciones y procesos y compárala con las características de commercetools, como la flexibilidad técnica, la escalabilidad y la estabilidad del rendimiento. Esto sirve para evaluar qué funciones construir y cuáles comprar. Encontrarás información detallada en la documentación de la API.
Hay principalmente tres opciones para cada elemento:
Listo para usar: La función deseada es una característica estándar de commercetools que se puede configurar.
De terceros: Hay características y dominios que están fuera del alcance de commercetools, como CMS/DXP. commercetools tiene un gran ecosistema de servicios de terceros preintegrados disponibles. Para soluciones de terceros no preintegradas, la arquitectura API-first de commercetools facilita la integración con otras soluciones.
Personalizado: Estas son las partes que deben ser codificadas personalizadamente.
4.- Crear equipos: Finalmente, asegúrate de que tu personal y tu estructura organizativa cumplan con las nuevas demandas de una solución basada en la nube. En lugar de conjuntos de habilidades organizados horizontalmente y claramente definidos, como especialistas en frontend, desarrolladores de backend y científicos de datos, el "nuevo mundo en la nube" requiere el trabajo de equipos multifuncionales y verticales.
Paso 2: Crear un mapa de migración
A continuación, crea un mapa de migración que enumere los hitos importantes, los entregables y una línea de tiempo. En términos generales, hay tres áreas que son la base del mapa:
1.- Datos: Una de las primeras cosas que debes abordar es asegurarte de mover los datos de la base de datos de SAP a commercetools, por ejemplo:
Catálogo de productos: catálogos, categorías, productos, SKU, etc.
Perfil del cliente: segmentos de clientes, perfil del cliente, dirección, métodos de pago, etc.
Pedidos: carritos, pedidos, métodos de envío, etc.
Hablaremos más sobre qué hacer en estos casos en el Paso 3 del plan de migración.
2.- Lógica empresarial: Esta área incluye todas las extensiones personalizadas que deben construirse o integrarse cuando se incluyen servicios de terceros.
3.- IU/UX: Como commercetools es una solución de backend headless, tienes la libertad de conectar el frontend de tu elección y crear experiencias personalizadas para el cliente, no solo para la web y el móvil, sino para cualquier punto de contacto que exista, desde pantallas en el automóvil hasta electrodomésticos inteligentes y asistentes de voz.
Como confiamos en que la solución de frontend de Commercetools ofrece lo mejor de lo que las marcas necesitan hoy en día, te recomendamos encarecidamente que explores sus capacidades e incluyas esta opción en tu proceso de toma de decisiones.
Nota: Estos tres pasos no tienen que abordarse en esta secuencia exacta. Estas sugerencias solo sirven para agregar un poco de estructura a tu planificación.
Paso 3: Extracción de datos
Comienza exportando tu capa funcional de SAP, que incluirá tus personalizaciones superpuestas en el modelo de datos listo para usar. Es esencial que puedas ver todo el modelo de datos.
Exporta datos usando el generador de scripts de SAP
Ejecuta exportaciones para todos los tipos desde el script como CSV
Modifica los archivos (mapear al nuevo modelo de datos)
Crea borradores en el archivo CSV de exportación modificado
Carga los datos
A continuación, compara ese modelo de datos exportado con el modelo de datos de commercetools. Querrás observar cualquier diferencia en:
Objetos: Una empresa de alimentos para mascotas podría tener un objeto "perro".
Sub-tipos: Un minorista de ropa podría tener tipos de productos de camisas y jeans, cada uno con diferentes atributos.
Atributos de objeto: Un producto digital podría tener un atributo de "conteo de descargas".
A diferencia de SAP, commercetools utiliza un modelo de datos extremadamente flexible que permite actualizaciones en tiempo real en su estructura. En lugar de cambiar una tabla en una base de datos y luego mapearla de regreso a Jalo, puedes cambiar el modelo de datos en tiempo real utilizando el Merchant Center o directamente a nivel de API.
Recomendaciones de mapeo inicial
Si implementas tu catálogo como tipos de productos, puedes utilizar el siguiente mapeo como guía. Por supuesto, esos mapeos son siempre específicos para cada proyecto.
Definición de Objetos Personalizados
Los objetos personalizados en commercetools son registros arbitrarios formateados en JSON que se mantienen indefinidamente. Pueden ser identificados por una clave o un ID y pueden ser anidados usando el atributo contenedor. Los atributos de un objeto personalizado pueden hacer referencia a otros objetos en commercetools, como un pedido o un perfil de cliente. Consulta Tipos de objetos personalizados para obtener más información.
Convertir subtipos en tipos personalizados
Los subtipos se representan como tipos personalizados en commercetools (los variantes, como en SAP, también se pueden usar). Podrías definir un subtipo de producto de camiseta que capture la talla (S/M/L/XL) y un subtipo de producto de jeans que capture la medida de la cintura y la longitud de la pierna. Al crear productos, podrías crear un producto genérico, un producto de camiseta o un producto de jeans. Puedes aplicar este concepto a otros objetos, incluyendo categorías, clientes, pedidos, etc.
Finalmente, se pueden modelar los atributos utilizando campos personalizados (Custom Fields) en commercetools cuando no se desean tener múltiples subtipos de un objeto. Por ejemplo, es posible que se desee capturar el nombre de usuario de Twitter de todos los nuevos clientes. En lugar de crear un tipo personalizado "Cliente con Twitter", solo se agregaría un campo personalizado para capturar el nombre de usuario de Twitter.
Migrando el Catálogo de Productos
Si comienzas migrando tus datos de catálogo de productos y funcionalidades relacionadas a comercetools, deberás realizar una exportación única de tus datos enriquecidos (datos base desde el ERP de origen, PIM, etc., más enriquecimientos realizados por los usuarios de negocios para eCommerce) desde SAP utilizando ImpEx, lo cual exportará todos tus datos de catálogo de productos a un archivo CSV. El script de ImpEx que deberás utilizar será algo similar a:
$contentCatalog=YourCatalog
$contentCatalogName=Your Catalog
$catalogVersion=catalogversion(catalog(id[default=$contentCata
log]),version[default=’Staged’])[unique=true,default=$contentCatalog:Staged]
$contentCV=catalogVersion(CatalogVersion.catalog(Catalog.id[de
fault=$contentCatalog]),CatalogVersion.version[default=Staged])
[default=$contentCatalog:Staged]
Valida el script y luego ejecútalo. Puede tardar algunas horas en ejecutarse, dependiendo de qué tan grande sea tu catálogo de productos.
Paso 4: Personalizando el comportamiento de la plataforma
Luego, importa esos datos a commercetools. Aunque commercetools ofrece su propia versión de ImpEx, que es funcionalmente similar a la versión de SAP, no se puede usar para datos complejos como este. Hay diferencias inherentes entre los modelos de datos de commercetools y SAP. Por ejemplo, SAP utiliza el concepto de catálogo, mientras que commercetools utiliza el concepto de canal. Los datos pueden reutilizarse en gran medida, pero la estructura e incluso la sintaxis (formatos de fecha, formatos de números, etc.) pueden cambiar.
Por esas razones, es más fácil usar algún código personalizado para analizar el CSV que exportaste desde SAP, extraer los datos que deseas e importarlos a commercetools llamando a las API correspondientes. Los usuarios de Java SDK pueden usar la biblioteca Java proporcionada por commercetools o, muy fácilmente, otro SDK de su elección.
También puedes utilizar el enfoque de elemento de línea personalizado donde, dependiendo de la estrategia de migración adoptada, comenzarás a crear el "Carrito" en commercetools mientras mantienes los productos o PIM en SAP. En commercetools, un elemento de línea personalizado es un elemento genérico que se puede agregar al carrito pero que no está vinculado a un producto. Puedes usarlo para descuentos (dinero negativo), cupones, reglas de carrito complejas, servicios o tarifas adicionales. Tú controlas el ciclo de vida de este elemento.
A largo plazo, todavía deberás mantener una copia actualizada de tu catálogo de productos en SAP porque existen referencias "fuertes" en todo SAP a productos, categorías, etc. Es más fácil.
Para continuar, debes seguir enviando tus datos sin procesar de catálogo de productos desde tu ERP, PIM u otro maestro de catálogo de productos a SAP como lo has hecho tradicionalmente. Además de eso, comienza también a enviar esos datos a commercetools y solo permite que tus usuarios de negocios enriquezcan aún más esos datos en commercetools. Las "cáscaras" de datos de catálogo de productos sin enriquecer en SAP son suficientes ya que los detalles del catálogo de productos se están sirviendo desde commercetools.
Paso 5: Construcción de Extensiones Personalizadas
Como sugiere el término "personalización", es imposible encontrar una solución que sirva para todas las implementaciones. En cambio, este pequeño ejemplo debería servir como una demostración para darte una idea aproximada de cómo proceder.
Digamos que lograste importar tu catálogo de productos a commercetools y te has asegurado de que este catálogo se sincronice regularmente entre el sistema antiguo y el nuevo. Puedes acceder a ellos a través de los puntos de acceso de Productos y trabajar con ellos de cualquier manera que desees, como mostrarlos en la Tienda en línea, que de otra manera estaría impulsada por SAP. En otras palabras, estás anulando esta parte del proceso haciendo que commercetools entregue los datos, un caso clásico del patrón estrangulador de Martin Fowler.
Esto significa mover todas las personalizaciones de SAP para que sean sin servidor y basadas en eventos.
Paso 6: Migrar la Interfaz de Usuario
El último elemento en tu agenda de migración es la interfaz de usuario. El término "migrar" es un poco incorrecto en este contexto, porque en la mayoría de los casos te enfrentas a una reconstrucción completa, simplemente porque SAP y commercetools son tan fundamentalmente diferentes en este sentido.
Especialmente si has utilizado un acelerador de SAP como base para tu interfaz, no es posible tallar y reutilizar el código de la interfaz ya que la tienda en línea está estrechamente conectada al núcleo de SAP. El único contexto en el que una migración de la interfaz de usuario podría ser posible es si ya tienes una interfaz personalizada basada en una tecnología como Angular o React y usas la capa SAP OCC. En este escenario, el patrón estrangulador mostrado en el paso anterior también puede ayudar con la construcción de la experiencia de usuario.
Identificando cómo la interfaz envía datos y recibe datos de la capa de API de SAP, entonces es posible sustituir los puntos finales originales por los proporcionados por la solución de commercetools.
Para continuar, debes seguir enviando tus datos sin procesar de catálogo de productos desde tu ERP, PIM u otro maestro de catálogo de productos a SAP como lo has hecho tradicionalmente. Además de eso, comienza también a enviar esos datos a commercetools y solo permite que tus usuarios de negocios enriquezcan aún más esos datos en commercetools. Las "cáscaras" de datos de catálogo de productos sin enriquecer en SAP son suficientes ya que los detalles del catálogo de productos se están sirviendo desde commercetools.
Principales 3 desafíos al migrar de SAP
Los costos pueden ser altos: Dependiendo de la versión de SAP de la que se está migrando, la migración debe ser precedida por una actualización completa de la plataforma, lo que suele ser costoso.
Ligado a los servicios de SAP: La migración tiene aspectos de "migración de datos" que solo pueden ser realizados por SAP Services (a un costo), por lo que los clientes están atados a SAP por más tiempo de lo esperado.
Obstáculos en las negociaciones: Muchos clientes de SAP Cloud Commerce Versión 1 han comprado en métricas que ya no están disponibles (por ejemplo, el número de núcleos utilizados). Esto debe cambiarse a métricas actuales (GMV o número de órdenes), y eso puede introducir una negociación complicada. Además, hace 12 meses, SAP cambió sus términos legales de DPA, por lo que se tendrán que aceptar nuevos términos de contrato menos atractivos.