Von Excel zur Scoring API: Entscheidungslogik ohne Code-Drift

Das Modell funktionierte. Die Software nicht.

Die ADAC-Klassifikation von Campingplätzen basiert auf einem umfangreichen Bewertungsmodell mit zahlreichen Regeln, Gewichtungen, Berechnungen und Abhängigkeiten.

Dieses Modell wurde ursprünglich von den Fachbereichen in Excel entwickelt und gepflegt.

Die Excel-Datei definierte:

• die Bewertungskriterien
• die Gewichtungen
• die Teilbewertungen
• die Klassifikationslogik
• die Berechnung der finalen Sternebewertung

Die Tabelle war damit nicht nur ein Hilfsmittel für die Konzeption der Klassifikation.
Excel war das eigentliche Entscheidungsmodell.

Fünf Jahre Versuch, Bewertungsvorlage in Software nachzubauen

Über Jahre wurde versucht, das Excel-Modell in Anwendungscode zu implementieren. Die Entwickler übernahmen die fachlichen Regeln und bauten eine technische Implementierung der Klassifikationslogik in PHP.

Auf dem Papier klang das einfach:

flowchart TD

    A[Excel-Bewertungsmodell]
    B[Manuelle Nachimplementierung im Anwendungscode]
    C[ADAC-Klassifikation]

    A --> B
    B --> C

In der Praxis entstand jedoch ein anderes Problem.

Mit jeder neuen Version zeigte sich, dass die Ergebnisse der Software von den Ergebnissen des ursprünglichen Excel-Modells abwichen.

Über Jahre hinweg wurde versucht, diese Abweichungen zu beseitigen. Fehler wurden korrigiert, neue Versionen veröffentlicht und Berechnungen angepasst. Trotzdem gelang es nie, eine dauerhaft identische technische Umsetzung des ursprünglichen Bewertungsmodells zu erreichen.

Es existierten plötzlich zwei Versionen derselben Logik:

• das fachliche Originalmodell
• die technische Interpretation im Anwendungscode

Und beide drifteten immer weiter auseinander.

Der Perspektivwechsel: Das Excel-Modell ist der Source Code

Mit CLE wurde ein anderer Ansatz gewählt.
Anstatt das Modell erneut zu implementieren, wurde die ursprüngliche Excel-Datei direkt verwendet.

Das vorhandene Bewertungssystem wurde nicht übersetzt.
Es wurde ausgeführt.

flowchart TD

    A[Excel-Bewertungsmodell]
    B[CLE]
    C[Scoring API]
    D[ADAC-Klassifikation]

    A --> B
    B --> C
    C --> D

Die Excel-Datei blieb die einzige fachliche Quelle der Wahrheit.

Es gab jetzt nur noch eine Implementierung.

• Kein manuelles Nachbauen der Regeln
• Kein Übersetzen in Anwendungscode
• Keine Abweichungen zwischen Modell und Runtime
• Keine Synchronisation zweier unterschiedlicher Logiken
• Kein manuelles Reparieren von falschen Berechnungen

Mit CLE wurde das Bewertungsmodell nicht mehr nachgebaut. Es wurde ausgeführt.

Das Ergebnis

Bereits die ersten Ausführungen lieferten die erwarteten Ergebnisse. Nicht weil ein neues Regelwerk entwickelt wurde. Sondern weil erstmals das ursprüngliche Regelwerk direkt ausgeführt wurde.

Die Software berechnete nicht mehr etwas, das dem Excel-Modell ähnelte. Die Software führte das Excel-Modell selbst aus. Damit verschwand das grundlegende Problem der vorherigen Lösung:

Fachliches Modell ≠ Technische Implementierung

Es existierte wieder nur eine Version der Wahrheit.

Die eigentliche Bewährungsprobe kam Jahre später. Eine Mitarbeiterin aus dem Fachbereich passte das Bewertungsmodell an, obwohl sie weder an der ursprünglichen Modellierung noch an der technischen Umsetzung beteiligt gewesen war. Die Änderungen konnten direkt im Modell vorgenommen werden und führten sofort zu den fachlich erwarteten Ergebnissen.

Genau dafür wurde der Ansatz entwickelt: Das Wissen bleibt im Modell, nicht in den Köpfen einzelner Entwickler.

Von der Klassifikation zur Scoring Runtime und Scoring API

Heute wird das Bewertungsmodell des ADAC Campingführers durch CLE ausgeführt.

