Software selection: La fase di concetto

Continua il nostro viaggio alla scoperta del processo di software selection. È il momento di affrontare la fase di concetto. Prerequisti? Una solida conoscenza del mercato e dei software disponibili. Obiettivo? Creare le basi per la redazione del capitolato tecnico definitivo.

NOTE

Per approfondire l’argomento, consigliamo la lettura di:
• Il software logistico – Logistica, giugno 2025
• Il ciclo di vita del software logistico – Logistica, luglio 2025
• Cosa è la software selection e perché è fondamentale in ambito logistico – Logistica, settembre 2025
• Le fasi della selection – Logistica, ottobre 2025
• La fase d’analisi – Logistica, novembre 2025

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.

Nell’articolo “le fasi della Selection” (logistica, ottobre 2025, ndr) abbiamo illustrato il processo necessario 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 e cioè, quattro macro-fasi: analisi, concetto, selezione e implementazione; cinque sotto-attività da svolgere all’interno di ciascuna macro-frase; quattro deliverable finali (evidenziati in grassetto), che rientrano comunque tra le sotto-attività.

In questo articolo approfondiremo i dettagli e le peculiarità della seconda fase: la fase di concetto.

La fase di concetto in sintesi

Questa è la fase in cui entra in gioco, in modo determinante, la conoscenza del mercato e dei software disponibili. L’obiettivo è ottimizzare i processi mappati nella fase precedente e convertirli in processi futuri (TO-BE), tenendo conto: delle potenzialità dei nuovi software (e, in parte, anche dei desideri dell’azienda) e delle nuove tecnologie disponibili.

Nota bene: non bisogna dimenticarsi di mantenere forte il focus sui propri processi e sulle reali esigenze aziendali. Questa attività costituisce la base per la redazione del capitolato tecnico definitivo, che verrà completato nella fase successiva, e pone le basi per elaborare una short list di potenziali fornitori, ossia il deliverable finale di questa fase di concetto.

La fase di creazione del concetto è la fase “creativa” della Selection, dove bisogna pensare “out-of-the-box” per mettere in dubbio al massimo la bontà dei processi esistenti. La conoscenza del mercato e della tipologia di software da scegliere è fondamentale in questo contesto perché:

• Offre degli spunti per l’innovazione dei processi interni basati su funzionalità presenti in diversi software ed implementate in altre aziende.
• Garantisce trasparenza su alcune funzionalità critiche per il modello di business dell’azienda, che risulta sottorappresentante nei software presenti sul mercato. Tali funzionalità devono quindi essere considerate prioritarie o osservate con particolare attenzione durante il progetto.
• Garantisce trasparenza quando l’azienda decide di intraprendere soluzioni che discostano dagli standard dei software di mercato – scelte legittime, ma che devono essere adottate con piena consapevolezza.

Analizziamo i dettagli delle sotto-attività della fase “concetto”:

Sviluppo dei processi TO-BE

Questa è la sotto-attività cardine dell’intera fase di concetto. La sfida principale consiste nel trovare il giusto equilibrio tra diversi aspetti fondamentali. Da un lato, occorre cogliere l’opportunità offerta dall’investimento in un nuovo software per progettare processi TO-BE che siano realmente innovativi e si differenzino in un modo significativo dai processi AS-IS esistenti.

Come già evidenziato nel primo articolo di questa serie, un software logistico (ma anche di un’altra natura) tende a restare in uso in azienda per almeno 12 anni, generando nel tempo un costo complessivo rilevante lungo tutto il ciclo di vita (TCO – Total Cost of Ownership).

Una volta installato, il sistema risulta infatti più difficile da adattare: imitarsi a replicare i processi AS-IS presenterebbe quindi un enorme spreco di risorse e, soprattutto, una perdita di opportunità di miglioramento.

Da un altro lato, è importante non pretendere troppo dall’organizzazione dei dipendenti, evitando di oltrepassare le capacità interne.

