Spostare gli ordini via fax sul Web ── progettare il periodo di doppia gestione e una migrazione graduale

Nell’articolo precedente, “Che cos’è l’EDI? Come semplifica lo scambio di ordini tra aziende”, abbiamo esaminato il meccanismo che sostituisce il reinserimento manuale degli ordini ricevuti via fax o e-mail con uno scambio di dati tra sistemi.

Questo articolo ne è il seguito. Il tema fa un passo avanti rispetto a “comprendere il meccanismo”, verso come effettuare concretamente la migrazione.

Le richieste del tipo “vogliamo spostare gli ordini via fax sul Web” proseguono spesso così:

“Ma alcuni nostri partner commerciali possono usare solo il fax”

“Vogliamo continuare a usare il sistema di gestione vendite così com’è”

“Non possiamo permetterci che gli ordini si blocchino durante il passaggio”

In altre parole, la vera sfida operativa non è costruire un sistema di ordini Web. È progettare il periodo durante il quale si passa gradualmente al Web mentre il fax resta attivo.

Questo articolo organizza lo spostamento degli ordini via fax sul Web attorno a quattro temi: la progettazione del periodo di doppia gestione, l’import CSV come forma intermedia, la preparazione delle anagrafiche di prodotti e clienti, e come coinvolgere i partner commerciali.

Questo articolo è rivolto agli addetti alla gestione degli ordini e ai responsabili dei sistemi informativi di aziende in cui gli ordini arrivati via fax o e-mail vengono inseriti a mano nel sistema di gestione vendite. Al termine della lettura, ciò che si porta a casa non è come costruire il sistema di ordini Web in sé, ma come assemblare un piano di migrazione: “da quale partner commerciale, in quale ordine e cosa misurare mentre si migra”. Se si vuole prima il quadro complessivo del meccanismo, conviene leggere l’articolo precedente sull’EDI.

1. La conclusione, prima di tutto

I punti chiave nel pianificare il passaggio degli ordini via fax al Web sono i seguenti:

• Fissare l’obiettivo non sull’“eliminazione del fax”, ma sulla “riduzione del numero di ordini che richiedono inserimento manuale”
• Partire dal presupposto che un periodo di doppia gestione di fax e Web si verificherà comunque, progettandone prima la durata e il modo di misurarla
• I canali di ricezione possono essere più di uno, ma la gestione interna degli ordini va unificata in un unico flusso
• Non richiedere subito l’inserimento tramite schermata Web, ma prevedere l’import CSV come forma intermedia
• Poiché la schermata di ordine Web espone direttamente ai partner commerciali le anagrafiche di prodotti e clienti, preparare prima queste anagrafiche
• Non far passare tutti i partner commerciali insieme, ma classificarli per volume di ordini e disponibilità a collaborare, e migrarli in ordine

Anche JIPDEC (Jipdekku, 一般財団法人日本情報経済社会推進協会, Fondazione per la promozione dell’economia e della società dell’informazione del Giappone; ente noto per la gestione del sistema PrivacyMark e del codice aziendale standard) afferma, nella pagina esplicativa del progetto sul codice aziendale standard “I vantaggi dell’EDI e la necessità degli standard”, che “se restano l’elaborazione manuale e la gestione di fax e telefono, è necessario garantire il personale a tale scopo, e non si arriva a un’automazione e una meccanizzazione al 100%, così i benefici dell’efficientamento non si ottengono appieno”. Proprio per questo, il periodo di doppia gestione non va lasciato come “qualcosa che accade inevitabilmente”, ma il piano stesso per accorciarlo va reso oggetto di progettazione.

Mappa della conoscenza di questo articolo

