Ovvero come tirarsi fuori da una situazione limacciosa
Anche quando credi di aver fatto un ottimo lavoro, anche quando sei certo di averle pensate tutte, nel nostro mestiere l’insidia è sempre dietro l’angolo.
Tutti i test preliminari nell’ambiente di prova, avevano dato esito positivo. Avevamo procrastinato questo intervento prendendoci tutto il tempo necessario per le opportune verifiche. Quindi programmammo l’aggiornamento per la notte tra il 4 e il 5 aprile.
Fu così che il mattino seguente ci trovammo a dover affrontare un problema sul processo più nevralgico dell’azienda: la gestione del picking. Improvvisamente i terminali in radiofrequenza del magazzino avevano smesso di funzionare nel modo consueto, non consentendo la chiusura delle liste picking ed impedendo il cambio di stato dei documenti.
Il blocco della funzione di picking rappresenta un problema serio per un’azienda, tanto da poter determinare l’arresto della bollettazione e, di conseguenza, la mancata evasione degli ordini. Senza contare il caos generato nella programmazione delle consegne e i disservizi ai clienti.
Ci trovavamo di fronte alla tempesta perfetta, in grado di mettere a dura prova persino i lupi di mare più navigati.
Bisognava nel minor tempo possibile:
- coordinare le attività della squadra del magazzino;
- attivare velocemente la procedura di emergenza che consisteva nell’effettuare il picking in modalità manuale su PC;
- fornire supporto alla squadra dei tecnici che si stava occupando del troubleshuting.
La pressione era alle stelle e, dopo più di una giornata spesa nel tentativo vano di diagnosticare il problema, un misto di frustrazione e spaesamento iniziava a prendere il sopravvento nell’animo dei nostri protagonisti.
Poi, la sera del 6 aprile, dopo l’ennesimo test un indizio mi spinse ad ipotizzare una possibile causa: avevo notato una differente modalità di funzionamento tra l’ambiente reale e quello di prova: nell’ambiente reale la chiusura del picking non determinava il cambio di stato del documento di vendita, mentre nell’ambiente di prova questo avveniva normalmente.
Preso dall’entusiasmo preparai un dettagliato documento di analisi corredato da screenshot esplicativi da inviare ai tecnici per la verifica.
Il giorno seguente, lo stesso test effettuato con Giampaolo a parità di condizioni portava allo stesso identico risultato, privando di ogni utilità diagnostica quell’intuizione che mi era parso potesse aiutare nella risoluzione del caso.
Nel frattempo la squadra aveva affinato una notevole dimestichezza nella gestione dell’emergenza, anticipando l’esecuzione manuale del picking e il momento della bollettazione in modo da avere il tempo necessario per affrontare eventuali problemi dell’ultimo minuto.
Il venerdì eravamo ancora lontani dalla comprensione del problema. Il malfunzionamento infatti sembrava verificarsi solo in condizioni di normale operatività dell’azienda. I successivi test effettuati il sabato e la domenica ci diedero ragione confermando un’evidenza inizialmente solo presunta.
Il passo successivo sarebbe stato di partire il lunedì con un solo terminalino in funzione, attivando gradualmente tutti gli altri e schedulando il login di un solo utente alla volta in modo da analizzare gli effetti di queste interazioni.
E cosi di buona lena il lunedì successivo iniziammo i test di concorrenza degli utenti, scoprendo ahimè solo alla fine di essere sulla strada sbagliata.
Infine, dopo quasi due settimane di passione riuscimmo ad emergere da quella situazione limacciosa: avevamo scoperto che il comportamento del browser PC risultava non perfettamente in linea col comportamento del browser dei terminalini, rendendo le attività di troubleshuting una difficilissima caccia la tesoro!
Nota. Il problema evidenziato ha riguardato il modulo della logistica light, un modulo molto recente che l’azienda in questione ha dovuto adottare in tempi stretti per consentire l’avvio del progetto. La giovane età del modulo e la mancanza di un installato sufficiente a testare tutte le possibili combinazioni (magazzino, ubicazione, articolo, lotto, configurazione, variante) sono stati certamente la causa del problema evidenziato.
A seguito di questa problematica, facendo tesoro dell’esperienza acquisita, revisionammo la check-list di verifica aggiornamenti, riformulandola nel modo seguente.
CHECK LIST VERIFICA AGGIORNAMENTI PANTHERA
Pacchetto FastUpdate da 4.6.## a 4.6.##
- Sospendere le fix anticipate e Installare il fast update su PANTH02
- Verificare il corretto funzionamento dei seguenti punti su PANTH02
Controllo
OK
Note
Caricare ed evadere ordine cliente (DDT)
Caricare ed evadere ordine cliente (FATT. ACC.)
Caricare ed evadere ordine eCommerce e Verificare corretta conversione UM (da colli a Kg/Lt/Nr) su immissione quantità
Fare nuovo ordine esecutivo e metterlo in produzione
Stampare un paio di etichette pallet
Verifica tasti terminalini V125 (Verde/avanti) e V126 (Rosso/indietro)
Menu parametri personalizzazione Parametri: successivo/precedente
Fare Piking magazzino con terminalino
Raccogliere ed eliminare le stampe Lista piking e le etichette spedizione
Caricare i pallet in magazzino con terminalini
Verificare i relativi Documenti di Produzione
Fare stampa massiva DDT e verificare Pinzatura
Fare stampa massiva FATT. ACC. e verificare Pinzatura
Raccogliere ed eliminare le stampe di DDT e FAC
Verifica generazione dei documenti generici con causale SCN spedizione pallet (automatica) su stampa massiva e su stampa singola DDT/FATT. ACC.
Verifica cancellazione dei documenti generici con causale SCN spedizione pallet (automatica) su regressione DV
Verificare generazione documenti trasporto su stampa DDT/FATACC
Verificare cancellazione documenti trasporto su retrocessione DDT/FATACC
- Sospendere le fix anticipate e Installare il fast update su PANTH01
Data __________ Firma ____________________
