con APPS

Este es el n.º 2 de 8 artículos sobre cómo cubrir todo su negocio con BUSINESS CENTRAL
- sin extensiones a medida
- utilizando solo APPS
Cubra todas sus necesidades de gestión de VENTAS y CLIENTES en BUSINESS CENTRAL.
En este artículo explicamos qué debe exigir, cómo evitar las personalizaciones y qué APPS utilizar.
Las ventas consisten, básicamente, en mantener un diálogo con clientes y socios comerciales, en el que ofrecemos bienes y servicios y hacemos coincidir las expectativas del cliente con nuestra capacidad de entrega.
Después recibimos un pedido, que puede llegar a través de muchos canales de pedido distintos. A continuación confirmamos el pedido al cliente y, cuando llega el momento de la entrega, planificamos el envío, algo que a menudo también involucra al departamento de ventas y que, como mínimo, debe coincidir con lo que hemos prometido durante el proceso de venta.
Estos son, en esencia, los procesos de venta que Business Central debe gestionar.

Calcular los precios para los clientes en Business Central puede ser una tarea compleja. Los descuentos de campaña y los acuerdos de precios pueden adoptar muchas formas, y debemos poder gestionarlos todos en Business Central.
Existen descuentos por volumen y descuentos de campaña, y además acuerdos de precios a medida para clientes concretos. Válidos solo durante un tiempo limitado. Específicos de una ubicación. O para un surtido seleccionado. Calcular automáticamente un precio exacto puede resultar muy complejo.
Si queremos elaborar una oferta con rapidez, nuestros precios deben estar estructurados y actualizados. Business Central lo hace bastante bien sin necesidad de soluciones complementarias.
Pero puede ocurrir que el artículo deba configurarse según los deseos del cliente. Esto suele ser también un reto en Business Central.

Si vendemos suscripciones, se trata de una necesidad de gestión independiente. Necesitamos una forma sencilla de generar facturas basadas en suscripciones, de forma masiva para una fecha de renovación seleccionada.

Y si tenemos artículos de alquiler, esto también requiere una solución específica. Queremos poder alquilar artículos a los clientes en un pedido de venta normal y aprovechar toda la funcionalidad de Business Central para la planificación, la disponibilidad, las reservas y la gestión de almacén con ubicaciones, números de serie, etc.

Gestionamos la comunicación y la relación con el cliente en un sistema CRM, porque para eso es ideal.
El CRM es muy útil para gestionar relaciones. Podemos llevar un diario del diálogo. El ERP, en cambio, es ideal para las transacciones y todo lo relacionado con cifras y dinero. Al personal de ventas internas y a los asistentes comerciales probablemente les guste trabajar en el ERP porque les interesan las cantidades y el dinero, pero los comerciales preferirán el CRM porque les interesan las relaciones y los diálogos.

El pedido puede recibirse en Business Central a través de muchos canales distintos, por ejemplo, ventas de campo, ventas internas, pedidos por correo electrónico, punto de venta, etc.
Es posible que tengamos una tienda de comercio electrónico o un portal de socios donde franquiciados, distribuidores u otros revendedores puedan realizar pedidos. También podemos tener acuerdos EDI con clientes seleccionados. Y debemos estar preparados para todos los nuevos canales de pedido que vayan apareciendo, como chatbots, comercio en redes sociales, compras dentro de aplicaciones, etc.

Utilizamos las siguientes apps para recibir pedidos en Business Central: algunas apps tienen fines específicos y Commerce Manager es la herramienta multiuso que nos permite añadir nuevos canales de pedido con facilidad.
Las integraciones son un tema importante en la entrada de pedidos. La integración no es algo especialmente interesante para quienes quieren optimizar los procesos de venta, pero es un requisito previo importante para que todos los canales de pedido de la empresa funcionen de forma automatizada.