Questo articolo tratta la progettazione di una migrazione graduale degli ordini via fax: l’obiettivo non è passare tutto al Web in un colpo solo, ma ridurre il numero di ordini che una persona deve inserire. I canali di ricezione possono essere più di uno, ma la gestione interna degli ordini va unificata in un unico flusso; si inserisce l’import CSV come forma intermedia, poi i partner commerciali si classificano in A, B e C per volume e disponibilità a collaborare, e si costruisce il modello con un solo partner pilota prima di espandere. Nel periodo di doppia gestione si fissano in cifre una scadenza e un valore obiettivo, e ogni mese si misurano i volumi per canale usando la colonna del canale di ricezione. La tabella di conversione dei codici resta presso di noi, che siamo i primi a sapere dei cambiamenti di prodotto; dopo l’import CSV seguono forme superiori come il codice aziendale standard e l’EDI.

flowchart LR
    accTitle: Mappa della conoscenza della migrazione graduale degli ordini via fax sul Web
    accDescr: Diagramma che mostra la progettazione di una migrazione graduale: l'obiettivo è ridurre il numero di ordini inseriti da una persona, e accorciare con una scadenza il periodo di doppia gestione tramite l'import CSV come forma intermedia, la classificazione dei partner commerciali e la costruzione del modello con un pilota
    fax_order_web_migration["Passaggio degli ordini FAX al Web (graduale)"]
    dual_operation_period["Periodo di doppia gestione"]
    transcription_volume_reduction_goal["Obiettivo: meno ordini inseriti a mano"]
    all_at_once_web_migration["Passaggio immediato e totale al Web"]
    indefinite_dual_operation["Doppia gestione permanente senza scadenza"]
    dual_operation_deadline_target["Scadenza e obiettivo della doppia gestione"]
    channel_migration_kpi["Misura dei volumi per canale"]
    receiving_channel_field["Colonna canale di ricezione"]
    csv_import_intermediate_form["Import CSV come forma intermedia"]
    csv_file_format_spec["Accordo sul formato file CSV"]
    master_data_readiness["Preparazione anagrafiche prodotti e clienti"]
    pilot_partner_approach["Modello con un partner pilota"]
    partner_classification["Classificazione dei partner (A/B/C)"]
    unified_order_channel_processing["Più punti di ingresso, un'unica gestione interna"]
    code_mapping_ownership_rule["Chi detiene la tabella di conversione"]
    all_or_nothing_import_validation["Blocco totale dell'import su errore"]
    import_failure_notification["Notifica minima di import fallito"]
    cross_channel_rule_consistency["Regole operative allineate tra i canali"]
    duplicate_order_registration["Registrazione duplicata"]
    fax_handling_improvement["Miglioramento della ricezione FAX"]
    edi["EDI (scambio elettronico di dati)"]
    standardized_business_code["Codice impresa standard"]
    fax_order_web_migration -->|"richiede"| dual_operation_period
    transcription_volume_reduction_goal -->|"consigliato per"| fax_order_web_migration
    all_at_once_web_migration -->|"può causare"| indefinite_dual_operation
    transcription_volume_reduction_goal -->|"previene"| all_at_once_web_migration
    dual_operation_deadline_target -->|"mitiga"| indefinite_dual_operation
    channel_migration_kpi -->|"usa"| receiving_channel_field
    dual_operation_deadline_target -->|"verificato da"| channel_migration_kpi
    csv_import_intermediate_form -->|"consigliato per"| fax_order_web_migration
    csv_import_intermediate_form -->|"usa"| csv_file_format_spec
    csv_import_intermediate_form -->|"richiede"| master_data_readiness
    pilot_partner_approach -->|"richiede"| master_data_readiness
    partner_classification -->|"consigliato per"| fax_order_web_migration
    partner_classification -->|"deve precedere"| pilot_partner_approach
    unified_order_channel_processing -->|"consigliato per"| fax_order_web_migration
    code_mapping_ownership_rule -.->|"consigliato per"| csv_import_intermediate_form
    all_or_nothing_import_validation -.->|"consigliato per"| csv_import_intermediate_form
    all_or_nothing_import_validation -->|"richiede"| import_failure_notification
    cross_channel_rule_consistency -->|"consigliato per"| fax_order_web_migration
    cross_channel_rule_consistency -->|"mitiga"| duplicate_order_registration
    fax_handling_improvement -->|"consigliato per"| dual_operation_period
    edi -->|"successore di"| csv_import_intermediate_form
    standardized_business_code -.->|"consigliato per"| edi
    partner_classification -->|"previene"| all_at_once_web_migration

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 23, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Perché il passaggio immediato e totale al Web tende a fallire

