Une annonce de partenariat intéresse rarement le lecteur auquel elle est adressée. Elle dit que deux entreprises travaillent ensemble, que c'est une bonne nouvelle, et que le client y gagnera en agilité.
La seule question qu'un dirigeant se pose devant une telle annonce est plus prosaïque : si je lance ce projet, qui porte quoi, et qu'est-ce qui reste à ma charge ? Ce texte y répond.
Ce que le partenariat a produit, concrètement
BizBloqs travaille avec Dynamics Development Solutions, qui intervient dans l'écosystème Microsoft. Deux de leurs consultants sont venus au siège de BizBloqs, à Bois-le-Duc, avec Willem ten Asbroek, fondateur et dirigeant, et Martin de Sain, responsable du développement commercial. Son arrivée au poste de Business Development Manager a été annoncée séparément.
L'occasion était le démarrage d'une mise en service combinée : un ERP et une exécution d'entrepôt mis en production ensemble, chez un client que la page d'origine ne nomme pas — et que je ne nommerai donc pas davantage.
C'est tout ce qu'il y a de factuel, et c'est assez. Un démarrage combiné ERP et entrepôt est un projet qui échoue souvent ; qu'il soit allé au bout est l'information.
Faites défiler latéralement pour voir toute la figure.
Les trois rôles, et ce que chacun porte
Un projet qui touche à la fois la gestion commerciale et le magasin met trois acteurs autour de la table. La confusion de leurs rôles est la première cause de dérapage, parce que chacun attend de l'autre une décision que l'autre ne peut pas prendre.
L'éditeur de l'ERP
Il fournit la gestion commerciale et financière : le référentiel article, la commande d'achat, la commande client, la facture, la comptabilité. Dans l'écosystème Microsoft, c'est le domaine de Business Central et des solutions voisines.
Ce qui lui appartient et ne doit pas être déplacé : le code article. Un magasin n'invente jamais un code, même quand une palette arrive avec une référence inconnue — surtout dans ce cas-là.
Le partenaire d'intégration
C'est le rôle le moins compris et celui qui décide de la durée du projet.
Il connaît votre installation. Pas l'ERP en général : le vôtre, avec ses champs détournés de leur usage d'origine, ses développements faits il y a six ans par quelqu'un qui est parti, et les raisons historiques d'un paramétrage que personne n'ose toucher. Un référentiel article accumulé sur dix ans contient toujours un champ « poids » qui porte en réalité un code fournisseur, parce qu'un jour il n'y avait pas d'autre place.
Cette connaissance est la différence entre un projet qui se compte en semaines et un projet qui s'enlise. Le cadre de travail avec un partenaire est décrit sur intégrateur logiciel, et le programme sur programme partenaires.
L'éditeur de l'exécution d'entrepôt
Il fournit le magasin : le geste dirigé à l'emplacement, confirmé au scan, la position de stock tenue au mouvement, l'affectation du stock entre les canaux, ce qui est réellement parti. C'est le périmètre décrit sur logiciel WMS.
Ce qui lui appartient : la quantité physique et l'emplacement. Sur une quantité réellement présente, c'est le magasin qui gagne, parce que c'est le seul système dont la donnée vient d'un geste confirmé et non d'un calcul.
Et ce qui ne lui appartient pas, puisqu'il faut le dire : BizBloqs n'est pas un ERP. Il ne tient pas votre comptabilité, ne facture pas, et ne remplace pas votre gestion commerciale. Les deux systèmes tournent ensemble, chacun dans son rôle.
Ce que le client décide, et que personne ne décide à sa place
Voici le passage que les annonces de partenariat ne contiennent jamais, et c'est celui qui détermine si le projet se passe bien.
Trois décisions appartiennent au client, se prennent avant le démarrage, et ne se délèguent ni à l'éditeur ni au partenaire.
Qui détient quelle donnée. Une donnée a un propriétaire et un seul. Le plus souvent : l'ERP possède le code article et la commande, le magasin possède l'emplacement et la quantité physique, la boutique possède le prix. Quand deux systèmes se croient propriétaires de la même donnée, vous n'avez pas une intégration mais un conflit, arbitré chaque nuit par celui qui écrit en dernier.
Qui gagne en cas de divergence. Il y aura des divergences. La question n'est pas de les éviter mais de savoir par écrit, à l'avance, ce qui se passe quand elles arrivent : une correction saisie dans l'ERP alors que le magasin a compté autre chose, une commande annulée côté boutique alors qu'elle est déjà prélevée, une fiche article modifiée pendant une préparation en cours.
Ce qui se passe quand le lien tombe. Il tombera. L'entrepôt doit pouvoir continuer sur ce qui est déjà descendu, les messages doivent s'accumuler et se rejouer dans l'ordre, et un message reçu deux fois ne doit compter qu'une fois. Les mécanismes sont décrits sur connecteur ERP.
Ces trois réponses tiennent en une demi-page. Elles valent plus que trois semaines de développement, et c'est le partenaire d'intégration qui est le mieux placé pour aider à les écrire — pas pour les écrire à votre place.
Pourquoi un démarrage combiné est difficile, et ce qui le rend possible
Mettre en production un ERP et une exécution d'entrepôt en même temps est le scénario que l'on déconseille généralement, et pour une raison solide : quand deux systèmes changent la même semaine, plus personne ne peut dire d'où vient un incident.
Ce qui le rend faisable quand on y va quand même :
Un seul responsable de la séquence. Pas deux chefs de projet qui se coordonnent : un, qui décide de l'ordre des bascules.
Les trois décisions ci-dessus réglées avant, pas pendant. Un développement qui attend une réponse de réunion, et une réunion qui attend un développement pour trancher, c'est trois semaines perdues.
Un périmètre réduit au premier jour. Les six messages essentiels entre gestion commerciale et magasin — l'article, la réception attendue, la réception réalisée, la commande à préparer, l'expédition réalisée, la correction de stock — et rien d'autre. Le reste s'ajoute après.
Une date qui n'est pas en pointe. Un démarrage en octobre avant un quatrième trimestre chargé est le scénario qui échoue le plus souvent, pour une raison simple : la formation et le volume arrivent la même semaine.
Le déroulé par étapes est sur projet WMS.
Ce que ce partenariat change, et ce qu'il ne change pas
Ce qu'il change. Un client dans l'écosystème Microsoft a en face de lui quelqu'un qui connaît les deux côtés du lien plutôt que deux fournisseurs qui se renvoient les questions d'interface. C'est le bénéfice réel d'un partenariat et il n'a pas besoin d'être exagéré pour être réel.
Ce qu'il ne change pas. Le travail de reprise de données. L'état de votre référentiel article. Les trois décisions qui vous appartiennent. Et le fait qu'un projet d'exploitation se juge six mois après le démarrage, pas le jour de la mise en production.
Pour voir ce que des mises en service ressemblantes ont donné, les cas publiés sont sur études de cas. Aucun chiffre de gain n'est avancé ici, parce que la page d'origine n'en donne aucun et que je n'en inventerai pas pour étoffer une annonce.
Pour aller plus loin
BizBloqs fournit l'exécution d'entrepôt et laisse la gestion commerciale et financière à l'ERP, en le disant. Pour regarder ce qu'un projet combiné donnerait sur votre installation, réserver une démo. Si vous n'êtes pas dans l'écosystème Microsoft, la répartition des trois rôles décrite ici reste valable — seuls les noms changent.
