Come riconoscere il limite nascosto nei sistemi di gestione progetti finanziati, prima che la crescita lo riveli per voi.
Anna è la direttrice operativa di una cooperativa sociale con quaranta dipendenti e cinque bandi attivi. La cooperativa è organizzata bene. Le cartelle sull'archivio cloud hanno una struttura chiara: una per progetto, con sottocartelle per budget, rendicontazione, corrispondenza. I permessi sono assegnati per ruolo. I fogli di calcolo dei budget sono condivisi, con formule che si aggiornano quando qualcuno modifica un dato. C'è un template standard che ogni nuovo coordinatore riceve quando parte un bando. Anna lo ha costruito tre anni fa, lo ha affinato progetto dopo progetto, e oggi è un sistema che funziona.
Quando le chiedono il margine residuo di un progetto, Anna sa dove guardare e in tre ore ha il report pronto. I numeri tornano, il finanziatore riceve quello che deve ricevere. Tre ore e non tre giorni. Funziona.
Ma funziona adesso, con queste persone, con questi bandi, con queste regole. La domanda che Anna non si è mai fatta ad alta voce è un'altra: cosa succede quando qualcosa cambia?
La logica che non è nel file
Il foglio del budget del bando ministeriale è su un archivio cloud condiviso. Chiunque nel team può aprirlo. In questo senso, il dato è accessibile. Ma dentro quel foglio c'è una cella — una sola — che calcola il costo orario da rendicontare al finanziatore. La formula tiene conto della retribuzione lorda annua, degli oneri contributivi, di una quota di costi indiretti ripartita in proporzione alle ore dirette di progetto. È corretta. Ma è scritta in un modo che riflette il ragionamento di Anna: la sua interpretazione delle regole del bando, le sue scelte su come trattare le eccezioni, il suo modo di leggere una circolare ministeriale che lasciava margine di interpretazione.
Un giorno un coordinatore le ha chiesto di spiegargli come funziona quella formula. Anna ci ha messo quarantacinque minuti. Non perché il coordinatore fosse lento — perché la logica non è nella formula. La formula è il risultato finale di una catena di decisioni che Anna ha preso nel tempo: perché quel denominatore e non un altro, perché quel coefficiente per i collaboratori a partita IVA è diverso da quello dei dipendenti, perché i costi indiretti si ripartiscono così e non in un altro modo. Il coordinatore ha annuito. Anna sapeva che non aveva capito davvero. Ma non c'era tempo per rispiegare e il report andava consegnato.
Poi ci sono le convenzioni che non stanno in nessun documento. Come si allocano le ore quando un educatore lavora su due bandi nella stessa giornata — tre ore su uno e cinque sull'altro, o si divide proporzionalmente in base al budget residuo? Come si trattano i rimborsi trasferta quando il finanziatore non specifica se vanno nei costi diretti o negli indiretti? Come si gestisce quel fornitore il cui costo è al limite dell'ammissibilità — dentro o fuori? Anna lo sa perché ha preso quelle decisioni mesi fa, il revisore le ha accettate, e da allora si fa così. Ma "si fa così" non è scritto da nessuna parte. È nella memoria di Anna, cristallizzato in abitudini operative che lei applica senza pensarci e che nessun altro conosce.
Il territorio digitale è condiviso. La conoscenza di come farlo funzionare, no. Il limite non è il file. Il limite è la logica dentro al file.
Il soffitto che non si vede finché non ci sbatti
Il sistema di Anna è stato costruito per una cooperativa con quaranta persone e cinque bandi. Funziona a quella scala, con quelle persone, con quelle regole. Il problema è che nessuna di queste tre variabili resta ferma.
La cooperativa ha appena vinto un bando europeo con tre partner internazionali. Anna si siede davanti al template standard e capisce subito che non copre niente di quello che serve. I costi del personale si calcolano in modo diverso — un forfettario giornaliero diviso per un numero di giorni convenzionale, non il costo orario analitico che usa per i bandi nazionali. I costi indiretti sono un forfettario al sette per cento, non una ripartizione analitica. Il budget è organizzato per pacchetti di lavoro, non per voci di spesa. Il report va in inglese, con un formato che non corrisponde a nessuno dei template esistenti. E il partner tedesco chiede un riepilogo mensile in un suo formato proprietario.
Anna ha due opzioni: adattare il template esistente, rischiando di rompere le formule che servono per gli altri cinque bandi, o costruirne uno nuovo da zero. Sceglie la seconda. Ci mette tre giorni. Il foglio funziona, ma non è collegato a niente perché le ore dell'educatore che lavora sia sul bando europeo sia su quello comunale vanno scritte in due fogli diversi con due logiche diverse. I fogli da mantenere sono passati da cinque a sette. E la persona che sa come funzionano tutti e sette è sempre la stessa.
Poi ci sono le otto persone nuove, assunte tra settembre e marzo per coprire i progetti in crescita. Il sistema è intuitivo per chi ci lavora da tre anni. Per chi arriva e apre una cartella con venti fogli collegati tra loro, non lo è per niente. I coordinatori passano ore a spiegare dove si mette cosa, quali celle non vanno toccate, come si legge il template senza rompere le formule. Poi lo rispiegano la settimana dopo, perché qualcuno ha sovrascritto un valore senza accorgersene e un intero report ha smesso di tornare. Nessuno capisce cosa si è rotto finché qualcuno non va a controllare cella per cella. Il tempo speso a spiegare e correggere si aggiunge al tempo già speso per far funzionare il resto.
Con otto bandi il carico di manutenzione del sistema cresce, ma non in modo proporzionale, infatti cresce più di quanto ci si aspetti, perché ogni bando nuovo aggiunge interazioni con gli altri. E quando un partner chiede dati aggregati in un modo che il sistema non prevede, qualcuno deve fermare tutto, riaggregare a mano, e sperare che le formule reggano il passaggio.
Il sistema di Anna non è sbagliato. È costruito per una scala che l'organizzazione sta superando. E nel Terzo Settore, dove un bando nuovo può arrivare in qualsiasi momento e cambiare il volume del lavoro da un mese all'altro, un sistema che funziona solo alla velocità attuale è un sistema che ha già una data di scadenza.
Perché riorganizzare non basta
A questo punto la reazione è ragionevole: "Devo documentare meglio. Devo formare una seconda persona sulle formule. Devo ristrutturare i fogli per renderli più modulari." Sono i primi pensieri che vengono a chiunque e non sono sbagliati: sono insufficienti.
Documentare ha senso quando si tratta di decisioni interpretative, ad esempio come leggete una circolare, cosa ha accettato il revisore, perché un certo costo è stato classificato in un modo e non in un altro. Quelle sono scelte di contesto che meritano di essere scritte da qualche parte. Ma documentare le formule di calcolo e le regole di allocazione è un cerotto: sono cose che dovrebbero vivere nel sistema come regole che si applicano da sole, non in un documento che qualcuno deve leggere e poi replicare manualmente in un foglio. Il problema non è che Anna non documenta. Il problema è che la logica operativa (come si calcolano i costi, come si struttura il budget, come le ore diventano euro) vive in celle che solo lei sa leggere, invece di essere regole che il sistema applica autonomamente.
Formare una seconda persona è meglio che dipendere da una sola ma significa che ora il sistema dipende da due persone invece di una. Non è indipendenza, è ridondanza, e il giorno in cui una delle due esce e viene sostituita, il tempo investito nella formazione va rifatto da capo con la persona nuova, che nel frattempo deve anche imparare il contesto dei bandi, le eccezioni accumulate, le decisioni prese nei mesi precedenti.
Ristrutturare i fogli per renderli più modulari è un progetto nel progetto. Richiede giorni di lavoro, e la persona che sa farlo è quasi sempre la stessa che ha costruito il sistema originale. E soprattutto: va rifatto a ogni bando nuovo con regole diverse. Il bando europeo di Anna ha richiesto un foglio da zero perché nessuna ristrutturazione del template esistente poteva coprire un formato di rendicontazione completamente diverso.
Queste soluzioni non sono sbagliate. Comprano tempo. Funzionano per sei mesi, forse un anno. Poi il cerotto si stacca per vari motivi, forse perché nel frattempo il volume è cresciuto, le persone sono cambiate, o un finanziatore ha modificato le regole, e il problema è di nuovo lì, spesso più grande di prima.
Il principio che risolve il problema in modo strutturale è diverso: i dati e la logica che li governa devono appartenere al sistema, non alla persona che li ha costruiti. La formula per il costo orario non dovrebbe vivere nella cella di un foglio che solo Anna capisce che dovrebbe essere una regola che il sistema applica da solo, leggibile da chiunque, modificabile in un punto e propagata ovunque. La convenzione su come si allocano i costi indiretti non dovrebbe stare nella testa di Anna ma dovrebbe essere una configurazione che il sistema esegue automaticamente ogni volta che qualcuno inserisce un dato.
Quando arriva un bando con regole diverse, non serve ricostruire un foglio da zero. Serve configurare la struttura del progetto con le sue regole, e il sistema le applica dal momento in cui i dati entrano. I dati grezzi restano gli stessi, ovvero le ore lavorate, i costi sostenuti, ma la logica con cui vengono letti e valorizzati è nel sistema, non nella testa di qualcuno.
Un sistema robusto funziona indipendentemente da chi lo opera. Si adatta a requisiti nuovi senza essere ricostruito da zero. Scala senza che il carico umano cresca proporzionalmente. Non è un'utopia ma è un criterio progettuale. E il primo passo per raggiungerlo è sapere dove, oggi, il vostro sistema non lo soddisfa.
Il rischio è mappabile
Anna lo sente, anche se non lo dice spesso. Lo sente quando il bando europeo le ha chiesto tre giorni per un foglio nuovo. Lo sente quando il coordinatore le chiede di rispiegare la formula e lei non ha quarantacinque minuti. Lo sente quando guarda la lista dei bandi in fase di candidatura e pensa al suo template che non coprirà nemmeno quello successivo.
Non è frustrazione. Anna non è nel caos. È la lucidità di chi capisce che il sistema regge oggi ma non è costruito per reggere domani. E che nel suo settore, dove un bando nuovo può arrivare in qualsiasi momento, "domani" potrebbe essere il mese prossimo.
Non serve aspettare che qualcosa si rompa per scoprire dove il sistema è fragile. Si può simulare: cosa succederebbe se la persona che tiene in piedi la logica del sistema non fosse disponibile per un mese? Cosa succederebbe se arrivasse un bando con un formato di rendicontazione completamente diverso da quelli che avete? Cosa succederebbe se il numero di progetti attivi raddoppiasse in sei mesi?
Abbiamo costruito uno strumento che mette il vostro sistema sotto pressione simulata. Tre scenari, venti minuti, nessun numero da calcolare: solo domande oneste su cosa succederebbe se le condizioni cambiassero. Il risultato non vi dice quante ore sprecate. Vi dice dove il vostro sistema si piegherebbe.
L'abbiamo chiamato Stress Test dell'Architettura Operativa. Quanto regge il vostro sistema?
Scarica lo Stress Test qui
.png)