Implementierung
Provisionen werden typischerweise einmal im Monat als Grundlage für die Auszahlungen an Mitarbeiter neu berechnet. Mit DecisionRules können Sie diese Berechnungen jedoch jederzeit im Laufe des Monats auf Team- oder individueller Maklerebene durchführen, um deren Motivation zu steigern.
Modellstruktur
Die Lösung muss in der Lage sein, drei verschiedene Provisionsmodelle zu berechnen. Um dieses komplexe Verhalten einerseits zu definieren und die Integration andererseits zu vereinfachen, haben wir eine hierarchische Regelstruktur implementiert.
- Die 1. Ebene repräsentiert die Hauptregel (Provisionen berechnen), die für die Integration in beide Richtungen IN und OUT verantwortlich ist und Regeln in den folgenden Ebenen ausführt.
- Die 2. Ebene definiert verschiedene Provisionsmodelle und enthält eine Liste aller Regeln in jedem Modell.
- Die 3. Ebene enthält die endgültigen Regeln, die die endgültige Provision basierend auf den Eingabedaten berechnen. In dieser Ebene wird für jeden Produkttyp eine Regel erstellt. Es ist möglich, verschiedene Versionen einer Regel für jeden Produkttyp zu definieren und sie nach Bedarf ein- und auszuschalten.
1. Ebene
Die Regel Provisionen berechnen ist dafür ausgelegt, alle anwendbaren Regeln für einen Masseneingang zu bewerten, was bedeutet, dass der Eingang alle Konten und/oder Geschäfte eines Maklers enthält. Es ist jedoch immer möglich, jede Regel isoliert zu bewerten, wenn dies erforderlich oder einfacher für die Implementierung ist.
Die Regel hat eine Eingabeeigenschaft commissionType, die den Typ der Provision bestimmt, die berechnet werden soll, sodass für jede Teilmenge dieser Provisionen der Eingang gleich bleiben kann.
Diese Regel ist nicht dazu gedacht, geändert zu werden, es sei denn, das Modell wird erheblich geändert, beispielsweise wenn ein anderer Provisionsart hinzugefügt wird. Wenn die Struktur der Provisionen gleich bleibt und Regeln nur entfernt oder hinzugefügt werden, würde sich nur das Eingabeschema ändern, um die Struktur Ihrer Eingabedaten widerzuspiegeln.
2. Ebene
Diese Ebene organisiert die Regeln in einzelne Provisionsmodelle. Es gibt drei Tabellen, jeweils für ein Provisionsmodell. Jede Tabelle enthält eine Liste aller aktiven Provisionsregel-IDs. Nur die aktuellen Regeln in diesen Tabellen werden bewertet.
Die Tabelle für Verdienste-Provisionen enthält auch eine Spalte, in der eine Exklusivitätsgruppe festgelegt werden kann. Diese Funktion ermöglicht es, mehr Regeln für einen Fall zu definieren. Alle Regeln dieser Exklusivitätsgruppe werden gleichzeitig bewertet, und nur die am höchsten provisionierte wird vergeben. Dies schafft die Möglichkeit, mehrere Stufen von Verdienste-Provisionen zu gestalten.
3. Ebene
Die letzte Ebene enthält die eigentliche Logik zur Bewertung der Provisionen. Diese Regeln werden aus dem orchestrierenden Skript Provisionen berechnen aufgerufen. Es besteht jedoch auch die Möglichkeit, alle separat zu bewerten, falls dies erforderlich ist.
Alle Provisionen haben eine separate Regel, in der ihre Logik gespeichert ist, daher kann jede Regel unabhängig geändert werden.
Verwaltung der Provisionsregeln
Wir erwarten, dass die Anzahl der Regeln zunimmt. Es könnte vorteilhaft für einen Geschäftsnutzer sein, der die Möglichkeit sieht, seine Kreativität auszuleben. Für einen Anwendungsadministrator könnte dies schnell zu einem Kopfzerbrechen werden. Aus diesem Grund haben wir einige Techniken eingeführt, um die Anzahl der Regeln auf einem überschaubaren Niveau zu halten.
Regelvariablen
Für jede Regel können wir eine Regelvariable definieren, die nützlich ist, wenn ein einzelner Wert in mehreren Abschnitten eines Algorithmus verwendet wird oder wenn es notwendig ist, bedeutende Attribute wie den Provisionsbetrag einfach zu ändern.
Ein gutes Beispiel kann ein Provisionsprozentsatz sein, der als Teil einer Bedingung in der Regel Verkaufsprovision - Darlehensverkauf verwendet wird, wie oben beschrieben. Mit einer Variablen können wir ihn gleichzeitig ändern und die Wahrscheinlichkeit eines potenziellen Fehlers verringern.
Die Regelvariablen können auch auf die gleiche Weise verwendet werden, als wären sie Teil des Eingangs.
Aktivieren/Deaktivieren von Provisionen
Wie oben beschrieben (Modellstruktur - 2. Ebene) werden nur die in den Listentabellen vorhandenen Regeln bewertet. Das bietet die Möglichkeit, aktive Provisionen einfach zu verwalten; alles, was der Administrator tun muss, um eine Provisionsregel zu deaktivieren, ist, ihren Eintrag in dieser Tabelle auszuschalten.
Es ist auch möglich, eine Aktivierungszeit für eine bestimmte Regel festzulegen, was die Möglichkeit bietet, zeitlich begrenzte Aktionen zu erstellen oder die Provisionsbedingungen je nach Saison zu variieren.
Eingabe-/Ausgabemodelle
Die Eingabedaten sind um den Makler strukturiert. Alle Informationen für die Provisionsverarbeitung werden in einem einzigen Batch gesendet, und auch die Provisionen für einzelne Makler werden auf einmal bewertet. Die Datenstruktur wird als Array erstellt, sodass es möglich ist, verschiedene Arten von Provisionen für einen einzelnen Makler, eine Art von Provision für mehrere Makler oder jede andere Kombination zu verarbeiten.
Eingabedatenmodell
Die Eingabestruktur ist im I/O-Modell der Hauptregel - Provisionen berechnen - festgelegt. Der Eingang ist in drei Teile unterteilt: Provisionsart, ein kritischer Parameter, der das verwendete Provisionsmodell bestimmt. Mögliche Werte sind: „VERKAUF“, „VERDIENST“, „EINNAHMEN“ Geschäfte - notwendige Informationen über getätigte Geschäfte. Diese Struktur sollte alle Daten enthalten, die von den jeweiligen Regeln, die bewertet werden sollen, benötigt werden. Makler, der einige Informationen über den Makler bereitstellt, der das Geschäft gemacht hat. Diese Informationen sind sowohl für die Provisionsverarbeitung nützlich, wo die Höhe der Provision möglicherweise vom Rang des Verkäufers abhängt (zum Beispiel), als auch für Berichterstattungszwecke.
Die Eigenschaft CommissionType ist in der Provisionsverarbeitung obligatorisch. Der Inhalt der Eigenschaften Deals und Consultant ist variabel und hängt von der Regel und den für die Geschäftslogik der Provision signifikanten Parametern ab.
Ausgabemodell
Während die Eingabestruktur einige obligatorische Komponenten und viele optionale Parameter enthält, die je nach Provisionsmodell variieren, wird die Ausgabestruktur immer gleich sein:
- Bewertungsdatum
- Die Branche, in der der Makler tätig ist
- Identifikation des Maklers
- Array der dem Makler zugesprochenen Provisionen
Eingabe-/Ausgabemodell der Provisionsregeln
Jede Regel kann ein unterschiedliches Set von Eingaben zur Bewertung haben, und daher ist die Eingabestruktur variabel. Wenn wir uns ein Beispiel der Verkaufsprovision SC_LOAN ansehen, sieht ihr Eingabemodell wie das in Bild Nr. 1 aus.
Die Ausgabe jeder Provisionsregel hat die gleiche Struktur, um die endgültige Ausgabe einheitlich und einfach zu integrieren. Sie können das Ausgabemodell in Bild Nr. 2 sehen. 
Bild Nr. 1
Bild Nr. 2
Beispiel-Provisionsregeln
Lassen Sie uns die Regeln in der 3. Ebene betrachten, die die Geschäftslogik der einzelnen Provisionen definieren. Jedes Provisionsmodell hat seine Besonderheiten, genau wie jede Produktklasse.
Für jedes Beispiel werden wir die benötigten Eingabedaten, die Logik und die festgelegten Parameter sowie die Ausgabe der Regel beschreiben.
Während die Eingabestrukturen oft je nach Art des Provisionsmodells variieren, wird die Ausgabe im Wesentlichen gleich sein. Alle Regeln, die wir präsentieren möchten, können einfach in einer einfachen Baumstruktur festgelegt werden, sodass keine Programmierkenntnisse erforderlich sind. Dies könnte für Organisationen nützlich sein, in denen die IT-Ressourcen sehr begrenzt sind. Bitte beachten Sie, dass es wie bei jedem anderen IT-Tool dringend empfohlen wird, einen Anwendungsadministrator in den Prozess der Entwicklung neuer Regeln einzubeziehen.
Verkaufsprovision - Darlehensverkauf
Die Verkaufsprovision eines Darlehens wird in unserem Fall aus drei grundlegenden Eingaben berechnet:
- Darlehensbetrag oder Kreditlimit
- abgehobener Betrag
- und der Produkttyp
Es könnten mehrere andere Parameter zur Berechnung der Provision herangezogen werden, aber wir haben uns entschieden, eine einfache Regel zu verwenden.
Zur besseren Wartbarkeit sind auch zwei Regelvariablen definiert. Eine definiert die Prozentwerte für den Provisionssatz, der zur Berechnung der Auszahlung der Provision verwendet wird, und die andere gibt das Mindestverhältnis des ausgezahlten Betrags an.
Diese Regel ist in Form eines Entscheidungsbaums konstruiert, und ihre Implementierung nimmt die folgende Form an:
Bedingungen
Es gibt nur eine Bedingung, die überprüft, ob die Anzahl der Kunden den vordefinierten Schwellenwert überschreitet.
Wir verwenden die Funktion ARRAY_FILTER, um alle Konten herauszufiltern, bei denen die Eigenschaft newClient nicht wahr ist, dann zählen wir diese Einträge und überprüfen, ob die Anzahl größer oder gleich dem in den Regelvariablen definierten Schwellenwert ACC_COUNT_THRESHOLD ist.
Positives Ergebnis
Wenn die Bedingung erfüllt ist, wird der Provisionswert auf einen vordefinierten Wert (in unserem Fall 30.000) gesetzt und die Eigenschaft awarded auf true gesetzt.
Negatives Ergebnis
Wenn die Bedingung nicht erfüllt ist, wird der Wert der Provision auf 0 gesetzt, die Eigenschaft awarded auf false gesetzt und es wird eine Nachricht unter der Begründung generiert, die besagt: „Nicht genügend neue Kunden“ mit der Anzahl neuer Kunden, die der Makler erreicht hat.
Integration
DecisionRules integriert sich über die Restful API (Dokumentation). Für die Zwecke unserer Fallstudie würden wir die Massenverarbeitung größerer Datensätze nutzen. Darüber hinaus besteht auch die Möglichkeit, eine einzelne Regel nur für ein Geschäft aufzurufen. Das könnte in Situationen nützlich sein, in denen ein Makler den Betrag der Provision für ein Geschäft, das er/sie abschließen möchte, validieren muss.
API-Aufrufe
Die Kommunikation mit den DecisionRules, die sich mit größeren Datenmengen befassen, erfordert die Nutzung einer Middleware-Lösung, um eine nahtlose Kommunikation zwischen den DecisionRules und der Datenquelle zu ermöglichen. Dieses Zwischenwerkzeug verwaltet die Datenübertragung, gewährleistet einen sicheren und effizienten Austausch von Informationen und erhält die Datenintegrität.
Die Antwort auf den API-Aufruf enthält eine vordefinierte Ausgabestruktur, die oben im Detail beschrieben ist. Nach der Verarbeitung in der Middleware-Komponente kann sie als Quelle für weitere Geschäftsprozesse zur Genehmigung der Provisionen und Zahlungen verwendet werden.
Um die Lösung zu testen, können wir das Tool https://www.postman.com/ verwenden, um die Middleware zu simulieren, die empfangene Antwort zu visualisieren und die funktionierende Logik innerhalb der DecisionRules.io zu beweisen.
Ein Aufruf aus einer Postman-Anwendung könnte so aussehen.
… und die Antwort von der Verkaufsprovisionsregel:
Berichterstattung
Unternehmer benötigen eine Reihe von Berichten, die Informationen über die Summe der zu zahlenden Provisionen sowie detaillierte Informationen über einen einzelnen Fall bereitstellen, um mögliche Beschwerden entscheiden zu können.
Power BI wird unser Werkzeug der Wahl sein.
DecisionRules.io ist in der Lage, detaillierte Informationen über jede einzelne Regelverarbeitung zu speichern, einschließlich der Eingabedaten und der berechneten Ausgaben. Diese Art von Daten wird in Form von Audit-Logs gespeichert. Diese Protokolle können dann über die API abgerufen und für Berichterstattungszwecke in Power BI verarbeitet werden. Erfahren Sie mehr über die Audit-Logs in unserer Dokumentation: link
In unserem Beispiel protokolliert die Regel einige grundlegende Informationen über den Makler zusammen mit allen Daten, die in der Regelbewertung verwendet wurden, dem Provisionsbetrag, dem Namen und Typ der Provision, dem Datum, an dem die Provision vergeben wurde, und grundlegenden anonymen Informationen über das Konto oder den Kunden.
Fazit
In diesem Artikel haben wir beschrieben, wie die Provisionsmodelle in DecisionRules implementiert werden und haben grob beschrieben, wie das Modell funktioniert und wie es bewertet wird. Wir haben auch die Berichterstattung über die Provisionsresultate behandelt.
Wir haben erwähnt, dass DecisionRules.io kein einzelnes Tool ist, das jeden Aspekt des Provisionsprozesses lösen wird, aber es könnte das kritische sein, das das wertvolle Know-how enthält und verwaltet.
Im nächsten und letzten Teil dieser Serie werden wir tiefer in die Implementierung in DecisionRules.io eintauchen, damit Sie es selbst ausprobieren und mit verschiedenen Provisionsmodellen experimentieren können.
Pavel Wasserbauer
Leiter für Business Intelligence