CASE STUDY.

Digitale Kundeninteraktionsplattform für eine akquisitionsgetriebene B2B-Unternehmensgruppe.

Wie ein europäischer Industriehersteller sein Gesamtportfolio digital verkaufbar macht — Zielbild, Architektur und Machbarkeitsnachweis.

MACHWERK DIGITAL — Case Study aus der Praxis der B2B-Plattformentwicklung. Technische Langfassung für die fachliche und IT-Leitungsebene; eine kompakte Management-Fassung ist separat verfügbar.

1. Executive Summary

Eine europäische Unternehmensgruppe der herstellenden Industrie, gewachsen durch organische Entwicklung und mehrere Akquisitionen, stand vor einem strukturellen Dilemma: Das Marktpotenzial des zusammengeführten Produktportfolios ließ sich digital nicht heben. Zwar existierten zwischen den Gesellschaften bereits etablierte Intercompany-Prozesse für den Austausch von Aufträgen und Daten — doch ohne vereinheitlichten Artikelstamm, mit je Gesellschaft eigener Artikelnummernlogik und getrennten Marken- und Webauftritten konservierte die Systemlandschaft die historischen Unternehmensgrenzen. Kunden begegneten nicht einer Gruppe, sondern einzelnen Gesellschaften mit jeweils eigenen Bestellwegen, Artikelnummern und Portalen.

Gemeinsam mit dem Kunden wurde ein Zielbild entwickelt und dessen Umsetzbarkeit nachgewiesen: eine Kundeninteraktionsplattform, die Website, Produktkatalog mit Bestellfunktion und einen geschlossenen Kundenbereich unter einer Domain vereint — getragen von einem zentralen Product Information Management (PIM) als führendem System für Produktdaten, einer Integrationsschicht zur losen Kopplung der heterogenen Backend-Systeme und einer Marketing-Automation-Anbindung für die systematische Gewinnung und Qualifizierung von Leads.

Das Engagement war dabei bewusst breiter angelegt als ein Technologieprojekt und deckte die gesamte Wertschöpfung des Vorhabens ab: eine markenstrategische Neupositionierung, die aus dem Nebeneinander der Einzelunternehmen eine erkennbare Unternehmensgruppe formt, sowie eine betriebswirtschaftliche Prozessanalyse, die die internen Abläufe hinter dem digitalen Vertrieb — von der Auftragsabwicklung bis zur Stammdatenorganisation — durchleuchtete und in verbindliche Soll-Prozesse überführte. Digitalisiert wurde erst, was markenseitig geklärt und prozessual geordnet war.

Die zentrale architektonische Entscheidung: Die Vereinheitlichung erfolgt vor den Backend-Systemen, nicht in ihnen. Die Gruppe muss ihre ERP-Landschaft nicht erst in einem mehrjährigen Konsolidierungsprogramm harmonisieren, um am Markt als ein Anbieter aufzutreten — die Integrationsschicht entkoppelt Kundenerlebnis und Systemlandschaft und erlaubt es, beide in unterschiedlichen Geschwindigkeiten zu entwickeln.

Sämtliche Kernkomponenten wurden vor der Investitionsentscheidung in Fachkonzepten spezifiziert und durch lauffähige Proof of Concepts validiert — einschließlich eines vollständigen technischen Durchstichs von der Produktdatensynchronisation bis zur Bestellauslösung. Das Vorhaben ging damit nicht als Hypothese, sondern als nachgewiesen umsetzbares Konzept in die Realisierung.

Diese Case Study richtet sich an Entscheider in B2B-Unternehmen mit gewachsenen Strukturen. Sie zeigt, wie sich digitale Vertriebsfähigkeit auch in heterogenen Systemlandschaften herstellen lässt — methodisch abgesichert, technologieoffen und mit kalkulierbarem Risiko.

2. Strategischer Kontext

2.1 Das Unternehmen

Gegenstand dieser Case Study ist eine Unternehmensgruppe der herstellenden Industrie mit führender Marktposition in Europa. Das Sortiment umfasst technisch erklärungsbedürftige, stark variantenbehaftete Produkte sowie zugehöriges Zubehör und produktbegleitende Dienstleistungen. Die Kundenstruktur ist dreigeteilt — Handelspartner, OEM-Kunden und industrielle Endanwender — mit jeweils mehreren beteiligten Rollen im Beschaffungsprozess, von der Konstruktion über den strategischen bis zum operativen Einkauf.

Die Gruppe ist über Jahre durch Zukäufe gewachsen. Jede Akquisition erweiterte das Portfolio und die Marktabdeckung — und brachte zugleich eine eigene Systemwelt mit: ein eigenes ERP, ein eigenes Produktdatenmodell, eine eigene Artikelnummernsystematik, einen eigenen Webauftritt.

2.2 Marktumfeld

