Resumen

Una miráda conceptual de distintas soluciones de commerce a requerimientos de una organización de Gobierno, para revisar las ventajas y desventajas de las distintas plataformas, y proveer una mirada transversal en torno a las posibilidades y alternativas de solución como plataforma de ecommerce.

Contexto

El marco regulatorio de una institución de Gobierno es único e irrepetible. Muchas de las reglas de negocio y funcionalidades son únicas en el mundo, por lo que el nivel de customización es muy alto, por lo que no hay plataforma que pueda suplir todas las necesidades para este tipo de instituciones.

Requerimientos

Antes de analizar las distintas soluciones de ecommerce disponibles en el mercado, se debe realizar un análisis respecto de las necesidades y requerimientos mínimos de la institución, y de esta forma descartar plataformas que no cumplan que dichos requerimientos.

El caso de negocio es sumamente particular y único, por lo tanto, no es comparable las necesidades de una institución de Gobierno con las necesidades de las empresas en el mundo privado.

Historia del Proyecto

Originalmente, se seleccionó Magento el año 2018 como plataforma de ecommerce, en donde la decisión se enfocó en los siguientes atributos:

Sin embargo, después de haber implementado el proyecto (~2019), se incorporaron nuevos atributos a la tabla de requerimientos, y se cambió la relevancia de cierto atributos:

En el proyecto, se modificaron “a la baja” los siguientes 3 atributos:

1. Número de funcionalidades: Muchas soluciones de ecommerce (como Magento) tratan de resolver una gran cantidad de funcionalidades, para que éstas puedan ser utilizadas por empresas de todo el mundo, con un sin fin de reglas de negocios muy particulares a cada región. De esta forma, se transforman en gigantescas soluciones para abarcar todos los escenarios que requieren las empresas tradicionales. Pero en el caso de una institución de Gobierno,  las funcionalidades son especiales y únicas, y por tanto deben se desarrolladas.
2. Casos de éxito (B2C y B2B): El caso de negocio de una institución de Gobierno (B2G) se parece poco o nada a los casos de negocios de las industrias B2B o B2C, por tanto, no conviene usar como respaldo los casos de éxito de las soluciones de ecommerce en estas industrias. Como casos de éxito, sí servirían aquellas soluciones “Marketplace B2B” con un alto nivel de customización, que es lo más cercano al modelo B2G de Gobierno.
3. Soporte de la Marca: Considerando que la solución será excesivamente customizada por terceros, es poco probable que alguna marca se comprometa a respaldar su plataforma modificada. No tiene mucho sentido solicitar el respaldo para un producto que será “transformado”. Y por tanto no es relevante el soporte de la marca que provea el código, a no ser que sea la propia Marca quién desarrolle las customizaciones.

Adicionalmente se incorporaron 5 nuevos atributos para reevaluar las distintas soluciones de ecommerce:

Altamente Customizable

Implica que sea cual sea la plataforma, ésta será intervenida y personalizada a la medida de los requerimientos de la institución, reglas que son únicas en la industria. Por tanto, la solución escogida debe permitir el acceso al código fuente.

Independencia entre tiendas

El proyecto en particular, debía implementar distintas tiendas. Y, debido a que cada tienda es un “mundo distinto”, es estrictamente necesario implementar una solución que permita total independencia entre tiendas. Es decir, la arquitectura de la solución debe permitir que cada tienda pueda “vivir” aislado y con total independencia del resto de las tiendas. Si bien esto es un problema de infraestructura, el diseño de la solución debe permitir un único punto de ingreso (login).

Bajo Costo de Desarrollo (Eficiencia)

Debido a la gran cantidad de funcionalidades y mejoras que deben realizarse, es necesario que la solución tenga una baja curva de aprendizaje, de tal forma que los nuevos desarrolladores puedan comenzar a producir lo antes posible. Debe ser eficiente, en términos de sea rápido y fácil de implementar, además de no repetir código en distintas secciones.

Especialistas Locales

Ya sea para contratar personal directamente o a través de terceros, se requiere contar con profesional locales y una comunidad de desarrollo accesible.

Múltiples Equipos Colaborando

Debido a la necesidad de realizar múltiples desarrollos en forma paralela, es fundamental que el proceso de desarrollo permita el trabajo de múltiples equipos y profesionales de forma simultánea, y por tanto, debe contar con un flujo de desarrollo de Continuous Delivery. Por los puntos mencionados anteriormente, se descartaron las siguientes plataformas:

