Perché iniziamo ogni progetto con una «giornata storta»

Quando ci sediamo per la prima volta con un’azienda, non chiediamo «cosa vi serve». Chiediamo un’altra cosa: «raccontateci una giornata storta». Quella in cui è saltato tutto, in cui qualcuno ha alzato la voce, in cui a fine giornata nessuno sapeva più a che punto fosse una pratica. Perché è lì, nel racconto di una giornata andata male, che si vede davvero come lavora un’azienda — e dove le fa male. È da questa analisi dei processi aziendali che parte ogni nostro progetto, molto prima di aprire l’editor.

Cosa intendiamo per «giornata storta»

La giornata storta è un trucco onesto. Se chiedi a un imprenditore cosa gli serve, ti risponde con una soluzione già confezionata: «un gestionale nuovo», «un’app», «un portale per i clienti». Ha già deciso, e spesso ha deciso guardando cosa usa il concorrente o cosa gli ha proposto l’ultimo fornitore.

Se invece gli chiedi di raccontare il giorno in cui tutto è andato per traverso, smette di vendersi la soluzione e comincia a descrivere il problema. E il problema, quasi sempre, è diverso da quello che pensava.

Ascoltiamo il flusso reale, non l’elenco delle funzioni

La parte centrale del nostro lavoro, in questa fase, è stare zitti e guardare. Ci facciamo accompagnare lungo il flusso vero: chi riceve l’ordine, dove lo scrive, chi lo prende in carico, cosa succede quando arriva in produzione, come torna indietro l’informazione. Non l’organigramma appeso al muro — il percorso reale che fa un’informazione dal momento in cui entra a quando esce.

Un’analisi dei processi aziendali fatta bene serve proprio a questo: separare come le persone dicono di lavorare da come lavorano davvero. Le due cose non coincidono quasi mai, e la distanza tra le due è dove si annidano gli errori.

Dove si nasconde l’attrito

Man mano che seguiamo il flusso, cerchiamo l’attrito: i punti in cui il lavoro rallenta, si duplica o si perde. Non è mai spettacolare. Sono piccole cose che, ripetute cento volte al giorno, diventano una zavorra. Qualche esempio che troviamo praticamente ovunque:

• La caccia al file. Cinque minuti per ritrovare l’ultima versione del preventivo, tra la mail, il desktop di qualcuno e una cartella condivisa che nessuno ha più il coraggio di riordinare.
• Il doppio inserimento. Lo stesso dato — un cliente, un ordine, un indirizzo — digitato una volta nel gestionale e una volta nel foglio Excel, perché i due non si parlano.
• Il passaggio tra reparti. L’informazione che si ferma sulla scrivania di qualcuno, aspetta, viene ricopiata, e nel tragitto tra commerciale e produzione perde un pezzo per strada.

Nessuno di questi punti, preso da solo, sembra un dramma. Ma è la somma che spiega perché a fine mese si lavora tanto e si conclude poco. È lo stesso meccanismo che raccontiamo quando il problema non è il software, ma quanti software hai: l’attrito non sta dentro un programma, sta nei vuoti tra un programma e l’altro.

Il software giusto non nasce da cosa un’azienda chiede, ma da dove si fa male mentre lavora.

Il problema dichiarato non è quasi mai il problema vero

Ed eccoci al cuore del metodo. Il problema che un’azienda dichiara è la punta dell’iceberg; quasi sempre è il sintomo, non la causa.

«Ci serve un CRM» spesso significa «i commerciali non si fidano dei dati». «Vogliamo un’app per i tecnici» a volte vuol dire «le informazioni dal cantiere arrivano tardi e sbagliate». «Ci serve un sito che venda» può nascondere un problema che con il sito non c’entra niente. Se ci fermassimo al problema dichiarato, costruiremmo lo strumento sbagliato: bello, funzionante, e inutile — perché risolve il sintomo e lascia intatta la causa.

Distinguere il problema dichiarato dal problema vero è la ragione per cui insistiamo tanto su questa fase. Un’ora spesa a capire davvero ne fa risparmiare venti in sviluppo di cose che nessuno userà.

Perché facciamo tutto questo prima di scrivere codice

Scrivere codice è la parte facile e costosa. Facile perché, una volta chiaro cosa serve, è mestiere. Costosa perché ogni riga scritta sulla base di un’analisi sbagliata va poi buttata, e buttare lavoro fatto è la spesa più silenziosa e più alta di tutte.

Per questo il nostro punto di partenza non è la tecnologia, ma l’analisi dei processi aziendali e l’ascolto di come lavori davvero. La tecnologia arriva dopo, quando sappiamo esattamente dove fa male e perché. Che poi sia un software su misura, un’integrazione tra due sistemi che già hai o, a volte, semplicemente rimettere in fila un processo, lo decidiamo insieme — ma solo dopo aver capito la giornata storta.

Non promettiamo niente in questa fase, e non parliamo di preventivi. Ascoltiamo. Perché il modo migliore per costruire lo strumento giusto è, prima di tutto, avere il coraggio di guardare bene il problema.