Nous avons vu récemment que la complexité des ERP, combiné à un lourd passé, en faisaient des monstres ruineux et techniquement assez cryptiques.

En tant que développeur il y a bien pire que les termes barbares du système à assimiler : il faut comprendre ce que l’utilisateur veut faire avec le système. (Comme de plus c’est lui qui paye, c’est lui qui commande).

Pour le naïf technicien qui débarque en plein dans un flux logistique, le monde un peu flou de la vente et des livraisons prend soudain sa pleine dimension. Au début il s’imagine qu’une commande ne doit pas être si tordue à concevoir dans un modèle de données bien propre :

  • on commence par un en-tête avec quelques informations : le client, son adresse, le numéro de la facture ;
  • on enchaîne avec les lignes de commandes : un objet ou un service, une quantité, un prix unitaire ;
  • on termine en sommant les lignes, on rajoute la TVA ;
  • il reste éventuellement à livrer à l’adresse du client…

Commençons par les adresses. Si on veut tout prévoir, il faut distinguer d’abord l’adresse de livraison de l’adresse de facturation. N’importe quel site de commerce en ligne est à présent capable de gérer la différence : vous pouvez ainsi envoyer un cadeau de Noël à votre chère grand-mère tout en recevant vous-même la facture papier.

Mais cela peut être encore plus compliqué ; par exemple :

  • l’usine TARTEMPION, en France ;
  • peut recevoir une commande de TOTO GmbH (« donneur d’ordres » européen) ;
  • au nom de la PME brésilienne PEDRO (« destinataire final  » des biens physiques) ;
  • à facturer à TOTO Bizness International (entité comptable du groupe TOTO, « destinataire de la facture ») ;
  • et qui sera effectivement payée par TOTO Bank Ltd (« payeur ») ;
  • à VITENCAISSE, société d’affacturage de TARTEMPION, qui lui sous-traite la facturation (relances, frais, avance, garantie de paiement…) ;
  • la livraison ne sera pas à envoyer directement au Brésil, mais à un intermédiaire logistique (« client délivré »), disons FedDHL à Amsterdam.

Les ordinateurs de TARTEMPION, se doivent donc, pour une unique commande, créer chacune de ces entités, et ne pas perdre les liens entre elles. Il est mal vu et parfois coûteux d’envoyer une facture papier au lieu d’une palette, ou de réclamer le paiement à celui qui sert juste de livreur.

Renseigner tout cela à la main devient vite pénible, d’autant plus que les ERP sont rarement des monstres d’ergonomie 1. Mais on atteint le cauchemar lorsque la création d’adresses ou clients doit être automatisée et que les données adéquates doivent se remplir spontanément sur les écrans informatiques de l’administration des ventes. Au passage on se demande qui là-dedans est vraiment le sacro-saint « client » 2.

Avec le jargon adéquat, mélangé à l’anglais imposé par certaines multinationales à leurs filiales, on aboutira au final à la conclusion que TOTO Bank Ltd est le PayTo From de PEDRO, et TOTO Bizness International le BillTo Of de TOTO GmbH 3. Le CRM a des joies cachées pour les amateurs de puzzle, de casse-têtes et de barbarismes linguistiques.

Ce n’est que le début. Inutile de dire que PEDRO, TOTO Bank ou VITENCAISSE ont chacun une demi-douzaine d’adresses physiques (prévoir la notion d’« adresse primaire »), chacune dédiée à un rôle différent, ou pas (rajoutons une table des « usages d’adresse »). Certaines de ces adresses peuvent être celles d’une autre entité d’ailleurs (stock déporté par exemple).

À suivre…

  1. Ils en violent même la plupart des règles. ↩︎

  2. Et se poser cette question, c’est se poser celle de l’entité à qui il faut plaire en priorité : l’utilisateur final ou l’un de ces intermédiaires qui ne l’ont peut-être jamais vu ? ↩︎

  3. Exemple immonde inspiré d’Oracle Applications. ↩︎