54 4. PANORAMICA DELL’AUTOMA DEI PRELIEVI
In questo capitolo è presentata una panoramica sull’automa dei prelievi illustrandone gli obbiettivi e lo schema generale dell’architettura software. Tutti i dettagli implementativi sono discussi all’interno del capitolo 6.
4.1 Obbiettivi
Come è stato mostrato nel paragrafo 1.5.3 durante l’analisi delle realtà aziendale sono sorte delle problematiche per quanto riguarda la generazione delle liste di prelievo. L’automa dei prelievi deve, in primo luogo, rispettare e riprodurre le logiche attuali di gestione del magazzino, in secondo luogo, risolvere le problematiche evidenziate in analisi e, infine, apportare migliorie alla logistica di magazzino.
Gli obbiettivi del progetto, quindi, sono:
• Irrobustire e migliorare la comunicazione fra i reparti dell’azienda in merito a:
o solvibilità del cliente
o priorità di consegna clienti importanti
• Automatizzare la generazione delle liste di prelievo per:
o Aumentare la produttività del reparto magazzino o Ridurre i tempi di spedizione
o Eliminare l’errore nella scelta dell’ordine cliente da imballare o Aumentare l’efficienza delle spedizioni
o Eliminare gli ordini clienti “abbandonati”
4.1.1 Solvibilità del cliente
Attualmente, come abbiamo visto durante l’analisi, il capo reparto del magazzino è informato sulla solvibilità del cliente attraverso un apposito pallino colorato. Questo se rosso avverte che il cliente non è solvibile e che, quindi, ne devono essere bloccate le spedizioni.
L’automa dei prelievi tiene conto in fase di elaborazione dell’informazioni della solvibilità del cliente ed elimina, quindi, ogni possibilità di errore da parte del magazziniere.
4.1.2 Priorità di consegna clienti importanti
Dall’analisi è risultata mancante la gestione dei clienti importanti. Non è presente,infatti, nell’anagrafica cliente, un indicatore di “bontà” del cliente. Da questo deriva che non c’è una priorità in fase di consegna della merce per questi clienti “top”.
Sono state introdotte, quindi, sei classi di priorità con valore da 0 a 5. La classe 0 indica assenza di priorità mentre alla classe 5 appartengono i clienti con massima priorità.
Sono state fatte, quindi, inserite all’interno del database le 6 classi di priorità.
4.1.3 Aumentare la produttività del reparto magazzino
Come già evidenziato, l’attuale processo di generazione delle liste di prelievo è lento, ripetitivo e in certi casi anche poco robusto rispetto agli errori che l’operatore può commettere. Tutto ciò ha forti ripercussioni sulla produttività del reparto per quanto riguarda il numero di paia imballate e spedite quotidianamente. Con l’automatizzazione di tale processo si prevede un forte aumento di tale produttività
4.1.4 Ridurre i tempi di spedizione
Il processo di generazione delle liste di prelievo è molto lento e laborioso e causa, spesso, ritardi nella spedizione delle merci. Questo comporta che i clienti rifiutino la merce e la
55 restituiscano all’azienda per il mancato rispetto della data di consegna. Attualmente si presentano, a fine della stagione di vendita, grandi quantitativi di rimanenze. L’automa dei prelievi deve cercare, per quanto sia possibile, di ridurre tali rimanenze, assai gravose per l’azienda, andando ad abbassare i tempi di spedizione.
4.1.5 Eliminare l’errore nella scelta dell’ordine cliente da imballare
Sfruttando la totale automazione del processo di generazione delle liste, l’automa dei prelievi si prefigge l’obbiettivo di annullare l’errore di scelta dell’ordine cliente da imballare andando a compiere la scelta ottimale in base ai principi richiesti dall’azienda.
4.1.6 Aumentare l’efficienza delle spedizioni
Per aumentare l’efficienza del magazzino è necessario andare a ridurre più possibile il numero di spedizioni per ogni ordine. Con la scelta ottimale dell’ordine da imballare non si correrà più il rischio di confezionare spedizioni incomplete o composte da un numero di paia tale da creare tanti piccoli colli che aumentino i costi dei vettori.
4.1.7 Eliminare ordini clienti “abbandonati”
Durante il periodo di picco di lavoro, i magazzinieri devono gestire diverse decine di ordini clienti al giorno e questo causa inevitabili sviste che portano alla mancata generazione della lista di prelievo di alcuni ordini clienti che diventano così “abbandonati”.
Si è notato che solo quando il quantitativo di paia circolanti all’interno del magazzino si abbassa, i magazzinieri riescono a individuare tali ordini. Quando ciò accade, però, è spesso troppo tardi per spedire e le paia in ordine vanno a incrementare le giacenze di fine stagione.
Avendo automatizzato l’intero processo decisionale si prevede che il numero di tali ordini sia portato a zero.
4.2 Schema generale dell’architettura software
L’automa dei prelievi si deve interfacciare sia con il gestionale aziendale, e, quindi con il database Oracle, sia con le reti di Petri che rappresentano il suo motore logico. L’architettura creata per soddisfare queste esigenze è di tipo multi strato. Uno schema riassuntivo dell’architettura software dell’automa dei prelievi è raffigurato in Fig. 33.
Primo elemento dell’architettura è la rete di Petri che, una volta inizializzata correttamente, ne guida l’evoluzione. Questa andrà a lanciare una serie di funzioni legate ad un oggetto Java.
Tali funzioni, a loro volta, lanceranno delle store procedure Oracle che andranno a lavorare sui dati del database. Il linguaggio Java, per quanto riguarda l’elaborazione dati, funge solo da interfaccia tra le reti di Petri e il database Oracle. Questa scelta è dovuta all’elevato guadagno in prestazioni nel far elaborare i dati direttamente da store procedure invece che in codice Java.
Le potenzialità delle tecnologia Java sono messe in luce nell’interfaccia grafica dell’automa dei prelievi. Questa, infatti, è totalmente realizzata in codice Java.
Le reti di Petri, come già detto, hanno il ruolo di motore logico dell’automa quindi si è deciso di dedicare il capitolo 5 all’introduzione di questa tecnologia e alla piattaforma di sviluppo scelta.
Si ricorda, invece, che i dettagli implementativi dell’automa dei prelievi sono discussi all’interno del capitolo 6.
56 Fig. 33 Architettura software automa dei prelievi
