ERP-Integrationen für Magento: Eigenentwicklung oder Kauf nach 12 Implementierungen

Seit 2019 haben wir über 500 E-Commerce-Shops ausgeliefert und Magento mit zwölf verschiedenen ERP-Systemen integriert, darunter NetSuite, SAP Business One, Microsoft Dynamics 365 Business Central, Sage 200, Odoo, ein paar maßgeschneiderte Inhouse-ERPs und eine Handvoll veralteter Systeme mit Namen, die Sie nicht erkennen würden. Wir wurden bezahlt, um bei jedem einzelnen zu entscheiden, ob wir bauen oder kaufen. Nach allen zwölf ist unsere Antwort konsistent: Individuelle Lösungen gewinnen für die meisten Shops, mit drei spezifischen Ausnahmen, in denen Standard-Connectoren die richtige Wahl sind.

Dieser Beitrag behandelt, wann Eigenentwicklung gewinnt, wann Kauf gewinnt und wie man die Entscheidung absteckt, bevor man sich für eine der beiden Optionen entscheidet.

Warum Standard-Connectoren meist enttäuschen

Es gibt Dutzende von vorgefertigten Magento-zu-ERP-Connectoren auf dem Markt. Die Verkaufsargumente sind konsistent: schnellere Markteinführung, keine Ingenieureinvestitionen, der Anbieter kümmert sich für immer um die Kompatibilität. Die Realität bei echten Engagements ist ebenfalls konsistent: Der Connector deckt 70 Prozent Ihrer Anforderungen ab und die verbleibenden 30 Prozent kosten mehr in Form von Workarounds und individuellen Erweiterungen, als es der Aufbau von Grund auf gekostet hätte.

Die 30 Prozent Lücke zeigt sich normalerweise in:

• Individuelle Felder, die der Connector nicht zuordnet. Jeder Shop hat Produktattribute, Kundenattribute oder Bestellmetadaten, die dem Connector unbekannt sind. Diese zuzuordnen erfordert eine Erweiterung des Connectors, was bedeutet, dass man in das Plugin-System des Connectors eingreifen muss, was bedeutet, dass der Support des Connector-Anbieters Ihnen mitteilt, dass Anpassungen nicht abgedeckt sind.
• Bidirektionale Synchronisationskonflikte. Die meisten Connectoren handhaben eine Richtung gut (ERP zu Magento) und die andere Richtung schlecht (Magento zurück zu ERP). Bestandsaktualisierungen aus dem Lager, Bestellstatusaktualisierungen aus der Erfüllung, Änderungen an Kundenprofilen, die in Magento initiiert werden, werden alle zu Randfällen.
• Fehlerbehebung und Wiederholungssemantik. Fehlgeschlagene Synchronisationen, vorübergehende Netzwerkfehler, partielle Batch-Fehler. Das Standardverhalten ist normalerweise „wiederholen und dann aufgeben“ ohne Prüfprotokoll. Bei ERP-Integrationen, bei denen eine versäumte Synchronisation einen Überverkaufsvorfall bedeutet, ist das inakzeptabel.

Individuelle Integrationscodes, die für Ihr spezifisches Datenmodell und Ihre spezifischen Fehlermodi geschrieben wurden, vermeiden diese Probleme, indem sie gezielt entwickelt werden. Der Nachteil ist, dass Sie es für immer tragen müssen.

Die vier Probleme, die individuelle Lösungen lösen

Wenn wir empfehlen, zu bauen statt zu kaufen, sind die vier Probleme, die die Empfehlung antreiben:

1. Individuelle Feldzuordnungen, die mehr als fünf Felder betreffen. Fünf oder weniger, ein Connector mit einer UI-Zuordnungsoberfläche kann das handhaben. Mehr als fünf, konfigurieren Sie mehr in der Connector-UI, als Sie in individuellem Code schreiben würden, und die UI-Konfiguration ist schwieriger versionierbar.

2. Bidirektionale Synchronisation mit Konfliktlösung. Individueller Code ermöglicht es Ihnen, die Regeln zur Konfliktlösung explizit festzulegen. Standard-Connectoren wählen normalerweise „der letzte Schreiber gewinnt“, was für die meisten echten Konflikte falsch ist.

3. Hohe Volumen. Bei über 50.000 SKUs, die täglich synchronisiert werden, oder 1.000 Bestellungen pro Stunde, stoßen die meisten Connectoren an ihre architektonischen Grenzen. Individueller Code kann angemessen für die Last gebündelt, in Warteschlangen gestellt und parallelisiert werden.

