Se Storeden viene scelta come piattaforma di destinazione, la preparazione deve partire dal sistema realmente in uso, non da supposizioni sulla piattaforma. TeamSystem oggi presenta Storeden come TeamSystem Commerce, mentre account esistenti e documentazione interna possono continuare a utilizzare il nome Storeden. È quindi necessario registrare entrambi i nomi nei punti in cui compaiono, così che account corrente, esportazioni storiche, riferimenti marketplace e documentazione delle integrazioni non vengano interpretati come sistemi diversi e non correlati.
La documentazione operativa pubblica aggiornata non è disponibile in modo uniforme per ogni dettaglio. Il pacchetto di preparazione deve perciò basarsi sulle evidenze dell’account sorgente effettivo: esportazioni, schermate dell’amministrazione, record disponibili, note sulle integrazioni e responsabili identificati. Non bisogna dedurre comportamento dei campi, limiti o copertura delle esportazioni da articoli datati o descrizioni commerciali.
Confermare account, denominazione attuale e ambito di vendita
Inizia identificando con precisione l’account Storeden o TeamSystem Commerce, i domini principali, lingue e valute attive, il piano o i moduli abilitati quando rilevanti, la responsabilità sul tema grafico, i canali di vendita e i collegamenti con prodotti TeamSystem o sistemi esterni. Registra inoltre quale denominazione compare nell’area di amministrazione, nelle fatture, nei record API o delle integrazioni e nelle procedure interne.
| Azione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Confermare l’account sorgente | Amministratore dello Store | Identificativo dell’account, schermata dell’amministrazione, dominio principale | Lo Store sorgente è identificato senza ambiguità. |
| Registrare le denominazioni Storeden e TeamSystem Commerce | Responsabile del progetto | Riferimento incrociato tra account, esportazioni, integrazioni e documentazione | I riferimenti storici e attuali possono essere ricondotti allo stesso sistema. |
| Elencare i canali di vendita attivi | Responsabile e-commerce | Inventario di sito, marketplace, social, B2B o altri canali | Ogni record specifico di un canale ha un responsabile identificato. |
| Identificare i collegamenti con l’ecosistema TeamSystem | Responsabile dei sistemi | Note su ERP, contabilità, pagamenti, POS, logistica o altre integrazioni | Le dipendenze native dell’ecosistema sono visibili. |
| Confermare l’accesso alle evidenze sorgente | Responsabile dati o tecnico | Esportazioni e report disponibili, credenziali, contatto di assistenza | I record necessari possono essere raccolti dall’account effettivo. |
| Avviare un registro delle modifiche | Responsabile del progetto | Modifiche datate a catalogo, stock, Customers, Orders, app e URL | L’insieme delle evidenze può essere mantenuto aggiornato. |
Preparare Products, varianti, campi del catalogo e media
TeamSystem Commerce descrive pubblicamente una gestione centralizzata di catalogo e inventario, immagini e descrizioni dei Products, prezzi e distribuzione multicanale. L’account sorgente va però ispezionato per determinare i campi Product e le relazioni tra varianti realmente in uso. Prepara i Products in base ai modelli operativi effettivi, invece di presumere uno schema unico.
Registra identificativo Product, SKU o codice interno, titolo, stato, prezzo, contesto fiscale, stock, struttura di varianti o opzioni, Categories, marchio o produttore, immagini, descrizioni, contenuti per lingua, dati di spedizione, campi marketplace, identificativi esterni e campi personalizzati visibili nell’account o nelle esportazioni.
| Modello di Product | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Product semplice | Rilevare identificativi, prezzo, stock, stato, Category, media e contenuti | Esportazione Product e pagina campione | Il significato di base del Product è documentato. |
| Product con varianti | Registrare nomi e valori delle opzioni, identificativi delle combinazioni, prezzo, stock, immagine e stato | Esportazione delle varianti o schermate dell’amministrazione | Le combinazioni vendibili sono distinguibili dal Product padre. |
| Product specifico di un canale | Registrare identificativi, titoli, Categories, prezzi e regole di disponibilità del marketplace o del canale | Esempio di inserzione del canale | I dati del sito e quelli del canale non vengono confusi. |
| Product multilingue | Registrare proprietà dei contenuti per lingua, campi tradotti, differenze dei percorsi URL e comportamento di fallback | Campione per lingua | L’ambito dei contenuti è esplicito per ogni lingua. |
| Product personalizzato o arricchito da app | Identificare i campi creati da plugin, app o integrazioni | Dizionario dei campi e sistema responsabile | È definita la gestione dei dati Product non appartenenti al nucleo standard. |
| Product con molti media | Registrare immagini originali, documenti, video e posizione dei file | Manifest dei media | Gli asset originali possono essere associati ai relativi record. |
Non dedurre il comportamento di varianti o marketplace dai soli nomi dei Products. Usa evidenze dell’account reale per stabilire quali valori modificano stock, prezzo, immagini o disponibilità sui canali.
Preparare Categories, navigazione, lingue e scoperta dei Products
Prepara la gerarchia delle Categories, le assegnazioni dei Products, i menu di navigazione, i percorsi per marchi o collezioni, le versioni linguistiche, filtri o attributi usati per trovare i Products, landing page e URL prioritari. La classificazione del catalogo multicanale va documentata separatamente dalla navigazione del sito, perché una Category marketplace o un’etichetta di feed può non corrispondere alla struttura Categories dello Store.
| Ambito di scoperta | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Gerarchia Categories | Responsabile catalogo | Elenco padre-figlio, stato, assegnazioni Product | Ogni Category da mantenere ha uno scopo noto. |
| Menu e percorsi della vetrina online | Responsabile della vetrina online | Mappa di navigazione e schermate | I percorsi di presentazione sono distinti dai record Category. |
| Ambito linguistico | Responsabile contenuti | Lingue attive e campioni tradotti di Products, Categories e pagine | I contenuti localizzati necessari sono identificati. |
| Filtri e attributi | Responsabile merchandising | Nomi dei campi, valori, copertura dei Products | I dati usati per trovare i Products sono sufficientemente coerenti da poter essere collegati alla destinazione. |
| Classificazione per canale | Responsabile marketplace | Campioni di Category, feed e inserzioni del canale | La classificazione esterna resta distinta dalla tassonomia del sito. |
| Percorsi prioritari | Responsabile SEO | URL di Products, Categories, pagine, marchi e campagne | Per ogni percorso importante è definita la gestione prevista. |
Chiarire chi gestisce l’inventario e come avviene la sincronizzazione tra canali
Le quantità di inventario possono essere gestite direttamente nell’account e-commerce oppure sincronizzate da un’applicazione TeamSystem, un ERP, un magazzino, un POS, un feed del fornitore o un flusso marketplace. La preparazione deve identificare il sistema autorevole e la tempistica degli aggiornamenti. Una quantità presente in un’esportazione è soltanto un’istantanea finché non è chiaro chi governa lo stock.
| Domanda sull’inventario | Evidenza | Condizione di prontezza |
|---|---|---|
| Dove viene mantenuto lo stock autorevole? | Elenco dei sistemi, responsabile, schermate, nota sull’integrazione | Per ogni gruppo di Products è indicata una sola fonte autorevole. |
| Lo stock è gestito per Product o per variante? | Record rappresentativi di Products e varianti | La granularità è documentata. |
| Sono coinvolte più sedi o magazzini? | Elenco delle sedi ed esempi di allocazione | Il significato delle sedi è esplicito. |
| I marketplace riservano o sincronizzano lo stock? | Regole dei canali e inserzioni campione | La disponibilità sul canale non viene considerata automaticamente uguale allo stock del sito. |
| Sono usati bundle o Products componenti? | Evidenze su componenti e decremento dello stock | Le relazioni di stock condiviso sono documentate. |
| Sono usati stati negativi, preordine o backorder? | Elenco dei Products in eccezione | Le eccezioni di disponibilità hanno un responsabile. |
Registra l’orario di ogni esportazione dello stock ed evita operazioni di pulizia massive finché l’autorità dei dati sorgente non è stata chiarita.
Preparare Customers, indirizzi, segmentazione e contesto B2B
Prepara identità Customer, email, stato dell’account, indirizzi, lingua, consenso o stato delle comunicazioni, campi di gruppo o segmentazione, contesto B2B o aziendale, trattamento fiscale, dati di fidelizzazione o credito quando presenti e identificativi esterni. Usa l’account corrente e le integrazioni per stabilire quali campi appartengono nativamente alla piattaforma, quali a un’app e quali sono sincronizzati.
| Modello Customer | Azione di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Customer registrato | Registrare identità, stato dell’account, indirizzi e relazione con gli Orders | Campioni di Customers e Orders | La proprietà dell’account è chiara. |
| Acquirente guest | Registrare email e Orders storici senza presumere l’esistenza di un account | Insieme di Orders guest | La cronologia guest resta distinta. |
| Acquirente B2B o aziendale | Registrare azienda, contatti, contesto di prezzo o fiscale e responsabile dell’account | Registro campione B2B | Le relazioni commerciali sono documentate. |
| Customer segmentato | Registrare significato e responsabile di gruppo, tag, fidelizzazione o marketing | Dizionario di segmentazione | Le etichette hanno definizioni operative. |
| Customer gestito da un sistema esterno | Registrare identificativi di ERP, CRM, contabilità, POS o assistenza | Dizionario dei campi | Sono note le chiavi usate dai sistemi a valle. |
| Identità duplicata | Registrare email duplicate o condivise e la decisione di gestione | Elenco delle eccezioni di identità | I record ambigui hanno un responsabile. |
Preparare Orders, pagamenti, spedizioni, logistica e riferimenti ai canali
Prepara Orders che rappresentino i reali modelli operativi dello Store: vendite dal sito e dai marketplace, diverse etichette di pagamento e spedizione, Products con varianti, sconti, rimborsi, cancellazioni, resi, fatture, tracking, modifiche manuali, dettagli multilingue, casi B2B e riferimenti esterni.
| Ambito Order | Azione | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Provenienza dal canale | Registrare origine sito o marketplace e identificativo del canale | Campioni di Orders provenienti da più canali | Ogni Order può essere ricondotto alla sua origine. |
| Dettaglio Product | Includere selezioni di variante o opzione, SKU, quantità, prezzo e testo Product | Righe di Order rappresentative | La configurazione acquistata resta comprensibile. |
| Stato e logistica | Registrare etichette di stato, stato della spedizione, tracking, resi e note operative | Dizionario degli stati e Orders | Il flusso storico può essere interpretato. |
| Totali | Identificare imposte, spedizione, sconto, commissioni, rimborso e importi di pagamento | Campioni dei componenti del totale | Il contesto finanziario è completo. |
| Documenti | Registrare riferimenti a fatture, ricevute o documenti fiscali quando utilizzati | Esempi di documenti e responsabile | I riferimenti storici necessari sono rintracciabili. |
| ID esterni | Registrare identificativi ERP, contabilità, pagamento, logistica, marketplace o POS | Orders sensibili alle integrazioni | I requisiti di ricerca tra sistemi sono documentati. |
Le etichette storiche di pagamento e spedizione sono evidenze di Orders passati. Pagamenti attivi, checkout, imposte, spedizioni e impostazioni logistiche devono essere configurati separatamente nel nuovo Store.
Inventariare app, plugin, collegamenti TeamSystem e sistemi esterni
Crea un registro delle dipendenze per app, plugin, marketplace, servizi di pagamento, fornitori logistici, contabilità, ERP, POS, CRM, analytics, marketing, recensioni, feed e integrazioni personalizzate. Il passaggio di Storeden nell’ecosistema TeamSystem rende particolarmente importante identificare le integrazioni che il personale può descrivere come “parte di Storeden” anche quando sono gestite in un altro prodotto TeamSystem.
| Campo della dipendenza | Dettaglio richiesto | Condizione di prontezza |
|---|---|---|
| Nome del prodotto o servizio | Nome attuale e storico quando differiscono | La dipendenza può essere riconosciuta da tutti i team. |
| Responsabile e scopo | Responsabile business, responsabile tecnico, flusso supportato | La responsabilità è esplicita. |
| Oggetti dati | Products, stock, Customers, Orders, fatture, contenuti o canali utilizzati | Sono note le evidenze sorgente interessate. |
| Direzione e tempistica | Lettura, scrittura, bidirezionale, pianificata, basata su eventi o manuale | L’autorità dei dati sorgente è documentata. |
| Identificativi | SKU, Product ID, email Customer, numero Order, chiave esterna | Le dipendenze di ricerca vengono mantenute. |
| Decisione di transizione | Ricollegare, ricostruire, dismettere, sostituire o sottoporre a revisione | La continuità operativa non viene data per scontata. |
Preparare contenuti, temi, percorsi SEO ed evidenze per i redirect
TeamSystem Commerce descrive pubblicamente temi personalizzabili, commercio multilingue e funzionalità SEO. Il modello dei contenuti e le esportazioni effettivamente disponibili devono essere confermati nell’account reale. Prepara pagine, contenuti di Products e Categories, eventuali contenuti blog o editoriali, immagini, menu, sezioni del tema, metadati, impostazioni canonical, relazioni hreflang o linguistiche, link interni e record di rewrite o redirect.
| Ambito contenuti | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Pagine e policy | Responsabile contenuti | Elenco pagine, stato, percorso, lingua, link interni | Sono documentate le decisioni di mantenimento, ricostruzione, unione o esclusione. |
| Contenuti del tema | Responsabile tema | Backup o schermate del tema, sezioni personalizzate, asset incorporati | I contenuti archiviati nei livelli di presentazione sono visibili. |
| Metadati SEO | Responsabile SEO | Titoli, descrizioni, impostazioni canonical, relazioni linguistiche | Il contesto di ricerca è incluso nelle evidenze dei percorsi. |
| Redirect o URL riscritti | Responsabile SEO o tecnico | Elenco dei redirect esistenti e vecchi percorsi prioritari | Sono disponibili le regole storiche che devono continuare a funzionare. |
| Media | Responsabile contenuti | Immagini originali, documenti, video e collegamenti ai Products | I file sorgente possono essere associati ai record. |
Preparare esportazioni, schermate, backup e limiti della fonte
Poiché la documentazione operativa pubblica è limitata, l’archivio delle evidenze deve essere particolarmente esplicito. Salva ogni esportazione disponibile con data, contesto dell’account, campi selezionati, criteri di filtro e checksum. Acquisisci schermate per le relazioni non rappresentate nelle esportazioni e registra ogni campo o oggetto che non possa essere esportato senza l’intervento di un amministratore o dell’assistenza.
| Insieme di evidenze | Contenuti richiesti | Condizione di prontezza |
|---|---|---|
| Esportazioni principali | File di Products, Customers, Orders, Categories, stock, contenuti e canali quando disponibili | I file sono datati e riconducibili all’account. |
| Schermate e report | Varianti, app, integrazioni, impostazioni, lingue, redirect ed eccezioni | Le relazioni non esportate sono visibili. |
| Archivio media e tema | Asset originali e backup del tema o record del codice, quando disponibili | I file sorgente sono recuperabili. |
| Registro di assistenza | Contatto nominativo dell’account e questioni di esportazione irrisolte | Le lacune nelle evidenze hanno un responsabile. |
| Registro delle modifiche | Products, stock, Customers, Orders, canali e URL nuovi o modificati | Le modifiche sorgente successive possono essere riconciliate. |
Non colmare una lacuna nelle evidenze con un’ipotesi non supportata. Registra il limite e la persona incaricata di confermare il comportamento dell’account corrente.
Selezionare record rappresentativi per il test di migrazione
| Gruppo campione | Includere | Scopo della preparazione |
|---|---|---|
| Products | Product semplice, Product con varianti, Product multilingue, Product pubblicato su un canale, eccezione di stock basso, Product arricchito da app | Far emergere modelli diversi di catalogo e proprietà dei dati. |
| Customers | Registrato, guest, B2B, segmentato, identità duplicata, Customer con ID esterno | Rappresentare differenze di account e integrazione. |
| Orders | Sito, marketplace, rimborso, reso, diverso stato logistico, riferimento a fattura, Order di sistema esterno | Mantenere il contesto operativo. |
| Scoperta e contenuti | Category prioritaria, percorso linguistico, landing page, URL Product, redirect | Preparare relazioni tra percorsi e contenuti. |
| Dipendenze | Product, Customer o Order interessato da un’integrazione TeamSystem o esterna | Includere nelle evidenze gli identificativi usati tra sistemi. |
Ogni campione deve includere un’aspettativa sorgente che spieghi perché il record è rappresentativo, quali relazioni sono importanti e quali evidenze devono accompagnarlo.
Completare il controllo di prontezza per Storeden
| Controllo finale | Condizione di prontezza |
|---|---|
| Identità dell’account | Denominazioni Storeden e TeamSystem Commerce, account, domini, canali e responsabili sono riconciliati. |
| Catalogo | Products, varianti, Categories, lingue, media e campi personalizzati sono documentati. |
| Inventario | Autorità dello stock, granularità, sedi, canali ed eccezioni sono note. |
| Customers | Sono compresi casi registrati, guest, B2B, segmentati, duplicati e con ID esterni. |
| Orders | Canale, selezioni Product, stati, logistica, totali, documenti e ID esterni sono interpretabili. |
| Dipendenze | App, plugin, collegamenti TeamSystem, marketplace e sistemi esterni hanno una gestione definita. |
| Contenuti | Temi, pagine, media, campi SEO, percorsi linguistici e redirect sono preparati. |
| Input | Sono disponibili esportazioni, schermate, media, contatti di assistenza, limiti e registro delle modifiche. |
| Campioni | I record rappresentativi per la migrazione coprono modelli sorgente ordinari e complessi. |
Conclusione
Preparare una migrazione verso Storeden significa riconciliare il nome storico della piattaforma con l’attuale contesto TeamSystem Commerce e, allo stesso tempo, basarsi sulle evidenze dell’account effettivamente in uso. Catalogo, inventario, canali, Customers, Orders, contenuti, app e collegamenti TeamSystem devono essere documentati da responsabili che ne comprendono l’uso operativo.
Un archivio completo delle evidenze rende visibili i limiti della fonte invece di sostituirli con supposizioni. In questo modo la configurazione della migrazione parte da una base affidabile anche quando la documentazione pubblica a livello di campo è limitata.
Domande frequenti
Perché la checklist cita TeamSystem Commerce se la piattaforma dell’articolo è Storeden?
TeamSystem oggi presenta Storeden come TeamSystem Commerce. Account esistenti, esportazioni, integrazioni e procedure interne possono utilizzare uno dei due nomi, quindi la preparazione deve documentare esplicitamente la relazione.
Cosa fare se un campo Storeden non è coperto dalla documentazione pubblica attuale?
Usa evidenze dell’account reale, esportazioni, schermate, responsabili delle integrazioni e contatti di assistenza. Registra il comportamento non ancora confermato come limite della fonte invece di fare supposizioni.
Quali Products Storeden dovrebbero essere inclusi nel campione?
Includi Products semplici e con varianti, Products multilingue, Products pubblicati sui marketplace, eccezioni di inventario, Products con molti media e record arricchiti da app o sistemi esterni.
Come va preparato lo stock multicanale?
Identifica il sistema autorevole per lo stock, la granularità Product o variante, le sedi, le regole di riserva o sincronizzazione e gli identificativi specifici dei canali.
Quali Orders sono più utili durante la preparazione?
Usa Orders del sito e dei marketplace, rimborsi, resi, diversi stati logistici, riferimenti a fatture o documenti fiscali e Orders collegati a TeamSystem o ad altri sistemi.
Come vanno controllate le modifiche alla fonte successive all’esportazione?
Mantieni un registro datato che copra Products, stock, Customers, Orders, canali, app e URL, così che le evidenze di migrazione possano essere riconciliate con lo stato corrente dello Store.