Cuando registramos el pedido de venta, debemos poder reservar el artículo en el almacén de forma inteligente. Debemos priorizar los pedidos de venta y asignar los artículos en stock de la mejor manera posible.
Tenemos un artículo en stock ahora mismo, pero quedan pocas unidades. La cantidad restante está reservada para un pedido de venta que se entregará dentro de un mes.
Sin embargo, la semana que viene recibiremos un contenedor entero del producto. Si hay un cliente que desea realizar un pedido para entrega inmediata, Business Central rechazará el pedido porque el inventario actual está reservado. Pero queremos gestionar las reservas de forma más inteligente. Al fin y al cabo, recibiremos muchos artículos con tiempo suficiente, por lo que podemos liberar el stock actual para otro cliente. Es importante que podamos llevar a cabo este tipo de priorización.

Cuando enviamos al cliente una confirmación del pedido y, más adelante, un albarán y una factura, el diseño de estos documentos es un tema importante en Business Central.
Los documentos deben contener determinada información y datos maestros, y para ciertos clientes puede ser necesario un diseño distinto. También debemos poder enviar documentos por correo electrónico o EDI. Lo resolvemos con las dos apps siguientes:


Si tenemos muchas empresas que comercian entre sí, también debemos llevar el control de las operaciones intercompañía.
Debemos poder consultar cuántas unidades hay en stock en otras empresas y hacer que el artículo se envíe directamente al cliente. Y no queremos perder tiempo registrando las transacciones.

La planificación y la ejecución de las entregas no involucran mucho al departamento de ventas, pero si surge una falta de stock en un pedido de venta, debemos poder gestionarla, y es posible que el vendedor vuelva a intervenir para ofrecer un buen servicio al cliente y resolver el conflicto.
Para esta tarea necesitamos herramientas que resuelvan los conflictos de faltas de stock de la mejor manera, aclaren exactamente qué es posible entregar y cuándo, y proporcionen fechas de entrega en las que podamos confiar.


Ventas también puede participar en la planificación de las entregas al cliente. Necesitamos una forma sencilla de reservar un envío con un transitario e imprimir una carta de porte. Y para envíos de mayor tamaño, debemos poder planificar el envío de un contenedor, empaquetarlo de forma eficiente y enviarlo sin demasiado trabajo de registro manual.



Lo habitual en la mayoría de los sistemas ERP es que se puedan crear reservas como «reservas firmes».
Esto significa que, si tenemos el artículo en stock, o hay un pedido de compra en camino o una orden de producción en la que se fabricarán los artículos, podemos señalar desde el pedido de venta la recepción correspondiente y reservarla para la demanda.
Hay muchas empresas que utilizan esta función.
Por desgracia, esto bloquea muchas cosas en el sistema ERP porque, una vez hecha la reserva, queda fijada de forma «firme». Esto significa que, si desea revisar sus planes porque han cambiado las fechas de la demanda, debe «romper» la reserva manualmente.
El problema es que los pedidos de venta no siempre llegan en orden cronológico de entrega requerida, o que se prioriza a los clientes de forma distinta.
Si recibe un pedido que debe entregarse en 3 semanas y reserva el artículo del inventario, y mañana recibe un pedido urgente que debe entregarse en 3 días, es posible que no pueda entregarlo.
No hay tiempo para comprar el artículo, porque el plazo de entrega es de 1 semana. Sin embargo, es evidente que bastaría con romper la reserva, usar el artículo en stock para entregar el pedido urgente y después pedir nuevos artículos para el pedido que debe entregarse en 3 semanas.
Es bastante lógico, pero con reservas firmes hay que hacerlo de forma puramente manual.
Y la pregunta es: ¿llegaremos a darnos cuenta de que el problema puede resolverse rompiendo una reserva? Porque la mayoría de los sistemas simplemente nos dirán que no podemos suministrar el pedido urgente.
Esto es lo que hace interesante la idea de las reservas «flexibles» en el sistema ERP. Para muchas empresas, las reservas «flexibles» son la clave para elevar el nivel de servicio.
La mayoría de las empresas necesitan una forma más inteligente de gestionar las reservas, en la que el sistema pueda calcular lo que es factible según el principio de «primero en llegar, primero en ser servido».
Cuando añadimos un artículo a una línea de pedido de venta, el sistema ERP debería calcular lo que es factible; si no recibimos ninguna notificación, deberíamos poder dar por hecho que es entregable.
El sistema ERP debería ayudarnos a calcular las asignaciones matemáticamente más inteligentes. A esto nos referimos con reservas «flexibles».
Las reservas son aún más difíciles si, además, utilizamos un sistema de gestión de almacén. Nos obliga a tener en cuenta los números de lote y las ubicaciones.
Si hemos colocado el mismo artículo en diferentes ubicaciones del almacén porque se ha almacenado en varias operaciones, una reserva normalmente estará vinculada a una ubicación y un número de lote concretos.
El sistema obliga al operario a recoger de un número de lote y una ubicación específicos, lo que puede dar lugar a procesos bastante inadecuados en el almacén, quizá rompiendo un palé innecesariamente o creando una ruta de picking posiblemente poco óptima.
Con la gestión de almacén, la gestión de reservas se vuelve más compleja.
Imaginemos que un cliente nos llama por teléfono porque quiere pedir 100 unidades de un artículo para entregar en 2 semanas. Lo añadimos a la línea del pedido de venta y vemos que, por desgracia, no puede entregarse.
Le decimos al cliente que puede recibir una entrega parcial de 80 unidades en 14 días, pero que, si puede aceptar la entrega en 18 días, recibirá las 100 unidades en un solo envío.
Poder mantener esta conversación con el cliente en la fase de pedido es fantástico. Todas las expectativas quedan acordadas desde el principio.
Queremos que Business Central nos facilite esta información de inmediato, en cuanto añadimos artículos a las líneas del pedido de venta, y no después de que un proceso por lotes se haya ejecutado durante la noche.


