Ovvero come portare a termine la migrazione delle anagrafiche articoli dal vecchio gestionale al nuovo sistema E.R.P.

La migrazione delle anagrafiche è stato il primo ostacolo che abbiamo dovuto affrontare.

Come i tentacoli per un polpo le anagrafiche rappresentano i molti piedi di appoggio di un sistema E.R.P. Queste ultime hanno la funzione di sostenere e far muovere l’intero sistema. La progettazione attenta delle anagrafiche determina il buon funzionamento dell’intero applicativo. Quindi la regola principe in questo campo è non commettere errori!

Indice

1. Anagrafica Articoli: Prodotti Finiti
2. Anagrafica Articoli: Materie Prime
3. Anagrafica Articoli: Contenitori

1. Anagrafica Articoli: Prodotti Finiti

I prodotti finiti presentavano uno schema di codifica non perfettamente rigoroso, per via delle differenti stratificazioni generate con il passare degli anni.

Ma il problema principale era la codifica dei prodotti “custom”, prodotti diversi dallo standard in quanto caratterizzati da elementi di personalizzazione lato cliente, che spaziavano dalla semplice applicazione di un’etichetta alla variante in termini di imballo/formulazione.

Queste varianti custom venivano differenziate dagli articoli standard attraverso un suffisso KK/FF posto in fondo al codice. Per esempio:

• 0716        PREPARATO VEGETALE UHT1000ML (standard)
• 0716KK    PREPARATO VEGETALE UHT1000ML (packaging fuori standard)
• 0716FF    PREPARATO VEGETALE UHT1000ML (formulazione fuori standard)

Quindi, tornando all’esempio, l’articolo 0716KK conteneva in sé tutte le possibili varianti degli enne clienti che lo acquistavano in forma personalizzata. A questo articolo era associato un EAN13 diverso dallo standard.

Di conseguenza si evidenziavano queste problematiche:

1. la tipologia delle personalizzazioni non era sempre esplicitata in modo chiaro e univoco, con possibili fraintendimenti lato produzione;
2. la distinta base non veniva declinata per tutte le varianti, potendo generare una non perfetta valutazione dei costi e un certamente errato consumo di materiali e risorse;
3. un’eventuale ricodifica avrebbe creato serie difficoltà per via della preesistente integrazione del vecchio gestionale con il software di etichettatura prodotti;
4. in fase di picking si correva il rischio che potesse essere prelevata una variante al posto di un’altra, condividendo queste ultime lo stesso codice a barre;
5. le classificazioni degli articoli (linea e macro famiglia) presentavano alcuni elementi di ridondanza;
6. la gestione di un’unica unità di misura era fortemente limitante nei rapporti con alcuni canali, abituati a ragionare non nell’ottica di Kg/Lt ma in termini di Nr pezzi (GDO);
7. Bisognava studiare una strategia di migrazione che potesse da un lato velocizzare la presa dati, senza tuttavia rinunciare alla possibilità di introdurre significativi elementi di miglioramento messi a disposizione dal nuovo E.R.P.

Insomma, la sfida dell’import degli articoli chiamava e noi dovevamo rispondere!

In men che non si dica eravamo già sotto coperta in cerca di una soluzione per esplicitare in modo chiaro e univoco tutte le possibili personalizzazioni degli articoli.

Il modello “tentacolare” delle configurazioni ci è venuto in aiuto: abbiamo costruito uno schema di configurazione che tenesse conto delle seguenti varianti:

• etichetta cliente
• formula di produzione
• lingua del packaging
• promozione
• imballo

Fatto questo è stato necessario rimappare i vecchi codici articolo sulla base della nuova combinazione articolo-configurazione.

A questo punto avevamo evidenziato il fenomeno delle personalizzazioni ma non eravamo ancora in grado di gestirlo. Come avremmo potuto tradurre l’elenco di queste specifiche in informazioni utili per i reparti produttivi?

Il modello produttivo, cuore pulsante del modulo produzione Panthera era la risposta.