Questo rischio può essere mitigato introducendo le nuove funzionalità in modo graduale, step by step, e pianificando già nella fase di selezione gli sviluppi evolutivi successivi. Un’ ulteriore considerazione riguarda la complessità delle funzionalità richieste al software: è opportuno non eccedere nel livello di sofisticazione, per non generare costi aggiuntivi e aumentare il rischio complessivo del progetto di selezione.

Nella pratica, tuttavia, gli ultimi due aspetti tendono ad avere un impatto minore: le aziende, più spesso, falliscono nel pensare “oltre” e rimangono ancorate all’AS-IS, anche quando molti software sarebbero già in grado di sopportare processi molto più evoluti.

Il grafico a pag.64 illustra questa dinamica: una volta mappati i processi AS-IS, si tende a rimanere mentalmente troppo vicini alla situazione attuale. Le vere innovazioni diventano possibili solo quando ci si spinge a immaginare scenari completamente nuovi. (Vedi immagine 2)

Lo strumento utilizzato per lo sviluppo dei processi TO-BE è lo stesso impiegato nella fase precedente di analisi per la mappatura dei processi AS-IS (si veda anche articolo 5 di questa serie): il diagramma di flusso. Si consiglia di adottare uno strumento semplice e facilmente comprensibile da tutti i soggetti coinvolti nel progetto.

Non è indispensabile ricorrere a linguaggi di modellazione formali come l’UML (Unified Modeling Language) o la BPMN (Business Process Modeling Notation); l’importante è che il diagramma consenta la rappresentazione chiara e condivisa dei flussi operativi e delle interazioni tra le diverse funzioni aziendali.

La principale sfida nella mappatura dei processi TO-BE consiste nel trovare il giusto grado di dettaglio – la cosiddetta “granularità”.

Un errore piuttosto comune è quello di elaborare processi eccessivamente dettagliati, concepiti quasi come specifiche tecniche per gli sviluppatori del software, già con un livello di correttezza logica molto elevato. Tuttavia, questo approccio presenta due criticità:

1. In una fase ancora iniziale del progetto, molti dettagli non sono ancora definibili con precisione.
2. Tali dettagli, anche se definiti, cambieranno probabilmente nella successiva fase di analisi di dettaglio, quando verranno valutate concretamente le possibilità offerte dal software selezionato.

Un livello di dettaglio troppo elevato in questa fase, dunque, rappresenta uno spreco di tempo e risorse. D’altro canto, la mappatura deve comunque essere sufficientemente dettagliata per consentire di:

1. Evidenziare le differenze sostanziali rispetto ai processi AS-IS;

2. Individuare eventuali problemi o errori logici di alto livello, che potrebbero compromettere la coerenza complessiva del nuovo modello di processo.

Per individuare il giusto livello di granularità in questa fase, è fondamentale disporre di esperienza nella mappatura dei processi TO-BE. Qualora tale competenza non sia presente all’interno dell’organizzazione, può essere opportuno avvalersi del supporto di una risorsa esterna in grado di guidare il team nella definizione dei processi efficaci e sostenibili.

Sviluppo dell’architettura informatica TO-BE

Una volta chiariti i processi TO-BE, le attività successive derivano quasi automaticamente.

La prima riguarda la revisione dell’architettura dei sistemi informativi aziendali, già mappata nella fase di analisi. In questa fase si possono aggiungere informazioni utili per definire il TO-BE, come:

• Le priorità o probabilità di sostituzione o modifica dei vari moduli;
• Le sequenze temporali previste per gli interventi.

Un errore frequente è creare documenti troppo complessi: tecnici e ingegneri tendono a voler rappresentare tutti i sistemi, le interfacce e gli scambi di dati. Questo approccio riduce però la chiarezza e ostacola l’obiettivo principale: fornire una visione di insieme dei moduli esistenti e mancanti, con le relative priorità di introduzione o sostituzione.

Nella maggior parte dei casi è sufficiente una semplice matrice (vedi immagine 3). Questa attività è fondamentale: le aziende non cercano un singolo software, ma puntano-giustamente- a ottenere un’architettura dei sistemi informativi aziendali efficace e performante. La matrice consente di creare la trasparenza necessaria sia per il team di progetto interno, sia per i fornitori esterni.