La configuración consiste, en esencia, en gestionar las formas en que pueden componerse los productos configurables según los deseos de los clientes.
Pueden ser productos de complejidad relativamente baja, pero con algunas variables que el cliente puede elegir. El reto es que esto puede dar lugar rápidamente a miles o millones de combinaciones posibles, que no queremos crear como números de artículo independientes en Business Central.
La configuración ha ido entrando poco a poco en muchos sectores distintos, ya sea al comprar un coche, una cama, una estufa de leña o cualquier otra cosa.
Con la configuración queremos lograr dos cosas, y en la práctica existe un difícil equilibrio entre ambos objetivos:
Esto es difícil de conseguir en un ERP. Hay algunos complementos que admiten la configuración, y conviene elegir uno de ellos si necesita configuración, porque desarrollar una solución propia supone mucho trabajo.
Debe ser fácil para el cliente tomar las decisiones correctas al configurar el artículo y, naturalmente, el sistema ERP debe asegurarse de que el cliente solo haga selecciones válidas que realmente podamos entregar.
Todas las dependencias entre opciones deben configurarse en el sistema ERP. Y sería estupendo que el configurador pudiera mostrar, a medida que el cliente avanza, el efecto de cada decisión en el precio y la entrega.
La experiencia debe ser intuitiva y no se debe obligar al cliente a tomar decisiones en un orden determinado.
El sistema ERP debe permitir que las decisiones se tomen en un orden arbitrario. Esto plantea ciertos retos a la hora de gestionar las dependencias entre las selecciones, y el sistema ERP debe manejar esta estructura con soltura.
Las elecciones también pueden implicar que ya no haya que tomar decisiones sobre algunas de las preguntas posteriores, y el configurador no debería preguntar por ellas. También debería ser aceptable que el cliente no tenga preferencias en algunas preguntas. El configurador no debe forzar la mano del cliente.
La secuencia de las preguntas y las reglas sobre qué debe responderse primero influyen mucho en la experiencia de usuario en el sitio web o para quienes toman los pedidos.
Algunos configuradores solo pueden producir un artículo configurado creándolo como artículo en el sistema ERP. Esto significa que, una vez que el cliente ha compuesto su artículo, este se crea como un artículo independiente en el ERP, con una nueva ruta y una nueva lista de materiales.
Probablemente solo utilicemos ese artículo para este pedido. Puede que nunca volvamos a producir uno exactamente igual. No queremos que el sistema ERP termine lleno de números de artículo, rutas y listas de materiales que se han utilizado una sola vez.
Es realmente difícil informar de cuántas unidades de un artículo configurable se han vendido cuando todos los pedidos de venta acaban en números de artículo distintos.
Queremos una solución de configuración que no cree un nuevo número de artículo para cada pedido, a menos que el vendedor lo desee expresamente.
En su lugar, queremos crear un conjunto manejable de números de artículo para el artículo configurable. Deberían ser los casos más típicos y medios. Los llamamos «configuraciones maestras».
Ahora, cuando creamos una nueva configuración, utilizamos una configuración maestra como punto de partida y registramos las personalizaciones. La configuración maestra es el número de artículo en el que el artículo se producirá posteriormente.
Así, Producción puede ver qué configuración maestra debe fabricar y qué cambios respecto al estándar ha elegido el cliente. Pero la producción se realizará sobre el número de artículo de la configuración maestra, y los informes posteriores le mostrarán cuántas unidades de cada configuración maestra ha producido y vendido.
Esta es una forma mucho más inteligente de gestionar las configuraciones en el ERP. No nos ahogaremos en números de artículo y podremos elaborar informes sobre nuestros pedidos de venta y producciones.
También debería ser posible realizar una configuración inicial en una oferta de venta y, más adelante, convertirla en un pedido de venta de una configuración maestra con una lista de materiales modificada si el cliente desea comprar el artículo.
Debería ser posible que los parámetros registrados en la oferta de venta se trasladen hasta la orden de producción, de modo que no sea necesario copiar y pegar manualmente.
Las elecciones del cliente también deben aparecer en la oferta que se le envía, en la confirmación del pedido, en la factura, etc.
En los documentos no solo deben figurar las especificaciones. A menudo hay textos explicativos o legales que deben incluirse cuando el cliente toma una decisión concreta en la configuración.
¿Debería el configurador estar también disponible en su sitio web en modo de autoservicio?
En ese caso, el sitio web debe poder comunicarse con el sistema ERP mediante un servicio web o una API y recibir una respuesta cada vez que el cliente hace una selección. No conviene tener que mantener la lógica de configuración en dos lugares distintos.


