Unos días antes de la publicación de este blog me buscó un antiguo cliente que tenia un problema con su aplicación, hablamos del asunto, se revisaron algunos temas y quedó resuelto sin necesidad de realizar gastos o cambios mayores.
NAV 2013, arrancado en julio de 2013, 50 usuarios, 400 GB de base de datos aproximadamente, integración con un punto de venta especializado que hace muchas cosas, en el momento de mayor operación, 90,000 operaciones de venta por día a lo que habría que sumar las compras, cobros, pagos, movimientos de inventario, series, etc., un cliente que ha utilizado NAV como BackOffice durante todos estos años y que últimamente está pensando en migrar.
Ahora bien, ¿Qué tan importante es migrar de NAV 2013 a Business Central para esta empresa? ¿Existe una necesidad real de moverse a una versión mas reciente? ¿Qué beneficios obtendrá con el cambio?
Vamos a analizar este cliente desde un punto de vista consultivo, es decir, sin pensar en que como partner quiero vender y como cliente que no quiero gastar, hay que buscar argumentos en favor y en contra y ayudar a tomar una decisión.
Iniciemos con el soporte del producto
Cuando realizamos la implementación, estas fechas se veían lejanas, ahora ya no tanto (y recordé otros dos clientes que tienen NAV 2009).
¿Qué pasará cuando la versión pierda el soporte?
Bueno, ya no habrá actualizaciones al sistema por parte de Microsoft, esto realmente no importa mucho que digamos dado que el sistema no se ha actualizado desde hace varios años debido al costo para el cliente y, sobre todo, la falta de fallos en la versión ya que ha estado muy estable los últimos 9 años de operación.
El cliente se encuentra al corriente de su mantenimiento por lo que si hacemos cuentas:
50 usuarios a 1,800 USD por 16% dan 14,400 USD anuales, multiplicados por 9 dan 129,600 USD a lo que se tendría que sumar el costo original del proyecto mas el licenciamiento original y el costo de los objetos adicionales.
Lógicamente, se debe analizar el ROI para validar que esta inversión ya haya sido amortizada en estos años lo que es confirmado por el cliente, el ERP le ha traído beneficios que exceden los costos.
¿Podría seguir sin el soporte de Microsoft?
Por supuesto que sí, después de 129,000 dólares sin recibir nada tangible a cambio por parte de Microsoft queda claro que no es tan necesario el tener soporte de dicha empresa.
¿Qué pasa con el partner?
Tiene años sin adquirir una póliza de soporte ya que, como se mencionó anteriormente, el sistema es estable a tal grado que aburre (no siempre fue así, recuerdo tardes largas ajustando cosas y tratando de estabilizar la operación), pero si el partner cuenta con personal que conozca la aplicación en esa versión, la operación del cliente y los desarrollos que tiene, teóricamente seria factible seguir en la misma versión indefinidamente. Sin embargo, el partner requiere mantener al personal, eso genera un costo que debe ser cubierto y eso implica pólizas de soporte.
Aunque la versión 2013 es una versión de transición, su estabilidad esta comprobada en las implementaciones existentes y funcionales hoy en día, lo mismo sucede con las versiones 2009 en modo Classic que siempre demostraron una estabilidad legendaria, todo esto podría abonar la idea de no moverse de versión, sin embargo, no cuenta con muchas de las mejoras de las nuevas tecnologías.
Revisemos las necesidades del cliente en cuestión.
Tiene un punto de venta desarrollado por el mismo conectado a NAV para obtener y entregar información de manera bidireccional. Su operación de ventas, cobros, inventarios y almacenes depende totalmente de NAV aun operando en su punto de venta. El volumen de operaciones es muy elevado por lo que la transaccionalidad es muy fuerte y se requiere un procesamiento online.
El historial de clientes es muy importante en toda su operación por lo que todo debe ser accesible al operar.
Respecto a las compras, es mas ligera la operación, implica la compra de miles de productos, su control por serie, la distribución de cada producto, a quien se vendió, fecha, serie, contrato, etc.
Hay que controlar los pagos, los gastos, registrar toda operación y finalmente, entregar información y resultados por cada sucursal, producto, periodo; lo clásico.
Además de la integración del punto de venta, se cuenta con un portal de proveedores conectado al sistema como inicio de un SCM.
Las conexiones se realizan directamente a la base de datos mediante aplicaciones que hoy en día se consideran “antiguas” por no estar basadas en API o REST, este es uno de los puntos importantes a tomar en cuenta para una migración.
Veamos que escenarios podemos pensar aquí y analicemos cada uno.
- Business Central 100% Cloud.
- Business Central On-premise con conexiones al cloud.
Moverse a la nube.
Se tienen 50 usuarios concurrentes full con un costo anual del 16% de mantenimiento; si se hiciera el cambio a Cloud, el costo sería de 70 USD mensual por usuario. Por supuesto que Microsoft otorgara un 40% de descuento por cada licencia por cierta cantidad de tiempo lo que dejara cada licencia en 42 USD mensuales, esto genera un sobre costo anual de xxxx USD que podríamos justificarlo pensando en las mejoras y actualizaciones mensuales del sistema las cuales agregan funcionalidades y mejoras bastante interesantes.
Un asunto aparte es el espacio de almacenamiento, tomando en cuenta 50 usuarios, Microsoft otorgará 80 GB inicialmente y 2 GB por cada usuario lo que sumará un total de 180 GB de espacio para la base de datos.
Esto puede verse como una gran cantidad de espacio, pero no estamos tomando en cuenta que es compartido con los sandbox y acorde al crecimiento anterior, podríamos pensar en 50 GB por año. En dos años entraríamos en problemas para poder tener una copia de producción para desarrollos, pruebas y en algunos casos, capacitación como se utiliza actualmente.
Esto puede ser resuelto adquiriendo espacio adicional con un costo mensual que, aun siendo importante, es justificado por la redundancia que se otorga por Microsoft.
Ahora nos enfocaremos en los sistemas “satélites” que funcionan actualmente.
El punto de venta será actualizado a una versión web para actualizar tanto la interfaz como para agregar alguna funcionalidad, permitir utilizar cualquier sistema operativo y en su caso, diferentes dispositivos como teléfonos y tabletas lo cual no puede realizarse en este momento.
Esto implica un esfuerzo por parte del equipo técnico interno del cliente al remanufacturar todo su desarrollo y cambiar la estructura actual que implica el desarrollo de un cliente local con una conexión a un servidor SQL y de ahí su conexión a NAV a favor de un sistema que reciba las llamadas de una pagina web, procese las solicitudes, las dirija sus tablas o a las conexiones API o REST de Business Central, recibir las respuestas y presentarlas al usuario. Esto implica pensar en tablas en SQL Azure y almacenamiento en la nube (costo incremental) así como licencias de usuario por el acceso y modificación de datos.
Una de las ventajas mas importante, es la de poder desarrollar en el sistema las extensiones que se necesiten “sin costo de objetos y licencia de desarrollo” si es que el cliente aprende AL y el uso de VSCode además de poder agregar extensiones de otros partners acorde a sus necesidades.
En todo caso, se debe asegurar un escenario optimo de operación, traducido, poder registrar nn,nnn operaciones diarias.
Seguir On-Premise
El cliente cuenta actualmente con hardware suficiente para soportar esta operación aun con incrementos de un 50% de operación ya sea en picos o en tendencia creciente constante a alcanzar ese 50% o mas en un año con la posibilidad de crecer dicho hardware rápidamente. Esto permite que, desde el momento de registrar el pedido en el punto de venta a obtener una factura fiscal, incluyendo inserción en NAV, registro en NAV, envío a PAC y recepción de factura transcurra un mínimo de 6 segundos hasta un máximo de 20 segundos.
Entonces, ¿cuál o cuáles serían las ventajas de migrar de NAV a Business Central?
En primer lugar, debemos separar la aplicación de la operación para este análisis.
Respecto a la operación e integración de sistemas satélites, el cliente podrá o mas bien, deberá de migrar o remanufacturar su punto de venta a paginas web, esto permitirá crear un punto de venta independiente de la plataforma (Windows) pudiendo utilizar entonces Android (Tablets) que son más económicas que una computadora, ahorro en la licencia de Windows, menor costo de administración ya que no hay instalables, no hay que “actualizar la aplicación local” y, si se desarrollan las interfaces de usuario correctamente, podríamos incluso utilizar teléfonos permitiendo así, saltar una de las limitantes actuales (si no hay internet no hay venta) ya que el celular puede consumir datos logrando así incluso una venta ubicua, sucursales, eventos, en el domicilio del cliente, etc. Aquí incluso podemos implementar seguridad de conexión mediante certificados que se pueden generar o comprar para instalar en los equipos que podrán conectarse para vender.
Respecto al portal de proveedores, igualmente se deberá ajustar la arquitectura para poder trabajar en pagina web, esto facilitará no solamente la captura y programación de compras, incluso podríamos llegar a publicar “subastas” de compra a proveedores seleccionados sobre productos complementarios a la operación.
Apoyando esto, se puede ampliar la intranet y convertir una parte a extranet para el registro de gastos y viáticos permitiendo así un mejor control de gastos por parte del personal.
Ahora hablemos de la aplicación.
Business Central en versión On-premise NO es igual a la versión SaaS, punto.
Las diferencias pueden marcar o no la ruta a seguir en un inicio, de entrada, la mayor diferencia es la capacidad de desarrollo “gratis” ya que en la versión On-premise se deberán comprar los objetos necesarios para cualquier desarrollo y pagar el mantenimiento de estos a la “antigua usanza”.
- La integración con Teams está descartada y no hay planes de Microsoft de permitir esto (por ahora).
- El nuevo conector de Shopify NO puede usarse en ambientes On-premise (el cliente tiene su propio POS por lo que esto no es ningún problema).
- El hub de empresas y el contador externo NO sirven en On-Premise, no se requieren para este cliente.
- Algo que si es importante es el uso de Power Automate que no está habilitado para On-premise, esta si es una carencia importante, pero podría ser solventada con desarrollos ya que al final, el Power Automate es un “robot” que realiza ciertas acciones en función a ciertos disparadores, traducido a código seria una cola de proyectos de dispara funciones en codeunits en función a los suscriptores de eventos. Lógicamente, esto costará, pero igual cuesta el Power Automate.
- Respecto a la predicción de pagos atrasados, el “in-product search”, los sandbox (solo 3) y los Bookings, tampoco hay tema.
Ahora la lista de lo que requiere Azure Active Directory.
- Uso de Excel integrado, es importante pero igual se puede copiar y pegar.
- Combinación de correspondencia (Word), no se utiliza por el momento.
- Outlook, usan G Suite.
- PowerBI, usan QlikView.
Y para la conexión de REST, API´s y Web Services, se debe establecer manualmente un endpoint (como las versiones anteriores y con el uso de IIS), para permitir todo lo que comenté arriba para el nuevo POS.
Actualmente se cuenta con desarrollos en NAV 2013 que agregan campos a tablas del sistema mismos que pueden ser realizados como extensión utilizando incluso mismos nombres y tipos en Business Central.
Hay tablas intermedias donde se almacena la información previa a inyectarla a las tablas de NAV, estas tablas pueden replicarse sin problemas agregando, cambiando o quitando campos además de darle comportamientos de revisión gracias a su publicación como API, REST o Web Service.
La operación principal es realizada por el NAS que ejecuta codeunits especiales que validan, revisan copian y llaman codeunits estándar del sistema, digamos que mucho del diseño original realizado en 2013 se adecua a las normas y reglas actuales de Business Central por lo que mover esos desarrollos a extensiones e iniciar pruebas, será relativamente sencillo.
¿Cuál será el alcance de esta “migración”?
En primer lugar, dejar de decirle migración.
Se debe ver como un proyecto de reimplementación el cual permitirá cambiar el enfoque de la conexión y del punto de venta para permitir un crecimiento futuro “independiente” de la plataforma.
Es el momento de aprovechar y cambiar procesos definidos en su época que ya no son aplicables ahora y agregar procesos actuales que no existían en esa primera definición.
Aunque estamos de acuerdo en que los históricos no se migrarán, hay que definir qué información SI viajara al nuevo despliegue y la estrategia para hacerlo además de la conexión de Qlik con ambas bases de datos.
La depuración de catálogos maestros eliminando del nuevo despliegue productos descontinuados, clientes y proveedores no deseados y ajuste de dimensiones.
Hablamos de análisis de operaciones, si se cuenta con la documentación original, seria más fácil para ver que se cambió o que requiere cambiarse o mejorarse, si no, será entrevistas de usuarios con consultores que conozcan el negocio, definir los nuevos requerimientos.
Revisar el código, ver en que temas se requiere una mejora y esta puede darse, analizar con el equipo del cliente, los cambios posibles para darles visibilidad sobre su remanufactura de su POS y sesiones de arquitectura para definir nuevos caminos y rutas para el crecimiento del sistema.
Ayudar a depurar catálogos y como extraer la información para el nuevo inicio, hacer incluso las pruebas de carga y registro.
Capacitación en la nueva interfase ya que sufrió cambios considerables de las versiones 20xx a Business Central.
Ayuda y soporte en pruebas de desarrollos e integraciones, así como guía en nuevas integraciones.
Carga de saldos, acompañamiento en el arranque, soporte del primer mes.
Hay mucho trabajo por delante… mucho futuro del sistema por definir.
Continuara…...
Para ver la segunda parte da clic aquí
Leave a Reply
You must be logged in to post a comment.