Business Central – extensiones vs desarrollo, que implica cada cosa

Business Central es la evolución de Dynamics NAV que a su vez es descendiente de Navision y así podemos regresar en el tiempo a sus inicios, inicio este post con un poco de historia porque es importante entender como ha ido creciendo el sistema y, sobre todo, entender el mercado actual y como debería evolucionar.

Poco después del inicio de los tiempos, cuando se agregó la posibilidad de adecuar el sistema, tanto los clientes como los partners iniciaron una relación de amor/odio ya que esta capacidad de desarrollo permite agregar o modificar funcionalidades y/o comportamientos al ERP que le permiten ser uno de los programas mas adecuables en el mercado. Desde el punto de vista de amor es que, si queremos, podemos modificar completamente el sistema, y eso da paso al odio, cuando el partner dice que si a todo lo que pide el cliente y terminan con un monstruo sin pies ni cabeza identificables.

Ahí llegaron los verticales, desarrollos hechos a la medida de una industria o necesidad como Pebblestone Fashion (moda), LS Retail (POS), Incadea (Automotriz) llegando a existir versiones para pesca, ganado u hotelería.

Cada partner pudo crear estas soluciones en base a su conocimiento adquirido en implementaciones previas y darle forma como un producto vendible, con infinidad de opciones, funciones especificas para el tipo de negocio, reglas de operación basadas en estándares como el HACCP o algún organismo local, creo montañas de código en un monolítico vertical y le puso precio, creo el marketing y comenzaron a vender.

Partners de nicho les llamaban, hubo otros, que se especializaron en todo, es decir, desarrollaban lo que el cliente necesitaba en cada implementación, y como tal lo vendían. En los verticales, la venta era por usuario y funcionalidad la cual podía ser una renta periódica mensual, en los desarrollos a la medida en cambio, se acostumbraba a valuar previamente el esfuerzo y cotizar eso, si el cliente lo aceptaba pues lo pagaba y ya era suyo, podía cobrarse por desarrollo, horas, etc., pero no se tomaba en cuenta los usuarios puesto que el desarrollo era por base de datos.

Al llegar NAV 2018 se introdujo el concepto de extensiones al mundo de NAV, se crearon los eventos y comenzó el experimento con las versiones BC13 y BC14 que eran un hibrido de lo viejo (NAVXX) y el futuro (BCXX).

La idea de Microsoft finalmente nos alcanzó a todos, sin embargo, hoy en día, esa idea se entiende de varias maneras, una por cada partner existente y por cada visión de negocios (chueca o derecha) y voy a tratar de exponer mi idea de lo que se debe hacer para asegurar un mercado creciente y un ecosistema sostenible para BC.

1. La premisa básica es que una extensión es una funcionalidad que agrega algo que no hace BC o mejora algo que hace BC.
2. La segunda premisa es que esa extensión NO modifica el código estándar de Business Central.
3. La tercera premisa es que esa extensión no puede ni debe afectar incorrectamente los registros de Business Central (siento que son las 3 leyes de la robótica).
4. Y como hizo Giskard en Robots e Imperio, agregaremos otra premisa: “Ninguna extensión deberá dañar las funcionalidades de otras extensiones ni del sistema base” (esta es por lo que está haciendo Microsoft actualmente al “empujar” extensiones al sistema sin preguntar).

Bajo las premisas anteriores, cualquier extensión es un desarrollo, pero no cualquier desarrollo puede ser una extensión.

Y como tal, un desarrollo no puede ni debe cobrarse como extensión y mucho menos una extensión debe cobrarse como desarrollo.

Esto implica que los partners “deben invertir” en desarrollar esas extensiones, no cobrar esa idea a los clientes para luego cobrarles la cuota mensual; por ejemplo, cuando voy a la agencia, yo compro un auto del catalogo disponible, con las versiones y opciones que el fabricante creó al definir el auto. Pensemos que el desarrollo de un auto puede costar millones, el fabricante revisa el diseño base, calcula cuantos vehículos de ese podrá vender y si se logra el punto de equilibrio en un futuro cercano que permita obtener ganancias antes de que cambie la tecnología y el auto quede obsoleto. Si el análisis es correcto, el fabricante le pone precio y uno paga 20 mil dólares por su auto, no los millones que costó desarrollarlo.

Ahora bien, si yo como cliente pago un desarrollo a la medida, claro que me cobraran el diseño, las pruebas, la codificación, los ajustes, la pizza del programador, pero entonces ese desarrollo me pertenece a mí, no es para que el partner lo esté revendiendo a todos sus clientes cuando yo lo pagué.

Aquí entra la dicotomía de una implementación, ¿desarrollar o extender?

Si la nueva funcionalidad puede ser revendida a diferentes clientes dado que puede servirles, se debería tener la ética de decirlo e invertir para crear la extensión y publicarla en el appsource cobrándole al cliente como extensión.

Si la nueva funcionalidad es muy especializada, entonces es un desarrollo a la medida y esto se cobra a la antigua.

Ejemplo:

Un cliente pide un desarrollo que permita “cortar un pollo entero y vender sus partes”.

