Unternehmen, die jahrelang im Großhandel per E-Mail, Telefon und Tabellenkalkulation verkauft haben, stoßen irgendwann an eine Wand. Bestellungen gehen in Postfächern verloren, Vertriebsmitarbeiter tippen Positionen manuell ab, und individuelle Preislisten stecken in den Köpfen einiger weniger Personen. Genau hier stellt sich die Frage nach einem B2B-System nach Maß, also einer Plattform, die zu Ihrer tatsächlichen Art zu verkaufen passt und nicht umgekehrt. Als Team von Web Systems, einem software house aus Łódź, das seit 2006 tätig ist, entwerfen und implementieren wir solche Lösungen von der technischen, integrativen und wartungsbezogenen Seite. Nachfolgend zeigen wir, wie man über eine solche Plattform aus Sicht eines Dienstleisters denkt, der ihren gesamten Lebenszyklus kennt und nicht nur eine hübsche Demo.
Spis treści
Wozu braucht ein Unternehmen ein individuelles B2B-System statt einer Standardlösung
Der Unterschied zwischen E-Commerce von der Stange und einem individuellen B2B-System liegt in der Richtung der Anpassung. Eine Standardplattform gibt ihre Prozesse vor, und Sie biegen Ihren Vertrieb danach zurecht. Eine Anwendung nach Maß macht es umgekehrt: Sie bildet ab, wie Sie tatsächlich arbeiten. Verhandelte Preise, Rabattschwellen, Kreditlimits, ungewöhnliche Freigabewege für Bestellungen. Im B2B sind die Regeln oft so speziell, dass fertige Vorlagen schnell zu drücken beginnen.
Es gibt einige deutliche Signale dafür, dass ein Unternehmen dem Provisorium entwachsen ist. Das sind die häufigsten:
- Vertriebsmitarbeiter übertragen Bestellungen aus E-Mails und PDFs manuell ins Lagersystem.
- Individuelle Preislisten der Geschäftspartner liegen in vielen, oft widersprüchlichen Versionen von Tabellen.
- Der Kunde sieht weder seine Bestellhistorie noch die aktuellen Bestände und ruft deshalb wegen jeder Information an.
- Fehler bei Preisen und Verfügbarkeit fallen erst nach der Rechnungsstellung auf.
Es kommt auch der Moment, in dem sich das Anpassen einer fertigen Plattform nicht mehr lohnt. Weitere Plugins, Umgehungen und Aufsätze auf eine Standard-Engine kosten mehr als der Entwurf einer Anwendung von Grund auf und erschweren zudem Aktualisierungen. Aus unserer Praxis ergibt sich eine einfache Regel: Wenn die Geschäftslogik das Werkzeug ständig “austricksen” muss, ist schlicht das Fundament falsch. Die Entscheidung für ein eigenes System treibt in der Regel nicht die Mode, sondern echter Schmerz. Eine wachsende Zahl an Fehlern, verlorene Zeit in der Abwicklung, fehlende Skalierbarkeit. Dann wird die Entwicklung von Individualsoftware zu einer Investition in Ordnung und nicht zu einer teuren Laune.
Drei Nutzergruppen, drei verschiedene Bedürfnisse: Kunden, Partner und Vertriebsmitarbeiter
Eine gute B2B-Plattform bedient drei Welten gleichzeitig, und jede von ihnen erwartet etwas anderes. Der Kunde möchte schnell bestellen, ohne an Funktionen vorbeizuscrollen, die ihn nicht interessieren. Für ihn zählen individuelle Preislisten, die Einsicht in das gewährte Kreditlimit, eine übersichtliche Historie und wiederverwendbare Warenkörbe, mit denen er dieselben Positionen regelmäßig per Klick nachbestellt. Das ist ein Nutzer, der Berechenbarkeit und eine minimale Anzahl von Schritten bis zur Bestellung schätzt.
Der Partner sieht das System völlig anders. Ihn interessieren Provisionen, die Rabattstruktur, der Zugriff auf Lagerbestände nahezu in Echtzeit sowie ein Abrechnungspanel, das zeigt, was verkauft wurde und wie viel er daran verdient hat. Und der Vertriebsmitarbeiter? Er arbeitet im Außendienst und braucht ein mobiles Werkzeug: Er erfasst Bestellungen im Namen des Kunden, sieht die Zielerreichung ein und ist häufig bei schlechtem Empfang unterwegs. Drei Absichten, drei Arbeitslogiken.
Der häufigste Entwurfsfehler besteht darin, alle in eine einzige universelle Oberfläche zu pressen. Das Ergebnis ist absehbar: ein Bildschirm, überladen mit Optionen, von denen jede Rolle vielleicht ein Drittel nutzt. Der Kunde verliert sich in Feldern für den Vertrieb, und der Partner findet die Abrechnungen unter einer Schicht von Einkaufsfunktionen nicht. Deshalb trennen wir die Ansichten von Anfang an nach Rollen und Berechtigungen. Gemeinsam bleibt der Kern, also Katalog, Preise und Bestellungen, während sich Darstellung und verfügbare Aktionen danach unterscheiden, wer angemeldet ist. Tipp: Entwerfen Sie die Pfade für jede Rolle getrennt bereits in der Wireframe-Phase, bevor die erste Codezeile entsteht. Das ist günstiger, als die Oberfläche nach der Einführung zu entwirren, wenn sich die Nutzer bereits an das Durcheinander gewöhnt haben.
Architektur und technische Entscheidungen, die über die Langlebigkeit des Systems entscheiden
Die Langlebigkeit einer Plattform entscheidet sich auf der Ebene der Architektur und nicht bei der Farbe der Schaltflächen. Ausgangspunkt ist die Trennung der Schichten: Benutzeroberfläche, Geschäftslogik und Daten. Jede hat klar gezogene Grenzen und Verantwortlichkeiten. Am wichtigsten ist eine einzige Quelle der Wahrheit für Preise, Lagerbestände und Bestellungen, denn genau hier entstehen die teuersten Fehler. Wenn derselbe Preis an drei Stellen lebt, werden die Werte früher oder später auseinanderlaufen.
Die Trennung der Verantwortlichkeiten ist das Fundament einer Anwendung, die sich leicht warten und erweitern lässt. Die Logik der Rabattberechnung sollte sich nicht mit dem Code vermischen, der den Bildschirm zeichnet, und der Datenbankzugriff darf nicht über das ganze Projekt verstreut sein. Dadurch entwickelt das Team einzelne Module unabhängig, testet sie getrennt und tauscht sie aus, ohne zu riskieren, dass das Anfassen eines Elements das Ganze zum Einsturz bringt. Je sauberer die Grenzen, desto weniger kostet jede weitere Änderung.
Einige Entscheidungen müssen zu Beginn fallen, weil sie später schmerzhaft sind. Dazu gehören:
- Das Mandantenmodell (Multi-Tenancy), falls Sie mehrere Organisationen oder Marken in einem System betreiben wollen.
- Die Struktur von Rollen und Berechtigungen, also wer was sieht und was tun darf, beschrieben als schlüssiges Modell und nicht als Sammlung von Ausnahmen.
- Die Art der Versionierung von Preislisten und Bestellungen, damit sich rekonstruieren lässt, wie das Angebot an einem bestimmten Tag aussah.
Architektonische Abkürzungen sind mit Blick auf Termin und Budget verlockend, ihre Folge ist jedoch technische Schuld, die mit der Plattform mitwächst. Jede Funktion, die mit Gewalt auf ein schlechtes Fundament gesetzt wird, macht das Ganze brüchiger. Nach ein bis zwei Jahren beginnt das System, das das Unternehmen beschleunigen sollte, es zu bremsen, weil jede Änderung neue Ausfälle heraufbeschwört. Deshalb investieren wir lieber Zeit in ein solides Grundgerüst, als später die Folgen der Eile zu reparieren.
Integrationen mit ERP, Lager und Zahlungen – das Herz des B2B-Systems
Ein B2B-System lebt selten für sich allein. Sein Herz sind die Integrationen, denn sie entscheiden darüber, ob der Preis auf dem Bildschirm zur Rechnung passt und die angegebene Verfügbarkeit zum tatsächlichen Bestand. Entscheidend ist die Synchronisation von Preislisten, Lagerbeständen und Bestellstatus über eine API, am besten kontinuierlich und berechenbar. Ein Kunde, der ein als verfügbar angezeigtes Produkt bestellt und einen Tag später vom Fehlbestand erfährt, verliert das Vertrauen in die gesamte Plattform. Und das ist ihm kaum zu verdenken.
In der Projektpraxis sind Integrationen der Bereich der größten Überraschungen. Typische Fallstricke, auf die wir stoßen, sind fehlende API-Dokumentation in einem älteren ERP, Verzögerungen bei der Synchronisation sowie Datenkonflikte, wenn zwei Systeme denselben Datensatz gleichzeitig ändern. Eine direkte, starre Verbindung nach dem Muster “das System fragt bei jedem Klick das ERP” ist oft brüchig: ein Moment der Nichtverfügbarkeit und die Plattform funktioniert nicht mehr. Deshalb entwerfen wir eine Strategie zur Fehlerbehandlung und eine Warteschlange für Aufgaben. Operationen wandern in die Queue, werden bei Fehlern wiederholt, und der Nutzer bleibt nicht vor einem leeren Bildschirm sitzen, wenn das ERP gerade nicht antwortet.
Es lohnt sich, die vollständige Liste der anzubindenden Systeme gleich zu Beginn festzuhalten, denn der Appetit wächst meist unterwegs. Am häufigsten umfasst sie:
- ERP – Quelle für Preislisten, Geschäftspartner und Verkaufsbelege.
- WMS, also das Lagersystem, das für reale Bestände und Lagerplätze zuständig ist.
- Zahlungs-Gateways für Überweisungen, Zahlungsziele und Kreditlimits im Handel.
- Buchhaltungssysteme für Rechnungen und Abrechnungen.
- CRM, das die Historie der Vertriebskontakte mit den Bestellungen verbindet.
Jede dieser Integrationen hat ihr eigenes Tempo, Datenformat und ihre eigenen Einschränkungen. Je früher wir sie erkennen, desto weniger kostspielige Überraschungen gibt es bei der Einführung. Tipp: Bitten Sie vor dem Baustart den ERP-Anbieter um Testzugang und Dokumentation, und planen Sie, falls beides fehlt, Zeit für das Reverse Engineering der Schnittstellen ein.
Sicherheit, Daten und Skalierbarkeit – was man in der Demo nicht sieht
Eine Demo zeigt hübsche Bildschirme, schweigt aber über das Schwierigste: Sicherheit, Datenschutz und das Verhalten des Systems unter Last. Im B2B sind individuelle Preislisten und Handelskonditionen besonders sensibel. Ein Abfluss solcher Informationen an den Wettbewerb kann mehr schaden als ein Ausfall, deshalb gestalten wir den Zugriff so, dass jeder Geschäftspartner ausschließlich seine eigenen Preise und Daten sieht. Die Datenisolation zwischen Kunden ist kein Extra, sondern eine Grundanforderung.
Die zweite Säule ist die Zugriffskontrolle. Solide Authentifizierung, ein präzises Rollenmodell, Ereignisprotokollierung sowie die Begrenzung dessen, was Partner und Vertriebsmitarbeiter sehen, schützen sowohl das Unternehmen als auch seine Geschäftspartner. Die Ereignisaufzeichnung, also wer wann welche Aktion ausgeführt hat, ist bei der Klärung strittiger Bestellungen oder verdächtiger Anmeldungen oft unbezahlbar. Sie ist zudem ein Baustein der Konformität mit den Anforderungen an personenbezogene und kaufmännische Daten.
Die Skalierbarkeit entscheidet sich in der Entwurfsphase und nicht erst dann, wenn der Traffic bereits wächst. Man muss saisonale Spitzen, den Zuwachs an Geschäftspartnern und einen wachsenden Produktkatalog vorhersehen. Ein System, das für hundert Firmen und tausend Artikelnummern entworfen wurde, verträgt Last anders als eines, das für das Zehnfache vorbereitet ist. Deshalb achten wir von Anfang an auf die Performance der Abfragen, auf Datenbankindizes und auf Mechanismen zum Zwischenspeichern wiederkehrender Lesezugriffe.
Ein eigenes, häufig übersehenes Thema ist die Arbeit im Außendienst. Ein Vertriebsmitarbeiter beim Kunden ist manchmal an einem Ort ohne Empfang, deshalb sollte man einen Offline-Modus und die spätere Synchronisation der erfassten Bestellungen vorsehen. Die Anwendung sollte Aktionen lokal speichern und sicher nachsenden, sobald die Verbindung zurück ist, ohne das Risiko doppelter Bestellungen. Das sind Details, die man in einer Präsentation nicht sieht und die darüber entscheiden, ob die Leute das System wirklich nutzen.
Einführung, Wartung und Gesamtkosten (TCO) der Plattform
Eine vernünftige Einführung beginnt mit einem MVP, also einer Version, die die wichtigsten Prozesse abdeckt, und nicht sofort mit dem vollständigen System. Ein Minimalprodukt erlaubt zu prüfen, ob der entworfene Bestellweg tatsächlich der Arbeit von Kunden und Vertriebsmitarbeitern entspricht, bevor das Unternehmen Geld in den vollen Funktionsumfang pumpt. Besser, eine falsche Annahme im Kleinen zu entdecken als nach einem Jahr Bau einer umfangreichen Plattform. Diese Reihenfolge begrenzt das Risiko und ordnet die Prioritäten.
Die Gesamtkosten, also TCO, sind weit mehr als der reine Bau. Zur Rechnung gehören auch:
- Hosting und Infrastruktur, die mit dem Traffic mitskalieren.
- Monitoring und Reaktion auf Störungen, damit ein Problem vor dem Kunden entdeckt wird.
- Aktualisierungen von Bibliotheken und Sicherheits-Patches.
- Kontinuierliche Weiterentwicklung, denn Vertriebsprozesse verändern sich mit der Zeit.
Werden diese Posten im Budget übergangen, folgt die Enttäuschung, sobald nach der Einführung “unvorhergesehene” Ausgaben auftauchen, die in Wahrheit gut vorhersehbar waren. Ein eigenes, stark unterschätztes Risiko ist die Migration von Daten und Geschäftspartnern aus dem Altsystem. Historische Preislisten, offene Abrechnungen, inkonsistente Datensätze. Das kann mehr Zeit verschlingen als der Bau mehrerer Module. Deshalb behandeln wir die Migration als eigenes Projekt mit eigenem Plan und eigenen Tests und nicht als Tätigkeit für den letzten Tag.
Und zum Schluss das Einfachste, das am häufigsten unterschätzt wird: der Wartungsplan. Ein System ohne technischen Verantwortlichen, ohne Aktualisierungen und ohne jemanden, der auf Meldungen reagiert, verwandelt sich langsam in verlassene, nicht unterstützte Software. Nach einigen Monaten weiß niemand mehr, wie ein bestimmtes Modul funktioniert, und die Angst vor Änderungen wächst. Eine gut geplante Wartung sorgt dafür, dass die Plattform in Würde altert und den Vertrieb weiterhin unterstützt, statt ihn zu blockieren.
FAQ – die häufigsten Fragen zum B2B-System nach Maß
Wie lange dauert der Bau eines individuellen B2B-Systems und wovon hängt die Zeit ab?
Realistisch entsteht ein sinnvolles MVP meist in einigen Monaten, während sich die vollständige Plattform über einen längeren Zeitraum in Etappen entwickelt. Das Tempo hängt von der Zahl der Rollen, der Komplexität von Preislisten und Rabatten und vor allem von den Integrationen ab. Sie sind am schwersten zu schätzen, wenn die ERP-Dokumentation dürftig ist oder die Schnittstellen ungewöhnlich arbeiten. Je früher wir diese Einschränkungen erkennen, desto genauer fällt der Zeitplan aus, den wir nennen können.
Lässt sich das System an unser ERP anbinden, wenn es alt oder ungewöhnlich ist?
Meistens ja, auch wenn der Weg unterschiedlich ausfällt. Wenn das ERP eine API bereitstellt, verbinden wir uns direkt und synchronisieren die Daten über Warteschlangen mit Fehlerbehandlung. Bei geschlossenen Systemen nutzen wir Exporte, Dateiaustausch oder eine zwischengeschaltete Integrationsschicht. Der Schlüssel ist die Analyse zu Beginn: Wir prüfen, welche Daten sich lesen und schreiben lassen und wie oft sie ohne Konfliktrisiko synchronisiert werden können.
Lohnt es sich, mit einem MVP zu beginnen, oder gleich die volle Plattform zu bauen?
Wir empfehlen fast immer ein MVP. Es erlaubt zu bestätigen, dass der Prozess gut entworfen wurde, und Rückmeldungen echter Nutzer einzusammeln, bevor kostspielige Zusatzfunktionen entstehen. Eine ohne diese Validierung gebaute Vollplattform wird leicht in Bereichen überinvestiert, die niemand nutzt. Ein etappenweises Vorgehen schützt das Budget und lässt Raum für eine Kurskorrektur.
Wenn Sie ein B2B-System nach Maß, die Modernisierung einer bestehenden Plattform oder eine Integration mit ERP, Lager oder Zahlungen planen, schauen wir uns das gern von der technischen Seite an. Bei Web Systems helfen wir Ihnen, das MVP zu planen, die Architektur zu entwerfen und die benötigten Systeme sicher zu verbinden, auch mit Elementen der Automatisierung und von KI-Anwendungen. Nehmen Sie Kontakt mit uns auf, und wir legen gemeinsam einen sinnvollen ersten Schritt fest.