Das Beschaffungsverhalten im B2B verändert sich strukturell. Einkäufer und technische Entscheider erwarten heute digitale Recherche-, Vergleichs- und Bestellmöglichkeiten, wie sie sie aus dem privaten Umfeld kennen — mit den zusätzlichen Anforderungen des Geschäftskundenumfelds: kundenindividuelle Konditionen, Rahmenverträge, Freigabeprozesse, belastbare Verfügbarkeits- und Lieferzeitaussagen. Anbieter, die diese Erwartungen nicht bedienen, verlieren nicht sofort Umsatz, aber kontinuierlich Relevanz: Sie finden in der digitalen Anbahnungsphase, in der ein wachsender Teil der Kaufentscheidung fällt, schlicht nicht statt.

Für akquisitionsgetriebene Gruppen verschärft sich diese Anforderung. Der strategische Wert eines Zukaufs — Cross-Selling-Potenzial, gemeinsame Kundenbasis, komplementäres Sortiment — realisiert sich nur, wenn das erweiterte Portfolio für den Kunden auch als zusammenhängendes Angebot erfahrbar wird. Bleibt die digitale Integration aus, entsteht das, was sich als Integrationsschuld bezeichnen lässt: Jeder weitere Zukauf erhöht die interne Komplexität, ohne den Marktauftritt zu stärken.

3. Ausgangssituation und Problemstellung

Die Analyse zu Projektbeginn — durchgeführt in strukturierten Workshops mit allen relevanten Fachbereichen der Gruppe — ergab ein für gewachsene B2B-Organisationen charakteristisches Bild:

Integrierte Prozesse, aber keine Integrationsfähigkeit. Das operative Geschäft lief über mehrere ERP-Systeme in den einzelnen Gesellschaften. Für das Intercompany-Geschäft existierten bereits etablierte Systemprozesse — Aufträge und Daten wurden zwischen den Gesellschaften systemgestützt ausgetauscht. Diese Kopplungen trugen jedoch nur, weil die beteiligten Systeme derselben Technologiewelt entstammten, und sie waren als bilaterale Verbindungen für definierte Anwendungsfälle konzipiert, nicht als strategische Integrationsarchitektur. Ein künftiger Zukauf mit einem ERP-System außerhalb des bisherigen Spektrums hätte sich auf diesem Weg nicht anbinden lassen, sondern jeweils individuell eingebaut werden müssen — mit entsprechendem Aufwand, Risiko und Zeitverzug je Akquisition.

Der Kern: fehlende Vereinheitlichung des Artikelstamms. Das strukturelle Zentrum des Problems lag in den Produktdaten. Jede Gesellschaft führte ihren eigenen Artikelstamm mit eigener Artikelnummernlogik; Produktstammdaten, multimediale Anhänge, Klassifikationsinformationen und Produktbeziehungen lagen verteilt über die ERP-Systeme, teils in proprietären Erweiterungen. Eine übergreifende Sicht auf das Gesamtsortiment existierte weder intern noch für Kunden. Überschneidende Sortimente führten dazu, dass faktisch identische Produkte unter verschiedenen Artikelnummern in verschiedenen Gesellschaften geführt wurden — mit unmittelbaren Folgen für Lagerhaltung, Auswertbarkeit und Kundenkommunikation. Ohne gemeinsame Artikelidentität ließ sich weder ein einheitlicher Katalog aufbauen noch das Gruppensortiment konsistent bepreisen, auswerten oder exportieren.

Fragmentierte Marke und Kundeninteraktion. Die Gesellschaften traten unter eigenen Marken mit getrennten Webauftritten und getrennten Self-Service-Funktionen auf; eine inhaltlich gefüllte gemeinsame Markenklammer existierte nicht. Kunden mit gesellschaftsübergreifendem Bedarf mussten auf mehreren Plattformen mit jeweils eigenen Zugängen bestellen. Die Bestellerfassung erfolgte überwiegend manuell und dezentral; strukturierte digitale Bestellwege existierten nur punktuell.

Die Konsequenzen dieser Fragmentierung waren betriebswirtschaftlich messbar spürbar: Prozessbrüche zwischen den Systemen erzeugten Fehleranfälligkeit und Mehraufwand, der Vertriebsinnendienst war in erheblichem Umfang mit transaktionalen Routinetätigkeiten gebunden, und das Cross-Selling-Potenzial des Gruppenportfolios blieb mangels gemeinsamer Präsentationsfläche weitgehend ungenutzt.

4. Zielbild

Auf Basis der Anforderungsaufnahme wurde ein Zielbild mit vier tragenden Elementen formuliert:

One Face to the Customer. Die gesamte Gruppe tritt unter einer Domain mit einer Plattform auf. Das vollständige Produkt- und Serviceportfolio aller Gesellschaften ist an einem Ort auffindbar, vergleichbar und — im Umfang der Standardprodukte — direkt bestellbar. Welche Gesellschaft eine Bestellung erfüllt, ist eine interne Routing-Entscheidung, keine Kundenaufgabe. Voraussetzung dafür ist eine gemeinsame Markenidentität, die die Gesellschaften glaubwürdig als eine Gruppe positioniert — der Auftritt der Plattform macht sichtbar, was markenstrategisch zuvor definiert wurde.

Digitaler End-to-End-Prozess. Bestellungen von Standardprodukten durchlaufen die Strecke von der Erfassung über die Auftragsanlage im jeweils zuständigen ERP bis zur Statusrückmeldung ohne manuelle Zwischenschritte. Für individualisierte Produkte und Angebotsanfragen (RFQ) existieren strukturierte digitale Prozesse, die in den Vertrieb übergeben, ohne Medienbrüche zu erzeugen.

Geschlossener Kundenbereich als Abbild der Geschäftsbeziehung. Registrierte Kunden erhalten in einem geschützten Bereich Zugriff auf alle Dimensionen ihrer Geschäftsbeziehung: Bestellhistorie und Auftragsstatus über alle Eingangskanäle hinweg, kundenindividuelle Produkte und Preise, Rahmenverträge einschließlich Kontingenten und Konditionen, Begleitdokumente, Zertifikate und Datenblätter, Mehrbenutzerverwaltung mit Rollen- und Freigabekonzepten sowie den direkten Zugang zu den zuständigen Ansprechpartnern. Die Anforderungen wurden dabei differenziert nach Zielgruppen und Rollen erhoben — von der technischen Fachrolle, die belastbare Detailinformationen und Nachweisdokumente benötigt, bis zum strategischen Einkäufer, der Bonusvereinbarungen und Abnahmestände einsehen will.

Systematische Marktbearbeitung. Die Plattform dient nicht nur der Bestandskundenbetreuung, sondern ist zugleich Instrument der Neukundengewinnung: Eine umfassende Marketing-Automation-Anbindung erfasst Interessenten, entwickelt sie über personalisierte Strecken und übergibt sie bei erreichter Qualifikationsstufe als Sales Qualified Lead an den Vertrieb.

5. Vorgehen: die gesamte Wertschöpfung im Blick

Ein Vorhaben dieser Tragweite ist kein Technologieprojekt mit Beratungsanteilen, sondern ein Transformationsvorhaben mit einer technologischen Komponente. Die Begleitung wurde deshalb über drei eng verzahnte Arbeitsstränge organisiert — Marke, Prozesse, Technologie —, die jeweils eigene Ergebnisse liefern und einander zuarbeiten.

5.1 Marke und Positionierung: aus Einzelunternehmen wird eine Gruppe

„One Face to the Customer“ ist zunächst keine Plattform-, sondern eine Markenfrage: Welches Gesicht soll der Kunde überhaupt sehen? Zu Projektbeginn standen gewachsene Einzelmarken mit eigener Historie, eigener Kundenbindung und eigenem Marktprofil nebeneinander — wertvoll, aber ohne gemeinsame Klammer.

In Markenworkshops mit der Führungs- und Fachebene der Gesellschaften wurden bestehende Markenwerte, Zielgruppenwahrnehmungen und Differenzierungsmerkmale systematisch aufgenommen und zu einer neuen, gemeinsamen Positionierung der Gruppe verdichtet. Auf dieser Grundlage entstanden eine Markenarchitektur, die das Verhältnis von Gruppenauftritt und etablierten Einzelmarken regelt — einschließlich des Umgangs mit deren aufgebautem Marktwert —, sowie die inhaltlichen Leitplanken für Tonalität, Botschaften und Erscheinungsbild der künftigen Plattform. Erst diese markenstrategische Arbeit macht aus der Zusammenführung von Webauftritten einen glaubwürdigen Gruppenauftritt; ohne sie hätte die Plattform die Fragmentierung lediglich unter einer Domain versammelt.

5.2 Prozesse und Organisation: die betriebswirtschaftliche Fundierung

Parallel wurde die Wertschöpfung hinter dem künftigen digitalen Vertrieb betriebswirtschaftlich durchleuchtet — bewusst über die digitalen Prozesse und die Datengrundlage hinaus. Gegenstand der Analyse waren die operativen Kernabläufe der Gesellschaften: die Auftragsabwicklung über Gesellschaftsgrenzen hinweg einschließlich des kaufmännischen Intercompany-Zusammenspiels, die Organisation und Pflegeverantwortung für Stammdaten, die Preisfindungs- und Konditionensystematik sowie die Steuerung von Vertrieb und Innendienst.

