B2B-Portal-Entwicklung: Eure Prozesse sind kein Standard, Euer Portal sollte es auch nicht sein

Diese Situation kennt jedes B2B-Unternehmen: Ein Kunde ruft an, um nach dem aktuellen Lieferstatus einer Bestellung zu fragen. Jemand aus dem Innendienst schaut im ERP nach, prüft die Auftragsnummer und den Status und ruft zurück. Bis der Kunde seine Information hat, sind mindestens 15 Minuten vergangen.

Diese 15 Minuten sind eine Systemlücke. Der Kunde könnte längst selbst auf seine Daten zugreifen und den Status seiner Bestellung einsehen. Portale, die genau das leisten, lassen sich allerdings selten mit Standardsoftware abbilden. Preise sind im B2B-Umfeld nicht fix und Käufe müssen teilweise genehmigt werden.

Wann ein individuelles Portal sinnvoll ist, was bei der Entwicklung wichtig ist und woran Portalprojekte oft scheitern, beleuchten wir in diesem Beitrag.

Der eigentliche Unterschied besteht in der Rechte- und Preislogik, und deshalb ist der Login mehr als eine Formalie. Dahinter beginnt die kundenindividuelle Datenlage. In einem B2C-Shop sehen alle Kund:innen denselben Preis, im B2B-Portal richtet er sich nach Rahmenverträgen, Mengenstaffelungen und befristeten Aktionen und fällt damit von Kunde zu Kunde unterschiedlich aus.

Hinzu kommen weitere Faktoren, die noch mehr Komplexität bringen. In Unternehmen hat nicht jeder Besteller eine Freigabebefugnis und nicht jeder Freigebende ein Bestellrecht. Konzerne verfügen außerdem oft über mehrere Lieferadressen. Teilweise muss es möglich sein, eine Kostenstelle zuzuordnen und manche Artikel dürfen für manche Kunden gar nicht sichtbar sein.

Diese Anforderungen sind das Fundament der Anwendung und können daher nachträglich nur sehr schwer ergänzt werden. Hier kommt Standardsoftware schnell an ihre Grenzen.

Welche Lösung für B2B-Unternehmen am sinnvollsten ist, ist sehr individuell. In einigen Fällen kann Standardsoftware die richtige Lösung sein. Das ist beispielsweise dann der Fall, wenn die eigenen Prozesse nah am Marktstandard liegen, oder das Unternehmen noch nicht genau weiß, was seine Kunden erwarten. Die Standardsoftware kann dann erstmal als Lerninstrument dienen. Zudem ist Standardsoftware sofort einsatzbereit, was vielen Unternehmen zugutekommen kann.

Wird allerdings die Liste der benötigten Anpassungen länger als die der genutzten Funktionen, sollten Unternehmen darüber nachdenken, sich eine individuelle Software entwickeln zu lassen. Ansonsten besteht die Gefahr, dass Prozesse an die Software angepasst werden und nicht umgekehrt. Außerdem wird jedes neues Release des Standardsoftwareherstellers zum Risiko, weil es dazu führen kann, dass die eigenen Erweiterungen nicht mehr funktionieren.

Folgende Kriterien sollten Unternehmen betrachten:

Wichtig: Die Entscheidung muss nicht für immer getroffen werden. Unternehmen entscheiden sich häufig dazu, Standardsoftware als Markttest einzusetzen und dann auf eine eigene Lösung zu wechseln.

Auch das Thema Sicherheit gehört bereits in die Anforderungsphase. Ein B2B-Portal verarbeitet Preise, Konditionen, Verträge und teilweise personenbezogene Daten, also genau die Informationen, die weder beim Wettbewerb noch bei einem Leak auftauchen sollten. Wird Sicherheit erst zur Abnahme geprüft, lassen sich Fehler in der Architektur nicht mehr korrigieren, sondern nur noch notdürftig absichern.

Der etablierte Gegenentwurf heißt Security by Design. Sicherheitsanforderungen werden bereits in der Anforderungsanalyse definiert und über den gesamten Entwicklungsprozess mitgeführt. Dahinter stehen mehrere Prinzipien:

• Zero Trust: Kein Zugriff gilt als vertrauenswürdig, auch nicht aus den eigenen Reihen.
• Least Privilege: Jede Rolle erhält nur die Rechte, die sie für ihre Aufgabe tatsächlich benötigt.
• Defense in Depth: Mehrere gestaffelte Schutzebenen sorgen dafür, dass der Ausfall einer Ebene nicht gleich das ganze System für Angreifer öffnet.
• Separation of Duties: Kritische Vorgänge werden auf mehrere Rollen verteilt.
• Secure Defaults: Die Grundeinstellung sieht keine Rechte vor, Rechte müssen erst bewusst vergeben werden.