Il modello produttivo è una distinta base evoluta che consente di descrivere in modo molto dettagliato componenti e risorse utilizzati per la realizzazione di un prodotto. Per esempio, nella preparazione di una crema alla nocciola entrano in gioco materie prime alimentari come il cacao e le nocciole, parti di acquisto come i materiali di confezionamento, risorse macchina: gli impianti di produzione e confezionamento e risorse umane.

La scelta di aderire a questo nuovo paradigma comportava la necessità di ricaricare a mano i modelli produttivi di tutti i prodotti e le regole di condizionamento di tutte le personalizzazioni. Un’impresa ciclopica che Roberto ci ha aiutati a portare a termine nei tempi prefissati.

Inoltre andava studiata una strategia per integrare questa nuova filosofia di codifica con doppia chiave all’interno del software utilizzato per la gestione del processo di etichettatura prodotti.

Forte della conoscenza dell’applicativo, Marco ci ha risparmiato un grosso grattacapo, realizzando strumenti di verifica e script di migrazione automatica, consentendoci di non arrestare nemmeno per un attimo l’applicativo mission critical per la gestione dell’etichettatura prodotti.

A completamento di queste attività siamo intervenuti per scongiurare anche il rischio che in fase di picking potesse essere prelevata una variante del prodotto al posto di un’altra, assegnando ad ogni combinazione articolo-configurazione uno specifico EAN13.

Restavano poi da definire la riclassificazione delle linee-macro e la gestione delle unità’ di misura. Il primo punto non presentava particolari difficoltà mentre l’articolazione delle diverse unità di misura si manifestava come un problema di difficile soluzione.

Dopo un’analisi più approfondita appoggiammo l’idea di utilizzare le categorie di unità di misura. In sostanza ogni articolo poteva essere ricondotto ad una categoria di unità di misura in funzione della struttura del packaging e dei fattori di conversione tra le diverse UM. Per esempio tutte le basi per gelato confezionate in cartone contenenti 4 sacchetti da 1,3 kg potevano essere ricondotti alla categoria UM “scatola 4 sacchetti x 1,3”. Questo avrebbe comportato l’apertura di nuove possibilità anche nelle politiche e negli automatismi di generazione dei listini di vendita.

Infine abbiamo sviluppato una strategia di migrazione modulare step-by-step che ci ha consentito di automatizzare la presa dati, introducendo tutti gli elementi di miglioramento messi a disposizione dal nuovo E.R.P. Tuttavia, data la complessità delle nuove variabili in gioco, la familiarità della forza vendite con i vecchi codici e la difficoltà di far accogliere variazioni anagrafiche alla clientela più strutturata (GDO/clienti esteri con problematiche di registrazione doganale) si è deciso di non procedere alla ricodifica dei prodotti finiti.

2. Anagrafica Articoli: Materie Prime

La migrazione delle materie prime presentava tre aree problematiche:

• la definizione di un nuovo schema di codifica;
• la codifica dei lotti;
• la gestione delle versioni;

Il nuovo schema di codifica

Non avendo particolari vincoli come nel caso dei prodotti finiti, decidemmo per un schema di codifica completamente nuovo e più razionale. Tutti gli articoli in acquisto furono divisi in due macro gruppi: Materie prime (alimentari) e Parti di acquisto (imballi e materiali sussidiari).

Per le materie prime adottammo una classificazione di 21 linee prodotto mentre per le parti di acquisto ne evidenziammo 22.

Di conseguenza mettemmo su carta lo schema di codifica risultante:

• Cod. Articolo da 301001 a 321999 materie prime;
• Cod. Articolo da 401001 a 422999 pardi d’acquisto.

Per non perdere il legame tra vecchio e nuovo schema di codifica utilizzammo il campo Descrizione ridotta su Panthera per riportare il vecchio codice articolo ed evitare così errori di identificazione, soprattutto nella fase iniziale di avvio del progetto.

La codifica dei lotti delle materie prime in acquisto

