Absatzprognose je Artikel

Vorab gerechnet

Bestellhistorie, Saison und Auftragslage ergeben eine Prognose je Artikel — weniger Lagerleichen, weniger Fehlmengen. Wir möchten das als internen Prototyp für unser Unternehmen umsetzen.

Gerechnet am 11.09.2026 um 22:18 Uhr

Ihr erster Prototyp · Festpreis netto

6.390 €

Prototyp Aufwand 58 / 100 · ca. 6 Wochen

So haben wir Sie verstanden

Ein interner Prototyp soll aus Bestellhistorie, Saisonverlauf und Auftragslage eine Absatzprognose je Artikel berechnen, um Lagerleichen und Fehlmengen zu reduzieren.

Was der Prototyp enthält

Prognose für eine Artikelgruppe auf Basis vorhandener Bestelldaten mit einfacher Übersichtsseite.

58/100

Aufwands-Meter — 100 heißt maximaler Aufwand und maximaler Preis, keine Note.

Datenaufbereitung, Prognoselogik und Auswertung ohne klar definierte Datenquelle oder Modellvorgabe

Danach: Vollausbau

Vollausbau ab 77.000 € · indikativ bis 100.000 € · 6 Wochen · Team aus 3

Komponenten

Datenanbindung & Aufbereitung7 PT
Prognosemodell je Artikel9,75 PT
Anzeige & Auswertung5,5 PT
Architektur & Datenmodell2,75 PT

Besetzung

Inventive Engineer (Architektur)
Senior Developer (Senior .NET-Entwickler)
Lead Developer (Lead .NET-Entwickler)

Annahmen hinter dem Preis

Bestelldaten liegen strukturiert in einer bestehenden Datenbank oder Exportdatei vor
Prognose läuft im Haus mit einem gelernten Modell (ML.NET), eine externe KI-Anbindung ist nicht nötig
Nutzung durch wenige interne Mitarbeiter ohne komplexe Rechteverwaltung

Was wir zu Beginn klären

Aus welchem System stammen Bestellhistorie und Auftragslage konkret?
Wie viele Artikel und wie lang ist die verfügbare Historie?
Welche Genauigkeit bzw. welches Prognoseverfahren wird erwartet?

Der Fahrplan — was in welcher Woche fertig ist

Woche 1 Kickoff Abstimmung, Zugänge, Feinschnitt des Umfangs
Woche 3 Datenanbindung & Aufbereitung 7 PT
Woche 4 Prognosemodell je Artikel 9,75 PT
Woche 5 Anzeige & Auswertung 5,5 PT
Woche 5 Architektur & Datenmodell 2,75 PT
Woche 6 Abnahme Übergabe nach Abnahme und Restzahlung

Verstärkung: Köpfe auf Abschnitte legen

1 Woche früher, Abnahme in Woche 5 statt 6: „Datenanbindung & Aufbereitung“ +1 Senior Developer (Senior .NET-Entwickler), „Architektur & Datenmodell“ +1 Tester · +130 €
2 Wochen früher, Abnahme in Woche 4 statt 6: „Datenanbindung & Aufbereitung“ +1 Senior Developer (Senior .NET-Entwickler), „Prognosemodell je Artikel“ +1 Senior Developer (Senior .NET-Entwickler), „Anzeige & Auswertung“ +1 Senior Developer (Senior .NET-Entwickler), „Architektur & Datenmodell“ +1 Tester · +320 €
3 Wochen früher, Abnahme in Woche 3 statt 6: „Datenanbindung & Aufbereitung“ +2 Senior Developer (Senior .NET-Entwickler), „Prognosemodell je Artikel“ +3 Senior Developer (Senior .NET-Entwickler), „Anzeige & Auswertung“ +3 Senior Developer (Senior .NET-Entwickler), „Architektur & Datenmodell“ +1 Tester · +570 € hilft am meisten

