PrestaShop mit GoManage und Aunabase verbinden: ein echter Fall

Praxisbeispiele · 6 Min. Lesezeit

PrestaShop mit GoManage und Aunabase verbinden: ein echter Fall

Elf Uhr nachts. Ein Elektriker öffnet den Shop auf dem Handy, legt drei Meter Kabelkanal, eine Schachtel Schalter und einen Leitungsschutzschalter in den Warenkorb und bezahlt. Am nächsten Morgen stellt sich im Lager heraus: Es war noch eine Schachtel da – die anderen beiden gingen am Freitag um halb sieben über den Tresen.

Der Kunde hat nichts falsch gemacht, der Shop auch nicht. Das Problem ist, dass Shop und Lager an zwei verschiedenen Orten leben – die Website auf der einen Seite, das ERP auf der anderen – und dazwischen sitzt ein Mensch, der Preise und Bestände abtippt, wann immer er eine freie Minute hat.

Das haben wir für einen Großhändler für Elektro- und Sanitärbedarf gebaut, der mit zwei in der Branche bekannten Werkzeugen arbeitet: Go!Manage, dem ERP von Telematel, und Aunabase, der Produktdatenbank der Gruppe Aúna Distribución.

Der Ausgangspunkt: zwei Systeme, die bereits funktionierten

Das Unternehmen hatte kein Softwareproblem. Sein ERP war auf dem neuesten Stand, mit fast dreißigtausend erfassten Artikeln, seinen Preislisten und seinen Beständen je Lager. Und es hatte Zugang zu Aunabase, wo die Hersteller der Gruppe die guten Produktdaten veröffentlichen: den echten Handelsnamen, die technische Beschreibung, die Fotos, den Strichcode, die Marke, die Einheiten, in denen jeder Artikel verkauft wird.

Was es nicht hatte, war ein Shop. Und die Versuchung ist, ihn beim Bauen von Hand zu füllen: eine Tabelle exportieren, hochladen, nachbessern – und drei Monate später einen dritten Katalog besitzen, der zu keinem der beiden anderen passt.

Der Shop ist kein weiterer Ort, an dem der Katalog liegt. Er ist das Schaufenster dessen, was ohnehin im ERP steht.

Mit diesem Gedanken war die Aufgabe nicht mehr „die Produkte in PrestaShop bekommen“, sondern etwas viel Einfacheres: zu entscheiden, wer wofür zuständig ist.

Wer wofür zuständig ist

Das ganze Projekt ruht auf dieser Aufteilung, und sie zu klären lohnt sich, bevor irgendetwas angefasst wird:

  • Das ERP ist für das Geschäft zuständig. Welche Artikel verkauft werden, zu welchem Preis, wie viele übrig sind und welche auf einer Aktionspreisliste stehen. Nichts davon wird im Shop bearbeitet.
  • Aunabase ist dafür zuständig, wie das Produkt erzählt wird. Name, Beschreibung, Bilder, Marke, Hersteller, Strichcode, Warengruppe und Mindestverkaufseinheit.
  • Der Shop ist fürs Verkaufen zuständig. Die Startseite, die Kampagnen, seine eigenen Texte, den Versand und den Umgang mit dem Kunden.

Von den fast dreißigtausend Artikeln des ERP zeigt der Shop eine Auswahl von 16.700 Artikeln: die, die der Großhändler online verkaufen will. Der Rest bleibt im ERP und taucht nie auf. Diese Liste zu erweitern oder zu kürzen ist eine kaufmännische Entscheidung im ERP, keine Wartungsaufgabe der Website.

Was der Kunde sieht

Im Alltag verhält sich der Shop, wenn alles steht, so:

  • Produktseiten, die Sinn ergeben. Jeder Artikel kommt mit seinem Handelsnamen, seiner technischen Beschreibung, seinen Fotos und seiner Marke an – statt mit einem „REF 4021 WEISS“ und einem Symbolbild. Genau das macht die Seite bei Google konkurrenzfähig, und daher kommt die Hälfte der Besucher – wir haben es unter wo man anfängt, wenn der Shop nicht auftaucht beschrieben.
  • Preise und Bestände, die dem Lager gehören. Nicht die des letzten Exports.
  • Kein Bestand, kein Verkauf. Der Artikel bleibt sichtbar – Google soll ihn kennen und der Kunde soll wissen, dass Sie ihn führen –, aber er kann nicht in den Warenkorb, solange keine Einheiten da sind.
  • Alles in seiner eigenen Einheit. Wird ein Artikel in Zehnerpackungen geliefert, lässt der Shop niemanden sieben bestellen. Die Mindesteinheit kommt aus den Herstellerdaten, damit Bestellungen kommissionierfertig ankommen.
  • Ausgelaufene Artikel verschwinden von selbst. Wird ein Artikel zurückgezogen, steht er nicht mehr zum Verkauf, ohne dass jemand daran denken muss.
  • Angebote stellen sich selbst ein. Was im ERP auf einer Aktionspreisliste steht, landet in der Angebotskategorie des Shops – und verlässt sie ebenso lautlos, wenn die Preisliste wechselt.