Sebbene acronimi come WMS, TMS o MES aiutino a orientarsi, ogni software e ogni architettura aziendale sono diversi: è quindi essenziale capire quale soluzione si integri meglio nel contesto specifico dell’impresa.

Overview: Grafico delle macro-funzionalità TO-BE

Un altro strumento utile per creare trasparenza in questa fase è la revisione dell’overview delle macro-funzionalità TO-BE, già elaborata nella fase di analisi. Dopo aver definito i processi TO-BE, dovrebbe essere più chiaro quali nuove macro-funzionalità saranno necessarie rispetto all’AS-IS.

Questa attività consiste anche nell’aggregare processi TO-BE appena sviluppati, mantenendo però una visione a livello macro. Poiché ci troviamo ancora nella fase di concetto e non in quella di selezione, è importante evitare di scendere troppo nel dettaglio per non perdere di vista gli obiettivi strategici del progetto.

Nel caso dei software logistici, è possibile fare riferimento a strumenti consolidati: la normativa VDI 3601 per i sistemi WMS (citata nel primo articolo) e il grafico della piattaforma warehouse-logistics per i TMS (illustrato nel secondo articolo).

Per esempi di rappresentazione e prioritizzazione visiva di questi grafici si rimanda invece al quinto articolo della serie, dedicato alla fase di analisi.

Analisi del mercato e dei suoi trend

Anche se l’obiettivo principale della fase di concetto è definire un concept logistico come base per la successiva selezione del software, è utile prevedere anche un primo sondaggio di mercato. Questo consente di raccogliere i riscontri preliminari sulla fattibilità delle soluzioni ipotizzate e di delineare una prima short-list di fornitori potenzialmente idonei.

Questa sotto-attività comprende due aspetti principali:

1. Analizzare il mercato per comprendere l’offerta disponibile, soprattutto quando manca un know-how interno specifico.

2. Contattare i fornitori più promettenti, ponendo già alcune domande preliminari sul progetto.

Per il primo punto, è utile partecipare a fiere e eventi di settore, ma anche consultare studi e ricerche di mercato. Nel campo dei software logistici, una fonte di riferimento è la piattaforma warehouse-logistics.com del Fraunhofer IML, che pubblica ogni due anni il WMS Market Report (ve ne parleremo in futuro). Altre fonti specializzate possono integrare l’analisi.

Un elemento importante di conoscenza del mercato riguarda la consapevolezza di quali moduli o macro-funzionalità possano essere gestiti anche tramite software o moduli esterni (vedi immagine 4).

Questo consente all’azienda, in casi specifici, di adottare strategie multi-fornitore, suddividendo la fornitura tra più partner qualora non esista una singola soluzione pienamente soddisfacente. Si consiglia di contattare i fornitori più promettenti già in questa fase, prima ancora dell’invio del capitolo tecnico – attività centrale della fase successiva.

Questo approccio consente di effettuare una prima scrematura preliminare e risulta anche più corretto nei confronti dei fornitori: la lettura e la risposta a un capitolato richiedono tempo e impegno, e non sarebbe opportuno coinvolgere aziende che probabilmente non verranno poi considerate. Per il contatto con diversi fornitori si utilizza il materiale già elaborato nella fasi precedenti della Software Selection:

• Obiettivi del progetto: includere obiettivi quantitativi (idealmente KPI misurabili) e qualitativi, insieme alla tempistica prevista.
• Architettura informatica TO-BE: serve per chiarire al fornitore il proprio perimetro di copertura. In alcuni casi, il fornitore potrebbe coprire anche moduli pianificati per il futuro, riducendo così la necessità di interfacce e guadagnando vantaggio competitivo.
• Overview grafica delle macro-funzionalità TO-BE: offre una visione chiara delle priorità funzionali. Ciò consente anche ai fornitori di valutare autonomamente se partecipare meno alla gara successiva, qualora rilevino aree chiave non coperte dal loro software.

Importante: si sconsiglia fortemente di inviare ai fornitori, in questa fase, i processi TO-BE. Tali diagrammi potrebbero generare confusione, poiché ai fornitori mancherebbero ancora informazioni di contesto e di dettaglio necessarie per interpretarli correttamente.