4. Echtzeit-Bestandsanforderungen. Die meisten Connectoren arbeiten im Batch-Modus (5 bis 30 Minuten Synchronisationsintervalle). Wenn Ihr Shop eine Bestandsgenauigkeit von weniger als einer Minute benötigt, um Überverkäufe zu vermeiden, ist eine individuelle WebSocket- oder Webhook-Architektur der einzige Weg.

Die drei Fälle, in denen Kauf gewinnt

Zur Balance die Fälle, in denen wir einem Kunden empfohlen haben, zu kaufen statt zu bauen:

1. NetSuite-Integration mit einer SuiteApp. Der eigene SuiteApp-Marktplatz von NetSuite hat Magento-Connectoren, die von Partnern entwickelt wurden, die NetSuite besser kennen als wir. Drei unserer zwölf Engagements nutzten eine SuiteApp, weil der Kunde bereits stark auf SuiteApps bei seinen anderen Integrationen setzte. Die Gesamtkosten waren trotz der wiederkehrenden SuiteApp-Gebühren niedriger.

2. Odoo-Integration, bei der der Kunde die Standardversion von Odoo verwendete. Der offizielle Odoo-Magento-Connector verarbeitet Standard-Odoo-Implementierungen sauber. Wo Kunden ihr Odoo stark angepasst hatten, haben wir individuell entwickelt; wo Odoo Standard war, war der Connector in Ordnung.

3. Greenfield-Shop mit einem einfachen ERP und engem Zeitrahmen. Wenn Sie einen neuen Magento-Shop, einen kleinen SKU-Katalog und einen vierwöchigen Zeitrahmen für den Start haben, kauft Ihnen ein Connector Zeit, selbst wenn Sie ihn später durch eine individuelle Lösung ersetzen. Dieses Muster haben wir zweimal umgesetzt; beide Kunden wechselten im zweiten Jahr später zu individuellem Code.

Echte Zeit- und Kostenaufstellung

Für einen mittelständischen Magento-Shop, der mit einem komplexen ERP integriert:

• Kauf (Connector-Ansatz). 2 bis 4 Wochen bis zur Markteinführung. Connector-Kosten £2k bis £15k im Voraus plus £200 bis £2k monatliches Abonnement. Anpassungsarbeiten zur Deckung der 30 Prozent Lücke typischerweise £8k bis £25k. Gesamtkosten im ersten Jahr: £15k bis £60k. Die Wartung wird zwischen Ihnen und dem Connector-Anbieter geteilt.

• Bau (individueller Ansatz). 6 bis 12 Wochen bis zur Markteinführung. Vorab-Ingenieurekosten £15k bis £50k, abhängig von der Komplexität. Die Wartungsbelastung liegt vollständig bei Ihnen, typischerweise 1 bis 2 Tage pro Quartal für Kompatibilitätsprüfungen. Gesamtkosten im ersten Jahr: £18k bis £65k.

Die Kostenbereiche überschneiden sich. Die Bauoption beginnt höher und bleibt stabiler. Die Kaufoption beginnt niedriger und wächst, wenn Sie Anpassungen hinzufügen oder die Connectoren wechseln.

Was wir abraten

Zwei Muster, die bei Kunden Schmerzen verursacht haben und die wir nicht wiederholen würden:

• Einen Connector während des Engagements durch einen anderen ersetzen. Kunden, die die Grenzen von Connector A erreicht haben und während des Projekts zu Connector B gewechselt sind, haben immer das Budget überschritten. Wenn ein Connector in Woche 4 nicht funktioniert, ist der nächste Schritt individuell, nicht ein weiterer Connector.

• „Plattformunabhängige“ individuelle Integrationen bauen. Kunden, die darauf bestanden, die Integration so zu schreiben, dass sie über hypothetische zukünftige ERPs wiederverwendbar ist, haben immer über-engineert. Bauen Sie für das eine ERP, das Sie haben. Wenn Sie später das ERP wechseln, schreiben Sie neu.

Entscheidungsrahmen

Der kürzeste Entscheidungsrahmen, den wir gefunden haben: Zählen Sie die Felder, die Sie zuordnen müssen. Wenn es weniger als fünf individuelle Felder sind, befinden Sie sich im Bereich der Connectoren. Wenn es über zehn ist, sollten Sie individuell entwickeln. Fünf bis zehn ist die Grauzone, in der es von der API-Qualität des ERPs und der PHP-Kapazität Ihres Teams abhängt.

Verwandt

• Leitfaden zu den Kosten der Magento-Entwicklung behandelt, was individuelle Integrationsarbeiten tatsächlich kosten.
• eTechFlow-Dienstleistungsseite behandelt die Integrationsengagements, die wir umgesetzt haben.