Il passaggio degli ordini via fax al Web presenta una caratteristica che non può essere decisa solo in base alle esigenze del sistema interno: è il partner commerciale a inviare l’ordine.

Un approccio che annuncia a tutti i partner commerciali “dal mese prossimo ordinate tramite Web” tende a portare ai seguenti fallimenti:

• I partner commerciali che possono ordinare solo via fax smettono di essere un’“eccezione” e diventano un “ostacolo al piano”
• Ogni partner commerciale ha circostanze diverse, ma viene imposta a tutti la stessa scadenza
• Gli ordini dei partner che non migrano continuano ad arrivare via fax, rendendo la doppia gestione permanente
• Il progetto viene giudicato come “siamo passati al Web, ma il personale non è diminuito”, e si blocca

La causa è aver fissato l’obiettivo su “eliminare il fax”.

Sostituendo l’obiettivo con “ridurre il numero di ordini che richiedono inserimento manuale”, il piano diventa realistico. Ad esempio, se solo i partner commerciali principali, che rappresentano il 70% degli ordini, migrano verso il Web o il CSV, il lavoro di inserimento si riduce notevolmente anche se il restante 30% rimane sul fax.

Invece di muovere tutto in una volta, si procede prima dove l’impatto è maggiore. Questo è il principio di base di una migrazione graduale.

3. Come apparirà dopo la migrazione ── più punti di ingresso, un’unica gestione interna

Prima di progettare la migrazione graduale, si delinea prima la forma a cui si mira.

Il punto chiave è pensare separatamente il canale di ricezione e la gestione degli ordini.

flowchart LR
    ORDER["Dati d'ordine comuni<br/>(formato unificato)"]
    BACK["Gestione interna<br/>allocazione scorte, spedizione, fatturazione"]
    subgraph CH["Canali di ricezione"]
        FAX["FAX"]
        MAIL["Allegato e-mail"]
        CSV["Import CSV"]
        WEB["Schermata ordine Web"]
    end
    FAX -->|"Inserito da un addetto"| ORDER
    MAIL -->|"Inserito da un addetto"| ORDER
    CSV -->|"Import automatico"| ORDER
    WEB -->|"Registrazione automatica"| ORDER
    ORDER --> BACK

Indipendentemente da quanti canali di ricezione esistano, finché il formato e la gestione dei dati d’ordine a valle sono unificati in un unico flusso, i processi successivi - scorte, spedizione, fatturazione - continuano a funzionare secondo un flusso comune.

Al contrario, se si crea una gestione o un registro separato per ogni canale, l’attività si complica a ogni nuovo canale aggiunto, e il carico della doppia gestione continua a crescere.

Anche un ordine arrivato via fax, una volta inserito da un addetto, deve diventare gli stessi dati d’ordine degli altri canali. Si può dire che la migrazione consista nel ridurre, in questo schema, il volume che scorre nella riga “inserito da un addetto”, aumentando quello che scorre nelle righe “import automatico” e “registrazione automatica”.

Non è necessariamente indispensabile rifare il sistema di gestione vendite esistente. Finché si può verificare se è possibile aggiungere un punto di ingresso per i dati d’ordine (una funzione di import CSV, un’integrazione con database, un’API, ecc.), si può procedere mantenendo l’impostazione attuale. Questo punto di verifica è esattamente ciò che è stato trattato in “Verificare il collegamento con i sistemi interni” nell’articolo precedente sull’EDI.

4. L’import CSV come forma intermedia

Chiedere a un partner commerciale di passare direttamente dal fax all’inserimento tramite schermata Web può rappresentare per lui un onere notevole.

