Software Selection: la fase di analisi

La fase di analisi è cruciale nella software selection, ma spesso sottovalutata. Mappare i processi AS-IS, analizzare dati e architettura IT permette di evidenziare sprechi e definire obiettivi chiari per la scelta del nuovo software logistico.

Negli articoli precedenti abbiamo illustrato la nomenclatura dei principali software logistici, evidenziandone alcune caratteristiche distintive, e abbiamo spiegato perché sia importante effettuare una selezione strutturata di questi
strumenti[1].

In particolare, nell’articolo “le fasi della software selection”, Logistica ottobre 2025, abbiamo illustrato il processo per svolgere una software selection in modo strutturato, capace di ridurre al minimo indispensabile le problematiche e i rischi legati alla scelta di un nuovo software (vedi immagine 1). Il modello si articola in tre elementi principali:

• Quattro macro-fasi: analisi, concetto,  selezione e implementazione.
• Cinque sotto-attività da svolgere all’interno di ciascuna macro-fase.
• Quattro deliverable finali (evidenziati in grassetto), che rientrano comunque tra le sotto-attività.

In questo articolo approfondiremo i dettagli e le peculiarità della prima fase, quella di analisi.

NOTE

1 Per approfondire l’argomento, si consiglia la lettura dei seguenti articoli: Il software logistico,
Logistica, giugno 2025; Il ciclo di vita del software logistico, Logistica, luglio 2025; Cos’è la software selection e perché è fondamentale in ambito logistico, Logistica, settembre 2025; Le fasi
della selection, Logistica, ottobre 2025.

La fase di “Analisi” in sintesi

Questa è, in genere, la fase più sottovalutata dalle aziende che si apprestano a scegliere un nuovo software (logistico). Spesso si ritiene, erroneamente, di conoscere già a fondo i propri processi interni e, per ridurre tempi e costi, si tende a “saltare” o ad abbreviare questa fase. La realtà dimostra, però, nella maggior parte dei casi, che:

• La visione dei processi interni non è omogenea all’interno del team di progetto.
• Il livello di dettaglio richiesto per la Selection è superiore alle conoscenze possedute dai membri del team.
• I processi effettivi (AS-IS) sono spesso molto diversi da come vengono percepiti.
• I processi reali sono pieni di piccoli problemi, anche quando il management ritiene che tutto funzioni correttamente.
• La direzione aziendale ha strategie future non sempre condivise con il team di progetto.

Inoltre, nei processi AS-IS si accumulano nel tempo sprechi e attività ormai obsoleti, difficili da individuare per i membri del team, perché immersi nella routine quotidiana. Per questo motivo è indispensabile fermarsi e “prendere le distanze” mentalmente dal lavoro quotidiano, così da costruire una visione oggettiva dallo stato attuale (AS-IS), seguendo un approccio strutturato e logico.

Le sotto-attività previste in questa fase servono proprio a questo scopo. Tanta aziende by-passano questa fase, purtroppo, e si lanciano subito nella fase di concetto (o-peggio ancora-direttamente alla fase di selezione, senza avere minima chiarezza su cosa chiedere ai fornitori).

Vediamo sul campo che tendenzialmente solo aziende che si appoggiano a consulenti esterni svolgono questa fase di selezione software: il consulente esterno per forza deve attraversare questa fase perché non conosce l’azienda ed il suo punto di partenza.

La sotto-attività della fase “Analisi dei processi AS-IS”

Questa sotto-attività ha due obiettivi principali:

• Rendere trasparenti i processi attuali, che spesso risultano molto diversi da come il management li immagina. Con il tempo, infatti, possono essersi introdotti alcuni dettagli imprevisti o gli operatori possono aver sviluppato variazioni nello svolgimento delle attività.

• Evidenziare fin da subito i possibili miglioramenti dei processi AS-IS, in modo da fornire una guida utile per lo sviluppo del processo TO-BE.

Questi due obiettivi si raggiungono al meglio grazie a due strumenti complementari:

• Mappatura strutturata dei processi AS-IS– ad esempio, utilizzando strumenti di modellazione grafica come la BPMN (Business Process Modelling Notation) oppure semplici diagrammi di flusso (vedi immagine 2). In ambito logistico è molto utile affiancare 2-3 operatori durante, ad esempio, il processo di picking scattando foto di ogni attività notando subito possibili miglioramenti. Attenzione: è bene essere consapevoli che questo “campione” non mostrerà mai la totalità delle variazioni del processo osservato. Insieme allo strumento successivo (“intervista al personale”) permette comunque di coprire una buona parte del processo. Per ottenere una trasparenza completa occorre adottare soluzioni più avanzate, come ad esempio il MotionMining.
• Intervista al personale – oltre alla mappatura e all’osservazione dei processi logistici svolti da 2-3 persone diverse, si è dimostrato utile intervistare direttamente tutti (o almeno una buona parte) degli operatori e dei responsabili, chiedendo loro quali sprechi riscontrano quotidianamente. Il vantaggio di questo approccio è che durante le interviste emergono anche variazioni o casistiche del processo che non è stato possibile osservare durante la mappatura perché si verificano meno spesso, ma risultano comunque rilevanti.

Il risultato di questa attività – oltre alla mappatura grafica del processo AS-IS – consiste in due output fondamentali:

• Sprechi e problemi riscontrati, eventualmente già con una quantificazione che ne permetta al successiva prioritizzazione.

• Idee di miglioramento emerse in questa fase. È consigliabile eseguire una delle regole classiche del “brainstorming”: annotare tutte le idee, anche se si ha già in mente un concetto logistico futuro che potrebbe rendere obsoleta la singola proposta. In questa sotto fase conviene mantenere un approccio aperto e neutrale, senza anticipare alcuna soluzione.

