Quando un’azienda decide di investire in un nuovo progetto software, la prima riunione segue quasi sempre uno schema ben preciso. Sul tavolo compaiono elenchi di funzionalità, schermate da realizzare, integrazioni con i sistemi esistenti, requisiti tecnici, vincoli infrastrutturali e ipotesi di budget. Nel giro di poche ore si inizia a parlare di applicazioni web, app mobile, portali B2B, dashboard, workflow e automazioni, come se il progetto fosse già stato definito.
Eppure, osservando con attenzione queste conversazioni, emerge un aspetto curioso: raramente qualcuno si ferma a chiedere quale sia il risultato che l’azienda desidera realmente ottenere. Si dà quasi per scontato che la richiesta formulata rappresenti la soluzione corretta e che il compito del partner tecnologico sia trasformarla in un software funzionante. È un approccio talmente diffuso da sembrare naturale, ma proprio questa apparente normalità nasconde uno degli errori più frequenti nei progetti di trasformazione digitale.
Nessuna impresa investe in tecnologia perché desidera possedere un nuovo software. Le aziende investono perché vogliono lavorare meglio. Vogliono ridurre i tempi di attraversamento di un processo, diminuire gli errori, migliorare il servizio ai clienti, aumentare la capacità produttiva, sostenere la crescita del fatturato o rendere più rapide le decisioni. Il software, in fondo, è soltanto uno degli strumenti attraverso cui questi obiettivi possono essere raggiunti. Confondere lo strumento con il risultato significa impostare il progetto su presupposti fragili, con il rischio di ottenere un’applicazione perfettamente funzionante ma incapace di generare il valore atteso.
Questa distinzione può sembrare teorica, ma nella pratica cambia completamente il modo di affrontare un investimento. Se il punto di partenza è il software, tutta l’attenzione si concentra su ciò che dovrà essere sviluppato. Se invece il punto di partenza è il risultato, la conversazione cambia prospettiva: prima si cerca di comprendere quale problema l’azienda stia realmente cercando di risolvere e solo successivamente si valuta quale sia la soluzione più adatta.
La differenza non è soltanto metodologica. È una differenza che incide direttamente sulla probabilità di successo del progetto.
Molti investimenti tecnologici che vengono considerati deludenti non falliscono perché il software è stato sviluppato male. Al contrario, spesso rispettano i tempi concordati, il budget previsto e le specifiche definite all’inizio del lavoro. Il sistema viene rilasciato, gli utenti vengono formati, il collaudo si conclude positivamente e il progetto viene formalmente chiuso. Dopo qualche mese, però, qualcosa non torna. I tempi operativi non si sono ridotti quanto previsto, la produttività è rimasta sostanzialmente invariata, gli errori continuano a verificarsi e gli utenti finiscono per aggirare il nuovo sistema ricorrendo ancora a fogli Excel, email o procedure manuali.
In questi casi è facile attribuire la responsabilità al software. In realtà, molto spesso il problema è nato molto prima, nel momento in cui il progetto è stato impostato partendo dalla soluzione anziché dal risultato.
Succede perché ogni organizzazione sviluppa, nel tempo, una naturale tendenza a tradurre un problema operativo in una richiesta tecnica. Se il processo commerciale è lento, si pensa immediatamente che serva una nuova applicazione per gli agenti. Se il personale fatica a reperire le informazioni, si immagina un portale documentale. Se la direzione ha difficoltà ad analizzare i dati, la prima idea è realizzare una dashboard. È un meccanismo comprensibile: chi vive quotidianamente un processo tende a immaginare spontaneamente quale strumento potrebbe renderlo più semplice.
Il rischio, però, è che la richiesta descriva soltanto la soluzione immaginata da chi vive il problema e non il problema stesso.
Immaginiamo un’azienda che chieda di sviluppare una nuova applicazione per la propria rete commerciale. Durante il primo incontro vengono elencate tutte le funzionalità desiderate: consultazione del catalogo, configurazione dei prodotti, inserimento degli ordini, firma digitale, sincronizzazione con l’ERP e monitoraggio dello stato delle consegne. Dal punto di vista tecnico il progetto appare già delineato e la tentazione è quella di iniziare rapidamente a definire tempi, costi e modalità di sviluppo.
Se però qualcuno pone una domanda diversa — «Perché avete bisogno di questa applicazione?» — la discussione prende una direzione completamente nuova.
Forse emerge che il vero obiettivo è ridurre il tempo necessario per preparare un’offerta commerciale. Oppure che gli ordini arrivano frequentemente incompleti e richiedono continue verifiche da parte dell’ufficio interno. Magari il problema non riguarda affatto gli agenti, ma la qualità delle informazioni sui prodotti, distribuite tra sistemi diversi e spesso non aggiornate. In altri casi ancora si scopre che il processo di approvazione commerciale è così articolato da rallentare ogni trattativa, indipendentemente dallo strumento utilizzato.
A questo punto appare evidente che la richiesta iniziale rappresentava soltanto una possibile risposta a un’esigenza molto più ampia. Sviluppare esattamente l’applicazione richiesta avrebbe probabilmente prodotto un miglioramento limitato, mentre intervenire sulle vere cause del problema avrebbe consentito di ottenere benefici decisamente più significativi.
Questa dinamica si ripete in moltissimi contesti aziendali. Pensiamo, ad esempio, a un’impresa che desideri introdurre un sistema documentale perché «i documenti sono difficili da trovare». La soluzione sembra quasi obbligata: acquistare o sviluppare una piattaforma che centralizzi tutta la documentazione. Tuttavia, dopo un’analisi più approfondita, potrebbe emergere che il problema non è dove siano archiviati i documenti, ma il fatto che nessuno abbia definito regole condivise per classificarli, aggiornarli o renderli facilmente ricercabili. In assenza di queste regole, qualsiasi software finirebbe semplicemente per trasferire il disordine esistente all’interno di una piattaforma più moderna.
Lo stesso vale quando un’azienda richiede dashboard sempre più sofisticate per supportare le decisioni del management. Molto spesso si ritiene che il problema sia la mancanza di strumenti di analisi, mentre la vera criticità risiede nella qualità del dato. Informazioni duplicate, anagrafiche incoerenti, processi di aggiornamento non controllati o sistemi che utilizzano criteri differenti per rappresentare la stessa realtà rendono inevitabilmente poco affidabili anche i report più evoluti. Investire nella visualizzazione di dati non affidabili significa prendere decisioni più velocemente, ma non necessariamente prendere decisioni migliori.
È proprio per questo motivo che i progetti di maggiore successo iniziano quasi sempre con un lavoro che, almeno in apparenza, sembra produrre pochissimo. Si fanno domande, si osservano i processi, si ascoltano persone appartenenti a funzioni diverse, si mettono in discussione convinzioni considerate ormai acquisite e si cerca di comprendere quali siano gli obiettivi che l’azienda vuole realmente raggiungere. A chi osserva dall’esterno questa fase può sembrare lenta o addirittura superflua. In realtà è proprio qui che si determina gran parte del valore del progetto.
Un partner tecnologico non dovrebbe limitarsi a raccogliere requisiti. Se si limitasse a questo, il suo contributo sarebbe difficilmente distinguibile da quello di qualsiasi altro fornitore. Il vero valore nasce dalla capacità di aiutare il cliente a formulare le domande giuste prima ancora di cercare le risposte. Significa comprendere il contesto in cui l’azienda opera, individuare i vincoli organizzativi, riconoscere le inefficienze che nel tempo sono diventate parte della normalità e, soprattutto, mantenere sempre il collegamento tra la soluzione tecnologica e il risultato di business che quell’investimento dovrebbe produrre.
Questo approccio porta spesso a una conclusione sorprendente: il progetto finale non coincide con quello immaginato all’inizio. Talvolta è più semplice, perché alcune funzionalità ritenute indispensabili si rivelano prive di reale valore. In altri casi è più articolato, perché emerge la necessità di intervenire su aspetti che inizialmente nessuno aveva preso in considerazione. In entrambi gli scenari, però, cambia radicalmente il criterio con cui vengono prese le decisioni. La domanda non è più “Questa funzionalità è stata richiesta?”, ma “Questa funzionalità contribuisce realmente al risultato che vogliamo ottenere?”.
È una differenza sottile solo in apparenza. Nel primo caso il progetto viene misurato in base a ciò che è stato realizzato. Nel secondo viene valutato in base al valore che è stato generato.
Ed è probabilmente questo il cambiamento culturale più importante che le aziende sono chiamate ad affrontare quando investono in innovazione. Per troppo tempo la tecnologia è stata considerata un insieme di strumenti da acquistare, installare e utilizzare. Oggi, invece, rappresenta un investimento strategico che deve produrre effetti misurabili sul modo in cui l’organizzazione opera, prende decisioni e crea valore per i propri clienti.
Per questo motivo, forse, la domanda più importante da porsi all’inizio di qualsiasi progetto non è quale software realizzare, quale tecnologia adottare o quale architettura scegliere. La domanda più importante è molto più semplice: quale cambiamento vogliamo ottenere?
Solo quando la risposta è chiara diventa possibile progettare una soluzione realmente efficace. A quel punto il software torna a occupare il ruolo che gli spetta: non quello di protagonista dell’investimento, ma quello di strumento attraverso cui trasformare un obiettivo di business in un risultato concreto. Ed è proprio questa la differenza tra acquistare un software e investire in un cambiamento capace di generare valore nel tempo.