Los representantes de ventas externos y la toma de pedidos en tiendas tienen mucho que ver con disponer de acceso remoto a Business Central.
Muchas empresas tienen empleados «sobre el terreno». Lo que muchos de ellos tienen en común es que no están acostumbrados a trabajar con un sistema ERP. Los vendedores de la oficina que toman pedidos por teléfono o trabajan en grandes ofertas de venta conocen el sistema ERP, pero quienes visitan a clientes y tiendas rara vez son usuarios experimentados de ERP.
Esto significa que necesitamos una solución que facilite tomar un pedido de venta sobre la marcha.
Lo habitual es que el representante utilice una tableta u otro dispositivo móvil con una interfaz de usuario sencilla que le permita registrar pedidos; un conector se encarga después de sincronizar los pedidos con el sistema ERP cada noche. Existen varias excelentes soluciones independientes para ello.
Hay que construir una integración para que el pedido pueda tomarse fuera del sistema ERP y sincronizarse con él más tarde. Todo esto está muy bien, aunque puede llegar a ser muy complicado.
Puede ser necesario replicar en el dispositivo móvil la lógica de toma de pedidos del sistema ERP.
Cuando introducimos una cantidad en un pedido de venta en el ERP, por ejemplo, puede que el sistema valide de inmediato cuándo podemos entregar el pedido, cuántas unidades del artículo hay en stock o si el cliente en cuestión puede comprar este artículo.
El vendedor externo también necesita disponer de esa lógica al tomar pedidos, de modo que el nivel de servicio sea el mismo tanto si el cliente trata con el vendedor como con la oficina central.
No sirve de nada que el vendedor tenga que llamar por teléfono a la oficina y pedir a alguien que compruebe si un artículo puede entregarse mañana.
Si el vendedor también necesita disponer de este tipo de rutinas de validación, necesitamos una solución que pueda aplicar la lógica del sistema ERP. Básicamente, hay dos maneras de hacerlo:
Entonces, ¿cuál es mejor? No hay una respuesta definitiva.
Si sus clientes esperan que el pedido se prepare y se despache el mismo día, la solución sin conexión probablemente quede descartada.
Business Central funciona ya íntegramente en el navegador, ofrece funciones muy útiles, como mostrar artículos con imágenes en las búsquedas de listas, y está enriquecido con información de una forma mucho más inteligente. Es algo que gusta a los vendedores externos. La opción con conexión resulta cada vez más atractiva.
Queremos que los vendedores puedan tomar pedidos directamente en el sistema ERP.
Puede ocurrir que los representantes de ventas externos acudan a lugares con una cobertura de Internet poco fiable. En esta situación, la solución con conexión causará problemas y la solución sin conexión, con un software independiente, salvará el día.
Hoy en día, la cobertura de Internet suele ser muy buena, pero sin duda hay excepciones, y también depende de lo crítico que resulte que la toma de pedidos no esté disponible.
En Business Central, es posible que nos baste con una licencia Team Member si queremos dar acceso en línea a los vendedores externos. Esto da acceso a una selección de tablas.
En Business Central podemos crear un centro de roles en el que seleccionemos las funciones que debe utilizar el vendedor; así obtendremos una interfaz de usuario muy depurada, en la que nuestros vendedores tienen acceso a toda la funcionalidad y a las configuraciones lógicas del sistema ERP, pero sin todo lo que no es necesario, lo que les proporciona una herramienta intuitiva.
Esto también nos ahorra comprar una solución de pedidos independiente y llevar a cabo la integración para sincronizarla con el ERP. De hecho, se puede ahorrar mucho dinero con ello.
Business Central no gestiona especialmente bien las comisiones. Siempre implica muchos informes, algo que los vendedores detestan. Tener que recopilar datos y hacer cálculos a posteriori nunca será popular entre los vendedores que cobran comisión.
Nuestros vendedores pueden tener varios acuerdos de comisión distintos, según los clientes a los que vendan, y quieren poder consultar por sí mismos qué comisión ganan y por qué, y disponer de una forma sencilla de verificar que los importes son correctos.
En Business Central no hay componentes estándar que gestionen esto bien.
Queremos extraer los datos del ERP e importarlos a un sistema de inteligencia empresarial como Microsoft Power BI. Necesitamos una forma de extraer datos de Business Central con facilidad.


