avec des APPS

Voici l’article n° 2 sur 8 articles expliquant comment couvrir l’ensemble de votre entreprise avec BUSINESS CENTRAL
- sans extensions spécifiques client
- uniquement avec des APPS
Répondez à tous vos besoins de gestion des VENTES et des CLIENTS dans BUSINESS CENTRAL.
Dans cet article, nous expliquons ce que vous devez exiger, comment éviter les développements spécifiques et quelles APPLICATIONS utiliser.
Vendre, c'est avant tout dialoguer avec des clients et des partenaires commerciaux, auxquels nous proposons des biens et des services, en conciliant les attentes du client et notre capacité à livrer.
Nous recevons ensuite une commande, qui peut arriver par de nombreux canaux. Nous la confirmons au client puis, pour la livraison, nous planifions l'expédition, ce qui implique souvent aussi le service commercial, et elle doit au minimum correspondre à ce que nous avons promis lors du processus de vente.
Ce sont, pour l'essentiel, les processus de vente que Business Central doit gérer.

Calculer les prix pour les clients dans Business Central peut être une tâche complexe. Les remises promotionnelles et les accords tarifaires peuvent prendre de nombreuses formes, et nous devons pouvoir tout gérer dans Business Central.
Il y a les remises sur volume et les remises promotionnelles, puis les accords tarifaires spécifiques à certains clients. Valables pour une durée limitée. Propres à un site. Ou à un assortiment donné. Il peut être très complexe de calculer automatiquement un prix exact.
Si nous voulons établir rapidement un devis, nos prix doivent être structurés et à jour. Business Central s'en sort plutôt bien sans solutions complémentaires.
Mais il se peut que l'article doive être configuré selon les souhaits du client. C'est généralement aussi un défi dans Business Central.

Si nous vendons des abonnements, c'est un besoin de gestion à part entière. Il nous faut un moyen simple de produire des factures d'abonnement, en masse, pour une date de renouvellement donnée.

Et si nous avons des articles en location, cela nécessite également une solution dédiée. Nous voulons pouvoir louer des articles à des clients sur une commande vente ordinaire, en exploitant toutes les fonctionnalités de Business Central pour la planification, la disponibilité, les réservations, la gestion d'entrepôt avec emplacements, numéros de série, etc.

Nous gérons la communication et la relation avec le client dans un système CRM, car c'est ce pour quoi il est fait.
Le CRM est idéal pour gérer les relations. Nous pouvons tenir un journal du dialogue. L'ERP, lui, excelle dans les transactions et tout ce qui touche aux chiffres et à l'argent. Les sédentaires et les assistants commerciaux préféreront sans doute saisir dans l'ERP, car ils s'intéressent aux quantités et à l'argent, alors que les commerciaux préfèrent le CRM, car ils s'intéressent aux relations et aux dialogues.

La commande peut arriver dans Business Central par de nombreux canaux : vente terrain, vente sédentaire, commandes par e-mail, point de vente, etc.
Nous avons peut-être une boutique en ligne ou un portail partenaires où franchisés, distributeurs ou autres revendeurs peuvent passer commande. Nous avons peut-être aussi des accords EDI avec certains clients. Et nous devons être prêts pour tous les nouveaux canaux de commande qui apparaissent, par exemple les chatbots, le commerce sur les réseaux sociaux, les achats intégrés aux applications, etc.

Nous utilisons les applications suivantes pour recevoir des commandes dans Business Central : certaines répondent à des besoins précis, et Commerce Manager est l'outil polyvalent qui nous permet d'ajouter facilement de nouveaux canaux de commande.
Les intégrations sont un sujet majeur dans la prise de commande. L'intégration n'est pas ce qui intéresse le plus ceux qui veulent optimiser les processus de vente, mais c'est une condition essentielle pour que tous les canaux de commande de l'entreprise fonctionnent de façon automatisée.