Dal punto di vista di chi ordina, l’inserimento tramite schermata Web significa “reinserire, nella schermata dell’altra parte, un ordine già creato nel proprio sistema di ordinazione o in Excel”. Se il partner commerciale genera già i dati d’ordine tramite il proprio sistema, ricevere quei dati così come sono, sotto forma di file, e importarli comporta meno lavoro per entrambe le parti.

Perciò, come forma intermedia, si prevede l’import CSV (o Excel).

Fase 1: ricevere il CSV come allegato e-mail, che un addetto carica tramite la funzione di import
Fase 2: il partner commerciale carica il CSV da una pagina Web, con import automatico
Fase 3: i partner ormai standardizzati passano alla schermata di ordine Web o all'EDI

Già alla prima fase, il tempo di inserimento e gli errori di trascrizione diminuiscono nettamente rispetto all’inserimento manuale guardando il modulo d’ordine cartaceo. Un altro vantaggio è che è più facile ottenere la collaborazione, poiché il cambiamento richiesto al partner commerciale si limita a “sostituire ciò che veniva inviato via fax con un allegato e-mail”.

Quando si progetta l’import CSV, occorre definire almeno i seguenti elementi.

Tra questi sei elementi, quello che in pratica genera più discussioni è il sistema di codici. Chiedere al partner commerciale di “inviare con i propri codici prodotto” oppure di “convertirli prima nei nostri e poi inviare” determina chi detiene la tabella di conversione. Dal commerciale si sente dire “è più comodo se il partner invia con i nostri codici”; dai sistemi informativi, “tenere una tabella di conversione per ogni partner è un onere”.

Il punto di equilibrio è: la tabella di conversione la detiene chi viene a sapere per primo dei cambiamenti di prodotto. Chi per primo sa dei nuovi prodotti o di quelli fuori produzione è la propria azienda; se la conversione avviene dal proprio lato, non è più necessario chiedere a tutti i partner “sostituite la tabella dei codici” ogni volta che si aggiungono o si eliminano prodotti. Il metodo in cui si chiede al partner di memorizzare i nostri codici è comodo all’inizio, ma a ogni modifica di prodotto genera una comunicazione verso altrettante persone. Chiudere questo andirivieni prima della migrazione evita di dover rispiegare in seguito “perché è stato progettato così”.

Un altro punto che tocca direttamente l’operatività è il modo di restituire gli errori. In linea di principio, è più sicuro che l’import “si fermi con errore sull’intero file” (se anche una sola riga non è valida, non si importa nulla) piuttosto che inseguire in seguito un ordine entrato solo in parte. Ma questo vale solo a condizione che l’avvenuto blocco arrivi sempre a qualcuno. Una configurazione minima è la seguente:

• Notifica e-mail interna ── invio automatico di “import fallito” alla mailing list degli addetti agli ordini. Nell’oggetto, nome file e nome del partner commerciale; nel corpo, numero di riga dell’errore e causa (ad esempio “il codice prodotto ABC-123 non è presente in anagrafica”).
• Storico import nella schermata di gestione ── predisporre una schermata in cui successo, fallimento e non elaborato siano visibili in un elenco. Anche se l’e-mail viene trascurata, basta guardare questa schermata per prima cosa al mattino per accorgersene.
• Contatto con il partner commerciale ── all’inizio non si risponde in automatico; l’addetto interno verifica il contenuto e poi contatta. Quando si passa al caricamento via Web, l’errore viene mostrato immediatamente nella schermata di upload.

Una progettazione del tipo “gli errori sono nel log, per favore controllate” non è adatta al periodo di doppia gestione. Gli addetti sono già saturi con l’elaborazione dei fax.

Il CSV sembra semplice, ma è un formato con molte insidie riguardo alla codifica dei caratteri, agli a capo, e alla gestione di virgole e virgolette. I punti tecnici a cui prestare attenzione nell’implementare l’elaborazione di import sono riassunti in “Guida pratica alla gestione dei file CSV”.

Da notare che l’import CSV non è la forma finale, ma una forma intermedia. La definizione dei campi e il sistema di codici decisi qui costituiranno direttamente la base anche per il successivo ordine Web o EDI.

