Factures

Factures

Le traitement des commandes clients dans Microsoft Dynamics CRM

Le processus de traitement des commandes clients dans Microsoft Dynamics CRM est notamment composé des étapes suivantes :

  • opportunité : vente prévisionnelle,
  • devis : offre envoyée à un prospect,
  • commande : devis signé.

Le processus de vente peut éventuellement comporter une étape de facturation. Cependant, cette dernière est plutôt réalisée dans un logiciel de gestion commerciale.

En effet, Microsoft Dynamics CRM n’est pas considéré comme un outil de gestion financière à part entière. De manière générale, il est couplé avec un progiciel permettant de gérer le domaine financier. Dans ce cas, une interface doit être mise en place entre le logiciel Microsoft Dynamics CRM et le logiciel de gestion commerciale qui héberge les factures.

Etape 1 – opportunité : vente prévisionnelle

La première étape du processus de commande client est matérialisée la plupart du temps par la création d’une opportunité dans l’outil Microsoft Dynamics CRM.

Une opportunité possède tout d’abord le statut « ouvert ». Elle est alors modifiable.

Lorsqu’elle est fermée, l’opportunité possède le statut « conclu » ou « perdu », en fonction du résultat de la vente. Dans ce cas, elle n’est plus modifiable.

Cependant, l’opportunité est susceptible d’être rouverte. Elle est alors de nouveau modifiable.

Etape 2 – devis : offre envoyée à un prospect

La deuxième étape du processus de commande client correspond généralement au devis. Le devis reprend l’opportunité créée précédemment en incluant obligatoirement des informations relatives aux produits et aux prix associés.

En effet, un devis est un document informant un prospect des conditions tarifaires relatives à une opportunité de vente.

Pour ce faire, les tarifs doivent être gérés soit :

  • dans Microsoft Dynamics CRM,
  • dans un outil externe, duquel les informations tarifaires sont extraites vers Microsoft Dynamics CRM.

Etape 3 – commande : devis signé

Suite à l’acceptation du devis par le client, la commande associée peut être créée par le commercial. Elle peut être générée automatiquement à partir du devis accepté. Dans ce cas, la commande reprend toutes les données du devis d’origine. La commande est alors rattachée à l’opportunité et au prospect d’origine.

Les commandes doivent comporter les informations suivantes :

  • données d’expédition,
  • coordonnées de facturation,
  • articles,
  • tarifs.

Réussir une reprise de données

La reprise de données

La reprise de données constitue une des étapes les plus délicates au sein d’un projet d’implémentation d’un logiciel de gestion. En effet, elle doit souvent être réalisée très rapidement juste avant le démarrage d’un projet. De plus, elle est susceptible de reporter ce démarrage, en cas de problèmes bloquants, ce qui entraîne des coûts supplémentaires.

Or, il arrive très souvent que cette phase pose des problèmes, soit :

  • bloquants, du fait de données impossibles à reprendre,
  • consommateurs de charges supplémentaires non prévues (chez le prestataire en charge de la reprise et chez l’entreprise elle-même), en raison de la complexité de la reprise de données, qui a été identifiée trop tard par les acteurs en charge de cette dernière.

Ces problèmes sont principalement dus à l’analyse, qui n’est pas toujours réalisée de façon exhaustive. En effet, il est nécessaire lors de cette phase de mettre en parallèle tous les champs de données du logiciel source avec les mêmes champs au sein du logiciel de destination. Bien entendu, cela nécessite au préalable d’avoir identifié ces champs au sein du nouveau logiciel, soit via l’utilisation de champs existants, soit via la création de nouveaux champs. Or, pour cela, la compréhension du mode de fonctionnement du logiciel source est indispensable.

Jeux de tests

A partir du moment où cette analyse a été réalisée, il s’agit de réaliser en premier lieu un test avec un volume de données peu important (par exemple, 10 % des données à reprendre).

Cela permet d’identifier les principales anomalies, et de les corriger rapidement. Ce test doit avoir lieu au moins 1 à 2 mois avant la reprise complète des données. La date du test est déterminée en fonction du volume des données, ainsi que du délai prévisionnel de correction des anomalies rencontrées.

Ensuite, en fonction de l’importance de ces dernières, un second test peut être programmé.

Ces tests permettent notamment :

  • de s’assurer que la reprise des données se déroulera dans les meilleures conditions,
  • de prévoir précisément la durée de la reprise des données.

Dans le cas où des statistiques sont générées dans le logiciel source, il s’agit de procéder aux éditions correspondantes, puis de contrôler dans le logiciel de destination que les données restituées au sein des nouveaux états sont identiques.

Retour en haut