Lorsque nous prenons la commande vente, nous devons pouvoir réserver intelligemment l'article en entrepôt. Nous devons prioriser les commandes vente et allouer au mieux les articles en stock.
Nous avons actuellement un article en stock, mais il n'en reste que quelques-uns. La quantité restante est réservée pour une commande vente à livrer dans un mois.
Pourtant, nous recevrons un conteneur entier de ce produit la semaine prochaine. Si un client souhaite passer commande pour une livraison immédiate, Business Central rejettera la commande parce que le stock actuel est réservé. Mais nous voulons gérer les réservations plus intelligemment. Après tout, nous serons livrés en abondance en temps voulu et pouvons donc libérer le stock actuel pour un autre client. Il est important de pouvoir effectuer ce type de priorisation.

Lorsque nous envoyons une confirmation de commande au client, puis plus tard un bon de livraison et une facture, la mise en page de ces documents est un sujet important dans Business Central.
Les documents doivent contenir certaines informations et données de base, et ils peuvent devoir avoir une mise en page différente pour certains clients. Nous devons aussi pouvoir envoyer les documents par e-mail ou par EDI. Nous résolvons cela avec les deux applications suivantes :


Si plusieurs sociétés commercent entre elles, nous devons aussi gérer l'intersociété.
Nous devons pouvoir consulter les stocks des autres sociétés et faire expédier l'article directement au client, sans perdre de temps à comptabiliser les transactions.

La planification et l'exécution des livraisons impliquent peu le service commercial, mais si une pénurie survient sur une commande vente, nous devons pouvoir la gérer, et le vendeur peut être à nouveau sollicité pour offrir un bon service client et résoudre le conflit.
Pour cela, il nous faut des outils pour résoudre au mieux les conflits de pénurie, déterminer précisément ce qui peut être livré et quand, et fournir des dates de livraison fiables.


Le service commercial peut aussi participer à la planification des livraisons au client. Nous exigeons un moyen simple de réserver un envoi auprès d'un transporteur et d'imprimer une lettre de transport. Et pour les expéditions plus importantes, nous devons pouvoir planifier l'envoi d'un conteneur, le charger efficacement et l'expédier sans trop de saisie manuelle.



Dans la plupart des ERP, il est possible de créer des réservations dites « fermes ».
Cela signifie que, si vous avez l'article en stock, ou une commande achat en cours ou un ordre de fabrication sur lequel les articles doivent être produits, vous pouvez pointer depuis la commande vente vers la réception correspondante et la réserver pour le besoin.
De nombreuses entreprises utilisent cette fonctionnalité.
Malheureusement, cela verrouille beaucoup de choses dans l'ERP, car une fois la réservation faite, elle est « ferme ». Si vous voulez revoir vos plans parce que les dates de besoin ont changé, vous devez « rompre » la réservation manuellement.
Le problème est que les commandes vente n'arrivent pas toujours dans l'ordre chronologique de livraison souhaitée, ou que vous priorisez différemment vos clients.
Si vous recevez une commande à livrer dans 3 semaines, que vous réservez l'article en stock, puis que vous recevez demain une commande urgente à livrer dans 3 jours, vous ne pourrez peut-être pas livrer.
Vous n'avez pas le temps d'acheter l'article, car le délai d'approvisionnement est d'une semaine. Pourtant, il est évident que vous pourriez simplement rompre la réservation, utiliser l'article en stock pour livrer la commande urgente, puis commander de nouveaux articles pour la commande à livrer dans 3 semaines.
C'est tout à fait logique, mais cela doit se faire entièrement à la main si nous utilisons des réservations fermes.
Et la question est : nous rendrons-nous seulement compte que le problème peut être résolu en rompant une réservation ? Car la plupart des systèmes se contentent de nous dire que nous ne pouvons pas fournir la commande urgente.
C'est ce qui rend l'idée de réservations « souples » dans l'ERP intéressante. Pour de nombreuses entreprises, les réservations « souples » sont la clé pour améliorer le niveau de service.
La plupart des entreprises ont besoin d'une façon plus intelligente de gérer les réservations, où le système peut calculer ce qui est faisable selon le principe du « premier arrivé, premier servi ».
Lorsque nous ajoutons un article à une ligne de commande vente, l'ERP devrait calculer ce qui est faisable ; tant que nous ne recevons pas de notification, nous devrions pouvoir considérer que l'article est livrable.
L'ERP devrait nous aider à déterminer les allocations les plus intelligentes sur le plan mathématique. C'est ce que nous entendons par réservations « souples ».
Les réservations sont encore plus difficiles si nous utilisons aussi un système de gestion d'entrepôt, car il faut tenir compte des numéros de lot et des emplacements.
Si nous avons rangé le même article à différents emplacements de l'entrepôt, parce qu'il a été stocké en plusieurs opérations, une réservation portera généralement sur un emplacement et un numéro de lot précis.
Le système oblige le préparateur à prélever dans un lot et un emplacement donnés, ce qui peut conduire à des processus assez inadaptés dans l'entrepôt : une palette entamée inutilement, ou un parcours de préparation peut-être sous-optimal.
Avec la gestion d'entrepôt, la gestion des réservations devient plus complexe.
Imaginons un client au téléphone qui veut commander 100 unités d'un article pour une livraison dans 2 semaines. Nous l'ajoutons à la ligne de commande vente et constatons qu'il ne peut malheureusement pas être livré.
Nous disons au client qu'il peut avoir une livraison partielle de 80 unités dans 14 jours, mais que, s'il accepte une livraison dans 18 jours, il peut recevoir les 100 unités en une seule expédition.
Pouvoir avoir cette conversation avec le client dès la prise de commande est formidable. Toutes les attentes sont convenues dès le départ.
Nous voulons que Business Central nous donne cette information immédiatement lorsque nous ajoutons des articles aux lignes de commande vente, et non après un traitement par lots exécuté pendant la nuit.


