„B2B Portal“ ist kein Produkttyp mit einer festen Funktionsliste. Dahinter können ein Bestellkanal für Händler, ein Datenraum für Lieferanten oder eine Serviceoberfläche für vernetzte Maschinen stehen. Gemeinsam ist ihnen eine anspruchsvolle Eigenschaft: Eine Organisation arbeitet in den Systemen einer anderen Organisation, ohne ihre internen Grenzen aufzugeben
Die Architektur beginnt beim Mandanten
In einer Verbraucher App gehört ein Konto meist zu einer Person. Im B2B Umfeld gehört die Person zu einem Unternehmen, oft zusätzlich zu einem Standort, einer Abteilung oder einem Vertrag. Ein Nutzer kann für mehrere Organisationen tätig sein. Dieselbe Organisation kann Einkäufer, Techniker und Administratoren mit unterschiedlichen Befugnissen haben
Die Mandantentrennung muss in der Datenverarbeitung durchgesetzt werden. Jede Abfrage, jeder Export und jede Hintergrundaufgabe muss den organisatorischen Kontext erzwingen. Automatisierte Tests sollten gezielt versuchen, Datensätze eines anderen Mandanten über manipulierte Kennungen, Suchfunktionen oder Dateilinks zu erreichen. Genau dort entstehen die folgenschwersten Portalfehler
Fünf Schichten eines belastbaren B2B Portals
1. Identität und Organisationsmodell
Einladungen, Rollenwechsel und das Ausscheiden externer Nutzer brauchen nachvollziehbare Abläufe. Größere Geschäftskunden erwarten häufig Single Sign on über ihren eigenen Identitätsanbieter. Für sensible Aktionen können erneute Anmeldung oder zusätzliche Freigaben sinnvoll sein
2. Fachliches Modell
Produkte, Verträge, Anlagen, Servicefälle und Dokumente benötigen stabile Kennungen und klare Beziehungen. Wer diese Struktur lediglich aus einer vorhandenen Excel Datei übernimmt, importiert oft auch deren Mehrdeutigkeiten. Das Portal braucht ein eigenes verständliches Modell und eine definierte Zuordnung zum führenden System
3. Integrationsschicht
ERP, CRM, Dokumentenspeicher und Logistik arbeiten nicht im selben Takt. Schnittstellen brauchen Wiederholungsregeln, Duplikatschutz und Überwachung. Bei Ausfällen muss sichtbar bleiben, ob eine Aktion angenommen, nur vorgemerkt oder vollständig verarbeitet wurde
4. Arbeitsoberfläche
Geschäftliche Nutzer kommen oft mit einer konkreten Aufgabe: alle auslaufenden Zertifikate prüfen, eine Seriennummer finden oder zwölf Positionen nachbestellen. Gute Navigation folgt diesen Aufgaben. Eine Kopie der internen ERP Menüs ist selten verständlich und auf dem Smartphone kaum brauchbar
5. Betrieb und Beweiskette
Protokolle, Messwerte und Supportzugänge gehören zum Produkt. Das Team muss erkennen, welche Schnittstelle langsam ist, welche Benachrichtigung nicht zugestellt wurde und wer einen kritischen Wert geändert hat. Administratoren benötigen sichere Werkzeuge zur Unterstützung, keine gemeinsamen Masterkonten
Der Data Act verändert die Datenfrage
Seit dem 12. September 2025 gilt der EU Data Act. Besonders relevant ist er für Daten aus vernetzten Produkten und verbundenen Diensten. Hersteller müssen deshalb genauer klären, welche Daten ein Produkt erzeugt, wie Nutzer darauf zugreifen und wie eine Weitergabe an Dritte technisch umgesetzt wird. Ein Serviceportal für Maschinen kann dadurch einen kontrollierten Zugang zu Betriebsdaten bereitstellen
Das verlangt eine saubere Trennung zwischen Rohdaten, abgeleiteten Erkenntnissen, Geschäftsgeheimnissen und personenbezogenen Informationen. Downloadknöpfe allein lösen diese Aufgabe nicht. Benötigt werden Datenkatalog, Zweck, Aufbewahrung, Exportformat und ein Protokoll darüber, wer welche Daten erhalten hat. Die konkrete rechtliche Einordnung gehört in fachkundige Hände; die technische Architektur muss die Entscheidungen jedoch ausführbar machen
Eine sinnvolle Reihenfolge für die erste Version
Die erste Version sollte einen Vorgang vollständig beherrschen. Bei einem Lieferantenportal kann das der Weg vom angeforderten Zertifikat bis zur fachlichen Freigabe sein. Bei einem Serviceportal vielleicht die Meldung einer Störung einschließlich Anlagendaten, Priorität und Rückmeldung
Erst wenn dieser Durchlauf messbar funktioniert, kommen weitere Rollen und Prozesse hinzu. Ein paralleler Start mit Bestellungen, Tickets, Rechnungen, Schulungen und Stammdaten erzeugt viele Oberflächen, aber keine verlässliche Kette
- ein Verantwortlicher für jeden fachlichen Datensatz
- ein dokumentierter Systemführer pro Feld
- ein erwartetes Verhalten bei jeder nicht erreichbaren Schnittstelle
- ein Berechtigungstest für jede Rolle und jeden Mandanten
- eine Betriebsansicht für Fehler, Laufzeiten und offene Arbeiten
Portaltypen sind Fachmodelle, keine Skins
Ein Lieferantenportal dreht sich um Nachweise, Freigaben und Fristen. Ein Partnerportal muss Zusammenarbeit und Zuständigkeiten abbilden. Ein Händlerportal braucht häufig Preis, Verfügbarkeit und Produktdaten im richtigen Kontext. Sie können dieselbe technische Basis teilen. Ihr fachlicher Kern bleibt verschieden
Der zuverlässigste Entwurf beginnt deshalb nicht mit dem Dashboard. Er beginnt mit Organisationen, Rechten, Ereignissen und der Frage, welches System bei einem Widerspruch recht hat