“Sperimentiamo e vediamo cosa succede.”
È una frase naturale quando si parla di innovazione. Ma può essere anche pericolosa.
Quando una tecnologia è nuova o il problema non è ancora completamente compreso, è normale non avere tutte le risposte. Serve provare, osservare, correggere.
Questo però non significa rinunciare al metodo.
Sperimentare non significa procedere senza certezze. Significa scegliere quali incertezze vogliamo ridurre.
Un esperimento deve iniziare da una domanda
“Proviamo questa tecnologia” non è ancora un obiettivo.
La domanda utile è:
cosa vogliamo sapere alla fine della prova che oggi non sappiamo?
Per esempio:
- gli utenti riescono a completare il nuovo processo senza assistenza?
- l’automazione riduce davvero i passaggi manuali?
- un assistente AI produce risultati sufficientemente affidabili?
- le informazioni diventano più facili da trovare?
- la soluzione funziona nelle condizioni operative previste?
Se non sappiamo quale domanda stiamo cercando di risolvere, rischiamo di concludere la sperimentazione con molte impressioni e poche informazioni utili.
Un pilot non è una demo più lunga
Una demo mostra cosa una tecnologia può fare.
Un pilot dovrebbe mostrare cosa accade quando quella tecnologia incontra la realtà.
Durante una dimostrazione i dati sono spesso preparati, i casi selezionati e il percorso conosciuto.
Nel lavoro quotidiano emergono invece dati incompleti, eccezioni, comportamenti inattesi e utenti con esigenze differenti.
È proprio questo il valore del pilot: portare la realtà dentro il progetto quando è ancora possibile cambiare facilmente direzione.
Una demo risponde a “può funzionare?”. Un pilot dovrebbe rispondere a “funziona abbastanza bene qui, per noi, in queste condizioni?”.
Formulare un’ipotesi
Una sperimentazione diventa molto più utile quando parte da un’ipotesi verificabile.
Per esempio:
Se introduciamo questo workflow, diminuiranno i passaggi manuali.
Oppure:
Se utilizziamo un assistente AI per preparare una prima sintesi, ridurremo il tempo dell’attività senza peggiorare la qualità finale.
L’ipotesi chiarisce tre elementi:
- cosa stiamo cambiando;
- quale effetto ci aspettiamo;
- cosa dobbiamo osservare.
Non garantisce che avremo ragione.
Ed è proprio questo il punto.
Un esperimento deve poterci dare torto
Se iniziamo un pilot avendo già deciso che la soluzione dovrà essere adottata, la sperimentazione perde gran parte del suo significato.
Un vero esperimento dovrebbe poter produrre almeno tre risultati:
funziona;
non funziona ancora abbastanza bene;
non vale la pena proseguire.
Tutti e tre sono utili.
Scoprire presto che una tecnologia non è adatta può evitare investimenti e complessità molto più difficili da correggere successivamente.
Un esperimento fallisce davvero soltanto quando termina senza averci insegnato nulla.
Ridurre il perimetro
Un pilot efficace dovrebbe essere abbastanza piccolo da consentire correzioni rapide.
Un processo.
Un gruppo di utenti.
Una specifica attività.
Una tipologia di documento.
Un caso d’uso.
L’obiettivo non è dimostrare immediatamente che la soluzione possa gestire tutto.
È capire se il principio su cui si basa meriti il passo successivo.
Piccolo, però, non significa artificiale.
Una prova deve contenere abbastanza realtà da far emergere problemi autentici: utenti differenti, eccezioni, dati imperfetti e condizioni operative credibili.
Il buon perimetro non elimina la realtà.
La concentra.
Decidere prima cosa misurare
Le metriche dovrebbero essere definite prima di vedere i risultati.
Possiamo osservare:
- tempo necessario;
- numero di passaggi;
- errori;
- richieste di assistenza;
- qualità del risultato;
- casi gestiti automaticamente;
- eccezioni;
- utilizzo effettivo.
Non serve misurare tutto.
Serve misurare ciò che può cambiare la decisione.
Se vogliamo migliorare l’accesso alla conoscenza, il numero di accessi alla piattaforma dice poco. È più utile capire se le persone trovano ciò che serve e quanto tempo impiegano.
I numeri non bastano
Una metrica può dirci che un processo è diventato più veloce.
Non necessariamente perché.
Per questo servono anche osservazione e feedback.
Domande semplici possono rivelare molto:
Qual è stata la parte più difficile?
Cosa continui a fare fuori dal sistema?
Quale passaggio ti sembra inutile?
Dove ti aspettavi che il sistema funzionasse diversamente?
Gli utenti pilota non servono soltanto a trovare bug.
Portano nel progetto la conoscenza del lavoro reale.
Non scegliamo soltanto gli entusiasti
Un gruppo composto esclusivamente da persone favorevoli alla tecnologia può essere rassicurante, ma poco rappresentativo.
Un buon pilot dovrebbe coinvolgere prospettive differenti: utenti esperti e meno esperti, persone digitalmente autonome e persone più critiche.
L’obiettivo non è ottenere consenso.
È scoprire abbastanza presto ciò che non avevamo previsto.
Anche le eccezioni sono preziose.
Un processo funziona quasi sempre bene quando tutto avviene come previsto. È quando manca un dato, una persona non è disponibile o compare un caso anomalo che iniziamo a capire la qualità reale del sistema.
Il caso standard dimostra che il flusso funziona. Le eccezioni mostrano se è davvero utilizzabile.
Un feedback non è automaticamente un requisito
Durante un pilot arrivano molte richieste.
“Sarebbe meglio se…”
“Potremmo aggiungere…”
“Nel vecchio sistema facevo…”
Sono informazioni importanti, ma non ogni richiesta deve diventare una nuova funzionalità.
Serve capire il bisogno che c’è dietro.
Forse manca davvero qualcosa.
Forse la funzione esiste ma non è visibile.
Forse il problema può essere eliminato alla radice.
Il feedback è un punto di partenza per l’analisi.
Non la conclusione.
Una sperimentazione deve finire
Un pilot che continua indefinitamente smette di essere un pilot.
Per questo dovrebbe avere fin dall’inizio:
- un perimetro;
- una durata indicativa;
- criteri di valutazione;
- un momento di decisione.
Alla fine bisogna fermarsi e chiedere:
cosa abbiamo imparato?
cosa non sappiamo ancora?
vale la pena proseguire?
Le conclusioni possibili sono poche:
Adottare. La soluzione ha dimostrato abbastanza valore.
Modificare e riprovare. L’idea resta valida, ma qualcosa deve cambiare.
Approfondire. È emersa una nuova incertezza che merita una prova mirata.
Fermare. Il beneficio non giustifica costi, rischi o complessità.
Quest’ultima opzione è spesso la più difficile.
Ma non ogni idea deve diventare progetto e non ogni progetto deve diventare sistema.
Imparare prima di investire troppo
“Fail fast” è diventata una formula molto utilizzata.
Ma fallire rapidamente, da solo, non produce valore.
Il punto è imparare abbastanza velocemente da prendere una decisione migliore.
È questa la vera funzione della sperimentazione.
Prima di estendere una piattaforma.
Prima di cambiare una procedura.
Prima di costruire integrazioni definitive.
Prima di trasformare un’intuizione in una dipendenza organizzativa.
Possiamo ridurre il perimetro e chiedere alla realtà:
Funziona?
Quanto?
Per chi?
In quali condizioni?
Cosa non avevamo previsto?
Cosa dovremmo cambiare?
Innovare richiede curiosità e disponibilità a provare ciò che ancora non conosciamo.
Ma proprio quando non abbiamo tutte le risposte abbiamo più bisogno di sapere quali domande stiamo cercando di risolvere.
technology innovationsperimentazioneinnovazioneproof of conceptprogetto pilotaprocessiprototipazionemetricheadozione digitale