POS significa Point-of-Sale (punto de venta), por supuesto, y consiste en disponer de un terminal de caja que pueda comunicarse con el sistema ERP.
El POS es una categoría de soluciones informáticas que ha avanzado mucho tecnológicamente. Ya no se trata solo de efectivo y tarjetas de pago; ahora se trata de pagos móviles, tarjetas de fidelización, máquinas de monedas, gestión de campañas, descuentos... y la lista continúa.
Hay muchas preguntas importantes:
Hay muchas cuestiones que resolver al elegir una solución POS. Las anteriores son solo algunas de las más evidentes.
Los números de artículo y los códigos de barras son un tema importante en los sistemas POS. Si vendemos artículos comprados a proveedores, dependemos en cierta medida de ellos en lo que respecta a los códigos de barras.
Asignar los códigos de barras de los artículos a los números de artículo del sistema ERP es un paso previo importante a la introducción de un sistema POS.
Vemos casos en los que se concentra demasiado en el mismo número de artículo del sistema POS porque la tienda trabaja con un precio único para muchos artículos distintos, lo que significa que se utiliza el mismo código de barras para artículos diferentes.
Esto es una mala noticia, porque hace imposible la gestión del inventario. No se puede ver qué artículos han pasado por caja. No se pueden medir las mermas ni los robos. No se puede contar el inventario.
Los códigos de barras también deben reflejar la estructura de variantes con la que se trabaja en el ERP.
Si vende una camisa en cuatro colores, seis tallas y dos materiales, el registro en el POS debe permitirle ver en el sistema ERP exactamente qué variante se ha vendido. Hablaremos más sobre el tema de las variantes en las secciones sobre comercio electrónico y datos maestros.
También debe decidir el nivel de gestión de inventario en la tienda.
Las empresas suelen querer gestionar con gran detalle el inventario remoto, mientras que la gestión de inventario en cada tienda suele ser menos detallada.
No muchos sistemas ERP ofrecen una gran solución para la planificación, el reaprovisionamiento y la disponibilidad y, al mismo tiempo, un POS bien resuelto.

