Intégrations ERP pour Magento : construire ou acheter après 12 mises en œuvre
Depuis les plus de 500 magasins de commerce électronique que nous avons lancés depuis 2019, nous avons intégré Magento avec douze systèmes ERP différents, y compris NetSuite, SAP Business One, Microsoft Dynamics 365 Business Central, Sage 200, Odoo, quelques ERP internes personnalisés, et une poignée de systèmes hérités dont vous ne reconnaîtriez pas les noms. Nous avons été payés pour choisir entre construire ou acheter pour chacun d'eux. Après les douze, notre réponse est cohérente : le personnalisé l'emporte pour la plupart des magasins, avec trois exceptions spécifiques où les connecteurs prêts à l'emploi sont le bon choix.
Cet article couvre quand construire gagne, quand acheter gagne, et comment définir la décision avant de vous engager dans l'un ou l'autre.
Pourquoi les connecteurs prêts à l'emploi déçoivent généralement
Il existe des dizaines de connecteurs préconstruits Magento-ERP sur le marché. L'argument est cohérent : un temps de mise en œuvre plus rapide, pas d'investissement en ingénierie, le fournisseur gère la compatibilité pour toujours. La réalité lors des engagements réels est également cohérente : le connecteur couvre 70 % de vos exigences et les 30 % restants coûtent plus en solutions de contournement et extensions personnalisées que de construire à partir de zéro.
Le manque de 30 % se manifeste généralement par :
- Champs personnalisés que le connecteur ne mappe pas. Chaque magasin a des attributs de produit, des attributs de client ou des métadonnées de commande que le connecteur ne connaît pas. Les mapper nécessite d'étendre le connecteur, ce qui signifie s'accrocher au système de plugins du connecteur, ce qui signifie que le support du fournisseur de connecteur vous dit que les personnalisations ne sont pas couvertes.
- Conflits de synchronisation bidirectionnelle. La plupart des connecteurs gèrent bien une direction (ERP vers Magento) et l'autre direction mal (Magento vers ERP). Les mises à jour de stock depuis l'entrepôt, les mises à jour de statut de commande depuis l'exécution, les changements de profil client initiés dans Magento, deviennent tous des cas particuliers.
- Récupération d'erreur et sémantique de réessai. Synchronisations échouées, erreurs réseau transitoires, échecs de lots partiels. Le comportement par défaut est généralement de réessayer puis d'abandonner sans trace d'audit. Pour les intégrations ERP où une synchronisation manquée signifie un incident de survente, c'est inacceptable.
Le code d'intégration personnalisé, écrit pour votre modèle de données spécifique et vos modes de défaillance spécifiques, évite ces problèmes en étant conçu sur mesure. L'inconvénient est que vous devez le maintenir indéfiniment.
Les quatre problèmes que le personnalisé résout
Lorsque nous recommandons de construire plutôt que d'acheter, les quatre problèmes qui motivent la recommandation sont :
Mapping de champs personnalisés touchant plus de cinq champs. Cinq ou moins, un connecteur avec un écran de mapping UI s'en occupe. Plus de cinq, vous configurez plus dans l'UI du connecteur que vous n'écririez de code personnalisé, et la configuration de l'UI est plus difficile à contrôler en version.
Synchronisation bidirectionnelle avec résolution de conflit. Le code personnalisé vous permet de définir explicitement les règles de résolution de conflit. Les connecteurs prêts à l'emploi choisissent généralement "le dernier écrivain gagne", ce qui est faux pour la plupart des conflits réels.
Volume élevé. Au-delà de 50 000 SKU synchronisés quotidiennement ou 1 000 commandes par heure, la plupart des connecteurs atteignent leurs limites architecturales. Le code personnalisé peut être traité par lots, mis en file d'attente et parallélisé de manière appropriée pour la charge.
Exigences d'inventaire en temps réel. La plupart des connecteurs fonctionnent en mode par lots (intervalles de synchronisation de 5 à 30 minutes). Si votre magasin a besoin d'une précision de stock sous la minute pour éviter la survente, une architecture WebSocket ou webhook personnalisée est le seul chemin.
Les trois cas où acheter gagne
Pour l'équilibre, les cas où nous avons recommandé à un client d'acheter plutôt que de construire :
Intégration NetSuite avec une SuiteApp. Le propre marché SuiteApp de NetSuite a des connecteurs Magento construits par des partenaires qui connaissent NetSuite mieux que nous. Trois de nos douze engagements ont utilisé une SuiteApp parce que le client était déjà très dépendant de SuiteApp pour le reste de ses intégrations. Le coût total de possession s'est avéré inférieur malgré les frais récurrents de SuiteApp.
Intégration Odoo où le client utilisait Odoo standard. Le connecteur officiel Odoo-Magento gère proprement les déploiements Odoo standard. Là où les clients avaient fortement personnalisé leur Odoo, nous avons construit du personnalisé ; là où Odoo était standard, le connecteur était adéquat.
Magasin Greenfield avec un ERP simple et un calendrier serré. Si vous avez un nouveau magasin Magento, un petit catalogue SKU, et un calendrier de lancement de quatre semaines, un connecteur vous fait gagner du temps même si vous le remplacez plus tard par du personnalisé. Nous avons réalisé ce schéma deux fois ; les deux clients sont ensuite passés au code personnalisé au cours de la deuxième année.
Répartition réelle du calendrier et des coûts
Pour un magasin Magento de taille intermédiaire intégrant un ERP complexe :
Acheter (approche connecteur). 2 à 4 semaines pour être opérationnel. Coût du connecteur de 2 000 £ à 15 000 £ à l'avance plus un abonnement de 200 £ à 2 000 £ par mois. Le travail de personnalisation pour couvrir le manque de 30 % coûte généralement de 8 000 £ à 25 000 £. Coût total de la première année : de 15 000 £ à 60 000 £. La maintenance est partagée entre vous et le fournisseur de connecteur.
Construire (approche personnalisée). 6 à 12 semaines pour être opérationnel. Coût d'ingénierie initial de 15 000 £ à 50 000 £ selon la complexité. Le fardeau de la maintenance est entièrement à votre charge, généralement 1 à 2 jours par trimestre pour des vérifications de compatibilité. Coût total de la première année : de 18 000 £ à 65 000 £.
Les fourchettes de coûts se chevauchent. L'option de construction commence plus haut et reste plus stable. L'option d'achat commence plus bas et augmente à mesure que vous ajoutez des personnalisations ou changez de connecteurs.
Ce que nous déconseillons
Deux schémas qui ont causé de la douleur aux clients que nous ne répéterions pas :
Remplacer un connecteur par un autre en cours d'engagement. Les clients qui ont atteint les limites du connecteur A et sont passés au connecteur B en cours de projet ont toujours dépassé le budget. Si un connecteur ne fonctionne pas à la semaine 4, le prochain mouvement est de passer au personnalisé, pas à un autre connecteur.
Construire des intégrations personnalisées "indépendantes de la plateforme". Les clients qui ont insisté pour écrire l'intégration afin qu'elle soit réutilisable à travers des ERP futurs hypothétiques ont toujours trop sur-ingénierie. Construisez pour l'ERP que vous avez. Si vous changez d'ERP plus tard, réécrivez.
Cadre de décision
Le cadre de décision le plus court que nous avons trouvé : comptez les champs que vous devez mapper. Si cela concerne moins de cinq champs personnalisés, vous êtes dans le territoire des connecteurs. Si cela dépasse dix, vous devriez construire du personnalisé. Cinq à dix est la zone grise où cela dépend de la qualité de l'API de l'ERP et de la capacité de votre équipe en PHP.
Liens connexes
- Guide des coûts de développement Magento couvre ce que coûte réellement le travail d'intégration personnalisé.
- Page des services eTechFlow couvre les engagements d'intégration que nous avons réalisés.