La configuration consiste essentiellement à gérer la manière dont les produits configurables peuvent être assemblés selon les souhaits des clients.
Il peut s'agir de produits relativement peu complexes, mais comportant quelques variables que le client peut choisir. Le défi est que cela peut rapidement produire des milliers, voire des millions de combinaisons possibles, que nous ne voulons pas créer comme autant de numéros d'article distincts dans Business Central.
La configuration a peu à peu gagné de nombreux secteurs, qu'il s'agisse d'acheter une voiture, un lit, un poêle à bois ou autre chose.
Avec la configuration, nous voulons atteindre deux objectifs, entre lesquels il existe en pratique un compromis difficile :
C'est difficile à réaliser dans un ERP. Certains modules complémentaires prennent en charge la configuration, et il vaut mieux en choisir un si vous avez besoin de configuration, car développer sa propre solution représente beaucoup de travail.
Le client doit pouvoir facilement faire les bons choix lors de la configuration de l'article, et l'ERP doit naturellement garantir que le client ne fait que des sélections valides que nous pouvons réellement livrer.
Toutes les dépendances entre les options doivent être configurées dans l'ERP. Et il serait idéal que le configurateur puisse montrer au client, au fil de ses choix, l'effet de chacun sur le prix et la livraison.
L'expérience doit être conviviale, et le client ne doit pas être obligé de prendre ses décisions dans un ordre particulier.
L'ERP doit permettre de prendre les décisions dans un ordre arbitraire. Cela crée certains défis dans la gestion des dépendances entre les sélections, et l'ERP doit maîtriser cette structure.
Certains choix peuvent aussi faire que plus aucune décision n'est à prendre sur certaines questions suivantes, et le configurateur ne doit alors pas les poser. Il doit aussi être acceptable que le client n'ait pas de préférence sur certaines questions. Le configurateur ne doit pas forcer la main du client.
La séquence des questions et les règles sur ce à quoi il faut répondre en premier ont un grand impact sur l'expérience utilisateur sur le site web ou auprès des preneurs de commandes.
Certains configurateurs ne peuvent produire un article configuré qu'en le créant comme article dans l'ERP. Cela signifie que, dès que le client a composé son article, celui-ci est créé comme article distinct dans l'ERP, avec une nouvelle gamme et une nouvelle nomenclature.
Nous n'utiliserons probablement cet article que pour cette seule commande. Nous n'en produirons peut-être jamais un strictement identique. Nous ne voulons pas que l'ERP se remplisse de numéros d'article, de gammes et de nomenclatures n'ayant servi qu'une seule fois.
Il est vraiment difficile de savoir combien d'unités d'un article configurable ont été vendues lorsque toutes les commandes vente aboutissent sur des numéros d'article distincts.
Nous voulons une solution de configuration qui ne crée pas de nouveau numéro d'article pour chaque commande, sauf si le vendeur le souhaite expressément.
Nous voulons plutôt créer un ensemble gérable de numéros d'article pour l'article configurable. Ce doivent être les cas les plus typiques, moyens. Nous les appelons « configurations maîtres ».
Désormais, lorsque nous créons une nouvelle configuration, nous partons d'une configuration maître et nous enregistrons les personnalisations. La configuration maître est le numéro d'article sur lequel l'article sera ensuite produit.
La production voit ainsi quelle configuration maître elle doit produire et quelles modifications par rapport au standard le client a choisies. Mais la production s'effectue sur le numéro d'article de la configuration maître, et le reporting ultérieur indique combien d'unités de chaque configuration maître ont été produites et vendues.
C'est une façon bien plus intelligente de gérer les configurations dans l'ERP. Nous ne nous noyons pas sous les numéros d'article et pouvons établir des rapports sur nos commandes vente et nos productions.
Il devrait aussi être possible d'effectuer une première configuration sur un devis, puis de la convertir plus tard en commande vente pour une configuration maître avec une nomenclature modifiée si le client souhaite acheter l'article.
Les paramètres enregistrés sur le devis devraient pouvoir être transmis jusqu'à l'ordre de fabrication, sans aucun copier-coller manuel.
Les choix du client doivent aussi figurer sur le devis transmis au client, la confirmation de commande, la facture, etc.
Il n'y a pas que les spécifications qui doivent figurer sur les documents. Il faut souvent y inclure des textes explicatifs ou juridiques lorsque le client fait un choix précis dans la configuration.
Le configurateur doit-il aussi être disponible en libre-service sur votre site web ?
Si oui, le site web doit pouvoir communiquer avec l'ERP via un service web ou une API et obtenir une réponse à chaque sélection du client. Il n'est pas souhaitable de devoir maintenir la logique de configuration à deux endroits différents.