Für Portale ist das besonders relevant, weil die Rechtestruktur hier gleichzeitig Sicherheitsthema und Fachlogik ist. Wer bestellen darf, wer freigibt und wer welche Preise sieht, ist dieselbe Frage, unabhängig davon, aus welcher Perspektive man sie stellt. Eine saubere Modellierung erledigt deshalb beides in einem Zug.

In Ausschreibungen wird Technologie gerne wie ein Menü behandelt: klassisch oder headless, Plattform oder Eigenentwicklung, dieses Ökosystem oder jenes. In der Praxis handelt es sich dabei um Schichten, die sich frei miteinander kombinieren lassen.

Gut zeigen lässt sich das am Begriff Headless, der am häufigsten missverstanden wird. Headless beschreibt, wie Inhalte und Funktionen ausgeliefert werden, nämlich über Schnittstellen statt über fest gekoppelte Seitenvorlagen. Womit das Backend gebaut ist, sagt der Begriff dagegen nicht aus. Ein headless ausgeliefertes Portal auf einem .NET-Backend funktioniert ebenso wie ein klassisch gerendertes Portal mit modernem JavaScript-Frontend oder ein hybrider Aufbau, bei dem redaktionelle Seiten klassisch und Selfservice-Strecken headless laufen. Die eigentliche Frage lautet deshalb, welche Kanäle bedient werden müssen.

Drei Entscheidungen haben dagegen tatsächlich Gewicht, und sie sind unabhängig voneinander:

• Die Integrationsschicht: Kommt das Portal direkt, über eine Middleware oder über eine eigene Serviceschicht an die Daten aus ERP, CRM und weiteren Fachsystemen? Davon hängt ab, ob sich ein Vorsystem später austauschen lässt, ohne das Portal anzufassen. Diese Entscheidung hat die größten Folgekosten und wird trotzdem meist beiläufig getroffen.
• Der Zuschnitt zwischen Zukauf und Eigenentwicklung: Content Management, Rechte, Mehrsprachigkeit, Suche und Katalogfunktionen sind gelöste Probleme. Eine Plattform als Basis nimmt sie ab und lässt Raum für die eigentliche Geschäftslogik. Portale, die fast nur aus Transaktion und kaum aus Redaktion bestehen, brauchen diesen Überbau dagegen oft nicht.
• Der spätere Betrieb: Ein Aufbau, den das eigene Team nicht warten kann, ist unabhängig von seiner technischen Eleganz die falsche Wahl. Wer selbst hostet, entscheidet außerdem anders als ein Unternehmen, das diese Verantwortung bewusst abgeben möchte.

Sprache und Framework ergeben sich aus diesen Punkten. Wo bereits eine gewachsene Systemlandschaft existiert, gibt sie den Rahmen ohnehin vor, und ein Portalprojekt ist selten der richtige Anlass, ihn zu verlassen.

Die Gründe für ein Scheitern sind selten technischer Natur. Vor allem vier Muster kehren immer wieder:

• Der erste Wurf ist zu groß: Es wird über Monate spezifiziert, bevor überhaupt jemand das Portal benutzt hat, und beim Livegang passt die Fachlichkeit nicht mehr zur Realität.
• Die Integration wird unterschätzt: Das Frontend ist fertig, aber die Daten aus dem ERP kommen nicht sauber, nicht schnell genug oder nicht vollständig.
• Die interne Einführung fehlt: Ein Portal, das niemand erklärt und für das sich intern niemand verantwortlich fühlt, wird von Vertrieb und Innendienst oft ignoriert.
• Es gibt keinen fachlichen Entscheider auf Auftraggeberseite: Ohne eine Person, die inhaltlich entscheiden darf, versanden Entscheidungen in Abstimmungsschleifen.

Dagegen hilft ein bewusst enger Startumfang, Integration ab dem ersten Sprint statt am Ende, klare fachliche Verantwortung auf beiden Seiten und ein Team, das lange genug zusammenbleibt, um das Geschäft wirklich zu verstehen.

Dass Gestaltung im B2B zweitrangig sei, weil es ja nur um Funktion gehe, ist ein teurer Irrtum. Beruflich Nutzende bringen genau die Erwartungen mit, die sie privat gewohnt sind, denn eine getrennte Gewöhnung für den Arbeitsplatz gibt es nicht.

