Bei der Bewertung von Storeden als mögliche Zielplattform zeigt die Eignungsanalyse, für welche Quellshop-, Geschäfts- und Betriebsprofile dieses Ziel geeignet oder weniger geeignet ist.
Ob Storeden als potenzielle Zielplattform zu einem Unternehmen passt, sollte nach dem zukünftigen Betriebsmodell beurteilt werden und nicht allein nach der Größe des Shops. Ein kleiner Shop kann schlecht zu Storeden passen, wenn er von individueller Checkout-Logik, undokumentierter Marktplatzautomatisierung oder Quellcode-Verhalten abhängt, das sich in der Zielumgebung nicht sinnvoll abbilden lässt. Ein größerer Shop kann dagegen sehr gut passen, wenn Katalog, historische Orders, Verkaufskanäle, Integrationen und Erwartungen an die Storefront in Storedens verwaltetes Commerce-Modell übertragen werden können.
Die Entscheidung sollte eine praktische Frage beantworten: Kann das Unternehmen Storeden nach der Migration nutzen, ohne die geschäftlich relevanten Funktionen zu verlieren? Dazu müssen Products, Categories, Customers, Orders, Reviews, Coupons, CMS-Inhalte, SEO-Werte, Bestand, Marktplatzkontext, Zahlungshistorie, Logistikkontext, externe IDs, Apps und Integrationsabhängigkeiten anhand der Storeden-spezifischen Zielbedingungen geprüft werden.
Ein gutes Fit-Urteil setzt nicht voraus, dass jede alte Funktion kopiert wird. Entscheidend ist, zu wissen, was erhalten werden muss, was konfiguriert werden kann, was neu aufgebaut werden sollte, was vereinfacht werden kann und welche Anforderungen eine gesonderte Prüfung benutzerdefinierter Daten benötigen.
Entscheidungsrahmen für die Storeden-Eignung
Eine belastbare Storeden-Eignungsprüfung vergleicht das tatsächliche Geschäftsverhalten mit der Betriebsrealität der Zielplattform. Storeden beziehungsweise TeamSystem Commerce ist auf Cloud-Commerce, Multichannel-Verkauf, Katalog- und Bestandsverwaltung, professionelle Order-Abwicklung, integrierte Zahlungen, Logistik, Themes, Sicherheit, Apps, Plugins, API- und Entwicklerressourcen, Marktplatzkanäle und Verbindungen in das TeamSystem-Ökosystem ausgerichtet. Das ist attraktiv für Händler, die eine verwaltete Commerce-Umgebung suchen. Gleichzeitig hängt die Eignung davon ab, wie viel des bisherigen Geschäftsverhaltens in diese Strukturen übersetzt werden kann.
| Fit-Dimension | Starkes Fit-Signal | Bedingtes oder risikoreiches Signal |
|---|---|---|
| Katalogstruktur | Products, Varianten, Attribute, Categories, Bestand, Bilder und Preise lassen sich klar darstellen. | Products hängen von individuellen Konfiguratoren, ungewöhnlicher Optionslogik, quellplattformspezifischen Feldern oder undokumentierten Bestandsregeln ab. |
| Rolle von Marktplätzen | Marktplatzkanäle können nach der Katalogmigration wieder verbunden oder neu eingerichtet werden. | Bestehende Listing-IDs, Feeds, Channel-Categories und Synchronisierungszustände sind geschäftskritisch, aber nicht dokumentiert. |
| Storefront-Erwartung | Das Unternehmen akzeptiert Ziel-Theme-Konfiguration und Wiederaufbau von Inhalten. | Der Launch hängt von einer exakten Kopie des Quell-Themes, von Skripten, Page-Builder-Verhalten oder Frontend-Abläufen ab. |
| Order-Historie | Historische Orders müssen vor allem für Service, Finanzen, Fulfillment und Management lesbar bleiben. | Orders müssen integrationskritische Workflow-Status, externe Finanz-IDs oder Marktplatzautomatisierungszustände erhalten. |
| Integrationen | ERP-, Buchhaltungs-, POS-, Logistik-, Bestands- und TeamSystem-Abhängigkeiten sind bekannt und abgrenzbar. | Externe Systeme bestimmen Product-, Bestands-, Rechnungs-, Customer- oder Order-Bedeutung ohne klares Datenmodell. |
| Scope-Grenze | Kerndaten, Zielkonfiguration, Apps, Integrationen und benutzerdefinierte Daten haben eindeutige Verantwortliche. | Das Projekt setzt voraus, dass nicht unterstützte App-Daten oder individuelles Verhalten automatisch übertragen werden. |
Stark geeignete Profile
Händler, der in verwalteten Cloud-Commerce wechselt
Storeden ist ein starker Kandidat, wenn ein Händler Infrastrukturaufwand, Plattformwartung oder einen fragmentierten Technologie-Stack reduzieren und in eine verwaltete Commerce-Umgebung wechseln möchte. Besonders gut passt die Plattform, wenn das Unternehmen bereit ist, Storeden als neues Betriebssystem des Shops einzurichten, statt zu erwarten, dass die bisherige Implementierung unverändert wieder erscheint.
Der Migrationsfokus sollte auf der Erhaltung der geschäftlichen Bedeutung liegen: Katalogstruktur, Customers, historische Orders, Inhalte, SEO-Prioritäten, Marktplatzkontext und integrationsrelevante IDs. Quellplattformspezifische technische Umsetzung muss bewertet und in Storeden-Konfiguration, Apps, Integrationen, akzeptierte Änderungen oder Anforderungen an benutzerdefinierte Daten übersetzt werden.
Katalog- und bestandsorientierter Händler
Storeden kann gut zu Händlern passen, deren Verkaufsmodell von einem strukturierten Katalog, klaren Categories, sichtbaren Beständen, Bildern, Preisen, SKUs, Attributen und Product-Verfügbarkeit abhängt. Diese Shops profitieren von einer Planung, die den Katalog als betriebliche Struktur und nicht nur als Liste einzelner Product-Datensätze behandelt.
Besonders stark ist dieses Profil, wenn repräsentative Products früh getestet werden können. Die Eignungsprüfung sollte einfache Products, Variantenprodukte, attributreiche Products, marktplatzrelevante Products, bestandskritische Artikel, bildkritische Produkte und Products mit externen IDs oder festen SKU-Konventionen einschließen.
| Product-Stichprobe | Warum sie aufgenommen werden sollte | Was ein gutes Ergebnis nachweist |
|---|---|---|
| Einfaches Product | Schafft eine Basis für die Feldzuordnung. | Name, SKU, Preis, Bild, Beschreibung, Category und Sichtbarkeit sind verständlich. |
| Variantenprodukt | Prüft die Struktur der Kaufoptionen. | Optionen, Kombinationen, Preis, Bestand, SKU und Bildverhalten funktionieren in Storeden sinnvoll. |
| Attributreiches Product | Prüft Filter-, Vergleichs- und Marktplatzfelder. | Wichtige Attribute bleiben sichtbar und nutzbar oder werden an der richtigen Zielstelle abgebildet. |
| Bestandskritisches Product | Prüft operative Verlässlichkeit. | Bestandswerte und Verfügbarkeitsdarstellung führen nicht zu falschen Erwartungen. |
| Marktplatz-Product | Prüft die Channel-Bereitschaft. | Kanalbezogene Werte sind erkannt und gesondert eingeplant, statt in allgemeinen Product-Feldern verborgen zu bleiben. |
Multichannel-Verkäufer
Storeden ist häufig ein starker Kandidat für Händler, die Storefront und Marktplätze gemeinsam planen müssen. Kanäle wie Amazon, eBay, Facebook, AliExpress oder andere Verkaufsplattformen können Product-Felder, Category-Zuordnung, Verfügbarkeitsregeln, Order-Ursprung, Bestandsanforderungen und spätere Synchronisierung beeinflussen.
Dieses Profil ist stark, wenn das Marktplatzverhalten verstanden und dokumentiert ist. Es wird bedingt, wenn das Unternehmen von Channel-IDs, automatisierten Feeds oder marktplatzspezifischem Fulfillment abhängt, deren Funktionsweise niemand sauber dokumentiert hat.
Unternehmen mit TeamSystem-Verbindungen
Storeden kann eine starke Zielplattform sein, wenn die Commerce-Prozesse des Händlers mit TeamSystem-Workflows, Buchhaltung, ERP, Bestand, Zahlung, Logistik oder anderen Verwaltungssystemen verbunden werden sollen. Die Eignung steigt, wenn diese Verbindungen Teil des geplanten Zielbetriebs sind und nicht erst nach der Datenmigration entdeckt werden.
Externe IDs und die Datenhoheit sind dabei zentral. Wenn Storeden nach dem Launch mit Buchhaltungs- oder ERP-Systemen zusammenarbeiten soll, müssen die Felder erhalten beziehungsweise nachvollziehbar zugeordnet werden, die Abstimmung, Reporting und fortlaufende Synchronisierung ermöglichen, soweit dies unterstützt wird.
Händler, der die Storefront-Darstellung neu aufbauen will
Storeden passt gut zu Teams, die eine praktische Storefront auf Basis von Themes, responsiver Darstellung, Content-Werkzeugen und Zielkonfiguration aufbauen möchten. Besonders gut ist die Eignung, wenn das Unternehmen akzeptiert, dass visuelle Kontinuität Theme-Konfiguration, Content-Prüfung, Menüplanung, Bildprüfung, SEO-Planung und Redirect-Management in Storeden erfordert.
Das ist kein Nachteil, sondern eine realistische Migrationsannahme. Ein Quell-Theme wie eine normale Datenkategorie migrieren zu wollen, führt häufig zu falschen Erwartungen. Die Darstellung anhand des Storeden-Zielmodells neu aufzubauen, schafft einen klareren Launch-Plan.
Bedingt geeignete Profile
Manche Händler sind keine schlechten Storeden-Kandidaten, benötigen aber vor der Entscheidung eine deutlich stärkere Scope-Klärung. Typisch sind Geschäftsabläufe, die unterstützt, teilweise unterstützt, App- oder Integrationsabhängig sein können oder besser über eine Prüfung benutzerdefinierter Daten beziehungsweise separate Implementierungsarbeit behandelt werden.
| Bedingtes Profil | Warum es trotzdem funktionieren kann | Was zuerst geklärt werden muss |
|---|---|---|
| B2B- oder Großhandelsunternehmen | Storeden kann kontobezogenen Commerce über Konfiguration, Apps oder Ökosystemprozesse unterstützen. | Customer-Gruppen, eingeschränkte Kataloge, ausgehandelte Preise, Steuerbehandlung, Zahlungsziele, Freigaben und Vertriebsbeziehungen. |
| Marktplatzabhängiger Händler | Multichannel-Verkauf passt grundsätzlich zu Storedens Ausrichtung. | Listing-IDs, Feed-Verantwortung, Marktplatz-Categories, Synchronisierungsregeln, Bestandsverantwortung und Marktplatz-Order-Abwicklung. |
| Integrationsintensiver Händler | Storeden kann in Geschäftssystemprozesse eingebunden werden. | Welches System Products, Bestand, Rechnungen, Customer-IDs, Fulfillment-Status und Reporting-Werte besitzt. |
| App-abhängiger Shop | Apps und Plugins können Funktionen auf der Zielplattform erweitern. | Welche alten App-Daten erhalten werden müssen, welche Ziel-Apps bisheriges Verhalten ersetzen und was eine gesonderte Datenprüfung oder Implementierung erfordert. |
| SEO-sensibler Shop | URLs, Metadaten, Categories und Inhalte können geplant werden. | Priorisierte URL-Liste, Redirect-Plan, Metadaten-Stichproben, Seitenhierarchie und interne Verlinkung. |
Ein bedingtes Fit muss mit einem konkreten Behandlungskonzept enden. Werden alle offenen Fragen auf die Zeit nach der Migration verschoben, ist das Projekt noch nicht entscheidungsreif. Sind unterstützte Datensätze, Ziel-Setup-Aufgaben, Konfigurationen, akzeptierte Änderungen sowie gesonderte Datenprüfungen oder Implementierungspunkte klar zugeordnet, kann Storeden weiterhin eine tragfähige Zielplattform sein.
Profile mit höherem Risiko
Shop mit Bedarf an uneingeschränkter Quellcodekontrolle
Storeden ist eine verwaltete Commerce-Plattform. Sie ist kein direkter Ersatz für Umgebungen, in denen der Händler den vollständigen Application Stack, das Datenbankschema, Serververhalten und eigene Backend-Logik kontrolliert. Ein Wechsel kann trotzdem möglich sein, doch das bisherige Verhalten muss in unterstützte Zielstrukturen übersetzt werden.
Das Risiko ist hoch, wenn das Unternehmen technische Kontinuität bis auf Codeebene statt betrieblicher Kontinuität erwartet. Die bessere Frage lautet nicht „Kann der Code migriert werden?“, sondern „Welches Geschäftsverhalten erzeugt der Code heute, und wie soll Storeden dieses Verhalten unterstützen oder ersetzen?“
Shop mit stark individualisierter Produktlogik
Individuelle Product Builder, komplexe Konfiguratoren, Bundles, ungewöhnliche Optionsabhängigkeiten, kundenspezifische Preisberechnungen oder quellplattformspezifische Attributlogik können die Storeden-Eignung deutlich komplexer machen. Solche Funktionen sind häufig keine normalen Product-Daten.
Die Entscheidung sollte Product-Stichproben verwenden, die die tatsächliche Komplexität zeigen. Lassen sich die komplexesten Products nicht sauber durch Storeden-Strukturen, Ziel-Apps, akzeptierte Vereinfachungen oder eine gesonderte Prüfung beziehungsweise Implementierung darstellen, kann Storeden weiterhin möglich sein, darf aber nicht als geradlinige Standardmigration behandelt werden.
Shop mit undokumentierter Marktplatzautomatisierung
Storedens Multichannel-Ausrichtung kann sehr wertvoll sein, doch undokumentierte Automatisierung erhöht das Risiko. Wenn bisheriges Marktplatzverhalten von versteckten Regeln, App-generierten Feldern, Feed-Skripten, externen Listings oder channelspezifischer Fulfillment-Logik abhängt, braucht die Migration eine Prüfung pro Kanal.
Das Risiko besteht nicht nur in verlorenen Daten. Es besteht in operativer Unklarheit nach dem Launch: Products sind in der Storefront sichtbar, aber nicht marktplatzbereit; Bestände synchronisieren sich anders als erwartet; oder Orders verlieren den nutzbaren Kontext ihres Ursprungskanals.
Shop, dessen Apps oder externe Systeme Kerndaten besitzen
Manche Shops wirken zunächst standardisiert, bis App- oder extern systemeigene Daten untersucht werden. Eine Loyalty-App kann Customer-Segmentierung besitzen. Eine Feed-App kann Marktplatzfelder steuern. Ein ERP kann Product-IDs und Bestand besitzen. Ein Fulfillment-System kann Versandstatus kontrollieren. Reporting kann von individuellen Tags abhängen.
Dieses Profil erfordert eine sorgfältige Fit-Planung. Storeden kann passend bleiben, wenn der Händler festlegt, wie wichtige App-Daten, Plugins, APIs, externe IDs, benutzerdefinierte Felder und individuell erzeugte Quelldatensätze nach der Migration dargestellt oder implementiert werden.
Signale für eine weniger geeignete Ausgangslage
Ein weniger geeignetes Signal schließt Storeden nicht automatisch aus. Es zeigt jedoch, dass die Zielentscheidung kontrollierter getroffen werden muss.
| Signal | Warum es wichtig ist | Bessere Reaktion |
|---|---|---|
| Das Quell-Theme muss exakt kopiert werden | Theme-Dateien und Layoutlogik sind keine gewöhnlichen Migrationsdatensätze. | Planen Sie Ziel-Theme-Konfiguration, Content-Wiederaufbau, Designabnahme und SEO-Prüfung. |
| Marktplatzdaten sind nicht dokumentiert | Multichannel-Datensätze können IDs und Channel-Regeln außerhalb normaler Products enthalten. | Dokumentieren Sie Marktplatzfelder, Order-Ursprung, Feed-Verantwortung und Bestandsregeln vor der Scope-Freigabe. |
| Externe IDs sind unbekannt | ERP-, Buchhaltungs-, Logistik-, POS- und Bestandssysteme können von stabilen IDs abhängen. | Ermitteln Sie, welche IDs erhalten, zugeordnet oder neu erzeugt werden müssen. |
| Customers haben versteckte Geschäftslogik | B2B-Regeln, Gruppen, Rabatte, Steuerbehandlung oder Marketing-Einwilligungen sind nicht immer in Basisfeldern sichtbar. | Wählen Sie Customer-Stichproben nach Verhalten, nicht nur nach Datensatzanzahl. |
| Orders sollen Live-Prozesse steuern | Historische Orders sind nicht identisch mit neuem Checkout-, Zahlungs- und Fulfillment-Setup. | Trennen Sie Order-Historie von Zielkonfiguration der Live-Prozesse. |
| Nicht unterstützte App-Daten sind geschäftskritisch | App-Datensätze passen möglicherweise nicht in unterstützte Datenkategorien. | Führen Sie App-eigene Daten einer gesonderten Datenprüfung zu. |
Eignung vor der Entscheidung testen
Die Storeden-Eignung sollte mit repräsentativen Quell- und Zielnachweisen getestet werden und nicht mit optimistischen Annahmen. Die Stichproben müssen genau die Datensätze enthalten, an denen sich zeigt, ob Storeden zum Geschäftsmodell passt.
Sinnvolle Stichproben umfassen komplexe Products, Variantenprodukte, bestandskritische Products, Marktplatz-Products, Customer-Gruppen, B2B-Konten, unterschiedliche Orders, Zahlungs- und Versandbeispiele, SEO-relevante URLs, CMS Pages, App-abhängige Datensätze und externe IDs.
| Testbereich | Repräsentative Stichprobe | Fit-Frage |
|---|---|---|
| Katalog | Komplexe Products, Varianten, Attribute, Categories, Bilder, Bestand und Marktplatz-Products. | Können Products in Storeden verkauft, gefunden, verwaltet und synchronisiert werden? |
| Customer-/Kontodaten | Customers mit Adressen, Gruppen, B2B-Verhalten, Marketingkontext oder Order-Historie. | Bleibt die Customer-Bedeutung über Name und E-Mail hinaus erhalten? |
| Orders | Orders mit Rabatten, Steuern, Zahlungs- und Versandbezeichnungen, Tracking, Marktplatzursprung, Refunds oder Notizen. | Ist die Order-Historie für Service, Finanzen, Fulfillment und Management lesbar? |
| Inhalte und SEO | Priorisierte Seiten, Product-URLs, Category-URLs, Redirects, Metadaten und interne Links. | Lassen sich Auffindbarkeit und Vertrauenswirkung zum Launch erhalten? |
| Integrationen | ERP-IDs, Buchhaltungsreferenzen, Lagerwerte, Marktplatz-IDs und App-eigene Felder. | Sind externe Prozesse konkret eingeplant statt nur vorausgesetzt? |
Entscheidungstore für Storeden
Die abschließende Storeden-Entscheidung sollte prüfen, ob das Unternehmen für ein verwaltetes Multichannel-Betriebsmodell bereit ist - nicht nur, ob sich Datensätze importieren lassen. Die stärksten Nachweise verbinden Katalogstruktur, Marktplatzverantwortung, TeamSystem- oder andere externe Datenhoheit, Storefront-Erwartungen und operative Validierung.
| Entscheidungstor | Starkes Fit-Nachweisbild | Bedingtes oder schwächeres Nachweisbild |
|---|---|---|
| Verwalteter Cloud-Betrieb | Das Team möchte Hosting, Sicherheit, Updates und Plattformadministration in einer verwalteten Umgebung bündeln. | Das Unternehmen benötigt uneingeschränkte Kontrolle über Server, Datenbank oder Anwendungscode. |
| Katalog und Bestand | Products, Varianten, Attribute, Preise, Bestand, SKUs und Bilder sind strukturiert und mit repräsentativen Stichproben validierbar. | Zentrale Verkaufsfunktionen hängen von individuellen Konfiguratoren, undokumentierten Bundles oder quellplattformspezifischer Logik ab. |
| Multichannel-Verkauf | Marktplatz-Listings, Channel-Categories, Bestandsverantwortung, Order-Ursprung und Feed-Verantwortlichkeiten sind dokumentiert. | Marktplatzaktivität hängt von versteckten Skripten, App-generierten Feldern oder unbekannten Channel-IDs ab. |
| Integration in Geschäftssysteme | ERP, Buchhaltung, Logistik, Zahlung und Reporting haben klare Verantwortlichkeiten und stabile IDs. | Externe Systeme besitzen wesentliche Daten, aber IDs und Synchronisierungsverantwortung sind unklar. |
| Storefront und SEO | Der Händler akzeptiert Ziel-Theme-Konfiguration und besitzt eine priorisierte Liste für Inhalte, URLs, Metadaten und Redirects. | Exakte Theme- oder Codeübernahme wird erwartet oder wichtige Routen sind nicht identifiziert. |
| Operative Validierung | Das Team kann schwierige Products, Marktplatzfälle, Customers, Orders, Inhalte und Integrationsreferenzen testen. | Die Zielplattform wird ohne Nachweise aus realen Geschäftsszenarien ausgewählt. |
Ein starkes Storeden-Fit liegt vor, wenn diese Entscheidungstore gemeinsam das zukünftige Betriebsmodell unterstützen. Ein bedingtes Fit benötigt konkrete Entscheidungen zu Marktplatzdaten, externen Systemen, individueller Product-Logik oder Content-Kontinuität. Kann das Unternehmen die Grenzen einer verwalteten Plattform nicht akzeptieren oder die Systeme, die seine Commerce-Daten besitzen, nicht dokumentieren, ist Storeden ohne weitergehende Änderungen am Betriebsmodell möglicherweise nicht die richtige Zielplattform.
Fazit
Storeden ist eine starke potenzielle Zielplattform, wenn ein Händler verwalteten Cloud-Commerce, strukturierte Katalog- und Bestandssteuerung, Multichannel-Verkauf, praktikables Order-Management, Zahlungs- und Logistikkonfiguration, Storefront-Themes, Apps und eine mögliche Ausrichtung am TeamSystem-Ökosystem sucht. Bedingt oder risikoreich ist die Eignung, wenn das Unternehmen von exaktem Quellcode-Verhalten, individueller Product-Logik, undokumentierter Marktplatzautomatisierung, App-eigenen Datensätzen oder nicht dokumentierten externen Prozessen abhängt.
Eine gute Entscheidung basiert auf Nachweisen. Ein starker Storeden-Kandidat kann repräsentative Products, Customer-Datensätze, Orders, Inhalte, Marktplatzfälle, Integrations-IDs und SEO-Beispiele im vorgesehenen Zielmodell validieren. Zeigen diese Stichproben nicht unterstützte Annahmen, sollte das Projekt den Scope anpassen, Zielkonfiguration einplanen oder die betroffenen benutzerdefinierten Daten vor der Launch-Planung separat prüfen.
Häufige Fragen
Welche Händler passen typischerweise besonders gut zu Storeden?
Storeden passt meist besonders gut zu Händlern, die verwalteten Cloud-Commerce, strukturierte Katalog- und Bestandssteuerung, Multichannel-Verkauf, Zahlungs- und Logistikkonfiguration, Storefront-Themes, Apps und möglicherweise TeamSystem-Verbindungen suchen.
Passt Storeden zu Shops mit Marktplatzverkauf?
Das kann gut passen, muss aber sorgfältig geprüft werden. Listing-IDs, Channel-Categories, Feed-Regeln, Bestandssynchronisierung, Marktplatz-Order-Ursprung und die Verantwortlichkeit externer Kanäle sollten verstanden sein, bevor die Zielentscheidung freigegeben wird.
Wann ist Storeden nur bedingt geeignet?
Storeden ist bedingt geeignet, wenn der Shop von B2B-Regeln, App-eigenen Daten, externen Systemen, individueller Product-Logik, SEO-relevanten URLs oder Marktplatzautomatisierung abhängt, deren Verantwortlichkeit und Zielverhalten noch nicht geklärt sind.
Kann ein stark individualisierter Quellshop zu Storeden wechseln?
Das kann möglich sein, doch das Projekt sollte Geschäftsverhalten statt Codekontinuität übertragen. Individuelle Logik, App-Daten, externe IDs und spezielle Transformationen müssen verstanden sein, bevor Storeden als Ziel bestätigt wird.
Was sollte vor der Wahl von Storeden getestet werden?
Testen Sie repräsentative Products, Varianten, Attribute, bestandskritische Artikel, Marktplatz-Products, Customers, B2B-Beispiele, unterschiedliche Orders, Inhalte, URLs, App-eigene Datensätze und externe IDs gegen das vorgesehene Storeden-Betriebsmodell.
Macht ein kleiner Katalog Storeden automatisch zu einer guten Wahl?
Nein. Auch ein kleiner Katalog kann schlecht passen, wenn Marktplatzautomatisierung, externe Systeme, individuelle Preislogik oder spezielle Product-Funktionen das Geschäft bestimmen. Die Eignung hängt von der Betriebsstruktur ab, nicht von der Datensatzanzahl.