Les commerciaux itinérants et la prise de commande en magasin reposent largement sur l'accès à distance à Business Central.
De nombreuses entreprises ont des collaborateurs « sur le terrain ». Beaucoup d'entre eux ont en commun de ne pas être habitués à travailler avec un ERP. Les commerciaux au bureau, qui prennent des commandes par téléphone ou travaillent sur de gros devis, connaissent l'ERP, mais ceux qui rendent visite aux clients et aux magasins sont rarement des utilisateurs expérimentés d'ERP.
Cela signifie qu'il nous faut une solution qui facilite la prise d'une commande vente en déplacement.
Le plus souvent, le commercial utilise une tablette ou un autre appareil mobile doté d'une interface simple lui permettant d'enregistrer les commandes ; un connecteur assure ensuite la synchronisation des commandes avec l'ERP chaque nuit. Il existe plusieurs excellentes solutions autonomes pour cela.
Il faut construire une intégration pour que la commande puisse être prise en dehors de l'ERP et synchronisée plus tard. C'est très bien, même si cela peut devenir très compliqué.
La logique de prise de commande de l'ERP doit parfois être reproduite sur l'appareil mobile.
Lorsque nous saisissons une quantité sur une commande vente dans l'ERP, par exemple, l'ERP peut immédiatement valider quand nous pouvons livrer la commande, combien d'unités sont en stock, ou si le client concerné peut seulement acheter cet article.
Le commercial itinérant doit aussi disposer de cette logique lors de la prise de commande, afin que le niveau de service soit le même qu'il s'adresse au commercial ou au siège.
Il n'est pas acceptable que le commercial doive appeler le bureau pour demander à quelqu'un de vérifier si un article peut être livré demain.
Si ce type de routine de validation doit aussi être disponible pour le commercial, il nous faut une solution capable d'appliquer la logique de l'ERP. Il existe essentiellement deux façons d'y parvenir :
Alors, laquelle est la meilleure ? Il n'y a pas de réponse définitive.
Si vos clients attendent que la commande soit préparée et expédiée le jour même, la solution hors ligne est probablement exclue.
Business Central est désormais entièrement basé sur le navigateur, offre d'excellentes fonctionnalités comme l'affichage des articles avec images dans les recherches de liste, et enrichit l'information de façon bien plus intelligente. C'est ce qu'apprécient les commerciaux itinérants. L'option en ligne devient de plus en plus attrayante.
Nous voulons permettre aux commerciaux de prendre les commandes directement dans l'ERP.
Il arrive que les commerciaux itinérants se rendent dans des endroits où la couverture Internet n'est pas fiable. Dans ce cas, la solution en ligne pose problème, et la solution hors ligne, avec un logiciel distinct, sauve la situation.
Aujourd'hui, la couverture Internet est en général très bonne, mais il y a bien des exceptions, et la question est aussi de savoir à quel point il serait critique que la prise de commande soit indisponible.
Dans Business Central, une licence Team Member peut suffire si nous voulons donner un accès en ligne aux commerciaux itinérants. Elle donne accès à une sélection de tables.
Dans Business Central, nous pouvons créer un centre de rôle dans lequel nous sélectionnons les fonctionnalités que le commercial doit utiliser ; nous obtenons alors une interface très épurée, où les commerciaux ont en réalité accès à toutes les fonctionnalités et configurations logiques de l'ERP, mais où tout ce qui n'est pas nécessaire a été retiré, ce qui donne aux commerciaux un outil intuitif.
Cela nous évite aussi d'acheter une solution de commande distincte et de réaliser l'intégration pour la synchroniser avec l'ERP. On peut ainsi économiser beaucoup d'argent.
Les commissions ne sont pas particulièrement bien gérées dans Business Central. Elles impliquent toujours beaucoup de rapports, ce que les commerciaux détestent. Devoir collecter des données et faire les calculs a posteriori ne sera jamais populaire auprès des commerciaux rémunérés à la commission.
Nos commerciaux peuvent avoir plusieurs accords de commission différents selon les clients auxquels ils vendent, et ils veulent pouvoir extraire eux-mêmes la commission qu'ils gagnent et pour quoi, avec un moyen simple de vérifier que les montants sont corrects.
Dans Business Central, aucun composant standard ne gère bien cela.
Nous voulons extraire les données de l'ERP et les importer dans un système de Business Intelligence comme Microsoft Power BI. Il nous faut un moyen d'extraire facilement les données de Business Central.


