Implementando Business Central, ¿una nueva manera de hacerlo?

Lei un blog de Bjorgvin Gudmundsson (aquí el link) sobre el costo de implementación de Business Central bastante interesante y digamos que estoy de acuerdo en muchos puntos pero como siempre, el mundo europeo es muy diferente a algo fuera de ese continente.

La estrategia tradicional es la que sigue primando en Latinoamérica, donde se realiza un análisis, el diseño, un documento (o varios) muy extensos donde se pone con pelos y señales que es lo que hará el ERP cuando se oprima una tecla y sean las 10:23 de la mañana.

Todo esto, es puesto por escrito y lógicamente, cuantificado. Tenemos el documento de fit/gap y el proyecto ha incrementado su costo en, varios miles de dólares mas de la estimación inicial.

Ciertamente, uno de los principales causantes de esto, es la necesidad del usuario de que el sistema haga lo mismo que hace el actual porque es un requerimiento del negocio que alguien, que lo mas seguro es que ya no trabaje ahí, lo pidió hace cierto tiempo.

La segunda causa mas importante es, pues ya que vamos a invertir, que el sistema haga todo lo que no hace el actual, sin importar que no se sepa que hace el nuevo sistema.

La tercera causa es, necesito mis reportes actuales exportados desde el nuevo sistema para poder “cuadrar” la información sin importar que el nuevo sistema no requiera dicho “cuadre”. Aquí una pequeña disgreción, recientemente, fuí a un análisis (si acusome yo) y una de las peticiones mas importantes era el “cuadre” de la información de cuentas por cobrar del cliente contra la cuenta de cuentas por cobrar del catalogo de cuentas. Mostré el funcionamiento, demostré que cualquier movimiento que hagas utilizando al cliente hará un asiento contable contra las cuentas correspondientes, documente que no hay manera que si se hace un registro, este no haga algún movimiento en contabilidad y aun así, “necesito mi reporte para el cuadre”.

Regresando al tema, hay muchas maneras de incrementar costos y tiempo a un proyecto de implementación, cualquier partner sabe como hacerlo.

Pero, ¿Cómo disminuimos el costo de una implementación? Esa es la parte interesante.

En el blog mencionado, se explica la forma moderna de hacerlo, el cambio de paradigma donde “la última meta es ganar el juego” definiendo dichas metas como pasos específicos a realizar o cubrir antes de pasar a algo mas.

Aquí comenzamos con los problemas para la implementación tradicional, ¿pero cuál será el costo total del proyecto?¿cuál será el tiempo total del proyecto?¿cuánto ganará el partner en el proyecto? etc, etc, etc.

En las fechas en las que escribo este blogpost, estoy viendo un cliente con SL 2011 y SL2015, mal implementado y un dolor de cabeza para dicha empresa. Muchos retrabajos, mucha operación por fuera, lo clásico.

Hubo demo de Business Central, los usuarios fascinados, el dueño interesado, todo bien hasta el siguiente intercambio de información:

Acabamos de invertir en SL2015 para “n” empresas y estamos dejando “n” en 2011. ¿Como podemos minimizar el costo de irnos por Business Central?

Me interesa mucho lo de producción y proyectos pero, ¿hay alguna forma en la que podamos iniciar mas barato y posteriormente ir agregando cosas?

Justamente lo que menciona Bjorgvin en su post, la “Manera Moderna” entró en escena junto con “Estimando costos de implementación Ágil”.

Asumamos que lo importante para el cliente es poder comprar, vender, pagar, cobrar y que todo quede registrado en la contabilidad. Como dice Bjorgvin, necesitamos identificar el conjunto mas pequeño de características a implementar (y aquí entra la diferencia de Latam con Europa), es decir:

• Gestion Financiera
• Ventas
• Compras
• Almacén

¿Porque estos módulos específicamente?

Recordemos que en Latam se está implementando la factura electrónica en muchos países (y contabilidad electrónica en México), esto implica enviar información de múltiples líneas y la cabecera por lo que el uso de diarios de compras y ventas queda descartado, además se debe guardar el resultado de la facturación electrónica en el historial y en el caso de Mexico, mismo proceso para los pagos, transferencias entre almacenes, anticipos, etc (depende del tipo y actividades de la empresa).

Con esos módulos en mente y el alcance definido por el cliente, el proceso de venta actual (y de implementación) se definió como sigue:

• Copia de la base de SL2015 en SQL
• Extracción de catálogos maestros de SQL empresa 1
• Carga de Catálogos a Business Central
• Configuración contable
• Paquete de RapidStart para crear nueva empresa sin clientes, proveedores ni productos.
• Extracción de catálogos maestros de SQL empresa 2
• Carga de Catálogos a Business Central
• Configuración de intercompañias
• Creación empresa consolidadora
• Copia de RapidStart a consolidadora

Tiempo total de estas operaciones 24 horas.

Siguiente fase es pruebas de operaciones con usuarios del cliente y posteriormente, utilizaremos la facturación electrónica estándar de Business Central junto con la contabilidad electrónica. Pensemos en dos semanas de pruebas y ajustes.

¿Que seguiría?

Detectar donde no se puede cumplir con los procesos mínimos requeridos por el cliente (posiblemente la factura electrónica de traslado) y lógicamente todo lo relacionado a la producción y proyectos (que tampoco está en SL).

