Super Sache, dann will ich hier mal unsere Anforderungen schildern, wofür wir uns selber was auf SQL Basis gebaut haben:
- Mindestbestand unterschritten: Wäre(ist) ein super Feature, wenn der Wert dynamisch nach vorgegebner Formel ermittelt würde.
Wir benutzen/misbrauchen den. Wenn nach unserer Rechnung der Bestand den Bedarf unterschreitet, wir der Mindestbestand im Sinne eines Indikators auf 100.000 Stk gesetzt und wir sehen im Dashboard, dass wir den Bestellen müssen, erstellen eine Bedarfskalkulation und bestellen dann.
Wir haben gute Erfahrung mit 2,5 x Bezugszeit als Puffer. 2,5 hat für uns den Vorteil, dass sollte eine Sendung untergehen oder der Bedarf drastisch steigen, man nochmals bestellen kann und die Ware kommt bevor man leerläuft. Selbst für Händler die nur 2-3 Tage Lieferzeit für Nachschubhaben ist das immer noch ein praktischer Wert.
Hier könntet Ihr ganz simpel eine lineare Formel wie mx+b anwenden, damit sollten 90% aller Händler auskommen.
Konkret: Faktor(Puffer) x Bezugszeit + Offset (Puffer, was heute der Mindestbestand ist - z.B. eine Monatsmenge händisch ermittelt)
- Bisher wird in der Bestellplanung die Bezugszeit (Produktionszeit + Lieferzeit) nicht berücksichtigt, da wir ein produzierdendes Unternehmen in Fernost sind, dauert es von der Bestellung bis die Ware bei uns ist 3-6 Monate. Dies muss sowohl in den Punkten Bestellzeitpunkt als auch Bestellmenge berücksichtigung finden. Also früh genug ausreichend bestellen. Wir schreiben aktuell in die Lieferzeit den Wert der Bezugszeit rein.
- Der Betrachtungszeitraum (Verkäufe) sollte für jeden Artikel seperat pflegbar sein. Jeder Artikel ist individuell vom Absatz. Manche sind voll saisional, mache teilweise, andere garnicht und manche sind erst kurz am Markt und obwohl sie saisional wären, haben sie noch keine Historie über eine Saision. Wir haben daher ein eigenes Feld definiert, das wir pflegen wie weit der Artikel in den Verkäufen zurück betrachtet werden soll.
Neue Artikel oder nicht saisionale Artkel betrachten wir daher 30 Tage Rückblickend. Saisionale mit 365 Tagen, sofern sie schon eine räpräsentative Periode/Saision hinter sich haben.
- Natürlich müssen alle Bestellungen im Zulauf berücksichtigt werden. So können wir auch schön sehen, wenn der Bedarf drastisch ansteigt, dass wir obwohl wir schon eine Bestellung am laufen haben eine weitere tätigen müssen. Das hat sich bei uns schon mehrfach bewährt und wir hatten teilweise drei Bestellungen für einen Artikel parallel im Zulauf.
- Amazon Bestände verbessern: Es gibt drei Zustände für Reservierte Waren, mind. der Bestand "Reserviert in Umlagerung zwischen Versandzentren", wird von euch heute nicht erfasst, müsste es aber.
Da sind sehr erhebliche Mengen (30-50 Tages-Absatz) z.B. auf dem Weg von DTM2 nach Polen und die Ware ist dann für 1-2 Wochen vom Erdboden verschwunden, bis Amazon die final auf Bestand bucht.
Das ist ein deutliches Problem, denn es hat einerseits zur Folge, dass wir zum einen weitere Umlagerungen an Amazon anlegen, obwohl gerade erst Ware hingegangen ist. Folge: Es entstehen "teurere" Lagerkosten bei Amazon, bis hin zu drohenden Strafgebühren. Andererseits bestellen wir "zu früh" Ware nach, was unnötige Liquiditätsbelastungen nach sich zieht.
- Klar und dann darauf Bestellvorschläge in VPEe vielfachen unter der der Maßgabe der gewünschten Reichweite. Wir füllen den Bestand z.B. in der Regel auf einen Jahresbedarf auf.
Fazit ToDo:
- Zwei Felder für Faktor(Bezugszeit) und Offset um Mindestbestand per Regel "dynamisch" ermitteln zu lassen.
- Feld Bezugszeit/Produktionszeit anlegen
- Feld Betrachtungszeitraum anlegen
- Bestellung im Zulauf im Bestand berücksichtigen
- Amazon Bestände, besser erfassen
Und zum Schluss haben wir noch unseren ALLER, ALLER größten Pain, der aber hier nur teilweise hingehört, aber Schnittmengen hat.
Problem: Wir bekommen den identisch selben Artikel gleich fertig von unserm Lieferanten inkl. FNSKU belabelt.
Problem es gibt aktuell bis zu 4 verschiedene FNSKUs für den sonst gleichen Artikel. DE-
FBA, DE-S&L, USA-FBA, USA-S&L. Das konnten wir nur lösen in dem wir Artikel-Dubletten angelegt haben, da wir die lagertechnisch sonst nicht auseinander halten können und unser
FFN die auch nicht verwalten und scannen kann.
Das macht uns überall Probleme in der
Artikelpflege, Lagerhaltung, Angebotsverwaltung /-vorlagen,
Shop,
Bestandsplanung, Liquiditätsplanung.
Effektiv und kostentechnisch ist das (für uns) die einzige Möglichkeit das so zu handhaben, hat aber Konsequenzen.
Hier mal ein Fall, gibt noch unzählige mehr:
Dann treten so Alltagsprobleme auf wie, FBA Bestand im FFN leer -> eBay + Shop keine Sales. S&L Bestand aber noch da.
Da könnte man jetzt
a) vom FFN-Fulfiller umlabeln und umbuchen lassen oder
b) man listet jetzt S&L statt den FBA Artikel bei ebay und Shop
Umlabeln dauert 2-3 Tage und ist teuer - neu listen kostet Ranking und auch 2-3h Arbeit den ganzen Content im Shop und eBay auf "vordermann" zu bringen.
Wahl also zwischen Pest und Colera.
Eigentlich müsste es eine Art Haupt- / Unterartikelsystem (Zustand) geben, dass denselben Artikel mit verschieden Zuständen/Labels a,b,c und den mengen x,y,z im Lager unter einem "Dach" führt.
Hierrüber würde dasselbe Produkt nicht nur mit verschiedenen FNSKU Labels für FBA, USA, S&L am Lager liegen, sonderrn auch die Retouren mit Zuständen wie Gebraucht, B-Ware, "wie neu", gesperrt, "noch aufzubereiten", defekt.
Also jeder Zustand wird definiert und ist gesondert lagerbar. "Neu FNSKU FBA", "Neu FNSKU S&L", "Refurbished", ... mit Lagerort und Position.
Dann würde man weiter definieren können, dass die Zustände "Neu FNSKU FBA" und "Neu FNSKU S&L" auf den Kanälen Shop und eBay zur Verfügung stehen und sich somit von beiden Beständen bedient werden kann.
Das zieht sich dann natürlich durch das ganze System, über Listings und auch die Bestellplanung.