5. Preparare prima le anagrafiche di prodotti e clienti

Con gli ordini via fax, sono gli addetti ad assorbire le lacune delle anagrafiche.

Ad esempio, anche se sul modulo d’ordine è scritto un vecchio nome di prodotto, l’addetto interpreta “questo significa l’attuale versione di questo prodotto” e lo inserisce di conseguenza. Anche se l’unità è scritta come “cartone”, l’addetto ricorda quanti pezzi contiene un cartone e fa la conversione.

Passando all’import CSV o all’ordine Web, questa interpretazione deve essere svolta da una macchina. Inoltre, nella schermata di ordine Web, l’anagrafica prodotti viene esposta direttamente allo sguardo del partner commerciale.

Per questo motivo, prima della migrazione è necessaria almeno la seguente preparazione:

• Pulizia dei codici prodotto (gestione degli articoli fuori produzione, unificazione dei duplicati, tabella di corrispondenza tra codici vecchi e nuovi)
• Uniformazione della denominazione dei prodotti (i nomi sono presentabili ai partner commerciali?)
• Unità e quantità per confezione (relazione tra pezzo singolo, cartone e pallet, quantità minima d’ordine)
• Codici partner commerciale e codici di destinazione di consegna (come gestire i casi in cui un partner ha più destinazioni di consegna)
• Dove gestire i prezzi applicati e le condizioni contrattuali specifiche per ciascun partner

Il punto importante qui è non cercare di perfezionare tutte le anagrafiche prima di iniziare. Aspettare questo significa che la migrazione non inizierà mai.

L’approccio realistico è preparare prima solo l’ambito di prodotti e destinazioni di consegna riguardante il primo partner commerciale che migra (il pilota), per poi ampliare tale ambito a ogni nuovo partner aggiunto alla migrazione. Integrate il lavoro di preparazione delle anagrafiche stesso nelle fasi della migrazione graduale.

6. Progettare il periodo di doppia gestione

La doppia gestione di fax e Web (CSV) si verificherà inevitabilmente durante il periodo di migrazione. Se lasciata senza progettazione, la doppia gestione diventa permanente, e ci si ritrova in una situazione in cui “il lavoro è aumentato esattamente di quanti canali sono stati aggiunti”.

Progettare il periodo di doppia gestione significa concretamente decidere quanto segue.

6.1. Fissare una durata e un valore obiettivo

Decidere in cifre “entro quando, quale percentuale di ordini dovrà essere importata automaticamente”. Ad esempio, in una forma come “ridurre la quota di ordini via fax dal 70% al 30% entro sei mesi”.

Una doppia gestione senza scadenza si cristallizza così com’è. Anche se l’obiettivo non viene raggiunto, avere una scadenza spinge a verificare, partner per partner, “perché la migrazione non progredisce”.

6.2. Misurare ogni mese i volumi per canale

L’avanzamento della migrazione va seguito con i numeri, non a sensazione.

• Numero di ordini per canale (fax, allegato e-mail, CSV, Web)
• Numero di ordini inseriti manualmente e tempo impiegato
• Numero di errori di import e relative cause
• Numero di correzioni di inserimento e registrazioni duplicate

Questo è lo stesso approccio degli indicatori da misurare dopo l’adozione menzionati nell’articolo precedente. Misurare separatamente per canale permette di vedere “su quale partner commerciale vale la pena agire per il maggiore impatto”.

Il problema è come raccogliere questi dati. Se si decide “contiamo ogni mese” senza un meccanismo, il conteggio si ferma al primo mese. Ciò che è affidabile è aggiungere un solo campo di misurazione ai dati d’ordine stessi.

Se non è possibile aggiungere una colonna al sistema di gestione vendite esistente, si conservano i log dell’elaborazione di import e della schermata di inserimento in una tabella separata, e si aggrega da lì. In ogni caso, il modo di misurare si decide prima di avviare la migrazione. Poiché il criterio di giudizio delle fasi (capitolo 8) di cui si parlerà più avanti è la quota per canale, se quella quota non si può ottenere non si può decidere se passare alla fase successiva o fermarsi.

