Endbestand beim Plattformwechsel: Die eine Zahl, die zweimal stimmen muss
Anfangsbestand plus Zukäufe minus Wareneinsatz — die Endbestandsformel ist unstrittig. Unstrittig ist auch, dass sie am Cutover-Wochenende zweimal gerechnet wird: einmal im alten System, einmal im neuen. Wir zeigen, warum dieselbe Ware je nach Bewertungsverfahren rund zwanzig Prozent verschieden viel wert ist, was aus einem einzigen Bestandsfeld in Shopify wird, und welche sieben Etappen zwischen T−21 und T+30 darüber entscheiden, ob Ihre Marge nach dem Wechsel noch berechenbar ist.
Der Endbestand ist die langweiligste Zahl im Unternehmen. Sie steht einmal im Jahr in der Bilanz, wird von der Steuerberatung geprüft und danach von niemandem mehr angesehen. In keinem Migrationsangebot, das wir je gelesen haben, kam sie vor.
Bis zu einem Wochenende im Jahr. Am Freitagabend wird das alte System eingefroren, am Montagmorgen läuft der neue Shop, und irgendwo dazwischen existiert derselbe Bestand zweimal: als Endbestand des Altsystems und als Anfangsbestand von Shopify. Wenn diese beiden Zahlen auseinanderliegen, liegen sie das für immer. Es gibt keinen Punkt in der Zukunft, an dem sich der Anfangsbestand noch einmal von selbst herleitet — er wird nur fortgeschrieben.
Wir haben das inzwischen oft genug gesehen, um den Verlauf vorhersagen zu können. Die Differenz fällt im ersten Monat niemandem auf, weil alle auf Bestellungen, Zahlungen und Weiterleitungen schauen. Im Quartal danach wundert sich das Controlling über eine Marge, die zu gut aussieht. Und beim Jahresabschluss stellt jemand die Frage, die dann keiner mehr beantworten kann: Woher kommen diese Zehntausend Euro?
Dieser Text handelt von der Vorarbeit, die genau diese Frage überflüssig macht. Sie kostet im Projekt wenige Tage und ist hinterher praktisch nicht nachholbar.
Die Formel bestreitet niemand — die Zuständigkeit schon
Rechnerisch ist die Sache trivial, und das ist Teil des Problems: Weil die Formel so einfach ist, wird angenommen, dass sie sich von selbst erledigt.
Die Formel
Vier Zahlen, vier Quellen — und nur eine davon steht im Shop
Die Rechnung ist in jedem Handelsunternehmen dieselbe und in keinem an einer Stelle hinterlegt. Beispielperiode eines mittelgroßen Händlers; die Beträge sind gegriffen, die Verteilung der Quellen ist es nicht. Beim Plattformwechsel wird jede der vier Größen einmal angefasst.
- Anfangsbestand 240.000 €
- Zukäufe (netto) 610.000 €
- Wareneinsatz − 585.000 €
- Schwund und Abschriften − 12.000 €
- Endbestand 253.000 €
Der Wert der Ware, die am Stichtag noch im Lager liegt. Gleichzeitig der Anfangsbestand der nächsten Periode — und damit die Zahl, die sich jeder Fehler von hier an weitervererbt.
Die Formel überlebt jeden Systemwechsel unverändert. Was sie nicht überlebt, sind die Zuständigkeiten dahinter: Welches System führt nach dem Cutover den Anfangsbestand, welches die Einstandspreise, welches die Abschriften? Wenn diese drei Fragen im Migrationsprojekt nicht beantwortet werden, beantwortet sie später der Zufall.
Was diese Aufstellung sichtbar macht, ist die eigentliche Schwierigkeit. Kein einziger der vier Terme entsteht dort, wo am Ende das Ergebnis abgelesen wird. Der Anfangsbestand kommt aus der letzten Inventur, die Zukäufe aus der Warenwirtschaft, der Wareneinsatz aus den Einstandspreisen und der Schwund aus der Lagerrealität, die oft überhaupt nicht erfasst wird.
Solange alles im selben gewachsenen System liegt, funktioniert das trotzdem — nicht, weil es sauber wäre, sondern weil seit Jahren dieselben Menschen dieselben Handgriffe machen. Ein Plattformwechsel zerlegt genau diese Routine. Danach steht die Frage im Raum, wer welche Zahl führt, und sie muss beantwortet werden, bevor jemand sie stellt.
Dieselbe Ware, drei zulässige Werte
Bevor es um Systeme geht, muss ein Punkt geklärt sein, der in Migrationsprojekten regelmäßig übergangen wird: Der Bestandswert ist keine Messung, sondern eine Entscheidung. Sie können dieselben Kartons im selben Regal auf drei zulässige Arten bewerten und bekommen drei verschiedene Zahlen.
Bewertungsverfahren
Dieselben 170 Einheiten im Regal — drei zulässige Werte dafür
Beispiel mit zwei Wareneingängen zu unterschiedlichen Einstandspreisen: 150 Einheiten zu 7 €, danach 150 Einheiten zu 9 €, zusammen 2.400 €. Verkauft werden 130 Einheiten. Was im Lager liegt, ist in allen drei Fällen identisch — der Wert in der Bilanz nicht.
-
Fifo
1.490 €Zuerst gekauft, zuerst verkauft. Im Bestand bleiben die jüngsten, hier teureren Einheiten.
-
Gewichteter Durchschnitt
1.360 €Alle Einheiten teilen sich einen Mischpreis. Der Bestandswert liegt zwischen den beiden Extremen.
-
Lifo
1.230 €Zuletzt gekauft, zuerst verkauft. Im Bestand bleiben die ältesten, hier günstigeren Einheiten.
Zwischen dem höchsten und dem niedrigsten Wert liegen 260 € — rund 21 Prozent, bei völlig unverändertem Lagerbestand. Auf einen ganzen Katalog hochgerechnet ist das die Größenordnung, in der sich ein unbemerkter Verfahrenswechsel bei der Migration bewegt. Zulässig ist jedes der Verfahren; unzulässig ist, mittendrin unbemerkt zu wechseln.
Der Effekt wird meistens unterschätzt, weil er im Einzelartikel nach Rundungsfehler aussieht. Auf einen Katalog mit fünf- oder sechsstelligem Bestandswert hochgerechnet reden wir über eine Größenordnung, die eine Steuerprüfung interessiert.
Und jetzt der Teil, der beim Systemwechsel gefährlich wird: Das Verfahren steckt bei den meisten Händlern nicht in einer Richtlinie, sondern in einer Voreinstellung. Es steht in der Warenwirtschaft, hat es nie in ein Dokument geschafft, und niemand im Projekt weiß, welches gerade aktiv ist. Wenn diese Warenwirtschaft bleibt, ist alles gut. Wenn sie im Zuge des Wechsels ersetzt oder umgangen wird, wechselt das Verfahren mit — unbemerkt, mitten im Geschäftsjahr.
Das ist keine technische Panne, sondern ein bilanzieller Vorgang. Ein Verfahrenswechsel ist grundsätzlich möglich, aber er will begründet, dokumentiert und mit der Steuerberatung abgestimmt sein. Was man nicht möchte, ist ihn erst zu bemerken, wenn er schon passiert ist.
Der praktische Handgriff dauert eine Stunde: Schreiben Sie vor dem Cutover auf, nach welchem Verfahren heute bewertet wird und nach welchem nach dem Wechsel. Zwei Sätze in der Projektdokumentation. Falls sich beide unterscheiden, haben Sie ein Thema für ein Gespräch statt für eine Betriebsprüfung.
Was Shopify mit Einstandspreisen macht — und was nicht
Hier lohnt eine nüchterne Einordnung, auch wenn wir als Shopify-Agentur an dieser Stelle erwartbar begeistert klingen könnten.
Shopify führt pro Variante ein Feld für die Kosten pro Artikel. Ein Feld, ein Wert, kein Schichtenmodell. Wird ein Artikel verkauft, rechnet Shopify den Wareneinsatz mit dem Wert, der zu diesem Zeitpunkt im Feld steht. Das ist für Margenberichte im Shop völlig ausreichend und für eine handelsrechtliche Bestandsbewertung nach Fifo mit sauberen Zugangsschichten ausdrücklich nicht gedacht.
Daraus folgt eine Arbeitsteilung, die man besser bewusst wählt als versehentlich erbt:
Shopify führt die Menge. Was liegt wo, was ist verfügbar, was ist zugesagt. Das ist die operative Wahrheit, und sie muss in Echtzeit stimmen, weil daran die Verkäuflichkeit hängt.
Das ERP oder die Warenwirtschaft führt den Wert. Zugangsschichten, Bewertungsverfahren, Abschriften, Inventurdifferenzen. Das ist die bilanzielle Wahrheit, und sie darf einen Tag hinterherhinken.
Wer beide Rollen in Shopify zusammenlegen will, kommt bis zu einer bestimmten Unternehmensgröße gut damit durch — und merkt beim ersten Jahresabschluss danach, wo die Grenze lag. Wer sie umgekehrt beide im ERP belässt und Shopify nur als Anzeigefläche betreibt, kauft sich Synchronisationsprobleme ein, die im Tagesgeschäft weh tun. Welche Muster dafür in der Praxis tragen, haben wir in ERP-Integration mit Shopify durchgespielt.
Das Feld „Kosten pro Artikel“ verdient dabei besondere Aufmerksamkeit, weil es der stillste Fehler der ganzen Migration ist. Es ist optional. Ein Import ohne diese Spalte läuft fehlerfrei durch, der Shop funktioniert, alle sind zufrieden — und jeder Margenbericht der nächsten Monate rechnet mit einem Wareneinsatz von null. Die Zahlen sehen dann nicht falsch aus, sondern hervorragend. Das ist derselbe Mechanismus, den wir beim Bruttowarenwert nach dem Plattformwechsel beschrieben haben: Die schmeichelhafte Zahl ist immer die, die zuerst wieder da ist.
Aus einem Feld werden fünf Zustände
Der zweite Bruch ist kein Wert-, sondern ein Strukturthema. Gewachsene Systeme führen pro Artikel eine Bestandszahl. Shopify führt Bestandszustände, und zwar je Standort.
Bestandszustände
Aus einer Zahl werden fünf — und das je Standort
Ein Artikel, 412 Stück im Lager. Im Altsystem ist das ein Feld. In Shopify ist es ein Bestand vor Ort, der sich in Zustände aufteilt, von denen nur einer über die Verkäuflichkeit entscheidet. Wer beim Import alles in „verfügbar“ schreibt, hat am ersten Tag 94 Einheiten zu viel im Verkauf.
Altsystem
412
Bestand
Ein Feld, eine Zahl, keine Zustände. Häufig auch: nur ein Lagerort.
Shopify
Bestand vor Ort 412
- Verfügbar 318
Frei verkäuflich. Nur diese Zahl entscheidet, ob der Shop den Artikel anbietet.
Typischer Importfehler Wird beim Import gern mit dem Gesamtbestand gleichgesetzt — dann verkaufen Sie Ware, die längst zugesagt ist.
- Zugesagt 54
In bezahlten, aber noch nicht versandten Bestellungen gebunden.
Typischer Importfehler Entsteht am Cutover-Tag aus den offenen Bestellungen des Altsystems. Werden die nicht mitgezählt, überverkaufen Sie in der ersten Woche.
- Qualitätskontrolle 18
Physisch da, geprüft wird noch. Zählt zum Bestand vor Ort, nicht zum verfügbaren.
Typischer Importfehler In vielen Altsystemen gar nicht abgebildet — die Ware steht dort entweder voll im Bestand oder gar nicht.
- Beschädigt 9
Im Regal, aber nicht verkäuflich. Der ehrlichste Teil jeder Inventur.
Typischer Importfehler Wird beim Import mitgezählt und verschwindet damit als eigene Position. Der Schwund taucht später als „unerklärliche Differenz“ wieder auf.
- Sicherheitsbestand 13
Bewusst zurückgehalten, etwa für Ersatzlieferungen oder den Filialverkauf.
Typischer Importfehler Im Altsystem oft eine Kopfrechnung des Lagerleiters. In Shopify ist sie ein Feld — das jemand füllen muss.
Dazu kommt 240 eingehend — bestellte Ware, die noch beim Lieferanten liegt. Sie gehört nicht zum Bestand vor Ort. Wird sie beim Import trotzdem eingerechnet, stimmt Ihr Endbestand um genau diese Menge nicht.
Und das Ganze mal Standorte: Zentrallager, Filiale Innenstadt, Fulfillment-Partner. Jeder Standort führt seine eigenen Zustände. Wer aus einem einzigen Bestandsfeld migriert, muss vorher entscheiden, wo diese Ware künftig liegt — die Frage stellt sich sonst zum ersten Mal, wenn die erste Bestellung dem falschen Lager zugewiesen wird.
Diese Aufteilung ist im laufenden Betrieb ein Gewinn — sie ist der Grund, warum ein Shopify-Shop mit Filialen, Fulfillment-Partner und Zentrallager überhaupt sauber verkaufen kann, ohne dass jemand eine Excel-Tabelle danebenlegt. Wie weit das trägt, wenn stationärer Handel dazukommt, steht in Unified Commerce auf Shopify Plus.
Beim Import ist dieselbe Aufteilung eine Falle, weil die Quelldaten sie nicht hergeben. Aus einem einzigen Zahlenfeld lässt sich nicht ableiten, welcher Anteil zugesagt, welcher beschädigt und welcher bewusst zurückgehalten ist. Diese Information existiert oft nur im Kopf der Lagerleitung. Sie muss vor dem Import einmal aufgeschrieben werden — sonst schreibt der Import alles in „verfügbar“, und der Shop verkauft in der ersten Woche Ware, die längst jemandem gehört.
Überverkäufe in Woche eins sind besonders teuer, weil sie auf die Kundschaft treffen, die den neuen Shop zuerst ausprobiert. Eine Stornomail drei Tage nach dem Relaunch ist der schlechteste denkbare erste Eindruck, und sie ist vollständig vermeidbar.
Phantombestand: die Differenz, die niemand sehen will
Bleibt der unangenehmste Teil. In jedem gewachsenen Lager weicht der Systembestand vom tatsächlichen ab. Die Ursachen sind banal — Bruch, der nicht gemeldet wurde, Retouren, die nie eingebucht wurden, Ware, die für ein Fotoshooting mitgenommen und nie zurückgebracht wurde, Zählfehler aus früheren Inventuren, die sich seither fortschreiben.
Diese Differenz ist über Jahre gewachsen, und sie hat einen Namen: Phantombestand. Artikel, die das System als vorhanden führt und die niemand mehr finden kann.
Solange nichts passiert, lebt es sich damit. Ein Plattformwechsel ist der Moment, in dem die Differenz sichtbar wird, weil zum ersten Mal seit Jahren wieder gezählt wird — und das ist eine gute Nachricht, die sich schlecht anfühlt. Drei Dinge sind dabei wichtig:
Zählen Sie, bevor Sie migrieren, nicht danach. Ein Import auf Basis des Systembestands übernimmt die Differenz in das neue System und macht sie damit unauffindbar. Danach ist sie kein Altlastenproblem mehr, sondern ein Fehler im neuen Shop.
Vollständig ist schön, Stichprobe ist realistisch. Eine komplette Inventur mitten im Migrationsprojekt scheitert an den Menschen, die gleichzeitig testen sollen. Eine Stichprobe über die Artikel, die achtzig Prozent des Bestandswerts ausmachen, ist in ein bis zwei Tagen machbar und fängt den größten Teil der Differenz ab.
Buchen Sie die Differenz aus, statt sie zu verrechnen. Der Reflex, den fehlenden Bestand einfach im neuen System kleiner anzusetzen, ist verständlich und falsch. Der Schwund gehört als Schwund in die Bücher — dort, wo man ihn im nächsten Jahr wiederfindet und mit dem des Vorjahres vergleichen kann.
Der Schnitt ist kein Tag, sondern ein Fenster
Damit sind alle Bausteine beisammen, und sie lassen sich auf eine Zeitachse legen. In Projektplänen steht der Bestand meist als eine Zeile am Cutover-Wochenende. Tatsächlich beginnt die Arbeit drei Wochen vorher.
Das Schnittfenster
Der Bestandsschnitt ist kein Tag, sondern sechs Wochen
In Projektplänen steht der Bestand als eine Zeile am Cutover-Wochenende. Tatsächlich beginnt er drei Wochen vorher und endet einen Monat danach — und die teuren Fehler passieren nicht am Stichtag, sondern an den Rändern. Zu jeder Etappe gehört jemand, der die Zahl verantwortet. Wenn diese Spalte leer bleibt, verantwortet sie niemand.
- T−21
Stichtag und Verfahren festlegen
Datum des Bestandsschnitts festschreiben und dokumentieren, nach welchem Verfahren bewertet wird — im Altsystem und danach in Shopify.
Verantwortet Projektleitung gemeinsam mit Buchhaltung und Steuerberatung
Wird die Etappe ausgelassen Das Verfahren wechselt unbemerkt mit dem System. Die Differenz fällt erst beim Jahresabschluss auf, wenn niemand mehr rekonstruieren kann, woher sie kommt.
- T−14
Katalog bereinigen
Ladenhüter abwerten, unverkäufliche Ware ausbuchen, Einstandspreise je Artikel prüfen und Lücken schließen.
Verantwortet Einkauf, mit dem Lager als Gegenprüfung
Wird die Etappe ausgelassen Sie migrieren Ware, die niemand mehr verkauft, zu Preisen, die niemand mehr kennt — und zahlen auf einen aufgeblähten Bestandswert Steuern.
- T−3
Wareneingänge schließen
Offene Lieferungen entweder vollständig einbuchen oder bewusst hinter den Stichtag schieben. Kein Wareneingang darf im Fenster hängen.
Verantwortet Lagerleitung
Wird die Etappe ausgelassen Eine Palette wird im Altsystem eingebucht und in Shopify noch einmal — oder in keinem von beiden. Beides fällt erst Wochen später auf.
- T−1
Zählen
Physische Zählung, mindestens als Stichprobe über die A-Artikel. Die Differenz zum Systembestand wird dokumentiert, nicht wegdiskutiert.
Verantwortet Lager, protokolliert von der Buchhaltung
Wird die Etappe ausgelassen Sie übernehmen den Phantombestand des Altsystems ungeprüft. Jede Überverkaufsmeldung der nächsten Monate hat hier ihren Ursprung.
- T0
Cutover
Der gezählte Bestand wird zum Anfangsbestand in Shopify — aufgeteilt nach Standort und Zustand, offene Bestellungen als zugesagte Menge.
Verantwortet Migrationsteam, freigegeben von der Buchhaltung
Wird die Etappe ausgelassen Wird alles als „verfügbar“ importiert, verkaufen Sie in der ersten Woche Ware, die längst einer Bestellung gehört.
- T+7
Fenster nachbuchen
Alles, was während des Schnitts passiert ist — Verkäufe, Retouren, Wareneingänge — wird nachgetragen und gegen die Belege geprüft.
Verantwortet Buchhaltung
Wird die Etappe ausgelassen Das Fenster bleibt als dauerhafte Differenz stehen. Sie ist klein genug, um ignoriert zu werden, und groß genug, um jede spätere Abweichungsanalyse zu vergiften.
- T+30
Gegenprobe, solange das Altsystem lebt
Stichprobe über Bestandswert, Wareneinsatz und Marge — parallel im alten und im neuen System, bevor der alte Zugang endet.
Verantwortet Controlling
Wird die Etappe ausgelassen Nach der Abschaltung gibt es keine Vergleichsgröße mehr. Ab da ist der neue Wert per Definition richtig, auch wenn er es nicht ist.
Die letzte Etappe ist die, die am häufigsten gestrichen wird, weil zu diesem Zeitpunkt alle erleichtert sind und der Shop läuft. Sie ist zugleich die einzige, die sich später nicht nachholen lässt: Sobald das Altsystem abgeschaltet ist, gibt es keinen zweiten Wert mehr, gegen den man prüfen könnte.
Die Etappe, über die im Projekt am meisten gestritten wird, ist T−3: Wareneingänge schließen. Der Einkauf hört ungern, dass drei Tage lang keine Palette angenommen werden soll, und hat damit betriebswirtschaftlich recht. Der Kompromiss, der in der Praxis funktioniert, ist kein Annahmestopp, sondern eine klare Regel: Alles, was vor dem Stichtag ankommt, wird noch am selben Tag im Altsystem eingebucht — alles danach bleibt im Wareneingangsbereich stehen und wird nach dem Cutover in Shopify erfasst. Kein Vorgang darf über den Schnitt hinweg offen sein.
Die Etappe, die am häufigsten gestrichen wird, ist T+30. Zu diesem Zeitpunkt läuft der Shop, alle sind erleichtert, und niemand hat Lust, zwei Systeme gegeneinander zu rechnen. Sie ist trotzdem die wichtigste, weil sie die einzige ist, die sich später nicht nachholen lässt. Warum solche „Danach“-Positionen in Migrationsplänen systematisch untergehen, haben wir im Risikomanagement beim Plattformwechsel beschrieben.
Fünf Fehler, die auch mit einem guten Plan passieren
Der Bestand wird zu früh eingefroren. Ein Bestandsexport, der zwei Wochen vor dem Cutover gezogen und am Stichtag importiert wird, ist zum Zeitpunkt des Imports schon veraltet. Zwei Wochen Verkauf und Wareneingang fehlen. Das passiert häufiger, als man denkt, weil der Export ein technischer Schritt ist und technische Schritte gern vorgezogen werden.
Varianten und Bündel werden gleich behandelt. Ein Set aus drei Artikeln hat keinen eigenen Bestand, sondern hängt an den Beständen seiner Bestandteile. Wird es als eigener Artikel mit eigener Menge migriert, existiert dieselbe Ware im System doppelt — einmal als Bündel, einmal als Einzelteil. Der Endbestand ist dann rechnerisch korrekt und physisch unmöglich.
Retouren im Schnittfenster fallen durchs Raster. Eine Rücksendung, die im alten Shop bestellt und nach dem Cutover zurückgeschickt wird, hat in Shopify keine zugehörige Bestellung. Ihre Ware liegt danach im Regal, ohne dass ein System sie kennt. Für die ersten vier bis sechs Wochen braucht es dafür einen manuellen Weg — und jemanden, der ihn kennt.
Die Einstandspreise werden aus dem falschen Feld gezogen. Viele Altsysteme führen mehrere Preisfelder: den letzten Einkaufspreis, den kalkulatorischen Einkaufspreis, den Listenpreis des Lieferanten. Nur einer davon ist der, mit dem heute bewertet wird. Wird beim Import der falsche genommen, ist die Marge ab Tag eins um einen konstanten Faktor daneben — konstant genug, um plausibel auszusehen.
Niemand vergleicht die Summe. Der einfachste Test der ganzen Migration wird am seltensten gemacht: Bestandswert im Altsystem gegen Bestandswert in Shopify, eine Zahl gegen eine Zahl, am selben Stichtag. Es dauert zehn Minuten. Wenn die Summen auseinanderliegen, wissen Sie es an dem Tag, an dem Sie noch etwas dagegen tun können.
Was die Plattform beisteuert — und was nicht
Ein Plattformwechsel macht Ihren Bestand nicht genauer. Er macht ihn nachvollziehbarer.
Konkret sind das drei Dinge. Jede Bestandsbewegung bekommt einen Zeitstempel, einen Standort und einen Grund, statt als stille Korrektur in einem Feld zu verschwinden. Die Zustände sind benannt, sodass „verfügbar“ und „vorhanden“ nicht länger dasselbe Wort für zwei verschiedene Dinge sind. Und die Schnittstelle zum ERP ist definiert, statt aus einem gewachsenen Skript zu bestehen, das eine Person geschrieben hat, die nicht mehr im Unternehmen ist.
Was die Plattform nicht liefert: den Wert. Shopify weiß, was Sie im Regal haben. Was es wert ist, hängt an einem Feld, das jemand füllen muss, und an einem Verfahren, das jemand festlegen muss. Beides sind Entscheidungen, keine Einstellungen — und beide fallen am besten vor dem Cutover, nicht danach.
Wo Sie ansetzen, je nach Ausgangslage
| Ihre Situation | Der erste Handgriff |
|---|---|
| Migrationsangebot liegt vor, Bestand ist eine Zeile darin | Nachfragen, ob Einstandspreise und Bestandszustände zum Lieferumfang gehören — nicht nur Mengen |
| Niemand weiß, nach welchem Verfahren heute bewertet wird | Vor dem Cutover schriftlich klären. Eine Stunde jetzt, statt einer Diskussion beim Jahresabschluss |
| Letzte vollständige Inventur liegt über ein Jahr zurück | Stichprobe über die Artikel planen, die achtzig Prozent des Bestandswerts tragen |
| Es gibt nur einen Lagerort im System, aber mehrere in echt | Standortstruktur vor dem Import festlegen. Nachträglich umzulagern ist deutlich aufwendiger als richtig anzulegen |
| Sets und Bündel sind Teil des Sortiments | Für jedes Bündel entscheiden, ob es Bestand führt oder an seinen Bestandteilen hängt — vor dem Export |
| Das ERP soll bleiben | Festschreiben, wer die Menge führt und wer den Wert. Eine Zeile Dokumentation verhindert ein Jahr Synchronisationsärger |
| Das ERP soll mit abgelöst werden | Bewertungsverfahren und Zugangsschichten sind dann heimatlos. Klären, wo sie künftig liegen, bevor der Cutover terminiert wird |
| Der Abschalttermin des Altsystems steht schon fest | Mindestens 30 Tage Überlappung sichern. Ohne Vergleichswert ist jede spätere Differenz unauflösbar |
Checkliste
Vor dem Bestandsschnitt: elf Punkte
Abzuarbeiten, solange das Altsystem noch läuft und der Migrationsauftrag noch verhandelbar ist. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 11 erledigt
Von diesen elf Punkten sind zwei nach dem Cutover nicht mehr nachholbar: die Zählung und die Überlappung. Alles andere lässt sich mit Aufwand reparieren. Diese beiden nicht, weil die Vergleichsgröße dann physisch nicht mehr existiert.
Der Rest ist unspektakulär, und das ist der Grund, warum er liegen bleibt. Niemand hält eine Präsentation über gepflegte Einstandspreise, und in keiner Relaunch-Ankündigung steht etwas über Bestandszustände. Sie sind trotzdem der Unterschied zwischen einem Shop, dessen Zahlen ab dem ersten Monat tragen, und einem, in dem ein Jahr später jemand einen Betrag sucht, den niemand mehr erklären kann.
Wenn bei Ihnen ein Wechsel ansteht und Sie wissen wollen, wie Ihr Bestand dabei sauber hinüberkommt: Lassen Sie uns sprechen — wir sehen uns Ihre heutige Bestandsführung, den geplanten Importumfang und die Rollenverteilung zwischen Shop und Warenwirtschaft an und sagen Ihnen, welche Vorarbeit sich rechnet und welche nicht.