POS signifie bien sûr Point of Sale (point de vente) : il s'agit d'un terminal de caisse capable de communiquer avec l'ERP.
Le POS est une catégorie de solutions informatiques qui a beaucoup progressé sur le plan technologique. Il ne s'agit plus seulement d'espèces et de cartes bancaires ; il s'agit désormais de paiements mobiles, de cartes de fidélité, de monnayeurs, de gestion de campagnes, de remises, et la liste est longue.
De nombreuses questions sont importantes :
De très nombreuses questions doivent être tranchées lors du choix d'une solution POS. Celles ci-dessus ne sont que les plus évidentes.
Les numéros d'article et les codes-barres sont un sujet majeur dans les systèmes POS. Si nous vendons des articles achetés auprès de fournisseurs, nous dépendons un peu d'eux pour les codes-barres.
Faire correspondre les codes-barres des articles aux numéros d'article de l'ERP est un préalable important à l'introduction d'un système POS.
Nous voyons des cas où beaucoup trop de choses sont regroupées sous le même numéro d'article dans le POS, parce que le magasin travaille avec un prix unique sur de nombreux articles différents, de sorte que le même code-barres est utilisé pour des articles différents.
C'est une mauvaise nouvelle, car cela rend la gestion des stocks impossible. Vous ne voyez pas quels articles sont passés en caisse. Vous ne pouvez mesurer ni la démarque ni les vols. Vous ne pouvez pas inventorier le stock.
Les codes-barres doivent aussi refléter la structure de variantes que vous utilisez dans l'ERP.
Si vous vendez une chemise en quatre couleurs, six tailles et deux matières, l'enregistrement en caisse doit vous permettre de voir dans l'ERP exactement quelle variante a été vendue. Nous reviendrons sur le sujet des variantes dans les sections consacrées au e-commerce et aux données de base.
Vous devez aussi décider du niveau de gestion des stocks en magasin.
Les entreprises souhaitent généralement gérer très finement le stock central, alors que la gestion des stocks dans chaque magasin est souvent moins détaillée.
Peu d'ERP offrent une excellente solution de planification, de réapprovisionnement et de disponibilité tout en disposant d'une solution POS soignée.

