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

Gemessen am Anmeldeprotokoll, April und Juli 2026. Im September 2026 sind es 35 Personen in einer einzigen Woche, von rund 40 möglichen an zwei von drei Standorten.

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 dieser Fallstudie: 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 der dritten Fallstudie.

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.

Rollen und Rechte legen fest, wer welche Bereiche sieht und welche Änderungen er vornehmen darf. Das Änderungsprotokoll hält fest, wer wann was geändert hat. Die Überwachung meldet mir Fehler, bevor ein Nutzer sie meldet. Diese drei Bausteine sind unspektakulär. Sie sind der Grund, warum ich die Plattform allein betreiben kann.

Die 13 Alt-Systeme und Handprozesse habe ich nacheinander abgelöst. 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. Die Plattform ersetzt sie durch Auswertungen mit tagesaktuellen Daten, einige im Halbstundentakt.

Ergebnis mit Messung

Die Nutzung messe ich am Anmeldeprotokoll, nicht an Rückmeldungen. Von April bis Juli 2026 ist die Zahl der aktiven Personen je Monat von 9 auf 28 gewachsen. In 90 Tagen gab es 767 Anmeldungen. Im September 2026 nutzen 35 Personen die Plattform in einer einzigen Woche, von rund 40, die an den beiden angebundenen Standorten dafür in Frage kommen. Wer sich anmeldet, arbeitet täglich damit, die Geschäftsführung eingeschlossen. Der dritte Standort kommt noch dazu. 13 Alt-Systeme und Handprozesse sind abgelöst.

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 der zweiten Fallstudie dar, einschließlich der Ebene, auf der 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 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