Fragen Sie jeden, der schon einmal versucht hat, gemeinsam mit einem Geschwisterteil ein Haus zu kaufen, eine Rechnung mit einer Gruppe von Freunden zu teilen oder herauszufinden, wer in einem Familienunternehmen eigentlich das Sagen hat – und jeder wird Ihnen dasselbe sagen: Beziehungen sind kompliziert. Ein und dieselbe Person kann sowohl Ihr Geschäftspartner als auch Ihr Schwager sein. Dein Vermieter könnte auch dein Kunde sein. Dein größter Konkurrent auf einem Markt könnte auf einem anderen Markt dein wichtigster Vertriebspartner sein.
Unternehmen haben genau dasselbe Problem, nur in weitaus größerem Maßstab. In der Unternehmenssoftware haben wir einen Namen dafür: Geschäftsbeziehungen mit mehreren Rollen. Und es ist eines der schwierigsten und am häufigsten unterschätzten Probleme im Stammdatenmanagement.
Dasselbe Unternehmen in verschiedenen Rollen
Hier ist ein Szenario, das sich täglich in großen Unternehmen abspielt: Ein Distributor kauft Fertigwaren bei Ihnen ein und beliefert Sie gleichzeitig mit Rohstoffen. Ein einzelner Auftrag kann von der Zentrale erteilt, an ein regionales Lager versandt, einem Shared-Services-Center in Rechnung gestellt und von einer völlig anderen Einheit innerhalb des Konzerns bezahlt werden. Alle vier dieser Parteien sind legitim, korrekt und müssen möglicherweise unterschiedlich behandelt werden: Kreditbedingungen für die eine, Lieferfenster für die andere, Zahlungsbedingungen für eine dritte.
Die meisten Systeme wurden nicht für diesen Fall entwickelt. Ein Customer-Relationship-Management-Tool (CRM) geht davon aus, dass ein Unternehmen ein Kunde ist. Der Lieferantenstamm eines Enterprise-Resource-Planning-Systems (ERP) geht davon aus, dass ein Unternehmen ein Lieferant ist. Wenn dieselbe juristische Person beides sein muss, reagieren die meisten Plattformen darauf, indem sie zwei voneinander getrennte Datensätze anlegen – einen für jede Rolle – und hoffen, dass niemand sie jemals abgleichen muss.
Doch irgendwann muss es jemand tun, denn kein noch so sorgfältiger Dateneingabeprozess kann ein architektonisches Problem beheben.
Warum Organisationen so viel schwieriger sind als Einzelpersonen
Eine Person kann in der Regel nur eine begrenzte Anzahl von Rollen gleichzeitig ausfüllen. Eine Organisation kennt keine solche Grenze, und genau hier hört dieses Problem auf, ein Sonderfall zu sein, und wird zur Regel.
Eine einzige juristische Person kann über fünf Vertriebsgebiete verkaufen, von denen jedes seine eigenen Preise und Konditionen hat. Sie kann in jeder Rechtsordnung, in der sie tätig ist, unterschiedlich besteuert werden und unterliegt dort jeweils unterschiedlichen regulatorischen Rahmenbedingungen. In Ihren Systemen könnte sie in einer Transaktion als Auftraggeber, in einer anderen als Empfänger, in einer dritten als Rechnungsempfänger und in einer vierten als Zahler erscheinen: manchmal alle vier in derselben Bestellung, manchmal auf vier verschiedene Unternehmen innerhalb derselben Unternehmensgruppe verteilt. Fügt man nun noch mehrere Marken, einige Übernahmen und ein paar regionale ERP-Systeme hinzu, wird aus dem, was ursprünglich als „ein Kunde“ begann, ein Geflecht aus Rollen und Beziehungen, das niemand im Unternehmen vollständig überblicken kann, geschweige denn manuell steuern.
Genau hier wird es schnell unübersichtlich – nicht, weil jemand etwas falsch gemacht hat, sondern weil die Komplexität real ist und die meisten Plattformen nie dafür konzipiert wurden, sie als Komplexität abzubilden. Sie wurden dafür konzipiert, sie als „Rauschen“ abzubilden, das später bereinigt werden sollte. Später wird es jedoch nie ganz bereinigt.
Zwei verschiedene Arten von „Rollen“ – und warum der Unterschied wichtig ist
Um dies zu entwirren, muss man zunächst erkennen, dass „Rolle“ eigentlich zwei verschiedene Dinge bedeutet, und genau diese Vermischung ist der Grund, warum die meisten Datenmodelle still und leise versagen.
Die Geschäftspartnerrolle beantwortet folgende Frage: Was ist diese Entität? Ein Unternehmen kann gleichzeitig mehrere dieser Rollen einnehmen: Es kann im selben Datensatz und im selben System gleichzeitig Kunde und Lieferant sein. Dies ist das klassische Problem der Geschäftspartner mit mehreren Rollen, und es handelt sich dabei um eine Klassifizierungsfrage: An welchen Geschäftsfunktionen und Transaktionen darf diese Entität teilnehmen?
Die Interaktionsrolle beantwortet eine völlig andere Frage: In welcher Funktion agiert diese Entität gegenüber einer anderen spezifischen Entität bei dieser Transaktion? Hier kommen „Lieferadresse“, „Rechnungsadresse“, „Auftraggeber“ und „Zahler“ ins Spiel. Ein einzelnes Unternehmen kann innerhalb eines einzigen Auftrags mehrere Interaktionsrollen einnehmen, und die Entität, die eine Rolle erfüllt, ist oft nicht dieselbe, die eine andere Rolle erfüllt. Entscheidend ist, dass diese Beziehungen validiert und nicht nur erfasst werden müssen. Wenn eine „Versand-an“-Rolle eine „Zahler“-Rolle am anderen Ende der Beziehung erfordert, muss dies bereits bei der Erstellung der Beziehung durchgesetzt werden und darf nicht erst drei Wochen später bei einem Abstimmungsbericht festgestellt werden.
Die meisten Anbieter vermischen diese beiden Konzepte zu einem pauschalen Begriff von „Rolle“ und hoffen, dass der Unterschied keine Rolle spielt. Er spielt jedoch immer eine Rolle. Bei dem einen geht es darum, was eine Einheit ist; bei dem anderen darum, was sie gerade tut und für wen.
Wer darf was sehen?
Die Komplexität beschränkt sich nicht darauf, zu wissen, welche Rollen eine Partei innehat. Sobald ein Unternehmen über Händler, Franchise-Nehmer oder ein Netzwerk regionaler Partner operiert, taucht direkt im Anschluss an die erste Frage eine zweite auf: Wer darf dies einsehen, und wer darf es ändern?
Ein großes Vertriebsnetzwerk kann Dutzende von Partnerunternehmen umfassen, von denen jedes seinen eigenen Kreis an Geschäftspartnern verwaltet, wobei einige dieser Geschäftspartner von zwei oder mehr Partnerunternehmen gemeinsam genutzt werden, die denselben Kunden in verschiedenen Ländern betreuen. Daraus ergeben sich zwei unterschiedliche Anforderungen.
Erstens: Sicherheit. Eine Tochtergesellschaft sollte grundsätzlich nur die Geschäftspartner einsehen können, für die sie autorisiert ist, und verschiedene Benutzer benötigen möglicherweise unterschiedliche Zugriffsebenen auf verschiedene Bereiche desselben Datensatzes. Jemand, der die Vertriebsdaten eines Kunden verwaltet, hat möglicherweise keinen Grund, dessen Finanzdaten zu bearbeiten, und manche Benutzer sollten nur die Möglichkeit haben, Daten zu prüfen und zu genehmigen, nicht aber, etwas anzulegen oder zu ändern.
Zweitens: der Umfang. Ein verbundenes Unternehmen muss sowohl die Stammdaten einsehen können, die tatsächlich unternehmensweit gemeinsam genutzt werden – wobei sich der rechtliche Name und die Umsatzsteuer-Identifikationsnummer eines Unternehmens nicht je nach Betrachter ändern –, als auch die Daten, die bewusst lokal für das jeweilige Unternehmen bestimmt sind, wobei ein gemeinsames Feld legitimerweise von einem verbundenen Unternehmen zum nächsten unterschiedliche Werte enthalten kann.
Beides ist für ein Unternehmen dieser Struktur kein „nettes Extra“. Wer hier einen Fehler macht, legt entweder Daten offen, die eine Tochtergesellschaft nicht sehen sollte, oder zwingt jede Tochtergesellschaft in ein Einheitsfeld, das niemandem wirklich passt.
Die ehrliche Antwort lautet: STEP, unsere bewährte Intelligence-Plattform, verfügt über die Flexibilität und die Governance-Mechanismen, um dieses Problem ordnungsgemäß zu lösen – Sicherheit auf Knotenebene, domänenbezogene Rollen, Zugriff nur mit Genehmigung und kontextbezogene Attributverwaltung sind allesamt native Funktionen und keine Behelfslösungen. Wie genau diese konfiguriert werden – welche Partner-Struktur, welche Datendomänen, welche Genehmigungsketten – ist ein Gespräch, das es wert ist, direkt geführt zu werden, denn diese Konfiguration sollte der tatsächlichen Arbeitsweise Ihres Unternehmens entsprechen und nicht einer generischen Vorlage.
Wenn Sie auf SAP S/4HANA umsteigen, kommen Sie daran nicht vorbei
Für jedes Unternehmen, das auf SAP S/4HANA umstellt, ist dies keine theoretische Frage der Datenmodellierung mehr, sondern eine zwingende Entwurfsentscheidung. S/4HANA vereint das Kunden- und Lieferantenmanagement in einem einzigen Geschäftspartner-Konstrukt (BP): eine Entität, eine oder mehrere BP-Rollen, zentral verwaltet. Wenn Ihre bestehenden Stammdaten auf separaten, voneinander getrennten Kunden- und Lieferantendatensätzen basieren, muss diese Abstimmung vor oder während der Migration erfolgen. Das lässt sich nicht einfach ignorieren.
Genau darauf ist STEP ausgelegt. STEP unterstützt das SAP-Geschäftspartner-Datenmodell nativ, einschließlich Geschäftspartnerrollen, Partnerfunktionen und Geschäftspartnerbeziehungskategorien, sodass Unternehmen, die auf S/4HANA umsteigen, nicht gezwungen sind, sich zwischen der Anpassung an das SAP-Modell und der Beibehaltung der Stammdaten-Governance zu entscheiden, auf die sie sich bereits verlassen. Ob der richtige Ansatz für Ihr Unternehmen ein einziges, einheitliches Geschäftspartnerobjekt oder separate Objekttypen für Kunden, Lieferanten und Ansprechpartner ist, ist selbst eine Governance-Entscheidung, keine Einschränkung – und STEP ist so konzipiert, dass es beide Varianten unterstützt. Wenn Sie technische Details zur Umsetzung wünschen, finden Sie diese umfassend in unserer Dokumentation.
Warum dies heute wichtiger ist als früher
Jahrelang war dies ein Problem der Datenqualität: lästig, aber mit ausreichend manueller Bereinigung zu bewältigen. Das ändert sich derzeit rasant.
KI-Agenten führen keine manuelle Bereinigung durch. Ein Agent, der eine Lieferkette optimieren, einen Rechnungsstreit klären oder ein Compliance-Risiko kennzeichnen soll, muss Beziehungen durchlaufen, um sie zu analysieren – was eine erhebliche Weiterentwicklung gegenüber der bloßen Bereinigung von Datensätzen darstellt. Er muss wissen, welche Entität tatsächlich für diese Rechnung verantwortlich ist, welches Lager tatsächlich die Lieferadresse für diese Bestellung ist und welche Tochtergesellschaft tatsächlich die Vertragspartei in diesem Vertrag ist. Wenn diese Beziehungen nicht aussagekräftig modelliert sind, arbeitet ein KI-Agent mit einer Karte, auf der zwar alle Orte markiert sind, aber keine Straßen eingezeichnet sind.
Das ist der Gedanke hinter dem semantischen Datengrafen von STEP und unserem MCP-Server: Stammdaten, die die geregelten, typisierten Beziehungen zwischen den vorhandenen Entitäten speichern und den KI-Agenten als Grundlage für Schlussfolgerungen zur Verfügung stehen – nicht nur als Nachschlagetabelle.
Das Fazit
Beziehungen waren schon immer kompliziert. Was sich geändert hat, ist, wie sehr es mittlerweile darauf ankommt, sie richtig zu verstehen, und wie schnell sich die Kosten eines Fehlers bemerkbar machen – sei es eine an den falschen Empfänger versandte Sendung oder ein KI-Agent, der selbstbewusst auf der Grundlage einer Beziehung handelt, die eigentlich nie gültig war.
Stammdaten, die nur wissen, was ein Unternehmen ist, waren von vornherein unvollständig. Die Unternehmen, die dieses Problem heute lösen, sind diejenigen, die in Stammdaten investieren, die auch wissen, was ein Unternehmen tut: in jeder Geschäftspartnerrolle, die es innehat, jeder Interaktionsrolle, die es spielt, und jeder Beziehung, die diese miteinander verbindet.