6.3. Allineare le regole operative tra i canali

La confusione durante il periodo di doppia gestione tende a sorgere quando le regole aziendali differiscono a seconda del canale.

• L’orario limite di chiusura ordini è lo stesso per fax e Web?
• Quale canale gestisce modifiche e cancellazioni degli ordini? (Se un ordine ricevuto via Web viene modificato via fax, sarà necessaria una riconciliazione.)
• Il metodo di notifica in caso di esaurimento scorte cambia a seconda del canale?
• Il numero d’ordine è univoco tra tutti i canali? (Necessario per individuare registrazioni duplicate.)

In particolare, il pattern “ordinare via Web, per poi modificare subito dopo per telefono o via fax” si verificherà inevitabilmente. Decidete in anticipo quale canale gestisce le modifiche, e chi è responsabile di correggere quali dati.

6.4. Rendere oggetto di miglioramento anche il modo di ricevere il fax

Durante il periodo di doppia gestione, il fax rimane. Poiché si parte dal presupposto che rimanga, anche l’elaborazione lato fax è oggetto di miglioramento.

• Ricevere il fax tramite una multifunzione e convertirlo in PDF, smettendo di gestire la carta
• Raccogliere i PDF ricevuti in una cartella ordini e gestire lo stato di elaborazione (non elaborato, inserito, in sospeso)
• Collegare l’originale fax (PDF) dopo l’inserimento ai dati d’ordine tramite il numero d’ordine, così da poterli riscontrare in seguito

Pensare che “il fax prima o poi sparirà, quindi non vale la pena toccarlo” non riduce il carico durante il periodo di doppia gestione. Fino al completamento della migrazione, trattate l’elaborazione del fax come un ulteriore canale che confluisce negli stessi dati d’ordine.

7. Come coinvolgere i partner commerciali

Il successo della migrazione graduale dipende più dal modo in cui ci si rivolge ai partner commerciali che dal lavoro interno.

7.1. Classificare i partner commerciali

Non trattare tutti i partner commerciali allo stesso modo, e classificarli prima.

Sono le categorie A e B a determinare l’impatto. Cercare di far muovere forzatamente i partner della categoria C comporta solo costi, quindi è accettabile dichiarare loro chiaramente “continueremo ad accettare anche il fax”.

7.2. Scegliere un solo partner pilota

Invece di migrare più partner in parallelo fin dall’inizio, è meglio consolidare prima l’operatività con un solo partner. I criteri di selezione sono gli stessi dell’articolo precedente:

• Volume di transazioni elevato, così l’impatto è facile da misurare
• Prevalenza di ordini di tipo standardizzato
• Comunicazione agevole tra gli addetti di entrambe le parti, e comprensione dell’integrazione dei sistemi

Con il pilota, costruite il “modello” - formato CSV, modo di comunicare in caso di errore, tabella di corrispondenza delle anagrafiche, documenti guida - e riutilizzate questo modello a partire dal secondo partner.

7.3. Presentare la proposta in base al beneficio per il partner

Dal punto di vista del partner commerciale, un cambiamento nel metodo di ordinazione è una richiesta dettata dalla convenienza della propria azienda. Presentate quindi la proposta in base al beneficio del partner, non alla propria efficienza.

• La conferma d’ordine arriva immediatamente, eliminando la necessità di telefonate per verificare “se è arrivato”
• Diminuiscono spedizioni errate ed errori di quantità dovuti a letture sbagliate
• Il partner può consultare autonomamente lo storico degli ordini, rendendo più agevoli gli ordini ripetuti (nel caso dell’ordine Web)
• Non serve più l’attività di invio via fax né il reinvio in caso di errori di trasmissione

Anche l’attenzione pratica dà i suoi frutti.

