SAP BRIM hat den Ruf, komplex zu sein. In Wirklichkeit ist es flexibel, manchmal bis zu dem Punkt, an dem es zu viele gültige Konfigurationspfade gibt. Die Komplexität liegt normalerweise nicht im Werkzeug selbst, sondern in den Designentscheidungen, die darum herum getroffen werden.
Die meisten Unternehmen implementieren BRIM, um ein drängendes Problem zu lösen (z. B. Umsatzverluste, manuelle Abrechnung, Skalierung von Abonnementmodellen). Schnelligkeit scheint entscheidend zu sein, aber 12 Monate später überarbeiten sie die Preislogik, Ereignisstrukturen oder Integrationsmuster, die sie als „gut genug“ erachteten.
Das liegt nicht daran, dass BRIM defekt ist. Es liegt daran, dass BRIM architektonische Entscheidungen erzwingt, die sich nach der Inbetriebnahme nur schwer rückgängig machen lassen.
Im Video unten vergleicht Chief Revenue Architect von CLARITY, Nitish Puttur, BRIM mit einer Lupe. Sie schafft keine Komplexität, aber sie deckt strukturelle Probleme in Ihrem Order-to-Cash-Modell auf, die zuvor verborgen waren. Dieser Artikel beleuchtet die praktischen Gründe für diese Analogie und was dagegen getan werden kann.
Die drei Hauptursachen für die Komplexität der SAP BRIM-Implementierung
Sieht man einmal von der Oberfläche ab, wird die SAP BRIM-Implementierung meist durch dieselben zugrunde liegenden Muster bestimmt. BRIM schafft diese Probleme nicht. Dort werden sie unmöglich zu verbergen, weil es im Herzen des Order-to-Cash-Flusses sitzt.
1) Teams entwerfen lokal ohne durchgängige Abstimmung
Auch mit einer sauberen Architektur können BRIM-Projekte schwierig werden, wenn Teams die Umgebung nur innerhalb ihrer eigenen operativen Blase optimieren.
Der Finanzbereich legt natürlich Wert auf Compliance und Prüfbarkeit. Der Vertrieb legt Wert auf Schnelligkeit, Flexibilität und den Abschluss von Geschäften. Die IT kümmert sich um Stabilität und Risikominimierung. Jede dieser Ansichten ist isoliert betrachtet sinnvoll, doch BRIM verbindet sie – und genau hier beginnen die Probleme.
Ein gängiges Muster ist der Versuch, die traditionelle Verkaufsauftragslogik in einem ereignisbasierten Abrechnungsmodell nachzubilden. BRIM aggregiert nicht alles in einem einzigen „Dokument“, so wie es klassische ERP-Vertriebsmodule tun. Es verarbeitet und gruppiert Ereignisse zu abrechenbaren Ergebnissen. BRIM so zu gestalten, als wäre es ein Verkaufsauftragssystem, ist einer der schnellsten Wege, unnötige Komplexität einzuführen.
In der Praxis kann die lokale Optimierung auf verschiedene bekannte Weisen zu globaler Komplexität führen:
- Ein Preismodell, das sich kaufmännisch perfekt anfühlt, schafft Ausnahmen bei der Rechnungsstellung, die das Finanzteam nicht einfach verwalten kann
- Ein Arbeitsablauf, der den Vertrieb schnell voranbringt, führt zu Variationen, die sich schwer testen oder abstimmen lassen nachgelagert
- Ein technisch elegantes Integrationsmuster erhöht den Betriebsaufwand und verlangsamt Änderungen, sobald das System in Betrieb ist
Deshalb profitiert BRIM von einer Ownership auf Architekturebene, nicht nur von Projektmanagement. Jemand muss den gesamten Bauplan vereinheitlichen, damit die Entscheidungen jedes Teams End-to-End zusammenwirken, anstatt eine Sammlung isolierter Lösungen zu produzieren, die technisch “korrekt”, aber operativ inkompatibel sind.
2) Designentscheidungen, die ohne eine zukünftige Vision getroffen wurden
Ein Hauptgrund, warum sich BRIM zu komplex anfühlen kann, ist, dass es mehrere Wege bietet, um dasselbe Ergebnis zu erzielen. Teams wählen natürlich die Option, die am besten zu den aktuellen Anforderungen, dem Budget und den Zeitplänen passt.
Aber wie Nitish sagte, könnte ein Medienkunde heute eine Million Kunden in einer Region bedienen, was eine kostengünstige Designentscheidung vollkommen gültig macht. Wenn das Geschäft aber in den nächsten 6–12 Monaten auf zehn Millionen Kunden in mehreren Regionen anwächst, wird eine Neugestaltung weitaus teurer sein, als von vornherein mit den richtigen Leitplanken zu entwerfen.
Zukunftsorientiertes Denken bedeutet nicht, für jedes hypothetische Szenario zu planen. Es bedeutet, frühzeitig in der SAP BRIM-Implementierung einige disziplinierte Fragen zu stellen:
- Was ändert sich in den nächsten 12–24 Monaten? (Regionen, Kanäle, Akquisitionen, Kundenvolumen)
- Wird sich der Produktmix ändern? (Abonnement + Nutzung + Bundles, neue monetarisierte Add-ons)
- Welche Entscheidungen werden fest verankert, sobald BRIM live ist? (Pricing-Modelle, Ereignisbehandlung, Integrationsmuster, Governance-Workflows)
Die Projektteams, die uferlose Komplexität vermeiden, sind nicht diejenigen, die versuchen, am ersten Tag das perfekte System zu entwerfen. Es sind diejenigen, die bewusste Designentscheidungen treffen, mit einem klaren Verständnis davon, was skalierbar sein muss.
3) Ihre bestehende Architektur ist bereits zu komplex
BRIM sitzt typischerweise zwischen mehreren vor- und nachgelagerten Systemen: Front-Office-Tools, die Aufträge und Verträge erfassen. Das macht BRIM zu dem Punkt, an dem Inkonsistenzen schließlich kollidieren.
Branchenanalysen von Order-to-Cash-Programmen zeigen dasselbe Muster: Systemsilos und fragmentierte Daten werden durchgängig als größte Problembereiche genannt, zusammen mit komplexer Abrechnung und Vertragsänderungen während der Laufzeit, die schwer über CRM-, Abrechnungs- und Finanzplattformen hinweg abzugleichen sind.
Wenn Upstream-Systeme inkonsistente Vertragsdaten nach Markt produzieren oder Nutzungsereignisse in unterschiedlichen Formaten eintreffen, wird BRIM zum ersten Ort, an dem diese Unterschiede zu abrechenbaren Ergebnissen abgeglichen werden müssen.
Deshalb beschreiben Teams oft SAP BRIM-Probleme, die sich anfühlen, als würde BRIM nicht funktionieren, während BRIM in Wirklichkeit Unterschiede in Daten, Definitionen und Verantwortlichkeiten aufzeigt, die lange vor seiner Einführung bestanden.
Eine nützliche Denkweise ist Symptome vs. Ursachen:
- Symptom: Rechnungen entsprechen nicht den Erwartungen
- Wahrscheinliche Ursache: Die Preislogik existiert außerhalb eines verwalteten Systems (Tabellenkalkulationen, manuelle Schritte), oder Produkt-/Vertragsdefinitionen unterscheiden sich je nach Region/Kanal.
- Symptom: Änderungen dauern ewig, auch wenn sie „klein“ erscheinen
- Wahrscheinlicher Grund: zu viele Abhängigkeiten in integrierten Systemen, unklare Entscheidungsrechte oder Designmuster, die Änderungen an mehreren Stellen erfordern.
- Symptom: Früher Build funktioniert, Skalierung bricht jedoch
- Wahrscheinliche Ursache: Die Lösung wurde für das heutige Volumen/den heutigen Markt entwickelt, ohne Leitplanken für zukünftiges Wachstum.
Deshalb ist das, was Kunden als „SAP BRIM-Komplexität“ bezeichnen, in der Regel tatsächlich Landschaftskomplexität. BRIM ist das System, das eine End-to-End-Antwort auf Fragen wie die folgenden erzwingt: Wo liegt die Preislogik? Wer besitzt die Produktdefinitionen? Was ist die zuverlässige Quelle für die Nutzung? Wenn diese Fragen nicht klar sind, verwandelt BRIM diese Unsicherheit in operative Reibungsverluste.
Eine praktische Checkliste zur Reduzierung der BRIM-Komplexität, bevor sie sich verstärkt
Wenn Ihr SAP BRIM-Programm zu komplex erscheint, ist der schnellste Weg, die Kontrolle zurückzugewinnen, die Komplexität nicht mehr als ein BRIM-Konfigurationsproblem zu behandeln, sondern als ein End-to-End-Design- und Betriebsmodellproblem.
Diese einfache Checkliste wurde genau für diesen Zweck entwickelt. Sie können sie zu Beginn eines BRIM-Programms oder mitten im Projekt verwenden, wenn Sie Warnzeichen erkennen.
1) Architektur- + Eigentumsprüfungen (erhalten Sie den Bauplan, nicht nur den Plan)
BRIM-Projekte geraten in Schwierigkeiten, wenn Entscheidungen isoliert getroffen werden.
Bevor das Design fertiggestellt wird, stellen Sie sicher, dass Sie Folgendes beantworten können:
Wem gehört die End-to-End Order-to-Cash-Architektur?
Nicht „wer das Projekt leitet“, sondern wer Entscheidungsbefugnisse über Systeme und Teams hinweg hat
Wo werden Systemgrenzen definiert (und vereinbart)?
Was gehört ins Front Office (CRM/CPQ/Commerce), was gehört in BRIM und was gehört in Finance
Wer genehmigt Änderungen, die sich auf Abrechnungsergebnisse auswirken?
Preise, Produktstrukturen, Tarife, Ereignisdefinitionen, Rechnungslegungsregeln und die damit verbundene Governance
Wie sieht „gut“ im operativen Betrieb aus, sobald es live ist?
Wer pflegt die Preise? Wer bearbeitet Ausnahmen? Wie läuft der Änderungsprozess ab?
Achten Sie auf dieses Warnsignal:
Wenn der einzige Abgleichmechanismus wöchentliche Status-Updates sind, haben Sie wahrscheinlich einen Projektplan und keine Architektur-Blaupause.
2) Leitplanken für den zukünftigen Zustand
Sie müssen nicht jede Anforderung vorhersagen. Aber Sie brauchen eine gemeinsame Vorstellung davon, was sich wahrscheinlich ändern wird, damit frühe Designentscheidungen später nicht zu teuren Einschränkungen werden.
Verwenden Sie diese Aufforderungen:
- Skalierung: Was passiert mit den Volumina in den nächsten 12–24 Monaten? (Kunden, Nutzungsereignisse, Rechnungen)
- Märkte: Sind neue Regionen geplant? Gibt es pro Markt unterschiedliche Compliance- oder Abrechnungsanforderungen?
- Kommerzielles Modell: Wird sich die Preisgestaltung weiterentwickeln? Sind Bündel, Add-ons oder nutzungsbasierte Elemente wahrscheinlich?
- Produktmix: Werden Sie „reine Software“ bleiben, oder werden Hardware/Dienstleistungen/Partner in das Modell einbezogen?
- Betriebsmodell: Müssen mehr Teams häufiger Änderungen vornehmen?
Übersetzen Sie diese Antworten dann in einfache Leitplanken:
- Was ohne Neugestaltung skaliert werden muss
- Was kann für Phase eins bewusst einfach sein
- Was reversibel bleiben muss
So reduzieren Sie die Komplexität der BRIM-Implementierung von Grund auf, ohne Over-Engineering zu betreiben.
3) Daten- und Integrationsrealismus
BRIM ist oft der Ort, an dem Datenprobleme sichtbar werden, da hier unterschiedliche Eingaben in abrechenbare Ausgaben umgewandelt werden. Wenn Sie weniger Probleme mit SAP BRIM haben möchten, behandeln Sie die Datenqualität und das Integrationsdesign vorgelagerter Prozesse als erstklassige Workstreams.
Wichtige Prüfungen:
- Vertrauenswürdige Quelle: Gibt es für jede Domäne (Produkte, Verträge, Kunden, Nutzung/Ereignisse) eine klare vertrauenswürdige Quelle?
- Datendefinitionen: Sind wichtige Felder und Konzepte über Märkte/Kanäle hinweg konsistent (Produkt-IDs, Preisattribute, Vertragsbedingungen)?
- Validierung: Wo validieren und verwerfen Sie schlechte Daten; vorgelagert, bei der Integration oder innerhalb von BRIM?
- Integrationskomplexität: Bauen Sie nur das, was Sie brauchen? Oder überentwickeln Sie (zusätzliche Dienste, Ebenen und Abhängigkeiten), die Änderungen später verlangsamen werden?
- Betriebliche Abwicklung: Wenn etwas schiefgeht, wer behebt es – und wie schnell können Sie die Grundursache identifizieren?
Achten Sie auf dieses Warnsignal: Kann ein System nicht „on the fly“ auf Schemaänderungen oder inkonsistente Eingaben reagieren, benötigen Sie eine Governance vorgelagert. Andernfalls wird BRIM zu dem Ort, an dem Sie Probleme zu spät entdecken.
4) Lieferdisziplin
Auch bei gutem Design vervielfacht sich die Komplexität, wenn Änderungen unkontrolliert erfolgen. Zwei praktische Bereiche, die frühzeitig festgelegt werden sollten:
- Preis- und Tarifverwaltung:
Vermeiden Sie eine unkontrollierte Ausbreitung (z. B. Dutzende von Preislisten/Tarifen, die zu Hunderten werden). Definieren Sie Namensstandards, Verantwortlichkeiten, Genehmigungsabläufe und Release-Zyklen.
- Prüfdisziplin:
Da BRIM den Cashflow beeinflusst, sind Tests nicht optional. Gleichen Sie Testdaten, Szenarien und Freigaben im gesamten Unternehmen und in der IT ab, insbesondere bei Preisänderungen und Ausnahmen.
Hier beginnen viele Geschichten über Implementierungsprobleme von SAP BRIM: nicht, weil die Lösung falsch ist, sondern weil das Betriebsmodell sie nicht sicher ändern kann.
Komplexität vervielfacht sich, wenn Entscheidungen ohne gemeinsame Verantwortlichkeit, gemeinsame Definitionen und Leitplanken für zukünftige Zustände getroffen werden. Bringen Sie diese frühzeitig an Ort und Stelle, und BRIM wird wesentlich einfacher zu implementieren, zu skalieren und zu betreiben sein.
So erhalten Sie SAP BRIM einfach
Wenn es eine Idee gibt, die man aus der Analogie der Lupe mitnehmen kann, dann die, dass die Komplexität von SAP BRIM nicht immer durch BRIM selbst verursacht wird. Wenn BRIM auf unklare Grenzen, inkonsistente Daten, isolierte Entscheidungsfindungen und Designentscheidungen trifft, die nicht auf zukünftige Skalierbarkeit ausgelegt waren, dann zeigen sich die Risse.
Der Vorteil ist, dass die Flexibilität von BRIM es extrem reparierbar macht. Aber man repariert es nicht, indem man mehr Konfigurationen darauf wirft. So macht man die Dinge schlimmer. Man repariert es, indem man bei der Erstellung des Bauplans, der Definition von Zuständigkeiten und der Änderung der Disziplin überlegter vorgeht.
Ein einfacher Aktionsplan, den Sie sofort umsetzen können
1) Erstellen Sie den Entwurf, bevor der Bau sich verfestigt
Tun Sie dies zuerst, auch wenn Sie bereits mitten in einem Projekt stecken:
- Notieren Sie die Systemgrenzen in einfachem Englisch: was das Front Office besitzt, was BRIM besitzt, was die Finanzabteilung besitzt
- Benennen Sie einen einzigen End-to-End-Architekturverantwortlichen (Entscheidungsrechte, nicht nur Koordination)
- Einigung auf die „Source of Truth“ für Produkte, Verträge, Kunden und Nutzung/Ereignisse
2) Schaffen Sie Leitplanken für Entscheidungen mit hohem Aufwand
Betrachten Sie diese als langfristige Verpflichtungen, bei denen eine Kehrtwende schwieriger ist:
- Muster von Preis-/Bewertungsmodellen
- Ereignisstruktur + Validierungsansatz
- Integrationsmuster (so einfach wie das Betriebsmodell es zulässt)
- Governance für Preis-/Katalog-/Tarifplanänderungen
Wenn eine Änderung jedes Mal mehrere Teams, mehrere Systeme oder mehrere Genehmigungen erfordert, schaffen Sie zukünftige Komplexität für sich selbst.
3) Das Betriebsmodell anpassen, um Komplexität zu vermeiden
BRIM ist betrieblich meist dann nicht mehr funktionsfähig, wenn Änderungen unkontrolliert vorgenommen werden. Sorgen Sie für Disziplin bei:
- Preisgestaltung: Eigentum, Benennung, Versionierung, Release-Kadenz (Vermeidung einer Ausbreitung der Tarifstrukturen)
- Testdisziplin: Funktionsübergreifende Abnahme für abrechnungsrelevante Änderungen (Preisänderungen sollten nicht einfach „Gehofft und ausgerollt“ werden)
- Ausnahmebehandlung: Legen Sie fest, wer vorgelagerte Datenprobleme löst und wo diese gelöst werden. Lassen Sie BRIM nicht zu einem Entsorgungsort werden.
Denken Sie daran: Sie müssen nicht alles auf einmal lösen. Der effektivste Schritt ist, die Kategorie zu identifizieren, die die größten Probleme verursacht, und diese dann an der Wurzel anzugehen, nicht am Symptom.
Bereit, die Komplexität von SAP BRIM zu reduzieren?
Wenn BRIM zu komplex erscheint, ist es am schnellsten, die Ursache der Komplexität zu finden. Liegt es an der Architektur, den Daten, der Eigentümerschaft oder den Designentscheidungen? Sie müssen die Grundursache finden und beheben, bevor sich das Problem verschlimmert.
Sie wissen nicht, wo Sie anfangen sollen? Buchen Sie ein BRIM-Komplexitäts-Review mit einem CLARITY-Experten.