Deine Inventartabelle bricht bei 10k SKUs
Bei ~10k SKUs mit Varianten und Standorten wird eine Inventartabelle langsam und fehleranfällig. Die vier Fehlerbilder — und der Migrationsweg zu einer Datenbank.
Das Problem
Dein Inventar lebt in einer Tabellenkalkulation. Nicht weil es jemand bewusst gewählt hat — sie war kostenlos, vertraut, und jeder wusste, wie man sie benutzt. Sie funktionierte mit 500 SKUs. Sie funktionierte, langsam, mit 2.000. Dann wuchs die Produktlinie: Varianten, Farben, Größen, drei Lieferanten, zwei Lager, ein Shopify-Shop plus eine Großhandelsliste, und irgendjemand begann eine Bewegungserfassung in einem zweiten Tab “nur für die Historie”.
Diese Tabelle ist jetzt das teuerste Werkzeug deiner Abläufe, und die Rechnung taucht an seltsamen Stellen auf. Bestellungen werden überverkauft, weil zwei Personen gleichzeitig denselben Bestand geändert haben. Ware liegt im Lager, während die Tabelle sagt, sie sei ausverkauft. Die Mitarbeiter hören auf, den Zahlen zu vertrauen, und beginnen, von Hand nachzuzählen. Niemand aktualisiert die Tabelle mehr, weil das Aktualisieren zu lange dauert und niemand dem Ergebnis glaubt.
Dieser Artikel behandelt den Moment, in dem ein Tabellen-Inventar bricht: die vier Fehlerbilder, warum es bei etwa 10.000 SKUs passiert (nicht am theoretischen Zeilenlimit) und wie “echt” aussieht, wenn die Tabelle durch eine kleine Datenbank mit einer schlanken, durchsuchbaren Oberfläche ersetzt wird.
Die vier Fehlerbilder
1. Suchen und Filtern bricht zusammen
Einen SKU zu finden wird zum Ritual. Du fügst einen Code in das Filterfeld ein, die Tabelle friert einige Sekunden lang ein, dann zeigt sie drei Zeilen — und eine davon ist die Zeile der falschen Variante, weil die Suche den Lieferantencode in einer entfernten Spalte getroffen hat.
Bei 10.000 SKUs mit durchschnittlich drei Varianten pro Artikel umfassen allein die Stammdaten Zehntausende von Zeilen und mehr als 20 Spalten. Filter berechnen über jede Zeile neu, und die Leute hören stillschweigend auf, sie zu benutzen — sie merken sich einen Umweg oder fragen einen Kollegen, der “weiß, wo die Dinge sind”. Jede Frage wird zu einem Meeting.
2. Gleichzeitige Änderungen korrumpieren Bestände stillschweigend
Ein Bestand in einer Tabelle ist nur eine Zelle. Zwei Personen können die Tabelle öffnen, beide sehen Bestand = 40 und beide ändern ihn — eine auf 37 nach einem Verkauf, eine auf 52 nach einer Lieferung. Tabellen lösen den Konflikt nach dem Prinzip “der letzte Schreibzugriff gewinnt”, und niemand sieht den Verlierer. Es überlebt die Änderung, die zuletzt gespeichert wurde, nicht die, die richtig war.
Beim Inventar ist das schlimmer als in jeder anderen Funktion, weil der Korrekturzyklus langsam ist. Der falsche Bestand lebt tagelang in der Tabelle und erzeugt falsche Meldebestände, falsche Verfügbarkeitszusagen an Kunden und falsche Zahlen auf der Einkaufsseite. Wenn es jemand merkt, weichen Tabelle und Lager um einen Betrag voneinander ab, dessen Abgleich Stunden dauert.
3. Formel-Neuberechnung macht jede Änderung zum Warten
Inventartabellen stützen sich auf spaltenweite Nachschläge — VLOOKUP, SUMIFS, QUERY, IMPORTRANGE — um Mengen und Kosten über Tabs hinweg zu summieren. Jede Änderung löst eine Neuberechnung aus, die Zehntausende von Zellen berührt. Du öffnest die Tabelle und starrst auf einen Spinner; du machst eine Änderung und wartest wieder.
Der Workaround macht es schlimmer: Teams bündeln ihre Änderungen und erledigen sie spät am Tag, damit niemand zusehen muss, wie die Tabelle ächzt. Aber dann sind die Zahlen nur wenige Stunden am Tag aktuell, und jede Entscheidung außerhalb dieses Fensters beruht auf veralteten Daten.
4. Integrationen machen die Tabelle zu einem Zeitpunkt-Schnappschuss
Die Tabellenkalkulation enthält die Inventarwahrheit selten allein — sie importiert von Shopify, vom Lager, aus der Großhandelsliste. Jede Integration ist ein manueller Schritt: CSV exportieren, transformieren, importieren und hoffen, dass die Formate zusammenpassen. Jede Runde altert sofort: Die Tabelle ist eine Fotografie des Bestands, aufgenommen zu dem Zeitpunkt, an dem jemand zuletzt “Importieren” gedrückt hat.
Sobald dein Shop von nahezu aktuellem Bestand abhängt (öffentliche Verfügbarkeit, Nachbestellungs-Automatisierung, Fulfillment über mehrere Standorte), ist die Tabelle kein Werkzeug mehr, sondern eine Belastung. Shopify-Händler spüren das zuerst: Das Inventar der Plattform ist in Echtzeit, und die Tabelle daneben ist die einzige Quelle der Wahrheit, von der garantiert ist, dass sie falsch liegt.
Warum es bei etwa 10k SKUs bricht, nicht am Limit
Die veröffentlichten Limits sind groß: Google Sheets begrenzt auf 10 Millionen Zellen pro Arbeitsmappe, und Excel endet bei 1.048.576 Zeilen × 16.384 Spalten. Eine saubere Produktliste mit 10.000 SKUs passt bequem in beide.
Das Problem ist, dass Inventar nie eine einzige saubere Liste ist. Es sind Stammdaten, multipliziert:
| Element | Zeilen oder Zellen |
|---|---|
| 10.000 SKUs × 3 Varianten je Artikel | 30.000 Zeilen Stammdaten |
| × mehr als 20 Spalten (Barcode, Lieferant, Einkaufspreis, Verkaufspreis, Menge pro Standort, Meldebestand…) | Über 600.000 Zellen |
| 2 Lager + Shopify + Großhandel = 4 Standorte, jeder mit eigener Mengenspalte | ×4 Mengenspalten |
| Tägliches Bewegungsprotokoll, 10.000 SKUs × 180 Tage Historie | 1,8 Millionen Zeilen |
| Formeln, bedingte Formatierung, IMPORTRANGE-Tabellen obendrauf | Jede Neuberechnung läuft durch alles |
Ein Bewegungsprotokoll allein — eine Zeile pro SKU und Tag über sechs Monate — sind 1,8 Millionen Zeilen, die in Excel überhaupt nicht hineinpassen. In Sheets verteilt es sich über Tabs, und jeder tabübergreifende Nachschlag vervielfacht die Neuberechnungskosten. Mehrbenutzer-Bearbeitung und Integrationen stapeln sich dann auf einer Tabelle, die ohnehin schon am Rand war.
Die ehrliche Lesart des “10k” im Titel: nicht der Punkt, an dem die Datei nicht mehr öffnet, sondern der Punkt, an dem Genauigkeit, Geschwindigkeit und Vertrauen der Tabelle gleichzeitig versagen — und jeder Workaround das nächste Problem verschlimmert.
Wie “echt” aussieht: Postgres + eine schlanke Oberfläche
Wenn eine Inventartabelle bricht, ist die Ablösung keine größere Tabelle. Es ist eine kleine relationale Datenbank — in der Regel PostgreSQL — mit einer bewusst schlanken Oberfläche darüber. Der Umfang ist klein, und genau das ist der Punkt: Ein paar Tabellen und ein Suchfeld schlagen eine Arbeitsmappe mit 12 Tabs.
Das Modell ist normalisiertes Inventar, was nur eine höfliche Art zu sagen ist, dass die Daten einmal gespeichert und überall sonst gezählt werden:
products (one row per product: name, barcode, supplier, cost, price, status)
variants (one row per variant: product_id, sku, option values)
locations (warehouse A, warehouse B, Shopify, wholesale)
stock_levels (one row per variant × location: quantity, updated_at)
movements (one row per stock change: variant_id, location_id, delta, reference, at)Vier Eigenschaften unterscheiden das von der Tabellenkalkulation:
- Abfragen dauern in jeder Größe Millisekunden. Eine gefilterte Suche in einer Tabelle mit 100k Zeilen ist ein Indexnachschlag, kein Scan über ganze Spalten. Niemand in deinem Team wartet je wieder auf Zahlen.
- Schreibvorgänge sind atomar. Ein Verkauf, der den Bestand an zwei Standorten verringert, ist eine Transaktion — sie gelingt oder scheitert als Ganzes. Es gibt keine teilweise Änderung und keine “letzter Schreibzugriff gewinnt”-Kollision zwischen zwei Personen.
- Historie ist eingebaut. Jede Bewegung ist eine Zeile in
movements. Du kannst beantworten: “Wie hoch war der Bestand am Dienstag, und warum hat er sich geändert?” — die Frage, die eine Tabelle nicht beantworten kann, ohne ein Prüfprotokoll, das niemand geführt hat. - Die Oberfläche ist ein Suchfeld, kein Raster. Scanne einen Barcode und sieh die Variante, ihre Standorte, ihre Bestände und ihre letzten Bewegungen — auf einem einzigen Bildschirm. Dein Team liest weniger Zellen, nicht mehr.
Das ist kein Großkonzern-Projekt. Für einen Betrieb mit 10k SKUs ist der Bau ein paar Tage Arbeit: die vier Tabellen oben, der Import aus der aktuellen Tabelle und der schlanke Bildschirm. Die Erweiterungen — Shopify-Sync, Nachbestellungs-Warnungen, Bestellungen — kommen später, eine nach der anderen, auf demselben Modell dazu.
Der Migrationsweg, der niemanden in Panik versetzt
Der Umstieg von einer Tabellenkalkulation erfordert keinen Big-Bang-Cutover. Das Muster, das bei einem laufenden Geschäft funktioniert, ist dasselbe wie bei jeder Datenmigration:
- Zuerst das Schema. Definiere die vier Tabellen und lade eine Kopie der Stammdaten hinein — nicht in die Produktion, nur in eine Wegwerf-Datenbank.
- Import mit Kontrollpunkt. Der Export aus Sheets oder Excel wird Zeile für Zeile validiert: ungültige SKUs, fehlende Kosten und Artikel ohne Standort werden gemeldet, nicht stillschweigend verworfen. Du korrigierst die Daten einmal in der Tabelle, importierst erneut und siehst null Fehler.
- Parallelbetrieb. Die Datenbank läuft zwei bis vier Wochen neben der Tabelle. Alle benutzen weiterhin die Tabelle; das Team stichprobt die Datenbank dagegen. Wenn die Datenbank in jeder Stichprobe richtig liegt, ist das Vertrauen bereits umgezogen.
- Cutover. Die Tabelle wird zur Nur-Lese-Referenz und dann zum Export-Artefakt. Die Datenbank wird das Werkzeug, das die Leute morgens öffnen.
Eine ehrliche Anmerkung: Das ist dieselbe Reise wie bei jedem Umzug von Geschäftsdaten aus Tabellen, und das allgemeine Muster (einschließlich des Parallelbetrieb-Tricks) ist in Wenn Google Sheets nicht mehr skaliert beschrieben. Dieser Artikel ist die inventarspezifische Version: die vier Tabellen oben und das Suchfeld sind der ganze Sinn.
Vorher und nachher, in Zahlen
Ein konkretes Profil: 10.000 SKUs, zwei Lager plus ein Shopify-Shop, 250 Bestellungen pro Tag, fünf Personen, die das Inventar anfassen.
| Tabellenkalkulation | Postgres + schlanke Oberfläche | |
|---|---|---|
| Beantworten “wie viele X in Lager B?“ | 20–60 Sekunden Filtern, dann Zweifel | ~1 Sekunde, vertrauenswürdig |
| Täglicher Bestandsabgleich | 1–2 Stunden Quervergleich | 10 Minuten Ausnahme-Prüfung |
| Zwei Personen ändern denselben Bestand | Stille “letzter gewinnt”-Korrumpierung | Eine atomare Transaktion, der zweite Schreibvorgang wartet |
| Bewegungsprotokoll | ”Haben wir eigentlich nicht” | Jede Änderung, für immer |
| Verfügbarkeitsgenauigkeit in Shopify | Veraltet bis zur letzten manuellen Importierung | Echtzeit zur selben Minute |
| Monatlicher Tabellenaufwand | Laufend, unbezahlt, unvermeidbar | Keiner |
Der Punkt des Vergleichs ist nicht die Technologie — sondern dass die Tabellenversion dieses Betriebs kein Werkzeug mehr ist, sondern ein Teilzeitmitarbeiter, dessen einzige Aufgabe darin besteht, die Zahlen ungefähr richtig zu halten.
Zusammenfassung
| Anliegen | Tabellenkalkulation | Postgres + schlanke Oberfläche |
|---|---|---|
| Geschwindigkeit bei 10k+ SKUs | Sekunden bis Minuten pro Nachschlag | Abfragen in Millisekunden |
| Gleichzeitige Änderungen | Stille “letzter gewinnt”-Korrumpierung | Atomare Transaktionen |
| Historie / Prüfprotokoll | Keine | Eingebaut in movements |
| Integrationen (Shopify, Lager) | Manuell, bei Ankunft schon veraltet | Echtzeit, API-getrieben |
| Monatlicher Aufwand | Endlose unbezahlte Wartung | Nahe null |
Wenn dein Team das Inventar immer noch in einer Tabellenkalkulation abgleicht — oder schlimmer, der Tabelle nicht mehr vertraut und angefangen hat, von Hand nachzuzählen —, ist die Lösung eine kleine Datenbank mit einem Suchfeld, keine größere Tabelle. Für Shopify-Händler zeigt der Bundle-Fall genau, wie die Tabelle unter Bestelldruck versagt: Shopify-Bundle-SKUs ohne Tabellen-Chaos reparieren geht das mit einem echten Automatisierungsmuster durch.
Dieser Artikel ist Teil meiner Serie über wenn Tabellenkalkulationen nicht mehr skalieren und der Shopify-Automatisierungsserie. Wenn deine Inventartabelle schon langsam ist, buche eine 20-Minuten-Fit-Gespräch — ich schaue mir deine Einrichtung an und sage dir genau, wie viele Tage, nicht Monate, die Migration kostet.