Die relevanten Campingplatzdaten werden im PIM System Contene verwaltet. Contene übergibt die Objekte direkt an CLE, wo das Bewertungsmodell ausgeführt und die Klassifikation berechnet wird.

• Die Klassifikation wird an einer zentralen Stelle berechnet.
• Sie muss nicht mehrfach in unterschiedlichen Systemen implementiert werden.
• Business-Intelligence-Tools (Tableau, Microsoft BI, Power Query) greifen direkt auf die live berechneten Scores und Klassifikationen zu.

CLE agiert hier als zentrale Scoring Engine, die das Entscheidungsmodell konsistent für alle nachgelagerten Systeme ausführt.

Vom internen Scoring zur Scoring API

Obwohl die Klassifikation im PiNCAMP-Projekt als interne Integration zwischen Contene und CLE ausgeführt wird, kann dasselbe Bewertungsmodell auch als Scoring API bereitgestellt werden.

Andere Systeme können dann:

• Daten als JSON übergeben
• die berechnete Klassifikation, Teil-Scores und Begründungen zurückempfangen
• dieselbe Entscheidungslogik wie das PIM und die BI-Systeme nutzen

Damit wird aus einer internen Scoring-Runtime eine unternehmensweite Scoring API für alle Kanäle und Anwendungen.

Eingabe

POST /api/decision
Content-Type: application/json

[{
  "totalNumberOfUnits": 55,
  "residentialPitches": 15,
  "residentialPitchesWithOwnSanitaryFacilities": 10,
  "speciallyPitchesForCampingCarsOnCampsite": 5,
  ...
}]

Ausgabe

HTTP 200 OK 

[{
  "totalNumberOfUnits": 55,
  "residentialPitches": 15,
  "residentialPitchesWithOwnSanitaryFacilities": 10,
  "speciallyPitchesForCampingCarsOnCampsite": 5,
  ...
  "numberOfRegularTouristPitches": 35,
  "totalNumberTouristicPitches":40,
  ...
  "scoreQualitySanitaryFacilities": 9,
  "stars_2026" : 4.5
}]

Warum Nachvollziehbarkeit wichtig ist

Eine Klassifikation besteht nicht nur aus einem Ergebnis.
Die entscheidende Frage lautet:

Warum wurden genau 4 Sterne vergeben?

Vor der Einführung von CLE lautete die Antwort häufig:

Das System hat 4 Sterne berechnet. Aber warum, wissen wir nicht

Für Fachbereiche war das Ergebnis sichtbar, die Entscheidungsgrundlage jedoch nicht. Genau dieses Problem adressiert CLE mit seinem Explainable-Decision-Ansatz.

Eine moderne Scoring API sollte nachvollziehbar machen:

• welche Kriterien bewertet wurden
• welche Teilbewertungen entstanden sind
• welche Regeln angewendet wurden
• welche Faktoren zur finalen Klassifikation geführt haben

Deshalb wurde CLE von Anfang an für nachvollziehbare Geschäftsentscheidungen entwickelt.

→ Explainable Decisions: See How Business Decisions Are Made

Warum dieser Ansatz für Scoring APIs relevant ist

Viele Organisationen besitzen bereits funktionierende Bewertungsmodelle. Das eigentliche Problem besteht oft nicht darin, die Scoring-Logik zu definieren. Das Problem besteht darin, diese Logik langfristig konsistent, nachvollziehbar und wartbar in Software abzubilden.

Der Ansatz von CLE löst genau dieses Problem:

• Das Fachmodell bleibt die Quelle der Wahrheit.
• Excel bleibt die Modellierungssprache.
• Anwendungen konsumieren Ergebnisse über APIs.
• Änderungen erfolgen am Modell, nicht am Code.
• Scores bleiben nachvollziehbar und reproduzierbar.
• Eine Scoring API kann gleichzeitig Berechnung und Transparenz bereitstellen.

Eine Version der Wahrheit

Die Herausforderung bestand nicht darin, das Bewertungsmodell zu entwickeln. Die Herausforderung bestand darin, das entwickelte Modell über Jahre hinweg korrekt in Software nachzubilden.

CLE löste dieses Problem, indem das Excel-Modell selbst zur ausführbaren Quelle der Wahrheit wurde.

Das Excel-Modell wurde nicht mühsam nachprogrammiert.
Das Excel-Modell wurde ausgeführt.