Legen Sie Köpfe auf die Abschnitte, die schneller fertig werden sollen: dieselben Stunden, mehr Köpfe, weniger Wochen — wie bei den Tempopaketen, ein Kopf mehr +5 %, zwei +8 %, drei +10 %, vier +12 % auf den Anteil des Abschnitts am MVP-Festpreis. Entwickler kommen nicht auf Abschnitte, die andere zusammenführen, und nicht auf, was erst im letzten Drittel beginnt — dort macht ein weiterer Entwickler ein Projekt langsamer. Auf den letzten Abschnitt vor der Abnahme legen Sie stattdessen Tester. Wer die Köpfe sind, wählen wir.

Lastenheft und Pflichtenheft

Ziel Ein interner Prototyp liefert je Artikel eine Bedarfsprognose auf Basis vorhandener Daten.

Lösungsweg Eine ASP.NET-Core-Anwendung liest vorhandene Bestell- und Auftragsdaten aus SQL Server, berechnet artikelbezogene Prognosen und stellt sie in einer Übersicht dar.

Was gefordert istDas System muss Bestellhistorie, Saisonverlauf und aktuelle Auftragslage je Artikel zusammenführen.

Wie wir es umsetzenImport und Aufbereitung von Bestellhistorie, Saison- und Auftragsdaten in SQL Server via EF Core
Was gefordert istDas System muss daraus eine Prognose je Artikel berechnen.

Wie wir es umsetzenImplementierung eines statistischen Prognosealgorithmus je Artikel in C#/.NET
Was gefordert istDas System muss die Prognose für interne Mitarbeiter einsehbar machen.

Wie wir es umsetzenRazor-Oberfläche zur Anzeige der Prognosewerte je Artikel
Was gefordert istDas System muss als Prototyp für das eigene Unternehmen nutzbar sein.

Wie wir es umsetzenBereitstellung des Prototyps für interne Mitarbeiter über bestehende Infrastruktur

Rahmenbedingungen

Interne Nutzung, keine externen Kunden
Prototypcharakter, kein produktiver Vollbetrieb vorgesehen
Frist von rund sechs Wochen für ersten Prototyp

Nicht im Umfang

Keine automatisierte Bestellauslösung
Keine Anbindung an Warenwirtschaft oder ERP im Prototyp
Keine mobile Anwendung
Keine mehrsprachige Oberfläche

Woran Sie die Abnahme messen

Prognosewerte für mindestens eine reale Artikelgruppe werden angezeigt
Berechnung basiert auf tatsächlich importierten Bestell- und Auftragsdaten
Übersicht ist von mindestens einem internen Nutzer ohne Schulung bedienbar
Prototyp lauffähig innerhalb der vereinbarten sechs Wochen

Meilensteine

Woche 3: Datenanbindung & Aufbereitung
Woche 4: Prognosemodell je Artikel
Woche 5: Anzeige & Auswertung
Woche 5: Architektur & Datenmodell
Woche 6: Abnahme

Technologien, die wir einsetzen

.NET 10 LTS
C# 14
ASP.NET Core MVC & Razor Pages
Entity Framework Core & Dapper
SQL Server 2025
ML.NET & ONNX Runtime
Hangfire & Quartz.NET

.NET 10Laufzeitbasis der Anwendung
C# 14Implementierung der Prognoselogik und Datenverarbeitung
ASP.NET Core MVCWeb-Anwendung zur Anzeige der Prognosen
Razor ViewsServerseitige Oberfläche für die Artikelübersicht
EF Core 10Zugriff auf Bestell- und Auftragsdaten
SQL ServerSpeicherung von Bestellhistorie, Auftrags- und Prognosedaten
ML.NET & ONNX RuntimeDas Prognosemodell aus Bestellhistorie, Saisonverlauf und Auftragslage
Hangfire & Quartz.NETDer nächtliche Lauf, der die Prognose je Artikel neu rechnet

← Zurück zum Portfolio

NAVIGATION