Prognoseplattform: als alleiniger Entwickler von der ersten Zeile bis in den Betrieb

Gemessen am Anmeldeprotokoll, Juni bis September 2026. Der Sprung im September kommt vom dritten Standort, der seit Ende August angebunden ist.

Ausgangslage

Im Juli 2025 habe ich als AI Engineer bei einem mittelständischen Konzern der Fleischwirtschaft angefangen. Der Konzern arbeitet an drei Standorten. Prognose und Steuerung liefen dort in Alt-Systemen und Handprozessen, die nebeneinander gewachsen waren. Jedes davon beantwortete eine Frage. Keines zeigte den Zusammenhang. Wer eine Entscheidung vorbereiten wollte, trug Zahlen aus mehreren Stellen zusammen.

Mein Auftrag war eine interne Plattform, die Prognosen rechnet, die Steuerung unterstützt und im Alltag hält. Ein Entwicklungsteam gab es nicht. Ich war der einzige Entwickler, und ich bin es bis heute. Das prägt jede Entscheidung in diesem Projekt: Was ich baue, muss ich allein betreiben können.

Entscheidung

Drei Entscheidungen haben die Plattform geformt.

Erstens: ein System statt vieler. Ich habe die Alt-Systeme nicht nachgebaut. Ich habe die Fragen dahinter gesammelt und in einer Anwendung beantwortet. Jede Ablösung war ein eigener Schritt mit eigener Abnahme, keine Nebenwirkung.

Zweitens: Dateien statt Datenbankserver in der Laufzeitschicht. Die Anwendung liest ihre Daten aus Spaltendateien über eine eingebettete Analysedatenbank. Das hält den Betrieb einfach. Es gibt keine zusätzliche Datenbankinstanz zu pflegen. Ein Datenstand lässt sich kopieren, sichern und zurückspielen wie ein Ordner.

Drittens: Betrieb gehört zum Fundament. Rollen und Rechte, ein Änderungsprotokoll und Überwachung habe ich nicht als Anbau geplant, sondern als Teil des Kerns. Wer allein verantwortet, kann sich nachträgliche Sicherheitsarbeit nicht leisten.

Umsetzung

Die Oberfläche läuft im Browser. Dahinter steht ein Dienst mit 388 Endpunkten, der Daten liefert, Berechtigungen prüft und jede Änderung protokolliert. Die Laufzeitschicht hält die aufbereiteten Daten in Spaltendateien. Die Datenplattform, die sie an jedem Werktag füllt, beschreibe ich in Projekt C.

Ich habe in kleinen Schritten ausgeliefert. Bis Juli 2026 waren es 29 Produktions-Releases. Jede Auslieferung brachte einen abgeschlossenen Nutzen, keine halbe Baustelle. Der Code umfasst rund 110.000 Zeilen. Bei einem großen Versionssprung des Dienstes im September liefen 5.390 Tests grün durch.

Rollen und Rechte legen fest, wer welche Bereiche sieht und welche Änderungen er vornehmen darf. Im September habe ich das Rechtemodell umgebaut. Vorher war jede Seite im Code fest einem Team zugeordnet. Zwei Stufen je Fachbereich waren so nicht möglich. Jetzt trägt jede Berechtigung ihre Bereiche, Seiten und Schreibrechte selbst, und Fachadmins pflegen sie in der Oberfläche. Vor dem Umschalten hat ein Prüfskript für jeden der 34 Nutzer altes und neues Modell verglichen. Ergebnis: null Abweichungen, am selben Tag live. Seitdem beantragen Nutzer Rechte selbst im Profil. Von 49 Anträgen sind 47 genehmigt.

Das Änderungsprotokoll hält fest, wer wann was geändert hat. Die Überwachung meldet mir Fehler, bevor ein Nutzer sie meldet. Diese Bausteine sind unspektakulär. Sie sind der Grund, warum ich die Plattform allein betreiben kann.