Analisi dell’architettura informatica e della struttura dei dati anagrafici AS-IS

Questa sotto-attività comprende tre elementi fondamentali:

• Mappatura grafica dei sistemi software utilizzati/coinvolti attualmente e delle loro interfacce
• Analisi della struttura dei dati anagrafici (ossia degli elementi logistici)
• Analisi della qualità dei dati anagrafici AS-IS

1. Mappatura dei sistemi software – questo passaggio è fondamentale per definire, durante le fasi di concetto e selezione, il perimetro e la copertura del software da scegliere insieme ai diversi fornitori. Si tratta di un documento che torna utile anche nella fase di implementazione. Non è, però, un documento “scolpito nella pietra” : in alcuni casi può essere conveniente estendere il perimetro di progetto durante i lavori, ad esempio se il fornitore offre un modulo che inizialmente non si intendeva sostituire, ma che, integrato, permette di ridurre interfacce e rendere le implementazioni più snelle e meno costose.
2. Analisi della struttura dei dati anagrafici – questo è un passo fondamentale che spesso le persone interne all’azienda non compiono perché, vedendo i dati ogni giorno, li danno per scontati. Si tratta di mettere in trasparenza la struttura degli elementi da gestire logisticamente (prodotti) : confezione multistrato, bancali misti, kit gestiti a distinta base, master label o single label, e altre eventuali particolarità. Secondo l’esperienza degli autori, queste informazioni non possono mai essere troppo dettagliate e dovrebbero essere incluse già nelle prime fasi di redazione di un capitolato tecnico. Serve esperienza per individuare eventuali complessità e, in questo caso, consulenti esterni agli stessi fornitori possono aiutare a ottenere una visione più obiettiva.
3. Analisi della qualità dei dati anagrafici AS-IS – una volta evidenziata la struttura dei prodotti, è utile analizzare se i dati anagrafici presenti sono in grado di descriverla in modo completo e se risultano aggiornati. Questo fornisce una prima indicazione sul livello di complessità dell’eventuale aggiornamento o completamento dei dati durante il progetto stesso.

Compilazione di checklist funzionali

Per non tralasciare nulla durante la fase di analisi, le checklist si rivelano uno strumento molto utile. Il loro utilizzo è previsto volutamente dopo le sotto fasi 1 e 2, sia per riassumere quanto emerso in queste due fasi precedenti, sia per effettuare un cross-check e verificare che non sia stato trascurato nulla di importante.

Nel caso specifico dei software logistici WMS e TMS, in questa fase è possibile utilizzare sia la sfera normativa VDI 3601 (citata nel primo articolo di questa serie) sia il questionario delle funzioni della piattaforma warehouse-logistics.com (vedi box 1).

Un esempio pratico di applicazione potrebbe essere la colorazione grafica dei moduli funzionali utilizzati in azienda, a seconda del loro grado di importanza o del livello di sprechi/ mancanze riscontrati in ciascun elemento/modulo (ad esempio con il sistema “a semaforo”. Vedi immagine 3.

Analisi di strategia, dati e numeri aziendali

L’intero progetto di selezione e implementazione di un software logistico in azienda deve essere allineato alle strategie aziendali. Solo in questo modo è possibile, ad esempio, chiedere ai fornitori in gara di includere già funzionalità “anticipate” che potranno servire solo in una fase successiva.

Quasi tutte le aziende dispongono di un documento strategico (anche in forma grafica) che deve essere analizzato in questa fase, verificandone l’attualità e la rilevanza per il progetto di selezione software in corso. Se tale documento non esiste, può essere utile organizzare un workshop di analisi S.W.O.T. con la direzione logistica dell’azienda per creare un punto di partenza condiviso.

A questa attività di tipo qualitativo va affiancata un’analisi quantitativa basata su KPI che descrivano la logistica attuale e, se possibile, forniscano anche proiezioni future. Alcuni indicatori classici sono:

• Il numero di articoli diversi a stock contemporaneamente

• Numero di ordini giornalieri da spedire, con distribuzione delle righe delle quantità ordinate

• Giacenza media per articolo

Anche in questo caso, le aziende che affrontano la selezione software senza un consulente esterno tendono a trascurare questa parte, convinte di avere il loro business “in testa”. Tuttavia, è molto utile effettuare una fotografia oggettiva della situazione attuale, affiancandolo con una previsione a medio-lungo termine.

Definizione degli obiettivi specifici del progetto di selezione

L’obiettivo è riassumere in modo conciso gli aspetti più importanti emersi in questa fase del progetto, così da portarli nelle fasi successive. Si tratta di definire obiettivi specifici per il progetto di selezione (non per il software da scegliere – tema simile, ma distinto – che verrà affrontato nella successiva fase di concetto).

Sintesi di management

Nella prima fase di un progetto di selezione software si analizza lo stato dell’arte dei processi da coprire dei software che dovranno essere sostituiti con la nuova soluzione. L’obiettivo è individuare tutti gli sprechi attuali legati a questi processi e sistemi, oltre a raccogliere e documentare le idee di miglioramento già emerse o che nascono durante l’analisi.

Lo scopo finale è formulare obiettivi specifici per il progetto di selezione software. A tal fine vengono esaminate la strategia logistica aziendale e i principali indicatori numerici, includendo -ove possibile- una proiezione per il futuro. Nel prossimo numero ci dedicheremo alla seconda fase della Software Selection, quella di “concetto” : come affrontarla e i punti di attenzione.

👉 Molti rischi di progetto nascono da un’analisi iniziale incompleta: per approfondire come strutturare correttamente la fase di analisi nella software selection logistica, è possibile contattarci.