Une boutique en ligne est un besoin pour de nombreuses entreprises, qu'elles travaillent en business-to-business (B2B) ou en business-to-consumer (B2C), ou peut-être en business-to-agent (B2A), ou via un autre type de relation.
Il existe de nombreuses façons de faire du e-commerce, mais nous voulons partir de l'ERP et aller jusqu'à la boutique en ligne.
Les ERP sont bons pour gérer les données. C'est pour cela qu'ils sont conçus. Les systèmes e-commerce ne sont pas toujours optimaux pour gérer les données ; souvent, seules les personnes qui travaillent dans le back-office de la boutique en ligne connaissent les données de base et les structures de données et savent les maintenir.
Nous voulons maintenir autant de données que possible dans l'ERP. Il s'agit d'attributs de données structurées, de chaînes de texte destinées à la boutique en ligne, d'images à afficher ou de fichiers à télécharger. Cela représente beaucoup de données.
Maintenir de grands volumes de données articles dans le système e-commerce représente beaucoup de travail. Mettre à jour les données manuellement dans les deux systèmes n'est certainement pas une bonne solution.
Les besoins de données les plus élémentaires sont les données de base de tous les articles, toutes les descriptions d'articles, les prix de vente, etc. Le plus possible de ces données doit être consultable afin que le client puisse rechercher des produits.
Les informations que les clients veulent trouver dans votre boutique en ligne sont du même type que celles que vous voulez avoir sous forme de données structurées dans votre ERP. Il est logique de maintenir les données de base dans l'ERP et de les synchroniser avec la boutique en ligne.
Nous avons différentes variantes des mêmes données de base. Les couleurs en sont un bon exemple. Nous vendons un article destiné aux enfants et le tenons en stock en six couleurs : cyan, turquoise, bleu roi, magenta, cerise et rose.
Ce ne sont pas vraiment les codes couleur utilisés par notre fournisseur, c'est pourquoi notre service achats dispose d'un champ indiquant les couleurs CMJN pour tous les articles.
Sur votre boutique en ligne, les clients ne recherchent pas forcément avec un tel niveau de détail. Ils recherchent du bleu ou du rouge et se voient présenter les différentes variantes.
Dans ce cas, nous nous retrouvons avec trois codes couleur différents sur chaque article. Nous avons besoin de toutes ces informations sur chaque article.
L'ERP doit aussi pouvoir stocker du texte au format HTML qui sera envoyé à la boutique en ligne et affiché correctement.
Nous devons afficher sur les articles des icônes et des pictogrammes indiquant que l'article est bio, sans parabènes, etc. Nous devons pouvoir l'enregistrer dans l'ERP pour que les icônes s'affichent dans la boutique en ligne.
Nous devons aussi pouvoir stocker des images de l'article dans l'ERP pour les afficher dans la boutique en ligne.
Le commercial itinérant qui travaille dans l'ERP peut créer des commandes vente sur sa tablette et profite de retrouver dans l'ERP les mêmes images, informations et options de recherche que les clients dans la boutique en ligne. Et les magasiniers pourront eux aussi voir les descriptions et toutes les images de l'article à préparer.
Nous voulons aussi gérer dans l'ERP les hiérarchies d'articles et de groupes d'articles, c'est-à-dire la structure qui détermine comment les articles sont trouvés dans la boutique en ligne lorsque le client sélectionne une catégorie ou recherche des articles.
L'objectif est de pouvoir créer un nouvel article avec ses données de base dans Business Central, qui le positionne automatiquement dans la hiérarchie, puis que l'article apparaisse automatiquement au bon endroit dans la boutique en ligne, avec images et prix, sans que personne n'ait à copier-coller quoi que ce soit dans la boutique en ligne.
En réalité, la question la plus difficile en matière d'intégration est de savoir comment vous souhaitez exploiter les fonctionnalités de l'ERP pour offrir un bon service client dans la boutique en ligne.
Lorsqu'un client veut savoir si un article est en stock, comment la boutique en ligne accède-t-elle à l'ERP pour le savoir ?
Nous ne voulons pas vraiment d'intégrations. Nous préférons que la boutique en ligne soit pilotée directement depuis Business Central. Et aujourd'hui, c'est possible.