Lo standard Panthera prevede la possibilità di decidere come impostare la gestione dei lotti delle materie prime in acquisto, in maniera completamente autonoma rispetto alla gestione dei lotti di prodotti finiti, conto lavorazione e conto trasformazione.

Nello specifico è possibile scegliere se affidare al sistema la proposizione automatica dei lotti, il tipo di codifica ed il momento di creazione del lotto: all’emissione dell’Ordine piuttosto che del Documento di acquisto.

Le stese logiche di proposizione del lotto definite in fase di configurazione generale del sistema possono essere infatti gestite in deroga in maniera puntuale sull’anagrafica di ciascun articolo, consentendo un grado di flessibilità estremamente interessante.

Per l’azienda in questione scegliemmo la proposizione automatica dei lotti di acquisto nel formato AA/Tipo/Progressivo all’emissione del Documento di acquisto.

Questo per tutti gli articoli in acquisto, fatta eccezione per alcuni articoli per i quali invece la proposizione automatica andava disattivata.

La gestione delle versioni

Affrontammo poi la problematica della gestione di alcune parti di acquisto che erano suscettibili di variazioni nel corso tempo, come ad esempio i materiali di confezionamento.

Nello specifico alcuni imballi stampati venivano sottoposti a periodiche revisioni (di carattere informativo/commerciale o per rispondere a precisi dettami legislativi), determinando l’esistenza di diverse versioni dello stesso articolo.

Per questi articoli decidemmo di attivare il versionamento, e di conseguenza la tenuta saldi con profondità di versione (i saldi delle vecchie versioni avrebbero dovuto tendere a zero).

Tuttavia per non complicare ulteriormente la gestione dei prodotti finiti (già articolata in articolo/configurazione/lotto) decidemmo di non attivare il versioning degli articoli finiti su cui confluivano le parti di acquisto gestite a versioni.

3. Anagrafica Articoli: Contenitori

Nella gestione dei contenitori (nel ns caso pallet EPAL) dovevano essere previste due diverse tipologie di comportamento:

1. la valorizzazione immediata dei contenitori (problematica tipicamente legata al mercato estero);
2. la tenuta saldo contenitori per vettore.

Il primo caso rientrava nella gestione standard Panthera in quanto il contenitore poteva essere inserito direttamente in ordine come articolo di vendita (con apposita aliquota IVA) ed evaso come un normale articolo, scaricando direttamente il magazzino principale.

Nel secondo caso invece dovevamo studiare una gestione dei saldi contenitori che permettesse di monitorare la situazione delle giacenze con dettaglio Vettore (lo standard Panthera prevede invece la gestione in capo al Cliente).

Per ottenere questo risultato decidemmo di spostare l’imputazione dei contenitori spediti dal Cliente al Vettore,  attraverso la lettura, in fase di chiusura picking, del codice a barre del Vettore (codice fornitore) e del tipo di contenitore utilizzato.

Realizzammo quindi una personalizzazione che, al momento della stampa dei documenti, produceva un Documento Generico don doppia movimentazione:

• un movimento di uscita dal magazzino aziendale principale (-);
• un movimento di entrata nell’apposito magazzino contenitori con profondità fornitore (+).

Anche la riconsegna dei contenitori da parte dei Vettori veniva gestita con un Documento Generico (in questo caso manuale) don doppia movimentazione:

• un movimento di uscita dal magazzino contenitori con profondità fornitore (-);
• un movimento di entrata nel magazzino aziendale principale (+).

La consegna dei pallet ai vettori era riepilogata in un apposito report personalizzato “Scheda di carico” stampato al momento della spedizione della merce che riepilogava il nr di pallet assegnato al vettore, come da esempio che segue.

Scheda di carico del 21/08/2018 – Vettore ALFA TRASPORTI SPA – Pagina 1 di 3

La comunicazione del saldo contenitori veniva invece comunicata attraverso la generazione del report standard “stampa scheda magazzino con profondità fornitore”:

Stampa Scheda magazzino del 21/08/2018 – Fornitore ALFA TRASPORTI SPA – Pagina 1 di 42