El Mercado

En el mercado local, la preferencia de las grandes cadenas de retail han sido (~ datos del 2019):

1. Oracle Commerce o ATG, que es utilizado por Falabella, Sodimac, VTR entre otras empresas.
2. VTEX, en empresas como Jumbo.cl, El Mundo del Vino, Unimarc, Rosen, Colloky, Corona
3. Demandware (SalesForce Commerce): Lapolar.cl, hites.com, cruzverde.cl, cic.cl
4. Magento: Empresas de retail más pequeñas: marmot.cl, casaroyal.cl, northface.cl, casaideas.cl.

A nivel internacional, muchos de los principales ecommerce del mundo tienen soluciones propias. Sitios como Amazon, Otto.de, Alibaba, MercadoLibre, Ebay, Wallmart, Apple.

Dentro de las soluciones para empresas B2B a nivel internacional, destacan las soluciones de SAP, Intershop, Sana Commerce y Oracle. A continuación, los reportes B2C y B2B de Gartner y Forester 2020:

Soluciones de ecommerce aptas para una institución de Gobierno

Debido a la realidad de las restricciones presupuestarias del Gobierno, y a la necesidad de contar con desarrolladores locales a costos accesibles, es que sólo se consideraron soluciones de código libre (opensource), al margen de que los fabricantes puedan ofrecer licenciamiento por concepto de soporte y código.

La siguiente sección muestra un breve análisis respecto de 6 soluciones de ecommerce “compatibles con el modelo de la institución” con sus ventajas y desventajas.

Reaction Commerce

Reaction Commerce es una solución “Headless commerce”, es decir, no tiene frontend ni backend, sino que es básicamente un motor o API que permite administrar todas las funcionalidades del ecommerce. Esto permite conectarse a múltiples sistemas y no está atado a una solución de frontend ni backend.

Ventajas

• Su mayor ventaja es el desarrollo, ya que contiene una lógica apuntada a los desarrolladores, en que no se necesita tener conocimientos especiales en ningún sistema en particular, sino que utiliza un estándar de comunicación “universal”.
• Dado que sólo es el “motor”, permite construir los flujos y reglas a la medida. Posiblemente es la solución que permite el más alto nivel de customización.
• Contiene lógica de Marketplace multi-proveedor de forma nativa.

Desventajas

• Su mayor desventaja es que no tiene ningún diseño para el frontend ni backend.
• Aún tiene una comunidad de desarrolladores pequeña.
• Pocos empresas utilizan Reaction Commerce.

Magento

El crecimiento de la comunidad de Magento ha crecido muchísimos en los últimos años, principalmente porque:

• Es una plataforma muy sencilla de implementar. Una pequeña empresa puede comenzar a vender en un par de días.
• Tienes miles de funcionalidades ya implementadas. La plataforma intenta resolver todos los tipos de funcionalidades que existen en la industria del ecommerce a través de su gigantesco panel de administración.
• Como fue una de las primeras plataformas, cuenta con cientos y miles casos de éxito.

Ventajas

• Magento tiene una gran cantidad de funcionalidades ya desarrolladas, más que cualquiera otra aplicación. Esto hace que sea muy sencillo de implementar y adoptar por las empresas, ya que no requieren hacer ningún tipo de desarrollo.
• La comunidad es enorme, tanto en el número de empresas que lo están utilizando, como en el número de plugins —o extensiones— disponibles.
• Está validada por miles de casos de negocio exitosos.

Debilidades

• Las 4.1 millones de líneas de código que componen la plataforma, hacen necesario que exista un período de aprendizaje importante para los nuevos desarrolladores. Es una aplicación monólitica enorme, y fue diseñada según los antiguos conceptos de desarrollo (2008).
• Se requiere un profundo conocimiento de la plataforma para customizarla.
• El desarrollo es complejo, y por tanto, el costo del desarrollo es elevado.
• El nivel de desarrollo del módulo B2B es aún inmaduro, casi inexistente.
• No tiene lógica de Marketplace multi-proveedor de forma nativa.

Spree Commerce

La solución de Spree Commerce fue creada el 2007 y está basada en el lenguaje de programación Ruby on Rails. Es una solución de código abierto y a la fecha tiene aporte de más 840 colaboradores al código (Magento en comparación, tiene 1436 contribuyentes).

Sus principales ventajas son:

• Tiene una estructura liviana (188 mil líneas de código, en comparación con las 4.1 millones de líneas de código de Magento), por lo que es de fácil adopción.
• El lenguaje de programación Ruby on Rails es popular por su regla DRY —Don’t Repeat Yourself—, apunta a que la información del código debe ser clara y única para el resto del sistema. El propósito es disminuir la repetición de código al máximo, para que sea más sencillo el desarrollo.
• No es necesario que los nuevos desarrolladores tengan conocimiento ni experiencia en Spree Commerce. Basta que tengan experiencia en Ruby on Rails, ya que el framework es el mismo. Esto hace que los nuevos desarrolladores puedan comenzar a producir mucho antes que otros lenguajes.
• La eficiencia del desarrollo es mucho mayor al de otras soluciones, y por tanto el costo del desarrollo es menor.
• Tiene lógica de Marketplace multi-proveedor de forma nativa.

Y sus desventajas:

• La comunidad de desarrolladores es mucho menor que PHP.
• No tiene la gran cantidad de funcionalidades que sí tiene Magento.
• No hay soporte de la marca.

Empresas en Chile que utilizan Spree Commerce (2019): Macoline.cl, Salcobrand.cl, Preunic.cl, andesgear.cl

Shuup

Shuup es una solución de código abierto desarrollada en Django y Python. Tiene aproximadamente 392 mil líneas de código y fue lanzada el año 2012.

Ventajas

• El framework Django y el lenguaje Python están dentro de los lenguajes más populares (es el primer lenguaje que se enseña en la escuela de informática de las principales universidades del mundo)
• Tiene lógica de Marketplace multi-Proveedor de forma nativa, aunque dicho módulo requiere un pago anual por licenciamiento.

Desventajas

• La baja popularidad de Shuup hacen que aún su comunidad sea pequeña.
• La solución provee un módulo de Marketplace que requiere licenciamiento.
• Pocas empresas utilizan Shuup actualmente.

OroCommerce

OroCommerce es el único ecommerce opensource que nació el año 2012 con foco en el B2B y marketplace. La solución utiliza código PHP y fue fundada por parte del equipo original que desarrolló Magento, por lo que tienen varias similitudes con éste.

Ventajas

• Solución B2B nativo.
• Incluye lógica de compras similar a las soluciones de “procurement”, esto es, lógica de Centros de Costos, restricciones de compra, distintos flujos de compras, etc.
• Incorpora de forma nativa la lógica de Marketplace multi-vendor.

Desventajas

• Tiene 1.3 millones de líneas de código, por lo que se requiere desarrolladores con experiencia y conocimiento en la plataforma antes de poder comenzar a programar.
• El diseño de la solución está pensando en resolver todo tipo de funcionalidades que hoy utilizan las empresas B2B, por tanto, incluye muchas reglas que no se necesitan en una institución de Gobierno.
• En Chile hay muy pocas empresas usándolo (sólo Prisa.cl).

Saleor

Saleor es una plataforma enfocada en ser Headless API. Es una solución muy reciente (lanzada el 2012) y está basada en el popular lenguaje Python, lo que inmediatamente la convierte en un framework de desarrollo rápido e intuitivo. Es la solución más pequeña en términos de líneas de código, ya que sólo contiene 45 mil líneas.

Ventajas

• Solución basada en Python. No requiere experiencia de los desarrolladores, por lo que es muy fácil y rápido desarrollar sobre él.
• Está pensado para construir sobre él, es decir, al ser un “headless API”, permite que cada equipo de desarrolladores utilice el lenguaje de programación que mejor le acomode, y con él se consuma los servicios de la API.
• Alta comunidad de desarrolladores locales.

Desventajas

• No hay casos de éxito en Chile (al 2019)
• Su diseño y arquitectura es de última generación, por tanto, podría haber aún etapas que madurar.
• No hay soporte de la Marca.

Empresas usando Saleor: www.patchplants.com, pfefferundfrost.de/en/, a-dam.com, store.butterflynetwork.com, Demo: demo.saleor.io

Comparativa de Candidatos

Existen varios atributos comparables entre las soluciones de código abierto. Utilizaremos algunas de ellas para ilustrar de mejor forma las diferencias:

1. Cantidad de líneas de Código.
2. Costo de desarrollo
3. Tamaño de la Comunidad

Soluciones Opensource evaluadas:

Luego la comparación de los atributos requeridos es:

Notas a la comparación:

• La solución multi-vendor de Magento sólo existe en forma de plugin. (⚠️). Magento no permite de forma nativa la solución Marketplace multi-vendor.
• El gran número de funcionalidades de Magento y Oro Commerce, queda reflejado en el número de líneas de código de cada uno (4,1 y 1,3 millones de líneas)
• Para el caso de los especialistas locales, se marcó como “⚠️” aquellos escenarios en que hay desarrolladores para el lenguaje (Python o Ruby on Rails) pero que no tiene experiencia con la aplicación, ya que en dicho escenario no es necesario tener experiencia.

Recomendaciones

Entendiendo las necesidades de la institución declaradas previamente, es posible afirmar que, la institución de Gobierno requiere:

En base a lo anterior, Magento no es la plataforma adecuada para esta institución de Gobierno, por:

• Es una plataforma gigante con miles de funcionalidades que no se requieren.
• 👉 Se requiere varios meses (y años) de experiencia.
• Hay pocos desarrolladores locales.

Se recomienda reemplazar la solución actual y evaluar en profundidad estas 3 plataformas:

• Reaction Commerce (Node.js)
• Spree Commerce (Ruby on Rails)
• Shuup (Python & Django)

Respecto de la estrategia de desarrollo, se ha declarado que la institución no pretende ser una empresa de Tecnología, por lo que dicho servicio debe ser externalizado a través de terceros. Este punto puede ser discutible, dado que hoy en día, ya se habla —por ejemplo— de que “una empresa de retail, es una empresa de tecnología”, debido al fuerte cambio que ha experimentado la industria al moverse los canales de compra de las tiendas al ecommerce. Y este caso, la necesidad de la mejora continua, el control sobre las soluciones, y el manejo del conocimiento, quizás requiere contar con un equipo de desarrollo interno.

Ahora bien, depende en gran medida de la plataforma, ya que, en el caso de Magento, sin duda lo aconsejable es gestionar el desarrollo a través de terceros, debido a la escasez de desarrolladores, y al alto costo de entrenamiento. Sin embargo, podría haber otras plataformas que tuviesen mayor cantidad de desarrolladores, y un menor costo de entrenamiento. Si fuese el caso, quizás sería conveniente cambiar la estrategia de desarrollo y mantener un equipo interno. Respecto de la estrategia de desarrollo:

• Se recomienda mantener la externalización del desarrollo en caso de mantener la plataforma de Magento.
• Se recomienda un modelo híbrido de desarrollo en caso de migrar a alguna de las plataformas mencionadas, esto es, implementación a través de terceros, pero con un equipo interno para soporte y mantenciones

Respecto a la infraestructura:

• Independiente de la solución escogida, la arquitectura de las tiendas debe totalmente independiente. Cada tienda debe tener su instancia exclusiva y separada del resto.

Conclusiones

Mucho se dice respecto de que la transformación digital ha generado que muchas “empresas de Retail” se han convertido a “empresas de Tecnología”. Y con razón, ya que el comportamiento de los usuarios ha cambiado, y las expectativas de compra exigen que los sistemas sean adaptados rápidamente (o ágilmente). Pero las empresas mantienen sistemas “Legados” y arrastran un sinfín de estructuras tradicionales “no digitales”. No hay duda de que año a año los usuarios irán exigiendo que sus experiencias de compra sean más amigables y eficientes, y eso no será la excepción para esta institución. Por lo tanto, el desarrollo continuo y las mejoras a las aplicaciones deben ser parte de la estrategia digital de la institución.

La decisión que tomó la institución tiempo atrás, de externalizar el desarrollo de las tiendas de commerce, fue sin duda una buena decisión dado que Magento es complejo de internalizar, la comunidad de desarrolladores es pequeña. Sin embargo, debido la exigencia de la mejora continua en las aplicaciones quizás valdría la pena contar con un equipo interno de desarrollo para el soporte y mantención de la aplicación.

Si bien análisis buscaba conocer y ahondar las soluciones de ecommerce aptas al modelo B2G de la institución, quedan muchos otros aspectos relacionados o relevantes que evaluar como: los costos de transferencia o migración de una plataforma a otra, la evaluación del downgrade de Licenciamiento de Magento, la viabilidad estratégica, política o comunicacional de migrar de aplicación, y todos los costos internos y externos de realizar un cambio de este tipo.