Aus dieser Prozessarbeit entstanden dokumentierte Soll-Prozesse, geklärte Verantwortlichkeiten und konkrete Harmonisierungsentscheidungen, die als verbindliche fachliche Vorgaben in die Fachkonzepte einflossen — etwa für die Pflegeprozesse im PIM, das Routing von Aufträgen zwischen den Gesellschaften oder die Freigabe- und Registrierungsprozesse im Kundenportal. Der Grundsatz dahinter: Eine Plattform digitalisiert die Prozesse, die sie vorfindet. Wer ungeordnete Abläufe digitalisiert, macht deren Schwächen nur schneller und sichtbarer. Die prozessuale Ordnung ist deshalb Vorleistung der Digitalisierung, nicht ihre Nebenwirkung.

5.3 Daten und Technologie: in drei Stufen zur nachgewiesenen Machbarkeit

Der technologische Arbeitsstrang folgt einem eigenen Prinzip: Vorhaben dieser Größenordnung scheitern selten an der Technologie — sie scheitern an ungeprüften Annahmen, die erst in der Umsetzung als Fehlannahmen sichtbar werden. Das Vorgehen wurde deshalb konsequent auf Risikoreduktion vor Investition ausgelegt:

Stufe 1 — Anforderungsaufnahme. In moderierten Workshops mit allen relevanten Stakeholdern der Gruppe wurden Ziele, Zielgruppen, funktionale und nicht-funktionale Anforderungen, Datenstrukturen und Mengengerüste systematisch erhoben. Ergebnis war ein konsolidiertes, priorisiertes Anforderungsbild über alle Gesellschaften hinweg — für viele Beteiligte die erste gruppenweite Gesamtsicht auf die eigene Produkt- und Prozesslandschaft.

Stufe 2 — Fachkonzeption. Die Anforderungen wurden in drei aufeinander abgestimmten Fachkonzepten ausgearbeitet: Product Information Management, Integrationsschicht sowie CMS und Commerce. Jedes Fachkonzept spezifiziert Datenmodelle, Prozesse, Schnittstellen und Auswahlkriterien in einer Tiefe, die eine belastbare Systemauswahl und anschließende Detailspezifikation ermöglicht — einschließlich der Modellierung von Produktfamilien und Variantendimensionen, eines Integrationsmuster-Katalogs und der vollständigen Siteflows der Plattform.

Stufe 3 — Machbarkeitsnachweis. Parallel zur Konzeption wurde jede Kernkomponente in einem Proof of Concept mit realen Daten und definierten Prüfpunkten validiert (siehe Abschnitt 7).

Dieses Zusammenspiel der drei Arbeitsstränge stellt sicher, dass die Investitionsentscheidung auf einer Grundlage getroffen wird, in der die wesentlichen markenstrategischen, prozessualen und technischen Risiken bereits ausgeräumt sind — zu einem Bruchteil der Kosten einer Umsetzung.

6. Lösungsarchitektur

6.1 Architekturprinzip: Entkopplung statt vorgelagerter Konsolidierung

Die naheliegende Antwort auf eine heterogene ERP-Landschaft ist deren Konsolidierung. Sie ist langfristig häufig auch richtig — als Voraussetzung für den digitalen Marktauftritt ist sie jedoch die falsche Reihenfolge: Ein mehrjähriges Konsolidierungsprogramm bindet Ressourcen, trägt erhebliches Risiko und verschiebt jeden kundenwirksamen Nutzen an sein Ende.

Die gewählte Architektur kehrt diese Logik um. Eine dedizierte Integrationsschicht entkoppelt die Kundeninteraktionsplattform vollständig von den Backend-Systemen. Nach außen entsteht Einheitlichkeit — ein Katalog, ein Bestellprozess, ein Kundenkonto —, während die Systemlandschaft dahinter heterogen bleiben darf und in eigenem Tempo, nach eigener Priorität konsolidiert werden kann. Beide Vorhaben werden voneinander unabhängig; keines blockiert das andere.

Daraus ergibt sich eine Zielarchitektur mit klar geschnittenen Verantwortlichkeiten:

Schicht	Verantwortung
Kundeninteraktionsplattform	Kundenerlebnis: Content, Katalog, Commerce, Kundenkonto — als Headless-Architektur API-first ausgelegt
Integrationsschicht	Entkopplung, Orchestrierung und Transformation aller Datenflüsse; dedizierte Services für echtzeitkritische Daten
PIM	Führendes System für harmonisierte, qualitätsgesicherte Produktdaten der gesamten Gruppe
Backend-Systeme	Auftragsabwicklung, Warenwirtschaft, Preisfindung in den ERP-Systemen der Gesellschaften — unverändert

6.2 Product Information Management: die Datenbasis des Vertriebs

Im digitalen B2B-Vertrieb übernehmen Produktdaten die Funktion, die im persönlichen Vertrieb das Beratungsgespräch erfüllt: Sie müssen die Auswahlentscheidung des Kunden vollständig tragen — von der Identifikation des passenden Produkts über die Variantenauswahl bis zur Kompatibilität von Zubehör. Das PIM-Fachkonzept adressierte deshalb zunächst die fachliche Modellierung, nicht die Systemfrage:

Produktfamilien und Variantendimensionen. Das Sortiment wurde entlang seiner Datenstrukturen in Produktfamilien gegliedert und je Familie wurden die variantenbildenden Dimensionen präzise definiert — einschließlich der Abgrenzung von konfigurierbaren Parametern (etwa kundenspezifischen Besonderheiten), die bewusst keine eigenen Artikel erzeugen. Diese Modellierung ist die Voraussetzung für geführte Produktauswahl, sauberes Variantenmanagement und automatisierbare Prozesse.
Je Produktfamilie wurden die technischen und vertrieblichen Merkmale mit Datentyp, Pflichtstatus, Lokalisierbarkeit und Exportrelevanz spezifiziert — die Grundlage für Facettensuche, Vergleichbarkeit, Datenblattgenerierung und standardisierte Katalogexporte für Handelspartner, etwa im BMEcat-Format.
Parallele Klassifikationen. Das Konzept trennt eine interne Stammdatenklassifikation (eindeutige Zuordnung, konsistente Verwaltung) von marktorientierten Vertriebsklassifikationen (Mehrfachzuordnung, kanalspezifische Perspektiven) und hält die Anbindung an Branchenstandards für den elektronischen Katalogaustausch offen.
Zubehör- und Kompatibilitätsbeziehungen werden auf Variantenebene modelliert, sodass das Wissen „welches Zubehör passt zu welcher Ausführung“ im Datenmodell selbst verankert ist — ergänzt um Ersatz-, Nachfolger- und Cross-Selling-Relationen.
Übergeordnete Artikelidentität. Eine synthetische, gruppenweite SKU führt Sortimentsüberschneidungen zwischen den Gesellschaften zusammen: Identische Produkte unterschiedlicher Herkunft werden als ein Produkt erkennbar — für Kunden wie für Bestandsführung und Analytik.

Im Zielbild fungiert das PIM darüber hinaus als Quality Gateway: Produktdaten aus den ERP-Systemen genügen den Anforderungen einer Kundenplattform in aller Regel nicht unmittelbar. Erst Datensätze, die definierte Vollständigkeits- und Qualitätskriterien erfüllen, werden an die Plattform publiziert. Perspektivisch unterstützt das System zudem einen PIM-First-Ansatz in der Produktentwicklung, bei dem neue Produkte von Beginn an strukturiert im PIM entstehen und der ERP-Stammsatz am Ende des Entwicklungsprozesses aus bereits gepflegten Daten erzeugt wird.

6.3 Integrationsschicht: Entkopplung als Systemleistung

Die Integrationsschicht wurde nicht als Sammlung von Schnittstellen konzipiert, sondern als eigenständige Architekturkomponente mit definierten Prinzipien: lose Kopplung, Information Hiding, stabile Schnittstellenkontrakte, Resilienz. Die Umsetzung folgt einem API-First-Ansatz und einem Integrationsmuster-Katalog, der für jeden Schnittstellentyp — Publish/Subscribe, Queue-basierte Punkt-zu-Punkt-Kommunikation, Request/Reply, Callback, Managed File Transfer, Massendatenprozesse — ein verbindliches, technologieagnostisches Muster definiert. Neue Schnittstellen werden damit nicht individuell entworfen, sondern aus erprobten Mustern abgeleitet — ein wesentlicher Hebel für Wartbarkeit und Erweiterbarkeit.

Für jeden relevanten Datenkörper wurde der Datenfluss durchgängig konzipiert, jeweils mit zwei komplementären Verfahren: ereignisbasierte Synchronisation für den laufenden Abgleich einzelner Änderungen und Massendatenprozesse für Initialladungen und periodische Vollabgleiche.

Zwei Datenkörper erhielten aufgrund ihrer Geschäftskritikalität dedizierte Services innerhalb der Integrationsschicht:

Bestandsdaten sind Bewegungsdaten mit hoher Änderungsfrequenz; ihre Aktualität entscheidet über die Belastbarkeit von Lieferaussagen. Ein Bestandsservice hält die Verfügbarkeiten aller Gesellschaften echtzeitnah synchronisiert und zwischengespeichert vor und stellt sie der Plattform über eine performante API bereit.
Preisdaten sind im B2B kundenindividuell und ergeben sich im ERP aus komplexen Findungslogiken. Ein Preisservice überbrückt diese Lücke über kombinierbare Verfahren — von der ereignisgesteuerten Vorberechnung bis zur bedarfsorientierten Ermittlung — und macht individuelle Konditionen im Frontend darstellbar, ohne dass die Plattform je direkt auf ein ERP durchgreift.