Nichts davon pflegt ein Mensch. Es sind dieselben Informationen, die ohnehin im ERP und in Aunabase gepflegt werden, nur von der Website aus gesehen.

Und die Bestellung zurück

Die interessante Hälfte einer Integration ist die, die in die andere Richtung läuft. Wenn der Kunde bezahlt, landet die Bestellung in Go!Manage mit ihren Positionen, den Mengen, der Lieferadresse, der Rechnungsadresse und der Zahlungsart, übersetzt in die, die das ERP versteht. Niemand tippt sie erneut.

Und weil das nachprüfbar sein muss, zeigt die Bestellseite im Back Office, ob sie im ERP angekommen ist oder nicht, mit einer Schaltfläche zum erneuten Senden. Das ist die eigentliche Veränderung für das Unternehmen: kein „Ich trage es ins ERP ein, wenn ich eine Minute habe“ mehr. Das Lager sieht die Bestellung dort, wo es alle anderen sieht.

Die drei Entscheidungen, die es haltbar machen

Eine Integration wird nach sechs Monaten beurteilt, nicht am Tag der Inbetriebnahme. Das sind die drei, die die klassischen Probleme vermeiden:

  1. Preis und Bestand werden nur an einer Stelle bearbeitet. Im ERP. Ein Shop, in dem man sie auch von Hand ändern kann, streitet am Ende mit sich selbst – und der Streit geht immer am umsatzstärksten Tag verloren.
  2. Handgeschriebene Arbeit wird nie überschrieben. Wenn jemand einen Produktnamen verbessert, eine Beschreibung neu formuliert oder ein besseres Foto hochlädt, respektiert die nächste Aktualisierung diese Arbeit. Ohne diese Regel fasst nie wieder jemand eine Produktseite an.
  3. Die Aktualisierung läuft in Blöcken und kann fortsetzen. Ein Katalog dieser Größe wird nicht in einem Rutsch aufgefrischt: Er wird in Blöcken verarbeitet und setzt nach einer Unterbrechung dort fort, wo er war. Der Shop muss nie „wegen Wartung“ schließen oder mit einem halben Katalog dastehen.

Was wir von Ihnen brauchen

Wenn uns jemand danach fragt, ist es nicht viel, was wir wissen müssen:

  • Einen Verbindungsbenutzer für Ihr Go!Manage, den Ihr ERP-Anbieter ausstellt.
  • Ihre Aunabase-Zugangsdaten, falls Sie der Gruppe angehören.
  • Die Auswahl der Artikel, die Sie online verkaufen wollen, und wie Sie sie in Warengruppen gliedern möchten.
  • Und eine kaufmännische Entscheidung: ob Sie an Gewerbekunden zu vereinbarten Preisen verkaufen, sich der Allgemeinheit öffnen oder beides zugleich. Darüber haben wir gesondert geschrieben, unter wie man den Katalog nur freigegebenen Kunden zeigt.

Damit können wir bereits einen ersten Probelauf fahren und uns den echten Katalog im Shop ansehen, bevor irgendetwas anderes entschieden wird.

Wenn Sie mit Go!Manage oder Aunabase arbeiten

Wir kennen beide von innen und wissen, wo es üblicherweise wehtut: Artikel, die das ERP doppelt führt, Warengruppen, die nicht dazu passen, wie Kunden tatsächlich kaufen, Artikel ohne Foto, Sonderpreislisten. Nichts davon ist ungewöhnlich und nichts davon hält Sie vom Start ab.

Und wenn Ihr ERP ein anderes ist, bleibt der Ansatz derselbe: Dem ERP gehören Preis und Bestand, dem guten Katalog gehören die Produktseiten, und Bestellungen finden allein zurück.

Ihr ERP ist aktuell und der Shop steht noch auf der To-do-Liste? Sagen Sie uns, womit Sie arbeiten, und wir sagen Ihnen, was sich anbinden lässt und in welcher Reihenfolge.

Erzählen Sie uns von Ihrem Fall

So können wir Ihnen helfen

Alle Leistungen ansehen →
Dürfen wir Ihnen bei Ihrem Projekt helfen? Sprechen wir darüber

Machen Sie Ihren Onlineshop zu Ihrem besten Vertriebler

Bereit, Ihren PrestaShop-Shop nach vorne zu bringen? Sprechen wir über Ihr Projekt und bauen gemeinsam etwas Großartiges.

Schreiben Sie uns