Documentar y proceder con la creación de los procesos requeridos mientras se capacita a los usuarios en los saldos iniciales además de la operación normal del sistema

Pruebas finales de desarrollos y entonces podría ser el Go Live.

El proyecto podría llevar unas 160 horas sin problemas pensando en desarrollo, capacitación y todo lo necesario para ponerlo en marcha.

¿Podemos hacer implementaciones de "forma moderna" en Latam?

Creo que la respuesta es sí, pero primero, debemos educar a los clientes que toman las decisiones y a los usuarios avanzados para que comprendan esta forma moderna.

Esta educación debe incluir el proyecto "sin papel", las "ejecuciones y pruebas continuas" y la relación de confianza entre el cliente y el socio porque este es el punto más duro en Latinoamérica, la relación de confianza (y por qué necesitamos un documento con un muy buen alcance del proyecto definido).

Otro punto de capacitación es el propio socio y sus consultores, por lo general, comienzan un nuevo proyecto con las sesiones de análisis, tomando las mismas notas para los mismos procesos y más tarde, escribiendo el mismo documento de requisitos funcionales con las mismas soluciones.

Todas las empresas venden de alguna forma con “el mismo proceso", algunas parten de cotizaciones, otras con pedidos de venta, pero todos, seleccionaa al cliente, los artículos, los precios, las cantidades, etc., ¿qué diferencia podemos encontrar aquí?

Alguien puede pedir "Necesito un método para seleccionar el lote", puedes usar el proceso de selección de lote estándar, "Ok, pero necesito que el sistema los seleccione por mí y no, no usamos WMS", ok, esto es un problema pero tenemos que pensar, ¿el usuario debe seleccionar más de 10 números de lote? ¿Quizás podamos desarrollar algo, la relación costo / beneficio de este desarrollo puede ayudar al cliente? Tal vez, está del lado del cliente elegir pagar el desarrollo o no, pero evita usar más de 8 horas haciendo un documento para que lleguemos al mismo lugar, el usuario solicita la asignación automática de lotes.

Este ejemplo nos muestra la diferencia entre la forma antigua y la moderna. En el estilo antiguo, tomas notas, haces un documento, haces una presentación del documento, el usuario recibe el documento y una semana más tarde (o más) recibes la queja sobre la selección automática de lotes, debes modificar el documento nuevamente y esperar tal vez otra semana hasta que el usuario esté de acuerdo con el proceso representado.

Luego comienza con el análisis de fit/gap, realizas un diseño de desarrollo para la asignación automática de lotes, verifica con su desarrollador el tiempo para este trabajo, tal vez crear escenarios de pruebas de usuario; finalmente vas con el cliente y presentas tu documento, puedes obtener un "Está bien, adelante" o "¿Qué? Esto es costoso, el usuario puede hacer la asignación de lotes de la manera estándar del sistema" y tu obtienes una mirada enojada del usuario.

El mismo escenario en la forma moderna es, ejecuta algunos escenarios con el usuario, y llega al proceso de asignación de lotes, muestra ese proceso hablando de cómo puede reordenar los lotes por fecha o número (recuerda, es una prueba, es una clase, es una sesión de entrenamiento, pero lo más importante, es una sesión de sensibilización sobre las cosas buenas del sistema) y el usuario dice que necesita la asignación automática de lotes, pero en este momento, conoce las formas manuales, observó cómo lo hizo bajo tu supervisión por lo tanto, cuando vas con el tomador de decisiones, explicas ambas formas, manual o de desarrollo, y el tiempo que necesitarás para hacer el documento de diseño, el tiempo de desarrollo esperado y ambos usuarios comenzarán a pensar en los costos, sobre el tiempo requerido y el proceso estándar manual. No estoy diciendo que los usuarios van a elegir el estándar, pero al menos, vas a trabajar en un diseño de desarrollo preaprobado (porque dices el precio inicial cuando explica el problema) y ahorró mucho tiempo y costos.

¡Escribir esta publicación me hace pensar que la forma moderna es genial!

Otro problema es el variado sistema tributario, algunos países usan el IVA, otros usan las retenciones (Business Central no calcula estas retenciones de manera automatizada), la impresora fiscal, la facturación electrónica y muchas regulaciones y leyes.

Hablando sobre el cliente de los párrafos anteriores, en México necesitamos controlar algo llamado número de documento de importación e imprimir ese número cuando se vendan los artículos importados; bueno, este cliente importa artículos de otros países y esto puede ser un problema porque Business Central no maneja este tipo de información, la buena noticia aquí es que no venden directamente los artículos, los usan en sus proyectos, por lo que la factura final no necesita mostrar esa información y podemos saltar este problema.

Asi que, ¿hay una forma moderna de implementacion?

“En un proyecto normal, necesitamos administrar o desarrollar extensiones para dar soluciones a los problemas habituales, un buen partner debería haber planeado todo esto y tener soluciones disponibles para integrar y hacer que todo funcione.”

Si la respuesta a la afirmación anterior es Sí, puedes continuar con el método de la implementación moderna y lograr proyectos de bajo costo y tiempo.

Si la respuesta a la afirmación es No, bueno, tienes un gran problema, estás trabajando a la antigua usanza y quizás este sea el problema por el cual tu empresa no puede cerrar nuevos proyectos y los otros jugadores pueden hacerlo, Eres demasiado caro para este nuevo mundo de Business Central.