Diese Entkopplung hat eine operative Konsequenz von erheblichem Wert: Die Plattform bleibt auskunfts- und annahmefähig, auch wenn ein Backend-System temporär nicht verfügbar ist. Der Auftragsfluss selbst ist bidirektional konzipiert — Bestellungen und Angebotsanfragen fließen strukturiert in die zuständigen ERP-Systeme, Statusänderungen, Lieferinformationen und Auftragsanpassungen fließen zurück in die Kundensicht.

6.4 Kundeninteraktionsplattform: CMS und Commerce als Headless-Verbund

Für die Plattform selbst wurde eine Kombination aus Headless-Content-Management-System und Headless-Commerce-Engine auf Basis etablierter Open-Source-Technologien konzipiert und im Machbarkeitsnachweis validiert. Die Entscheidung für diesen Architekturstil beruht auf drei Erwägungen:

Trennung von Inhalt und Ausspielung. Content und Commerce-Funktionen stehen über APIs jedem Ausgabekanal zur Verfügung — der Website heute, weiteren Touchpoints und der direkten Anbindung von Kundensystemen morgen. Die Omnichannel-Fähigkeit ist damit architektonisch angelegt, nicht nachträglich anzubauen.
Funktionale Reife im Standard. Mehrsprachigkeit und Multi-Site-Fähigkeit, differenzierte Rechte- und Rollenmodelle, Produktvarianten- und Taxonomieverwaltung, kundenindividuelle Preislogiken und Bestandsführung aus mehreren Quellen sind im Standard der evaluierten Systeme abgedeckt — projektspezifische Entwicklung konzentriert sich auf die tatsächlich differenzierenden Funktionen.
Souveränität. Der Open-Source-Ansatz vermeidet Lizenzkostenrisiken und Vendor-Lock-in; die Architektur bleibt im Eigentum und unter Kontrolle des Unternehmens.

Der funktionale Umfang wurde entlang vollständiger Siteflows spezifiziert — vom Catalog Browsing über Checkout und Order Approval bis zur Organisations- und Benutzerverwaltung auf Kundenseite. Hervorzuheben sind die B2B-spezifischen Prozesse, die über den Standard eines Webshops hinausgehen:

Differenzierter Bestellprozess. Standardprodukte mit gesicherter Verfügbarkeit sind vollautomatisiert bestellbar, inklusive transparenter Lieferzeitlogik auch bei Teilverfügbarkeiten. Individualisierte Produkte münden in strukturierte, systemgestützte Anfrage- und Angebotsprozesse (RFQ/CPQ) mit direkter Vertriebseinbindung auf der Plattform.
Kanalübergreifende Auftragssicht. Auch Aufträge, die per E-Mail oder telefonisch eingehen und vom Innendienst erfasst werden, erscheinen im Kundenportal und sind dort statusverfolgbar. Der Kunde profitiert vom Portal, ohne sein Bestellverhalten ändern zu müssen — ein zentraler Faktor für die Adoption der Plattform.
Order on Behalf. Vertriebsmitarbeiter können Warenkörbe und Bestellungen im Namen des Kunden anlegen; die Vorgänge erscheinen im Kundenkonto, als hätte der Kunde sie selbst ausgelöst. Beratung und Self-Service greifen ineinander, statt zu konkurrieren.
Registrierung mit Selbstverifizierung. Bestandskunden schalten sich anhand vorhandener Geschäftsdaten eigenständig frei; Neukunden durchlaufen einen definierten Prüf- und Freigabeprozess bis zur Debitorenanlage.

Ergänzend wurden nicht-funktionale Anforderungen — Ladezeiten, Skalierbarkeit, Verfügbarkeitsziele, Sicherheitsstandards einschließlich Mehr-Faktor-Authentifizierung, Barrierefreiheit — verbindlich spezifiziert. Das Betriebskonzept setzt auf containerisierte Cloud-Infrastruktur mit CI/CD-Pipeline; der kalkulierte laufende Betreuungsaufwand liegt deutlich unter einer Vollzeitstelle.

6.5 Marketing Automation: von der Reichweite zum qualifizierten Lead

Die Plattform wurde von Beginn an als Instrument der Marktbearbeitung konzipiert, nicht allein als Transaktionskanal. Fachinhalte, Anwendungswissen und interaktive Werkzeuge — insbesondere ein geführter Produktfinder, der von Anwendungsparametern zu passenden Produkten und kompatiblem Zubehör führt — erzeugen qualifizierten Traffic. Strukturierte Formulare und Anfrageprozesse überführen anonymes Interesse in identifizierte Kontakte.

Die angebundene Marketing Automation entwickelt diese Kontakte über personalisierte Strecken entlang definierter Reifegrade weiter. Erreicht ein Lead die Qualifikationsschwelle zum Sales Qualified Lead, erfolgt die Übergabe an den Vertrieb — mit vollständiger Interaktionshistorie. Für das Händlergeschäft wurde zusätzlich die Verteilung und Nachverfolgung von Leads an Handelspartner konzipiert, einschließlich der Auswertbarkeit von Konversionsraten je Partner. Der Vertriebstrichter wird damit über seine gesamte Länge messbar und steuerbar.