En général, les ERP s'intègrent plutôt mal aux systèmes CRM (Customer Relationship Management), compte tenu de la valeur que cette intégration peut réellement avoir.
Schématiquement, dans le CRM, le travail s'arrête à la commande, et dans l'ERP tout commence par un devis ou une commande. Pourtant, il existe de nombreux recoupements.
Le commercial qui conclut une affaire avec le client veut avoir accès dans le CRM à toutes les informations et règles de gestion de l'ERP afin de conclure les meilleures affaires possibles.
L'ERP contient les données produits, les classifications, les règles de remise, l'historique d'achats, les factures, l'historique de paiements, les encours, les stocks, les réservations, les délais de livraison, les capacités, etc.
Le commercial peut bien sûr aussi créer des devis dans l'ERP, et cela peut être la meilleure solution, surtout si des articles doivent être configurés.
Mais tout le dialogue avec le client, les e-mails et les activités sont normalement gérés dans le CRM, pas dans l'ERP ; selon cet argument, il serait donc préférable d'avoir le devis dans le CRM.
L'intégration entre ERP et CRM est souvent simple et développée à la main. L'intégration entre Business Central et Dynamics 365 Sales s'améliore peu à peu.
Fondamentalement, nous devons pouvoir créer une commande dans le CRM et l'envoyer à l'ERP, et pourtant cela est loin d'être suffisant. Le CRM et l'ERP doivent être deux processus métier intégrés. Transférer des données de l'ERP vers le CRM ne suffit pas non plus à tenir le commercial informé.
Qu'en est-il, par exemple, de la gestion des erreurs ou des modifications ? Que doit-il se passer si une commande est modifiée, dans l'ERP ou dans le CRM ? Une modification dans le CRM doit-elle apparaître dans les achats et la production de l'ERP ? Un changement de date de livraison, par exemple, dans l'ERP sera-t-il aussi visible dans le CRM, et le commercial pourra-t-il voir qu'il devrait parler au client de la nouvelle date ?
Nous pourrions donner de nombreux exemples de ce type, et l'intégration finit par devenir un chantier majeur.
La solution ultime est que le commercial utilise des composants de l'ERP mis à disposition du CRM et si bien intégrés qu'il ne remarque pas que certaines fonctionnalités proviennent en réalité d'un autre système.
La synchronisation bidirectionnelle ordinaire des données de base, comme les coordonnées, peut donc être traitée par une intégration ordinaire, et la logique métier peut être traitée en intégrant des fonctionnalités de l'autre système.
Lorsque nous parlons de vente et de marketing, nous ne devons pas oublier que le service marketing a des besoins informatiques croissants.
D'après notre expérience, la plupart des CRM actuels ne sont pas conçus pour les équipes marketing qui travaillent aux premières étapes du parcours client. Le directeur commercial ignore généralement les besoins informatiques du marketing, tandis que la plupart des professionnels du marketing modernes ne voient dans le CRM qu'une base de contacts.
Il n'est pas rare que le service marketing souscrive à 10 ou 20 systèmes cloud différents dont le service informatique n'a jamais entendu parler. Et certains s'intègrent même au CRM ou à l'ERP à l'insu des responsables CRM et ERP.
En général, nous travaillons à différentes étapes du parcours client :
Le marketing a besoin de processus automatisés qui reproduisent le traitement manuel.
Le marketing achète donc des outils de processus tels que l'automatisation marketing pour surveiller de grandes quantités de données, profiler les clients et exécuter des processus automatisés sur cette base.
Le CRM doit bien sûr être intégré aux outils du service marketing. Parfois, cela peut se faire très simplement. Par exemple, Power Automate peut récupérer des données issues de systèmes de messagerie ou de campagnes marketing et créer directement des leads ou des contacts dans Dynamics 365 Sales.
Les outils du service marketing peuvent être très utiles aux commerciaux. Ils peuvent collecter beaucoup d'informations sur le comportement des clients qui intéresseront les commerciaux.