Ein umständliches Portal wird deshalb schlicht umgangen. Telefon und E-Mail leben munter weiter und das Unternehmen trägt am Ende die Kosten des Portals und die des manuellen Prozesses gleichzeitig.

Entscheidend sind kurze Wege für die Aufgaben, die täglich anfallen, schnelle Ladezeiten auch bei großen Katalogen, eine Bedienung, die am Desktop wie am Smartphone funktioniert, und eine Rollenstruktur, die die reale Organisation der Kunden abbildet statt eines idealisierten Organigramms. Ist das gelöst, wird aus dem geduldeten Werkzeug der bevorzugte Kanal, und erst ab diesem Punkt rechnet sich die Investition.

Eine pauschale Zahl zu nennen wäre unseriös, denn die Spannweite ist groß. Ein fokussiertes Kundenportal mit Auftragsübersicht, Dokumentenzugriff und einer sauberen ERP-Anbindung bewegt sich in einem völlig anderen Rahmen als eine Plattform, die Vertrieb, Service und Partnergeschäft gleichzeitig abbildet.

Die Kostentreiber sind fast immer dieselben, und ihre Reihenfolge ist dabei aufschlussreicher als jede Zahl: zuerst die Integrationstiefe, dann der Funktionsumfang, dann die Anforderungen an Sicherheit und Compliance. Das Budget hängt also weniger an der Menge der Funktionen als daran, wie viele Systeme in welcher Datenqualität angebunden werden müssen.

Bewährt hat sich deshalb ein Vorgehen, das der Versuchung zum großen Wurf widersteht: mit einem klar umrissenen ersten Ausbau starten, der einen echten Prozess vollständig abbildet, statt mit zehn Prozessen, die alle nur halb funktionieren. Daraus entsteht ein belastbarer Business Case, auf dessen Basis sich alles Weitere fundiert planen lässt.

Bei der Dauer verhält es sich ähnlich. Sie hängt weniger an der Teamgröße als daran, wie eng der erste Ausbau gefasst ist und wie schnell auf Auftraggeberseite fachlich entschieden wird. Projekte verzögern sich fast immer in Abstimmungsschleifen und beim Warten auf Schnittstellenzugänge, selten in der Entwicklung.

Belastbar werden Aufwand und Termin erst, wenn drei Dinge auf dem Tisch liegen: die Prozesse, die das Portal abbilden soll, die Systeme, die dafür angebunden werden müssen, und der tatsächliche Zustand ihrer Schnittstellen. Eine kurze Analyse vorab schafft hier meist schnell Klarheit.

Ein gutes B2B-Portal ist kein Projekt mit Enddatum, sondern ein Produkt, das mit dem Geschäft wächst. Neue Funktionen, weitere Systeme, zusätzliche Nutzergruppen und veränderte Prozesse kommen mit der Zeit dazu.

Wer die Entwicklung von Anfang an so plant, sollte auf drei Dinge achten: einen ersten Ausbau, der klein genug für einen schnellen Livegang und groß genug für echten Nutzen ist, eine Architektur, die Erweiterung erlaubt statt sie zu bestrafen, und einen Betrieb, der die laufende Weiterentwicklung trägt. Dann ist das Portal auch in fünf Jahren noch ein Aktivposten und wird nicht zum nächsten Sanierungsfall.

Technologisch legen wir uns nicht vorab fest. Welche Basis, welche Auslieferungsform und welche Integrationsschicht passen, ergibt sich aus der vorhandenen Systemlandschaft, den fachlichen Anforderungen und dem Team, das das Portal später betreibt. Klassisch, headless und hybride Aufbauten setzen wir gleichermaßen um, ebenso plattformbasierte und vollständig individuell entwickelte Portale.

Was in jedem Projekt gleich bleibt: Die Integration steht von Beginn an im Plan. Entwickelt wird nach Security by Design mit klaren Rollen- und Zugriffskonzepten, Verschlüsselung und nachvollziehbarem Logging, begleitet von statischen Codeanalysen. IT-Security-Erfahrung sammeln wir seit 2001, Software entwickeln wir seit über 25 Jahren. Und weil B2B-Portale über viele Jahre laufen, planen wir Betrieb und Weiterentwicklung von Anfang an mit.

Steht bei Euch die Frage an, ob sich ein individuelles B2B-Portal rechnet? Dann sprechen wir am besten über Eure Prozesse, nicht über Featurelisten. Nehmt Kontakt zu uns auf, wir schauen gemeinsam, wo der größte Hebel liegt.