7. Machbarkeitsnachweis

Jede der drei Kernkomponenten wurde vor der Umsetzungsentscheidung in einem eigenständigen Proof of Concept mit definierten Prüfpunkten validiert:

PIM. Nach einer strukturierten Evaluation mehrerer Systeme wurde der favorisierte Kandidat mit realen Produktdaten des Unternehmens getestet — einschließlich komplexer Eltern-Kind-Variantenstrukturen mit Stammdatenvererbung, einem Merkmalskatalog im dreistelligen Umfang mit mehreren tausend gepflegten Ausprägungen sowie Klassifikations- und Dokumentenzuordnung. Geprüft wurden unter anderem Datenimport über Dateischnittstellen und API, Verhalten unter größeren Datenmengen, Flexibilität des Datenmodells und Exportfähigkeit. Alle Prüfpunkte wurden positiv abgeschlossen.

Integrationsschicht. In einer containerisierten Testumgebung wurde das Zusammenspiel der drei Bausteine Message-orientierte Middleware, Scheduling und grafische Workflow-Automatisierung nachgewiesen: Bereitstellung und Konsum eigener API-Endpunkte, Ansprache externer Schnittstellen sowie das Schreiben und ereignisgesteuerte Auslesen von Nachrichten über Queues — die tragenden Muster für sämtliche konzipierten Datenflüsse.

CMS und Commerce. Der umfangreichste Nachweis: ein vollständiger technischer Durchstich über die Zielarchitektur. Produktdaten wurden über eine Middleware kontinuierlich aus der Commerce-Engine in das CMS synchronisiert und dort ausgespielt; Preis- und Verfügbarkeitsprüfung, Warenkorbanlage und Bestellauslösung liefen über die APIs der Commerce-Engine bis zur Übergabe der Order in Richtung Auftragsverarbeitung. Damit war die kritischste Annahme des Gesamtvorhabens — das reibungslose Zusammenspiel der Plattformkomponenten über die vorgesehenen Schnittstellen — praktisch belegt.

Das Ergebnis dieser Stufe lässt sich präzise fassen: Zum Zeitpunkt der Investitionsentscheidung war keine tragende Architekturannahme mehr unbewiesen. Das verbleibende Projektrisiko lag in Umsetzungsqualität und Change Management — nicht mehr in der Frage, ob das Konzept trägt.

8. Wirkungsmodell: Beitrag der Plattform zum Wachstum

Die Case Study beschreibt ein Vorhaben in der Konzeptions- und Validierungsphase; belastbare Ex-post-Kennzahlen liegen naturgemäß noch nicht vor. Das Wirkungsmodell der Plattform lässt sich gleichwohl präzise entlang der adressierten Engpässe herleiten:

Erschließung des Portfolio-Potenzials. Der originäre strategische Zweck der Zukäufe — ein breiteres Angebot für eine gemeinsame Kundenbasis — wird erst realisierbar, wenn das Gesamtsortiment gemeinsam auffindbar, vergleichbar und bestellbar ist. Kuratierte Zubehör-, Ersatz- und Cross-Selling-Beziehungen im Produktdatenmodell übersetzen Sortimentsbreite systematisch in Warenkorbtiefe.

Skalierung ohne proportionalen Personalaufbau. Jeder Vorgang, der vom Innendienst auf den Self-Service verlagert wird — Bestellungen, Statusabfragen, Dokumentenabrufe, Datenblatterstellung —, senkt die Transaktionskosten je Auftrag und setzt Kapazität für beratungsintensive, margenrelevante Vorgänge frei. Die Vertriebsorganisation wächst nicht mit dem Auftragsvolumen, sondern mit der Komplexität des Geschäfts.

Planbares Neugeschäft. Mit der Marketing-Automation-Strecke wird Leadgenerierung von der Einzelinitiative zur messbaren Systemleistung: Reichweite, Konversion und Qualifizierung sind entlang des gesamten Trichters instrumentiert und optimierbar — bis hin zur Lead-Verteilung an Handelspartner.

Kundenbindung über Wechselkosten im positiven Sinne. Ein Portal, das Rahmenverträge, individuelle Konditionen, vollständige Auftragshistorie und technische Dokumentation an einem Ort bündelt, wird Teil der Arbeitsroutine des Kunden. Diese Integration in den Beschaffungsalltag ist im B2B ein wirksamerer Bindungsmechanismus als jedes Rabattprogramm.

Akquisitionsfähigkeit als Architektureigenschaft. Die Integrationsschicht verändert die Ökonomie künftiger Zukäufe: Neue Gesellschaften werden angebunden, nicht eingebaut — unabhängig davon, welches ERP-System sie mitbringen. Die digitale Eingliederung ist kein individuelles Integrationsprojekt mehr, sondern ein definierter Onboarding-Prozess: Anbindung des ERP über den Integrationsmuster-Katalog, Überführung der Produktdaten in das PIM mit Zuordnung zur gruppenweiten Artikelidentität, Freischaltung im gemeinsamen Katalog. Buy-and-Build-Strategie und konsistenter Marktauftritt schließen einander nicht länger aus.