Una tienda online es algo que necesitan muchas empresas, ya trabajen de empresa a empresa (B2B) o de empresa a consumidor (B2C), o quizá de empresa a agente (B2A), o a través de otro tipo de relación.
Hay muchas formas distintas de hacer comercio electrónico, pero queremos empezar por el sistema ERP y avanzar hacia la tienda online.
Los sistemas ERP son buenos gestionando datos. Para eso están diseñados. Los sistemas de comercio electrónico no siempre son óptimos para gestionar datos; a menudo solo las personas que trabajan en el back-end de la tienda online conocen los datos maestros y las estructuras de datos y saben cómo mantenerlos.
Queremos mantener la mayor cantidad posible de datos en el sistema ERP. Hablamos de atributos de datos estructurados, cadenas de texto para su uso en la tienda online, imágenes que deben poder verse o archivos que deben poder descargarse. Son muchos datos.
Mantener grandes volúmenes de datos de artículos en el sistema de comercio electrónico supone mucho trabajo. Actualizar los datos manualmente en ambos sistemas no es, desde luego, una buena solución.
Los requisitos de datos más básicos son los datos maestros de todos los artículos, todas las descripciones de artículos, los precios de venta, etc. Debería poder buscarse la mayor parte posible de esta información para que el cliente pueda buscar productos.
La información que los clientes quieren encontrar en su tienda online es del mismo tipo que la que usted desea tener en forma de datos estructurados en su sistema ERP. Tiene sentido mantener los datos maestros en el ERP y sincronizarlos con la tienda online.
Tenemos diferentes variantes de los mismos datos maestros. Los colores son un buen ejemplo. Vendemos un artículo para niños y lo tenemos en stock en seis colores distintos: cian, turquesa, azul real, magenta, cereza y rosa.
Estos no son en realidad los códigos de color que utiliza nuestro proveedor, por lo que nuestro departamento de compras tiene un campo que muestra los colores CMYK de todos los artículos.
En su tienda online, es posible que los clientes no busquen con tanto detalle. Buscan azul o rojo y se les presentan las diferentes variantes.
En este caso, acabamos con tres códigos de color distintos en cada artículo. Necesitamos toda esta información en cada artículo.
El sistema ERP también debe poder almacenar texto con formato HTML que se enviará a la tienda online y se mostrará correctamente.
Necesitamos mostrar iconos y pictogramas en los artículos para indicar que el artículo es ecológico, libre de parabenos, etc. Debemos poder registrarlo en el sistema ERP para que los iconos se muestren en la tienda online.
También debemos poder almacenar imágenes del artículo en el sistema ERP para mostrarlas en la tienda online.
El vendedor externo que trabaja en el sistema ERP puede crear pedidos de venta en su tableta y se beneficiará de disponer de las mismas imágenes, información y opciones de búsqueda en el sistema ERP que los clientes en la tienda online. Y los trabajadores del almacén también podrán ver las descripciones y todas las imágenes del artículo que deben preparar.
También queremos gestionar en el sistema ERP las jerarquías de artículos y grupos de artículos, es decir, la estructura que determina cómo se encuentran los artículos en la tienda online cuando el cliente selecciona una categoría o busca artículos.
El objetivo es poder crear un nuevo artículo con datos maestros en Business Central que lo sitúe automáticamente en la jerarquía y que el artículo aparezca después automáticamente en el lugar correcto de la tienda online, con imágenes, precios y todo, sin que nadie tenga que copiar y pegar nada en la tienda online.
En realidad, la pregunta más difícil en lo que respecta a la integración es cómo quiere aprovechar las funciones del sistema ERP para ofrecer un buen servicio al cliente en la tienda online.
Cuando un cliente quiere saber si un artículo está en stock, ¿cómo accede la tienda online al sistema ERP para averiguarlo?
En realidad, no queremos integraciones. Preferimos que la tienda online se gestione directamente desde Business Central. Y hoy en día eso es posible.