Die Alt-Systeme und Handprozesse habe ich nacheinander abgelöst, bis Juli 2026 waren es 13. Ein altes Werkzeug wurde erst abgeschaltet, wenn der neue Weg in Benutzung war. Ein großer Teil davon waren einzelne Excel-Berichte, die jemand von Hand gepflegt hat. Seitdem sind 8 dazugekommen, zusammen also 21. Die tägliche Liste der offenen Posten aus der Buchhaltung steht jetzt als Auswertung in der Plattform. Sieben Excel-Auswertungen der Viehabrechnung, die nach jedem Wochenabschluss von Hand entstanden, ersetzt eine Seite. Ich habe sie gegen die Vorlagen geprüft: alle 52 Zeilen der Wochenauswertung stimmen exakt. Die Rückmeldung der Fachanwenderin war am selben Tag umgesetzt.

Die Plattform zeigt Zahlen nicht nur, sie bewertet sie auch richtig. Die Verkaufsanalyse war bisher ganz auf Umsatz ausgerichtet. In der Fleischwirtschaft führt das in die Irre, weil ein Edelteil die günstigen Teile mitträgt. Erlös und Kosten lagen beide vor, wurden aber nie zusammengeführt. Für 86 Prozent der verkauften Kilogramm gibt es einen wochengenauen Planpreis. Damit ist der Deckungsbeitrag rechenbar, und eine neue Seite sortiert Kunden und Artikel danach. Das Ergebnis widerspricht der Umsatzsicht: Zwei Kunden, die im Umsatz fast gleichauf liegen, tragen sehr unterschiedlich viel bei.

Ergebnis mit Messung

Die Nutzung messe ich am Anmeldeprotokoll, nicht an Rückmeldungen. Im Juni 2026 waren 18 Personen im Monat aktiv, im Juli und August je 23, im September 54. Der Sprung im September kommt vom dritten Standort, der seit Ende August angebunden ist. In 90 Tagen haben sich 60 Personen angemeldet, zusammen 1.074 Mal. Angelegt sind 67 persönliche Konten. 11 Personen waren an mindestens 27 Tagen aktiv, also fast jeden Arbeitstag. In den 90 Tagen kamen 44 Fehlermeldungen aus dem Betrieb. Für mich ist das ein gutes Zeichen: Wer etwas meldet, arbeitet damit.

Was ich nicht gemessen habe: Zeitersparnis. Ich behaupte deshalb keine. Ob die Plattform Entscheidungen verbessert, hängt an der Prognosegüte. Die habe ich gemessen und stelle sie in Projekt B dar, einschließlich der Ebenen, auf denen das Modell die einfache Fortschreibung nicht schlägt.

Was ich anders machen würde

388 Endpunkte sind zu viele für eine Person. Viele sind aus einzelnen Ansichten gewachsen. Ich würde früher eine kleinere, einheitliche Schnittstelle entwerfen und die Ansichten darauf aufbauen. Das kostet am Anfang Zeit und spart sie bei jeder späteren Änderung.

Ich würde das Rechtemodell von Anfang an als Daten bauen, nicht als Code. Der Umbau im September ging gut, weil ich ihn mit einem Prüfskript abgesichert habe. Nötig gewesen wäre er nicht.

Ich würde jeder Ablösung von Beginn an ein Abschaltdatum geben. Ein festes Datum zwingt alle Beteiligten, den neuen Weg ernst zu nehmen. Ohne Datum bleibt das alte Werkzeug länger offen, als ihm zusteht.

Ich würde das Betriebshandbuch ab dem ersten Release mitschreiben, nicht nachziehen. Als Einzelner bin ich der Engpass. Jede Seite, die ich früh schreibe, ist eine Frage weniger, die nur ich beantworten kann. Das KI-Team, das ich jetzt aufbaue, ist die Antwort darauf. Ich hätte früher auf den zweiten Kopf drängen sollen.

Technik

• React
• TypeScript
• FastAPI
• Python
• DuckDB
• Parquet
• RBAC
• Audit-Log
• Monitoring