• Riassumere la procedura operativa in un manuale di una sola pagina (puntare a un’ampiezza spiegabile con poche schermate)
• Indicare esplicitamente la data di inizio e il periodo di coesistenza (“dal mese X accettiamo ordini anche via Web; il fax resta comunque utilizzabile in parallelo”)
• Nelle prime volte, accettare gli ordini indipendentemente dal fatto che arrivino via fax o Web, e rispondere immediatamente alle richieste

Inoltre, non è consigliabile pubblicare fin dall’inizio un avviso del tipo “il fax verrà eliminato dal mese X”. È preferibile sollevare la questione della scadenza solo quando la migrazione è già avanzata e i partner commerciali rimasti si sono ridotti a pochi, in modo da non danneggiare il rapporto.

Riguardo alla digitalizzazione dello scambio di ordini per le piccole e medie imprese, l’Agenzia per le PMI giapponese presenta iniziative di standardizzazione, incluso un EDI comune, e i relativi benefici. Se la vostra associazione di categoria o i principali partner commerciali già supportano tali standard, vale la pena considerare anche l’opzione di allinearsi a uno standard anziché a un formato proprietario.

8. Un caso modello di migrazione graduale

Organizziamo tutto quanto detto finora in un modello cronologico. Queste durate sono solo un esempio e variano in base al numero di partner commerciali e all’organizzazione interna.

L’“analisi della situazione attuale” della fase 0 può riutilizzare direttamente l’elenco dei metodi attuali di gestione degli ordini presentato nell’articolo precedente.

Inoltre, se non siete sicuri se spostare sul Web la gestione degli ordini stessa o mantenerla come applicazione desktop, “Conviene spostare un’applicazione Windows sul Web?” delinea un quadro decisionale. Spostare sul Web il canale di ricezione e spostare sul Web il sistema interno sono decisioni che possono essere prese indipendentemente l’una dall’altra.

9. Ostacoli comuni e contromisure

Infine, riassumiamo gli ostacoli che si verificano comunemente nelle migrazioni reali.

Conclusione

Spostare gli ordini via fax sul Web è meno un lavoro di costruzione di un sistema e più un lavoro di progettazione del periodo di migrazione.

• Fissare l’obiettivo su “ridurre il numero di ordini che richiedono inserimento manuale”, non su “eliminare il fax”
• I canali di ricezione possono essere più di uno, ma i dati e la gestione degli ordini interni vanno unificati in un unico flusso
• Non richiedere subito l’inserimento tramite schermata Web, ma inserire l’import CSV come forma intermedia
• Far progredire la preparazione delle anagrafiche in modo graduale, partendo dall’ambito del primo partner commerciale che migra
• Fissare una scadenza e un valore obiettivo per il periodo di doppia gestione, misurando l’avanzamento con i volumi per canale
• Classificare i partner commerciali per volume e disponibilità a collaborare, costruire il modello con un solo pilota e poi espandere

Come riassunto nell’articolo precedente, il beneficio dell’EDI o dell’ordine Web è determinato da fino a che punto i dati ricevuti possono scorrere nei processi aziendali interni. Progettare la migrazione significa pianificare, in un ordine ragionevole, come aumentare la proporzione di ordini che confluiscono in quel flusso.

Per chi sta valutando di spostare sul Web lo scambio di ordini

Se state valutando di ripensare gli ordini via fax ma non siete sicuri da dove cominciare - coordinamento con i partner commerciali, connessione al sistema di gestione vendite esistente, come procedere con il formato CSV e la preparazione delle anagrafiche - è necessario iniziare organizzando prima il conteggio attuale degli ordini per canale.

KomuraSoft LLC (合同会社小村ソフト) può assistervi nella progettazione e implementazione dell’import CSV e dell’integrazione con l’ordine Web sfruttando le applicazioni aziendali e i database Windows esistenti, oltre che nell’organizzazione del piano di migrazione stesso.

Senza presupporre necessariamente un rifacimento completo, si può anche valutare una configurazione che mantenga l’attuale impostazione di gestione vendite, aggiungendo gradualmente i canali di ricezione.

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.