ecommrce B2G - Miradas para un proyecto de Gobierno 馃憖

ecommrce B2G - Miradas para un proyecto de Gobierno 馃憖
馃挕
B2G 馃憠 Business to Government

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:

Requerimientos

Tipo

Atributos Relevantes (2018)

Ecommerce Multi-Vendor engine

Soluci贸n



Alto

N煤mero de funcionalidades

Soluci贸n



Alto

Casos de 茅xito (B2C y B2B)

Soluci贸n



Alto

Soporte de la Marca

Soluci贸n



Alto

Seguridad

Arquitectura



Alto

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:

Requerimientos

Tipo

Atributos Relevantes (2021)

Ecommerce Multi-Vendor engine

Soluci贸n



Alto

N煤mero de funcionalidades

Soluci贸n

Bajo



Casos de 茅xito (B2C y B2B)

Soluci贸n

Bajo



Soporte de la Marca

Soluci贸n

Bajo



Seguridad

Arquitectura



Alto

(i) Altamente Customizable

Soluci贸n



Alto

(ii) Independencia entre Tiendas

Arquitectura



Alto

(iii) Bajo Costo de Desarrollo (Eficiencia)

Soluci贸n



Alto

(iv) Especialistas Locales

Soluci贸n


Medio

Alto

(v) M煤ltiples Equipos Colaborando

Arquitectura


Medio


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谩 鈥渢ransformado鈥. 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 鈥渕undo 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 鈥渧ivir鈥 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:

Plataforma

Motivo

SAP Hybris

  • Alto costo de desarrollo.

  • Nula comunidad de desarrolladores

Oracle Commerce

  • Alto costo de desarrollo.

  • Nula comunidad de desarrolladores

IBM Websphere Commerce

  • Alto costo de desarrollo.

  • Nula comunidad de desarrolladores

Elasticpath Commerce

  • Soluci贸n privada de c贸digo. No es posible acceder al c贸digo fuente.

InterShop

  • Alto costo de desarrollo.

  • No es posible acceder al c贸digo fuente.

Vtex

  • Soluci贸n privada de c贸digo. No es posible acceder al c贸digo fuente.

Shopify

  • Soluci贸n Cloud que no permite el acceso al c贸digo fuente.

SalesForce Commerce

  • Soluci贸n Cloud que no permite el acceso al c贸digo fuente.

BigCommerce

  • Soluci贸n Cloud que no permite el acceso al c贸digo fuente.

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 鈥渦niversal鈥.
  • Dado que s贸lo es el 鈥渕otor鈥, 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 鈥攐 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鈥檛 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:

Soluciones 

Cantidad de L铆neas

Lenguaje

Fuente

Reaction Commerce

79000

Javascript

https://github.com/reactioncommerce/reaction

Shuup

390000

Python

https://github.com/shuup/shuup

Magento

4100000

PHP

https://github.com/magento/magento2

OroCommerce

1300000

PHP

https://github.com/oroinc/orocommerce

Spree Commerce

187000

Ruby

https://github.com/spree/spree

Saleor

44400

Python

https://github.com/mirumee/saleor

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:

馃憠 Una soluci贸n liviana, que sea sencilla y de r谩pido entendimiento para nuevos desarrolladores.
馃憠 Un framework que permita desarrolladar r谩pidamente (y eficientemente).
馃憠Acceso a desarrolladores locales.

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 鈥攑or 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 鈥渆mpresas de Retail鈥 se han convertido a 鈥渆mpresas 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 鈥淟egados鈥 y arrastran un sinf铆n de estructuras tradicionales 鈥渘o 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.