Ihre Business Rules Engine existiert bereits.
Sie heißt Excel.
Wer eine Business Rules Engine sucht, hat meist längst eine: die Excel-Tabelle, die die Fachabteilung pflegt und der alle vertrauen. SpreadAPI macht aus diesem Excel-Modell eine kontrollierte Decision-API — ohne sechsstellige Migration und ohne neues Tool, das erst jemand lernen muss.
Wofür eine Business Rules Engine eigentlich da ist
Lässt man das Hersteller-Vokabular weg, verspricht jede Business Rules Engine dieselben vier Dinge. Die Frage ist nur, was es Sie kostet, sie zu bekommen.
Logik raus aus dem Code
Preis-, Eignungs- und Risikoregeln ändern sich wöchentlich. Sie sollten nie jedes Mal Entwickler, Pull Request und Deployment erfordern.
Die Fachabteilung besitzt die Regeln
Wer die Regeln versteht — Pricing, Underwriting, Finanzen — sollte sie direkt ändern können, ohne sie erst für die Entwicklung zu übersetzen.
Eine aufrufbare Decision-API
App, Workflow oder KI-Agent schickt die Eingaben und bekommt eine Entscheidung zurück. Kein Copy-Paste, keine Nachbau-Logik, eine Wahrheit.
Kontrolliert und transparent
Jede Entscheidung muss erklärbar und kontrolliert sein: klare Ein- und Ausgaben, private Logik und eine Version, die Sie bewusst veröffentlichen.
Sie haben Ihre Rules Engine längst gebaut — in einer Tabelle
In fast jedem Unternehmen liegen die Regeln, die Sie verwalten wollen, bereits in einer Excel-Datei. Das Pricing-Team hat die Preisliste gebaut, das Underwriting das Risikomodell, die Finanzabteilung die Provisionslogik. Es funktioniert, alle vertrauen darauf, und es wird jede Woche gepflegt.
Der klassische Ansatz verlangt, das wegzuwerfen: jede Regel in einer proprietären Sprache oder DMN-Tabelle neu abzubilden, die Fachabteilung auf eine neue IDE zu schulen und ein Migrationsprojekt über Quartale zu stemmen — nur um nachzubauen, was Ihre Tabelle heute schon korrekt tut.
SpreadAPI geht den umgekehrten Weg. Die Tabelle ist die Regeldefinition. Sie veröffentlichen sie und erhalten die Decision-API — in Minuten.
„Kaufen Sie keine Business Rules Engine. Sie besitzen längst die beste: das Excel-Modell, das Ihr Team jeden Tag pflegt.“
Excel-nativ vs. klassische BRMS
Klassische BRMS = Drools, InRule, IBM ODM, Camunda und ähnliche Decision-Management-Plattformen.
Von der Tabelle zur Decision-API in drei Schritten
Excel mit Ihren Regeln hochladen
Dieselbe Datei, die Ihr Team ohnehin pflegt — SVERWEIS, verschachtelte WENNs, Tariftabellen, Finanzfunktionen und alles andere. Nichts nachzubauen.
Den Decision-Contract festlegen
Markieren Sie, welche Zellen Eingaben sind (die Falldaten) und welche Ausgaben (die Entscheidung). Nur dieser Contract ist nach außen sichtbar.
Die Entscheidung von überall aufrufen
Ihr Backend, ein n8n- oder Zapier-Workflow, Power Automate oder ein KI-Agent schickt die Eingaben und erhält die Entscheidung als JSON.
Wenn es in einer Tabelle steht, kann es eine API sein
Überall, wo die Fachabteilung in Excel „bei diesen Eingaben — was ist die Antwort?“ abbildet, macht SpreadAPI daraus einen Entscheidungsdienst.
Preise & Rabattstufen
Mengenstaffeln, regionale Preise, kundenspezifische Konditionen.
Underwriting & Risiko-Scoring
Versicherungsprämien, Risikoklassen, Annahmeregeln.
Kredit & Eignung
Kreditwürdigkeit, Limits, Scorecards, Leistbarkeitsprüfung.
Provisionen & Auszahlungen
Provisionsstufen, Boni, Partner-Umsatzbeteiligungen.
Angebote & Konfiguration
CPQ-Logik, Bundles, Zusatzoptionen, Machbarkeitsregeln.
Steuern, Gebühren & Zuschläge
Länderregeln, Abgaben, Schwellenwerte, Rundung.
Die Punkte, nach denen Ihr Risk-Team fragt
Das Risiko bei Tabellen war nie Excel selbst — es waren herumgemailte Kopien und eingefügte Werte. Genau das entfernt SpreadAPI.
Ihre Logik bleibt privat
Die API liefert die Entscheidung — nie die Formeln oder die Tabelle. Aufrufer sehen Eingaben und Ausgaben, nie den Weg dorthin.
Aufgabentrennung
Die Fachabteilung besitzt und pflegt das Modell in Excel. Entwickler nutzen nur einen stabilen Endpunkt. Keine Seite blockiert die andere.
Eine kontrollierte Version
Aufrufer nutzen immer die Version, die Sie bewusst veröffentlicht haben. Änderungen in Arbeit bleiben Entwurf, bis Sie freigeben.
On-Premises-Option
Für regulierte Daten läuft die gesamte Engine in Ihrer eigenen Infrastruktur. Die Tabelle verlässt Ihr Netzwerk nie.
Fragen, die sich lohnen
Ist eine Tabelle nicht riskanter als eine echte Business Rules Engine?
Das Risiko bei Tabellen entsteht durch unkontrollierte Kopien und eingefügte Werte — nicht durch Excel selbst. SpreadAPI beseitigt das: ein veröffentlichtes Modell, per API aufgerufen, Formeln nie sichtbar, Ergebnisse von der echten Excel-Engine berechnet. Sie behalten Excels Transparenz und verlieren das Copy-Paste-Chaos.
Wie unterscheidet sich das von Drools, InRule oder IBM ODM?
Diese Engines verlangen, dass Sie Ihre Regeln in ihrer Sprache neu schreiben und ein Migrationsprojekt fahren. SpreadAPI nutzt das Excel-Modell, das Ihr Team bereits gebaut hat. Kein Neuschreiben, kein neues Skillset, keine Migration.
Können Fachanwender Regeln ohne Entwickler ändern?
Ja. Sie bearbeiten die Tabelle und veröffentlichen. Solange Eingabe- und Ausgabezellen gleich bleiben, ändert sich der API-Contract nicht — nachgelagert bricht also nichts.
Was ist mit komplexer Logik — SVERWEIS, verschachtelte WENNs, Finanzfunktionen?
Alle 500+ Excel-Funktionen laufen exakt wie in Excel, mit denselben Ergebnissen. Komplexe, voneinander abhängige Modelle sind genau der Punkt.
Wie schnell ist eine Entscheidung?
Typisch 50–200 ms pro Berechnung — schnell genug für Echtzeit-Pricing, Checkout- und Antragsstrecken.
Können wir es in unserer eigenen Infrastruktur betreiben?
Ja. On-Premises-Betrieb ist für regulierte Branchen und Anforderungen an die Datensouveränität verfügbar.
Schluss mit dem Migrieren von Regeln. Rufen Sie sie einfach auf.
Machen Sie aus dem Excel-Modell, dem Ihr Team längst vertraut, eine kontrollierte Decision-API. Keine Migration, kein neues Tool, keine sechsstellige Lizenz.