Oltre alla documentazione fornita, è consigliabile richiedere ai fornitori alcune informazioni aggiuntive, utili per una prima valutazione comparativa:

• Dimensione dell’azienda fornitrice;
• Esperienze e referenze nel settore merceologico dell’azienda committente;
• Disponibilità a partecipare alla gara, rispettando le tempistiche definite negli obiettivi del progetto;
• Esperienze di integrazione con i principali software aziendali, indicando l’anno delle implementazioni e alcuni dettagli tecnici sulle modalità di concessione.

Già con le risposte dei fornitori a questa richiesta è possibile effettuare un primo confronto tra le proposte. È importante non sottovalutare i tempi necessari: non tutti rispondono subito, alcuni richiedono chiarimenti o solleciti.

Tuttavia, ogni scambio – mail o telefonata – contribuisce a completare il quadro della selezione. Si consiglia anche di organizzare brevi videochiamate con ciascun fornitore: sono molto utili per presentarsi e per chiarire la loro copertura rispetto all’architettura software TO-BE.

Attenzione: se dalle informazioni raccolte emergono elementi significativi che incidono sui processi TO-BE o su altri deliverable del progetto di selezione, questi devono essere aggiornati di conseguenza. È un’eventualità rara, ma possibile.

Il deliverable finale della fase di concetto

Le risposte dei fornitori consentono una prima scrematura basata su criteri chiave “KO”, ma non permettono ancora di valutare le funzionalità nel dettaglio. Per questo, l’attività conclusiva della fase di concetto consiste nel creare una shortlist o un ranking preliminare del software, anche in base ai requisiti funzionali emersi.

Nel caso dei software logistici, è possibile utilizzare il database di warehouse-logistics.com del Fraunhofer IML. Tutti i dati necessari sono già stati prodotti durante questa fase, il questionario della piattaforma include anche una checklist finale utile per verificare che nessuna funzionalità rilevante sia stata trascurata (vedi immagine 5 ).

In alternativa, qualora non fosse disponibile un database come warehouse-logistics.com, è opportuno creare un proprio elenco delle funzionalità più critiche e inviarle ai fornitori chiedendo di indicare il livello di copertura. Successivamente, si consiglia di elaborare una tabella comparativa finale tra i diversi software e fornitori, che integri tutti gli aspetti della selezione.

A ciascun criterio andranno assegnati i punteggi pesi specifici, considerando:

• Copertura funzionale;
• Copertura rispetto all’architettura dei sistemi informativi aziendali;
• Solidità economica del fornitore;
• Capacità di garantire la business continuity;
• Altri fattori rilevanti per il progetto.

Sintesi di management

Nella seconda fase di un progetto di selezione software, si definiscono i processi TO-BE da supportare con il nuovo sistema. In questa attività è importante adottare un approccio innovativo e critico, sfruttando l’occasione per rivedere i processi esistenti.

Parallelamente, è necessario valutare le potenzialità dei software disponibili sul mercato, per capire se e dove i processi desiderati superano le funzionalità standard. Per questo motivo, oltre alla ricerca dei fornitori, si effettua una prima richiesta di informazioni, che include anche la loro copertura funzionale massiva rispetto alla futura architettura dei sistemi informativi, elaborata in questa fase.

L’obiettivo finale è di definire una shortlist e un ranking dei software e dei fornitori più idonei alle esigenze aziendali.

A supporto, è possibile utilizzare il questionario della piattaforma warehouse-logistics.com. Questi due risultati – processi TO-BE e shortlist/ranking dei fornitori – costituiscono la base per la fase successiva di “selezione”, durante la quale verrà redatto e inviato il capitolato tecnico dettagliato ai tre-cinque fornitori più promettenti.

Ma di questo parleremo nel prossimo articolo della serie previsto sul numero di febbraio di logistica.

👉 Un concept ben costruito riduce tempi, costi e rework nella fase di capitolato: per approfondire il metodo e gli output attesi, è possibile contattarci.