I Programmi per i Partner raramente entrano in crisi con 10 Partner. Con 10, il coordinatore conosce per nome il direttore di ciascun Partner, basta una telefonata per sapere a che punto sono e il Report annuale richiede un pomeriggio. Entrano in crisi nel percorso verso i 200, quando lo stesso coordinatore inizia ogni lunedì con una casella di posta piena di risposte sullo stato di avanzamento, un modello di riferimento che esiste in tre versioni e un Report per il consiglio direttivo che richiederà settimane.
Non succede nulla di eclatante. Il Programma supera una serie di soglie e le abitudini che funzionavano con 10 Partner smettono di funzionare, una alla volta. Ecco come ampliare un Programma per i Partner evitando questo lento cedimento: i sette punti critici nell'ordine in cui si presentano di solito, perché ciascuno emerge a quelle dimensioni e come risolverlo, partendo dalle pratiche e solo dopo dagli strumenti. In più, una checklist di preparazione di una pagina per il vostro team.
Perché i Programmi per i Partner entrano in crisi per gradi: il coordinatore diventa il punto di accodamento
Prima di occuparmi di trasformazione digitale, insegnavo ricerca operativa all'Università di Porto: la matematica delle code, dei colli di bottiglia e della capacità. Visti attraverso questa lente, i diversi passaggi hanno una spiegazione.
Nella maggior parte dei Programmi, quasi ogni richiesta passa attraverso una o due persone: il coordinatore che risponde alle domande, controlla i documenti, sollecita aggiornamenti e compila i Report. Nel linguaggio della teoria delle code, il coordinatore è il servente e ogni richiesta è un arrivo.
La legge di Little afferma che il numero medio di elementi in un sistema è uguale al loro tasso di arrivo moltiplicato per il tempo medio che ciascuno vi trascorre [1]. L'accumulo di richieste aperte nella casella di posta del coordinatore non è mancanza di disciplina: è il prodotto degli arrivi per il tempo di attesa.
Un secondo risultato è meno intuitivo. Nel modello più semplice di coda a un solo servente, il tempo medio che una richiesta trascorre nel sistema è pari al suo tempo di gestione diviso per uno meno il tasso di utilizzo del servente [2]. Con un'occupazione del 50%, una richiesta impiega il doppio del suo tempo di gestione per essere completata; all'80%, cinque volte; al 95%, venti. L'attesa non cresce in modo lineare con il carico di lavoro. Esplode man mano che la settimana si riempie.
Un esempio, basato su ipotesi da sostituire con le vostre: un coordinatore dispone di 20 ore a settimana per le richieste dei Partner e ogni Partner invia una richiesta a settimana che richiede 20 minuti di gestione.
- 10 Partner: poco più di 3 ore a settimana. Il coordinatore è occupato al 17% e le richieste non devono quasi attendere.
- 50 Partner: quasi 17 ore. Occupazione all'83% e una richiesta impiega in media sei volte il suo tempo di gestione per essere completata.
- 60 Partner: tutte le 20 ore. La coda non si stabilizza mai: continua a crescere.
Il coordinatore non è diventato più lento: sono cambiati i numeri. Gli stessi calcoli indicano l'ordine degli interventi, come in qualsiasi linea di produzione: prima ridurre gli arrivi (i Partner trovano le risposte senza dover chiedere), poi abbreviare la gestione (ogni richiesta nello stesso formato e nello stesso posto) e solo dopo aggiungere persone. Assumere, da solo, sposta soltanto il limite: con le stesse ipotesi, due coordinatori lo raggiungono a 120 Partner.
I sette punti critici, nell'ordine in cui si presentano di solito
1. Gli aggiornamenti vengono sollecitati via e-mail (da circa 15 Partner)
Sintomo. Ogni mese qualcuno scrive a tutti i Partner per chiedere a che punto sono, sollecita i ritardatari e copia le risposte in un foglio di calcolo. Quando arriva l'ultima risposta, la prima è già superata.
Perché il problema emerge qui. Un giro di aggiornamenti genera soltanto arrivi: un messaggio in uscita e una risposta in entrata per ciascun Partner, più i solleciti. Con 15 Partner richiede un pomeriggio. Con 200 Partner e una cadenza mensile, sono 2.400 richieste all'anno, ancora prima del primo sollecito.
La soluzione. Smettete di chiedere aggiornamenti: rendete visibile lo stato di avanzamento. Concordate con i Partner cosa significhi progredire in termini osservabili (una fase raggiunta, un'attività completata, un documento accettato), in modo che lo stato di avanzamento diventi un risultato naturale del lavoro.
2. Il modello di riferimento esiste in più versioni (da circa 25)
Sintomo. Il modello di riferimento è un PDF di due anni fa, un file Word aggiornato e una slide di un workshop che qualcuno ha migliorato. I Partner entrati in anni diversi lavorano sulla base di definizioni diverse della stessa fase.
Perché il problema emerge qui. Con 10 Partner, una modifica viene annunciata in una riunione e tutti ne vengono a conoscenza. Con 25, le modifiche viaggiano come allegati e ogni copia diventa una versione separata.
La soluzione. Un solo responsabile, una sola versione corrente, un registro delle modifiche e una data di entrata in vigore per ciascuna modifica.
3. L'inserimento dipende da una sola persona (da circa 40)
Sintomo. I nuovi Partner vengono introdotti al Programma dalla persona che lo ha progettato, con un'unica lunga chiamata. Quando quella persona è in ferie, l'inserimento si ferma; quando se ne va, porta con sé la memoria del Programma.
Perché il problema emerge qui. L'inserimento è una richiesta con un tempo di gestione lungo e i Programmi tendono ad aggiungere Partner per gruppi. Quindici nuovi Partner nello stesso mese finiscono tutti nella stessa agenda.
La soluzione. Mettete per iscritto il percorso di inserimento: un breve kit di benvenuto, i primi tre passi, a chi rivolgersi per ciascun argomento. La prima chiamata potrà così concentrarsi sul Partner, non sul Programma.
4. Le evidenze sono disperse nelle caselle di posta (da circa 60)
Sintomo. Politiche, audit, elenchi di formazione e foto arrivano come allegati alla persona che il Partner conosce meglio. Prima di un audit o della visita di un donatore, il team passa giorni a cercare nelle caselle di posta.
Perché il problema emerge qui. Le evidenze crescono con il numero di Partner moltiplicato per i requisiti e arrivano in caselle di posta personali che i colleghi non possono consultare. Considerate anche il carico dall'altra parte: uno studio ICVA del 2016 sulle condizioni imposte dai donatori alle ONG umanitarie ha rilevato una media di 36 scadenze di rendicontazione per Paese all'anno e valutazioni delle capacità dei Partner che potevano arrivare a più di 100 domande e fino a 91 allegati [3]. I vostri Partner sostengono un carico analogo per voi.
La soluzione. Richiedete ogni evidenza una sola volta, con una scadenza e un collegamento al requisito che dimostra di soddisfare. Chiedete soltanto ciò che qualcuno leggerà.
5. La preparazione dei Report richiede settimane (da circa 90)
Sintomo. Il Report annuale comincia con un'e-mail che chiede i numeri a tutti i Partner, prosegue con settimane dedicate a unire file e termina con un grafico di cui nessuno riesce a ricostruire la fonte.
Perché il problema emerge qui. A queste dimensioni, preparare i Report è un lavoro di assemblaggio: se durante l'anno i dati non sono stati raccolti in un'unica struttura, qualcuno la costruisce a mano alla fine. Lo stesso studio ICVA descrive una ONG internazionale che aveva calcolato di poter risparmiare 11.000 ore di rendicontazione finanziaria se i suoi nove maggiori donatori avessero concordato le definizioni dei costi e accettato lo stesso modello finanziario [3]. Nel Grand Bargain del 2016, donatori e organizzazioni umanitarie si sono impegnati a ridurre le duplicazioni e i costi di gestione e a semplificare la rendicontazione: meno volume, terminologia comune, requisiti essenziali e una struttura comune per i Report [4].
La soluzione. Scegliete pochi KPI prima dell'inizio dell'anno, definiteli allo stesso modo per ogni Partner e raccoglieteli durante lo svolgimento del lavoro. Il Report diventa un'estrazione dei dati e le settimane possono essere dedicate alla sua lettura.
6. I Partner non sanno cosa ci si aspetta da loro o non possono lavorare nella propria lingua (da circa 120)
Sintomo. Continuano ad arrivare le stesse domande: cosa serve per la fase successiva, quale modello usare, entro quando. I Partner di alcuni Paesi rispondono in ritardo o non rispondono affatto, e questo viene interpretato come scarso coinvolgimento.
Perché il problema emerge qui. Ormai il Programma supera i confini nazionali, mentre le aspettative restano espresse in una sola lingua. Gli autori di un articolo del 2021 su Humanitarian Exchange hanno osservato che le linee guida globali e gli strumenti tecnici sono generalmente disponibili soltanto nelle lingue ufficiali dell'ONU e che le riunioni di coordinamento in lingue internazionali aggravano il problema [5]. Il silenzio è spesso un problema linguistico, non di motivazione.
La soluzione. Descrivete ogni fase in termini semplici e osservabili e traducetela insieme ai relativi modelli. Ogni domanda a cui la pagina risponde è una richiesta che non entra mai in coda.
7. Autorizzazioni e protezione dei dati (da circa 160)
Sintomo. Centinaia di persone hanno accesso alla cartella condivisa, nessuno sa con certezza chi possa vedere la valutazione di quale Partner e il responsabile della protezione dei dati pone domande a cui nessuno sa rispondere.
Perché il problema emerge qui. Con 10 Partner, una cartella condivisa è comoda. Con 200, diventa un rischio: le schede dei Partner contengono dati personali e valutazioni sensibili e gli accessi concessi manualmente vengono revocati di rado. Le indicazioni della Commissione europea sulla protezione dei dati per impostazione predefinita prevedono che i dati personali siano accessibili «solo a un numero limitato di persone, in base alla necessità di conoscerli» [6].
La soluzione. Definite i ruoli prima dell'ingresso del gruppo successivo: chi nel team può vedere e modificare cosa, e la regola per cui ciascun Partner vede i propri dati e nient'altro. Rivedete gli accessi quando le persone entrano o escono.
Cosa deve fare uno strumento in ciascun punto critico
Prima vengono le pratiche: uno strumento che automatizza un processo malfunzionante non fa che accelerarne il fallimento. Poi, ecco cosa richiede a uno strumento la gestione dei Partner su larga scala:
| Punto critico | Prima la pratica | Cosa deve fare uno strumento |
|---|---|---|
| Aggiornamenti sollecitati via e-mail | Rendere lo stato di avanzamento un risultato naturale del lavoro | Consentire ai Partner di registrare i progressi dove lavorano e mostrarvi la posizione di ciascuno senza doverla chiedere |
| Modello di riferimento in più versioni | Un responsabile, una versione, un registro delle modifiche | Mantenere un solo modello per tutti i Partner, modificabile in collaborazione, con aggiornamenti che raggiungono tutti contemporaneamente |
| Inserimento affidato a una sola persona | Un kit di benvenuto scritto | Mostrare a ogni nuovo Partner, fin dal primo accesso, a che punto si trova e cosa serve per il passo successivo |
| Evidenze perse nelle caselle di posta | Una sola richiesta per ciascuna evidenza | Collegare ogni file caricato al passaggio di cui dimostra il completamento e mostrare cosa manca per tutti i Partner |
| Preparazione dei Report che richiede settimane | Pochi KPI, definiti in anticipo | Conservare i KPI di ciascun Partner con il relativo storico e produrre Report a partire da quei dati |
| Aspettative poco chiare, una sola lingua | Descrizioni semplici delle fasi, tradotte | Mostrare a ogni Partner la propria posizione e il passo successivo nella sua lingua |
| Autorizzazioni e protezione dei dati | Ruoli definiti prima del gruppo successivo | Applicare i ruoli, limitare ogni Partner ai propri dati, supportare l'accesso della vostra organizzazione, indicare dove sono archiviati i file |
Una checklist di una pagina per prepararsi alla crescita
La checklist traduce i sette punti critici in 21 affermazioni, più i calcoli sul carico del coordinatore con spazio per inserire i vostri numeri. Compilatela con il team prima dell'arrivo del prossimo gruppo di Partner e iniziate dalla prima sezione con due o più caselle vuote.
Scaricate la checklist per prepararsi alla crescita (PDF, 1 pagina). Stampatela per una riunione del team.
Avete già superato il secondo punto critico? In Advancer.World ogni Partner lavora su un'unica versione del vostro Programma, vede la propria posizione e i requisiti della fase successiva nella propria lingua e invia le evidenze al passaggio a cui appartengono. Il vostro team vede a che punto si trova ciascun Partner senza doverlo chiedere. Potete iniziare gratuitamente.
Gestione dei Partner su larga scala in Advancer.World
Advancer.World è nato dalla trasformazione digitale dei Programmi di organizzazioni come UNICEF e Airbus. Un Programma è un'unica griglia, progettata una sola volta: le fasi su un asse, gli argomenti e i sottoargomenti sull'altro, con ogni cella che descrive cosa significa quella fase per quell'argomento. Più persone del vostro team possono progettarlo contemporaneamente e ogni Partner lavora sulla stessa versione.
I passaggi tra le celle racchiudono il lavoro: iniziative, questionari, richieste di caricamento di documenti e richieste di firma elettronica. Per ogni Programma scegliete come avanzano i Partner: tramite autovalutazione, automaticamente al completamento del passaggio precedente oppure con la conferma del vostro team. I Partner vengono invitati via e-mail e vedono la propria posizione e i requisiti della fase successiva in una qualsiasi delle 22 lingue, tra cui arabo, urdu, swahili e hausa. Non vedono mai i dati degli altri Partner e né i Partner né le loro persone pagano mai.
I KPI vengono registrati per ciascun Partner e le istantanee giornaliere ne conservano lo storico, così i Report Excel e i Report Word con grafici redatti dall'IA derivano dai dati raccolti durante l'anno. La vostra organizzazione può accedere con Microsoft Entra ID, i file sono archiviati nell'UE e, nei piani Gold ed Enterprise, un assistente IA può leggere lo stato di avanzamento dei vostri Partner tramite il server MCP. Se non conoscete ancora MCP, iniziate da che cos'è il Model Context Protocol.
Domande frequenti
Quanti Partner può gestire un coordinatore?
Non esiste un rapporto fisso. Moltiplicate il numero di Partner per le richieste che ciascuno invia a settimana e per i minuti necessari a gestire ogni richiesta, poi dividete per i minuti che il vostro coordinatore ha realmente a disposizione per lavorare con i Partner. Questo è il tasso di utilizzo. All'80%, una richiesta impiega già in media cinque volte il suo tempo di gestione per essere completata.
Quando dovremmo smettere di gestire un Programma per i Partner con fogli di calcolo ed e-mail?
Quando due dei primi quattro punti critici si manifestano contemporaneamente oppure prima dell'ingresso del prossimo gruppo di Partner, a seconda di quale evento si verifichi per primo. Per aiutarvi a trasferire i dati esistenti, Mourinho Solutions offre supporto alla migrazione.
Una piattaforma aggiungerà lavoro per i nostri Partner?
Dovrebbe ridurlo. Un Partner che risponde alle e-mail sullo stato di avanzamento, invia allegati a tre persone e compila un modello diverso per ogni finanziatore sta già facendo quel lavoro: uno spazio condiviso cambia soltanto dove viene svolto. Chiedete prima a due o tre Partner di provarlo.
Come far crescere un programma per i partner senza comprometterne il funzionamento
Non è necessario risolvere tutti e sette i problemi contemporaneamente. Individuate il primo punto critico che il vostro programma ha già superato, risolvete quello e calcolate il carico di lavoro del coordinatore prima che si aggiunga il prossimo gruppo. Un programma che cresce bene non ha un coordinatore eroico. Ha un coordinatore la cui settimana non è già piena. Per un secondo parere sulla progettazione del programma stesso, è disponibile la nostra consulenza sui programmi.
Gestite 10 o 200 partner con la stessa griglia. Progettate il vostro programma una sola volta, invitate i vostri partner e conservate le evidenze, i KPI e lo storico in un unico posto anziché nella casella di posta. Potete iniziare gratuitamente.
Riferimenti
- John D. C. Little, "La legge di Little a cinquant'anni dalla sua formulazione", Operations Research 59(3), pp. 536–549, maggio–giugno 2011, https://doi.org/10.1287/opre.1110.0940 (consultato a ottobre 2026).
- Richard C. Larson e Amedeo R. Odoni, "Ricerca operativa urbana", Prentice-Hall, 1981, sezione 4.6.1, "Un operatore, un numero infinito di linee", https://web.mit.edu/urban_or_book/www/book/chapter4/4.6.1.html (consultato a ottobre 2026).
- Consiglio internazionale delle agenzie di volontariato (ICVA), "Meno burocrazia, più aiuti: rendicontazione, valutazione delle capacità dei partner e audit", aggiornato a settembre 2016, https://alnap.org/help-library/resources/less-paper-more-aid-reporting-partner-capacity-assessment-and-audit/ (consultato a ottobre 2026).
- "Il Grand Bargain: un impegno condiviso per rispondere meglio alle esigenze delle persone bisognose", Istanbul, 23 maggio 2016, https://gblocalisation.ifrc.org/wp-content/uploads/2018/06/grand_bargain_final_22_may_final-2_0.pdf (consultato a ottobre 2026).
- Mia Marzotto, Kemal Alp Taylan, Fatuma Ibrahim, Marian Ellen Hodgkin, Paul Martin Lukusa Mbwebwa e Charles Abugo, "'Come possiamo contribuire se non possiamo partecipare?' L'accessibilità delle linee guida umanitarie per le organizzazioni locali e nazionali", Humanitarian Exchange 79, Humanitarian Practice Network, 25 maggio 2021, https://odihpn.org/en/publication/how-can-we-contribute-if-we-cant-participate-the-accessibility-of-humanitarian-guidance-to-local-and-national-organisations/ (consultato a ottobre 2026).
- Commissione europea, "Obblighi: protezione dei dati fin dalla progettazione e per impostazione predefinita", https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations/what-does-data-protection-design-and-default-mean_en (consultato a ottobre 2026).
© 2026 Mourinho Solutions. Tutti i diritti riservati.