En general, los sistemas ERP se integran bastante mal con los sistemas CRM (gestión de relaciones con clientes), teniendo en cuenta lo valiosa que puede llegar a ser esa integración.
A grandes rasgos, en el sistema CRM el trabajo termina con un pedido, y en el ERP todo comienza con una oferta o un pedido. Sin embargo, hay muchos solapamientos.
El vendedor que cierra un trato con el cliente quiere tener acceso en el CRM a toda la información y las reglas de negocio del sistema ERP para poder hacer los mejores tratos posibles.
El sistema ERP contiene datos de producto, clasificaciones, reglas de descuento, historial de compras, facturas, historial de pagos, importes pendientes, inventario, reservas, plazos de entrega, capacidades, etc.
El vendedor, por supuesto, también puede crear ofertas en el ERP, y esta puede ser la mejor solución, especialmente si hay que configurar artículos.
Pero todo el diálogo con el cliente, los correos electrónicos y las actividades se gestionan normalmente en el CRM, no en el sistema ERP, por lo que, según este argumento, sería preferible tener la oferta en el sistema CRM.
La integración entre ERP y CRM suele ser sencilla y hecha a mano. La integración entre Business Central y Dynamics 365 Sales mejora poco a poco.
Fundamentalmente, debemos poder crear un pedido en el CRM y enviarlo al ERP, pero esto dista mucho de ser suficiente. CRM y ERP deben ser dos procesos de negocio integrados. Tampoco basta con transferir datos del ERP al CRM para mantener informado al vendedor.
¿Qué ocurre con la gestión de errores, por ejemplo, o con los cambios? ¿Qué debería ocurrir si se modifica un pedido, ya sea en el ERP o en el CRM? ¿Debería un cambio en el CRM aparecer en compras y producción en el ERP? ¿Será visible en el CRM un cambio de fecha de entrega, por ejemplo, realizado en el ERP, y podrá el vendedor ver que debería hablar con el cliente sobre la nueva fecha?
Podemos plantear muchos ejemplos de este tipo, y la integración acaba convirtiéndose en una tarea de gran envergadura.
La solución definitiva es que el vendedor utilice componentes del ERP puestos a disposición del CRM e integrados de forma tan perfecta que el vendedor no note que algunas de las funciones proceden en realidad de otro sistema.
La sincronización bidireccional habitual de datos maestros, como los datos de contacto, puede abordarse mediante una integración ordinaria, y la lógica de negocio puede resolverse incorporando funciones del otro sistema.
Cuando hablamos de ventas y marketing, no debemos olvidar que el departamento de marketing tiene necesidades informáticas cada vez mayores.
Según nuestra experiencia, la mayoría de los sistemas CRM actuales no están diseñados para los profesionales de marketing que trabajan en las primeras fases del recorrido del cliente. El director de ventas normalmente desconoce las necesidades informáticas de Marketing, mientras que la mayoría de los profesionales de marketing modernos ven el CRM solo como una base de datos de contactos.
No es en absoluto inusual que el departamento de marketing esté suscrito a entre 10 y 20 sistemas en la nube distintos de los que el departamento de TI nunca ha oído hablar. Y algunos de ellos incluso se integran con el CRM o el ERP sin que los responsables del CRM y del ERP lo sepan.
En general, trabajamos en distintas fases del recorrido del cliente:
Marketing necesita procesos automatizados que emulen el procesamiento manual.
Por eso Marketing adquiere herramientas de proceso como la automatización de marketing para supervisar grandes cantidades de datos, elaborar perfiles de clientes y llevar a cabo procesos automatizados a partir de ellos.
Por supuesto, el CRM debe integrarse con las herramientas del departamento de marketing. A veces, esto puede hacerse con mucha facilidad. Por ejemplo, Power Automate puede tomar datos de sistemas de correo electrónico o de campañas de marketing y crear directamente clientes potenciales o contactos en Dynamics 365 Sales.
Las herramientas del departamento de marketing pueden ser de gran ayuda para los vendedores. Pueden recopilar mucha información sobre el comportamiento de los clientes que será de interés para ellos.