El partner piensa, sería un diario de inventario donde hago un ajuste negativo del pollo entero y un ajuste positivo de 2 alas, una pechuga, dos piernas, etc. Una página con cabecera y líneas, donde pongamos todo y lo mandamos al diario y que se registre, 8 horas.

El cliente agrega a la carta a santa claus la opción de control de lotes, etiquetado, peso, y la cuenta sube a 40 horas, más la ganancia, 80.

Se acepta la cotización y se desarrolla, se instala y el cliente feliz paga y todo bien.

¿Qué pasa si el partner detecta un mercado?

Si sirve para pollos, ¿porque no para atunes? ¿Y si pensamos en una computadora?

El atún se corta en lomos, ventresca, osobuco, etc., igual servirá el desarrollo. ¿Y la computadora?

Una computadora se puede despiezar en disco duro, motherboard, tarjetas, cables, y a un nivel más bajo, en metales y plásticos.

Cambiemos el alcance, agreguemos lotes, series, peso, metros, usemos listas de ensamble como guía para el corte/despiece/desarmado y creemos una nueva extensión.

Se analiza el mercado al que se atiende, ¿Cuántos clientes o prospectos similares? ¿Cuántos usuarios promedio por cliente? ¿Se puede utilizar en varios mercados? ¿Es afectado o afecta la cuestión fiscal? ¿Cuánto costará hacerlo y cuantos debemos vender para recuperar la inversión?

Se analizan las razones financieras, el mercado y se decide no cobrarlo como desarrollo, al cliente se le indica que será una extensión por la cual deberá pagar x cantidad mensual por usuario o compañía o tenant y si acepta, tendrá incluso posibilidad de recibir las mejoras de dicha extensión.

Aquí es donde la mayor parte de los partners “truenan”, en la parte de la inversión. Muchos piensan en cobrarle al primer cliente el desarrollo completo, y luego revenderlo como extensión y eso además de que es jugar sucio, pronto será difícil de hacer por las nuevas reglas de desarrollo.

En Microsoft, los rangos de desarrollo son muy específicos:

• 0-49,999 – Funcionalidad base, no disponible para tocar en modo SaaS.
• 50,000-99,999 – Desarrollos para clientes en sus proyectos, al parecer se comenzará a cobrar próximamente en SaaS, en on-premise cuestan los objetos.
• 100,000-999,999 – Para localizaciones de Microsoft, no accesible a los partners.
• 1,000,000-69,999,999 – Rangos donde los partners hacen sus verticales y los cobran como extensión para el caso de on-premise y pueden ser desarrollos publicados en el appsource.
• 70,000,000-74,999,999 – Este es el rango de extensiones de appsource.

En base a lo anterior, si un partner me quiere cobrar renta mensual por el desarrollo, tendría que instalar objetos de los dos últimos rangos.

Si el partner entrega objetos en el segundo rango:

• Me está cobrando un desarrollo por lo que solo debería pagarlo una vez y el código sería mío.
• Podría cobrarme la renta mensual, pero no me daría el código.

Por eso Microsoft está impulsando un cambio, por eso hay que desarrollar para la nube, para extensión, para modularidad. Los partners deben dejar atrás las ideas antiguas y enfocarse en ofrecer soluciones modernas, escalables, que satisfagan a muchos clientes de una manera estandarizada.

Esto aplica para la situación actual de factura electrónica en México, como partner hay que buscar alianzas con los PAC´s crear módulos que permitan tener una funcionalidad básica de generación de información mínima requerida legalmente (este sería una extensión base), un conector a cada PAC para enviar dicha información en el formato/método que el PAC requiera y que reciba la respuesta inyectándola en el ERP (extensión de extensión base como conector dos vías con revisión de addenda), extensiones de addenda si el cliente maneja estos conceptos con clientes de él como autoservicios o grandes superficies y finalmente otra extensión de extensión base para complementos.

Bajo ese esquema, podría por ejemplo solicitar la conexión con el PAC X ofertado por el partner, y comenzar a facturar (extensión base + extensión conector dos vías).

A los 6 meses comienzo a vender a Walmart, agrego la extensión de addenda e inmediatamente comienzo a facturarle a dicha cadena, solo agregando la información a los campos de dicha addenda.

3 meses después comienzo a exportar, o arrendar, o transportar, y voy agregando las extensiones de complementos.

Esto implica tiempos de negociación con los PAC, análisis de datos requeridos y métodos, diseño de extensiones y dependencias, programación, pruebas, ajustes, pruebas, documentación, mercadotecnia, capacitación a ventas y consultoría.

Si, son costos, pero si algún partner lo hubiera iniciado hace 3 años, ya tendría al menos 2 años ofreciendo estas soluciones de forma barata, en volumen y sobre todo, probadas y estandarizadas con lo que le daría un mejor servicio a sus clientes y quiero suponer que un guiño de aprobación de Microsoft por entender su idea original.

Finalmente, ¿Qué hacer como cliente? buscar un partner con una estrategia que me permita trabajar con el acorde a mis necesidades y poder cambiar incluso de partner o extensión si encuentro algo mejor, o mas barato.