BaseLinker ist oft das erste ernsthafte System, das in einem wachsenden Shop zum Einsatz kommt. Und lange Zeit leistet es genau das, was man von ihm erwartet. Das Problem kommt später, meist ohne Vorwarnung: Das Unternehmen verkauft weiterhin, aber jede Änderung im Prozess erfordert eine weitere Regel, eine weitere Ausnahme und eine weitere Person, die sich erinnert, warum das überhaupt so eingerichtet wurde. In den Projekten, die wir auf Dienstleisterseite betreuen, hat dieser Moment sehr konkrete technische Symptome. Besser, Sie erkennen sie früh und nicht erst im November.
Inhaltsverzeichnis
Was BaseLinker gut macht und wo seine Rolle endet
Als operative Schicht ist das Panel wirklich gut: Es zieht Bestellungen von Marktplätzen, spricht mit Versanddienstleistern, stellt Rechnungen aus und behält die Bestände im Blick. Den meisten Shops reicht das über Jahre, und es gibt keinen Grund, etwas Eigenes zu bauen.
Die Grenze liegt woanders, als üblicherweise angenommen wird. Es geht nicht um die Größe des Unternehmens. Es geht um den Moment, in dem die Geschäftslogik aufhört, Konfiguration zu sein, und zu Code wird. Eine Preisregel, die von der Marge des Geschäftspartners abhängt, die Prüfung einer B2B-Bestellung gegen ein Kreditlimit, das Zusammenstellen von Sets aus Komponenten: Das lässt sich mit Aktionen im Panel schlicht nicht sinnvoll abbilden.
Dann ändert sich auch die Sicht auf das Werkzeug. Die BaseLinker-Integration ist nicht mehr die gesamte Lösung, sondern ein Element der Architektur. Ein wichtiges, aber nicht dasjenige, das die Entscheidungen trifft. Eine Standard-WooCommerce-Integration mit BaseLinker bedient den Fluss von Bestellungen und Beständen, verantwortet aber keine unternehmensspezifischen Regeln.
Warnsignale: wenn das Panel dem Unternehmen nicht mehr folgt
Die Symptome wiederholen sich und sind von außen schneller zu erkennen als von innen. Wenn Sie mehr als zwei davon wiedererkennen, ist das meist keine Frage der Teamdisziplin, sondern die Decke des Werkzeugs:
- die automatischen Aktionen sind zu einem Zustand angewachsen, den niemand nachvollziehen oder einer neuen Person erklären kann,
- nach jeder Synchronisation bessert jemand von Hand nach, damit die Daten stimmen,
- ERP und Panel zeigen unterschiedliche Lagerbestände, und geklärt wird das telefonisch,
- ein zentraler Teil des Prozesses lebt in einer Tabelle neben dem System, nicht im System,
- bei einer Reklamation lässt sich nicht feststellen, wer den Bestellstatus wann geändert hat,
- API-Limits blockieren die Arbeit genau dann, wenn der Umsatz am höchsten ist.
Es gibt nur eine diagnostische Frage: Verschwindet das Problem, sobald Sie eine weitere Regel ergänzen, oder kommt es zwei Wochen später an anderer Stelle zurück? Der zweite Fall bedeutet, dass Sie eine Folge flicken. Die Ursache steckt in der Architektur.
API-Limits und Volumen: die harte Wand, die erst in der Spitze sichtbar wird
Die meisten Integrationen fragen die API in einer Schleife ab, weil sie so am schnellsten laufen. Die Kosten dieses Vorgehens wachsen linear mit der Zahl der Bestellungen im System, nicht mit der Zahl der tatsächlichen Änderungen. In einem ruhigen Monat sieht das ganz harmlos aus.
Saisonalität ist in dieser Branche der ehrlichste Architekturtest. Ein Ablauf, der im März flott läuft, kann im November verstopfen, weil die Warteschlange schneller wächst, als die Integration sie abarbeitet. Und dann zeigt sich das Fehlen von drei Dingen: Queuing, exponentielles Backoff bei Fehlern und Idempotenz. Ohne sie erzeugt eine wiederholte Operation eine zweite Bestellung oder eine zweite Sendung, und der Kunde bekommt zwei Pakete für eine Bestellung. Am schnellsten fällt das dort auf, wo eine Shop-Anbindung an Allegro hinzukommt und sich das Marktplatzvolumen auf den eigenen Traffic legt.
Ein eigenes Thema ist das Reporting. Ein operatives Panel ist kein Data Warehouse und hält die Historie nicht unbegrenzt vor. Sie brauchen Auswertungen im Jahresvergleich? Dann müssen die Daten woanders landen.
Wann Sie eine eigene Zwischenschicht brauchen
Middleware ist der Ort, an dem Mappings, Preisregeln, Validierungen und der ganze Rest der unternehmensspezifischen Dinge Platz finden. Code lässt sich testen, versionieren und zurückrollen. Anders als eine Sammlung von Aktionen, die jemand im Panel zusammengeklickt hat, der hier längst nicht mehr arbeitet. Hier beginnt bereits ganz gewöhnliche Entwicklung von Individualsoftware, mit Repository, Tests und einem Einführungsprozess.
Die Architekturentscheidung klingt anders, als viele meinen: Die Integrationsschicht ersetzt BaseLinker nicht, sie nimmt ihm nur die Verantwortung für die Logik ab. Das Panel spricht weiterhin mit Marktplätzen und Versanddienstleistern. Aber es entscheidet nicht mehr, was eine korrekte Bestellung ist.
Wenn der Verkauf über mehrere Kanäle gleichzeitig läuft, brauchen Sie eine eigene Quelle der Wahrheit für Katalog und Bestände. Dazu Logs und Event-Tracking, damit Sie einen Monat später rekonstruieren können, was genau mit Bestellung Nummer X passiert ist. Dieselbe Disziplin verlangt jede API-Integration, die anschließend über Jahre gepflegt werden muss.
Sicherheit, Zugänge und das, woran Unternehmen zu spät denken
Ein API-Token, das per E-Mail und Tabelle kursiert, ist ein Standard, den wir regelmäßig sehen. Meist eines, gemeinsam für alle Integrationen, sodass es sich nicht widerrufen lässt, ohne das halbe Unternehmen anzuhalten.
Getrennte Berechtigungen und die Rotation von Schlüsseln sollten von Anfang an Teil des Projekts sein und keine Korrektur nach einem Vorfall. Ein eigener Schlüssel pro Integration bedeutet, dass Sie beim Abgang eines Subunternehmers einen Zugang kappen und nicht alle. Gut zu wissen ist außerdem, wo die personenbezogenen Kundendaten, die durch die Integrationen fließen, tatsächlich landen und wie lange sie dort liegen. Adressen und Telefonnummern bleiben in Logs oft deutlich länger, als irgendjemand angenommen hat.
Eine Testumgebung gilt gern als Luxus. Bis ein Experiment auf der Produktion mit Paketen an falsche Adressen endet. Das Aufräumen einer solchen Situation kostet immer mehr, als sie zu vermeiden.
Kostenstruktur: was die Rechnung wirklich treibt
Der größte Fehler bei der Budgetierung ist, die Einführung statt der Wartung zu rechnen. Marktplätze ändern ihre APIs, neue Rechnungsformate kommen hinzu, weitere Versanddienstleister tauchen mit eigenen Anforderungen auf. Und so geht es über den gesamten Lebenszyklus des Systems.
Der zweite Kostenblock liegt versteckt auf der operativen Seite: die Stunden, in denen Menschen von Hand flicken, was das System nicht bewältigt. Er steht auf keiner Rechnung, wächst aber mit dem Volumen.
Die Rechnung treiben vier Dinge: die Zahl der Verkaufskanäle, die Zahl der Ausnahmen im Prozess, das Bestellvolumen sowie die buchhalterischen Anforderungen samt Retourenabwicklung. Das Entscheidungskriterium ist einfach. Solange sich die Ausnahmen mit Regeln beschreiben lassen, gewinnt der Ausbau des Panels. Sobald sie sich nur noch mit Bedingungen beschreiben lassen, die voneinander abhängen, kommt eine eigene Schicht günstiger, denn Chaos zu unterhalten kostet mehr, als es zu ordnen.
Wie Sie den Wechsel vollziehen, ohne den Verkauf anzuhalten
Die Migration läuft in Etappen: zuerst ein Kanal oder ein Prozess, dann der Rest. Der Ansatz “alles auf einmal am Wochenende” endet damit, dass am Montag niemand weiß, ob die Bestellungen wegen eines Mapping-Fehlers nicht stimmen oder wegen etwas ganz anderem.
Der alte und der neue Ablauf sollten eine Zeit lang parallel laufen, mit Vergleich der Ergebnisse, bevor irgendetwas abgeschaltet wird. Abweichungen zeigen sich dann in Ruhe und nicht in Reklamationen. Vor dem Start müssen Statusmappings, Ausnahmen, Preisregeln und die Grenzfälle der Reklamationsbearbeitung dokumentiert werden. Das ist die am häufigsten übersprungene Etappe, und genau dort steckt das Wissen, das in keiner Dokumentation steht.
Der typische Fehler? Das bestehende Durcheinander eins zu eins zu übernehmen. Die Migration ist der einzige Moment, in dem das Aufräumen des Prozesses nichts zusätzlich kostet, weil Sie ohnehin jedes Element anfassen. Dieselbe Regel gilt bei einer breiteren Modernisierung von Systemen.
Fazit
BaseLinker reicht nicht dann nicht mehr aus, wenn das Unternehmen wächst, sondern dann, wenn seine Prozesse nicht mehr in die Regeln des Panels passen. Diese Unterscheidung ist wichtig, denn den ersten Fall löst ein höheres Paket, den zweiten nicht.
Eine gute Entscheidung bedeutet selten, alles auszutauschen. Meist genügt es, eine Schicht zu ergänzen, die die Logik übernimmt und dem Panel das lässt, worin es wirklich gut ist: die operative Abwicklung von Bestellungen, Versanddienstleistern und Dokumenten.
Erkennen Sie bei sich mehrere der beschriebenen Symptome? Wir schauen uns das gern von der technischen Seite an. Wir machen Integrationsaudits, entwerfen Zwischenschichten, Automatisierungen und Modernisierungen von Vertriebssystemen, schreiben Sie uns, und wir beginnen mit einem Gespräch darüber, wo genau der Prozess auseinanderläuft.