9. Erfolgsfaktoren und Übertragbarkeit

Aus dem Projekt lassen sich sechs verallgemeinerbare Erkenntnisse für B2B-Unternehmen in vergleichbarer Lage ableiten:

Produktdaten sind das Fundament, nicht das Frontend. Die Qualität einer B2B-Plattform wird in der Daten- und Prozessarchitektur entschieden. Ein PIM mit sauberer Varianten- und Beziehungsmodellierung ist Voraussetzung — nicht Begleiterscheinung — jeder ernsthaften Commerce-Initiative.
Entkopplung schlägt vorgelagerte Konsolidierung. Eine Integrationsschicht liefert das einheitliche Kundenerlebnis um Jahre früher als eine ERP-Harmonisierung und nimmt dieser zugleich den Zeitdruck. Die Reihenfolge „erst Backend, dann Markt“ ist in den meisten Fällen eine unnötig teure Selbstblockade.
Echtzeitkritische Daten verdienen dedizierte Services. Verfügbarkeits- und Preisauskünfte entscheiden im B2B über die Glaubwürdigkeit des Kanals. Sie gehören in resiliente, zwischengespeicherte Services — nicht in synchrone Direktzugriffe auf Backend-Systeme.
Machbarkeit ist beweisbar — vor der Investition. Die Kombination aus Fachkonzepten mit Entscheidungstiefe und lauffähigen Proof of Concepts räumt die wesentlichen Risiken zu einem Bruchteil der Umsetzungskosten aus. Investitionsentscheidungen dieser Größenordnung sollten auf Nachweisen beruhen, nicht auf Anbieterversprechen.
Adoption ist eine Architekturfrage. Funktionen wie die kanalübergreifende Auftragssicht und Order on Behalf holen Kunden und Vertrieb in ihren bestehenden Arbeitsweisen ab, statt Verhaltensänderung zur Nutzungsvoraussetzung zu machen. Plattformen scheitern seltener an fehlenden Funktionen als an fehlender Nutzung.
Marke, Prozesse und Technologie sind ein Vorhaben. Eine Kundeninteraktionsplattform macht sichtbar, wie ein Unternehmen auftritt und wie es arbeitet. Sind Markenbild oder interne Abläufe ungeklärt, digitalisiert sie deren Widersprüche. Markenstrategische Arbeit und betriebswirtschaftliche Prozessberatung gehören deshalb in den Projektumfang — als Vorleistung der Technik, nicht als deren Nachsorge.

10. Fazit

Die verbreitete Annahme, ein einheitlicher digitaler Marktauftritt setze eine vorherige Vereinheitlichung der Systemlandschaft voraus, hält der architektonischen Prüfung nicht stand. Mit einem zentralen PIM, einer prinzipiengeleiteten Integrationsschicht und einer Headless-Plattform lässt sich das Kundenerlebnis von der historisch gewachsenen Systemwelt entkoppeln — nachweisbar, mit beherrschbarem Risiko und auf einer Technologiebasis, die dem Unternehmen gehört.

Für die betrachtete Unternehmensgruppe bedeutet das: Der Weg vom fragmentierten Nebeneinander der Gesellschaften zum gemeinsamen digitalen Vertriebskanal ist keine Frage der technischen Machbarkeit mehr. Sie ist erwiesen. Was bleibt, ist konsequente Umsetzung — auf einem Fundament, das künftiges Wachstum, organisch wie anorganisch, bereits eingeplant hat.

Über MACHWERK DIGITAL

MACHWERK DIGITAL begleitet B2B-Unternehmen entlang der gesamten Wertschöpfung digitaler Vertriebsmodelle — von Markenworkshop, Markenentwicklung und Positionierung über die betriebswirtschaftliche Analyse und Neuordnung der zugrunde liegenden Prozesse bis zu Fachkonzept, Machbarkeitsnachweis und Implementierung von PIM, Integrationsarchitektur und Kundeninteraktionsplattform. Strategie, Marke, Prozesse und Technologie aus einer Hand — methodisch fundiert, technologieoffen und mit einem klaren Anspruch: Investitionsentscheidungen auf Basis nachgewiesener Machbarkeit, nicht auf Basis von Anbieterversprechen.

Kontakt: Sprechen Sie mit uns darüber, wie ein Machbarkeitsnachweis für Ihr Szenario aussehen kann.

DER ERSTE SCHRITT IST DER WICHTIGSTE.

Wir schauen uns Ihre Systemlandschaft an und sagen Ihnen, wo der größte Hebel liegt.