Marco MerlinoIl modello RAPID è stato sviluppato daBain & Companye reso noto da Paul Rogers e Marcia Blenko. Distingue cinque ruoli — Recommend, Agree, Perform, Input e Decide — e insiste in particolare sulla presenza diun solo soggetto con la D, cioè con l’autorità finale di decidere. Le indicazioni originali raccomandano inoltre di limitare fortemente gli Agree, cioè i soggetti dotati di un effettivo diritto di veto.
Quando il problema non è decidere meglio, ma riuscire a decidere
Nelle organizzazioni contemporanee il problema non è sempre prendere decisioni migliori. Molto spesso è riuscire a prendereuna decisione, capire chi abbia realmente l’autorità per farlo e impedire che venga rimessa continuamente in discussione.
La crescita delle strutture a matrice, dei team cross-funzionali e dei modelli Agile ha aumentato le interdipendenze. Prodotto, tecnologia, operations, finance, legal, marketing e commerciale partecipano sempre più spesso alla stessa scelta.
È un’evoluzione necessaria: i problemi complessi richiedono prospettive differenti.
Ma quando partecipazione e autorità decisionale vengono confuse, la collaborazione può trasformarsi in paralisi.
È in questo spazio che RAPID offre una distinzione particolarmente utile. Non è una tecnica per trovare automaticamente la decisione corretta. È un modello per chiarire idiritti decisionali: chi formula la raccomandazione, chi deve essere ascoltato, chi possiede un effettivo diritto di veto, chi decide e chi esegue.
La sua intuizione più importante può essere sintetizzata così: collaborare non significa decidere tutti insieme.
Il costo invisibile dell’ambiguità decisionale
Immaginiamo una riunione di portfolio management. Sul tavolo c’è la scelta se interrompere un progetto digitale che ha già assorbito una parte significativa del budget ma continua a mostrare scarsa adozione.
Il responsabile di prodotto propone di interromperlo. IT ritiene che manchino poche funzionalità decisive. Finance sottolinea l’investimento già sostenuto. Sales sostiene che alcuni clienti importanti lo stiano aspettando. Il responsabile della business unit chiede ulteriori dati.
Dopo novanta minuti la riunione termina con una richiesta di approfondimento.
Due settimane dopo si tiene una seconda riunione. Vengono presentati nuovi dati, ma emerge una nuova obiezione. La decisione viene nuovamente rinviata.
Il problema potrebbe sembrare analitico: non abbiamo abbastanza informazioni.
Spesso, però, il vero problema è un altro:nessuno sa esattamente chi abbia il diritto di chiudere la decisione.
Quando questo accade, ogni stakeholder tende a comportarsi come se il proprio consenso fosse necessario. La consultazione diventa approvazione implicita e l’organizzazione cerca un consenso che nessuno ha formalmente dichiarato indispensabile.
Il costo non appare necessariamente nel budget di progetto. Compare sotto forma di attesa, meeting, rework, escalation e opportunità perse.
Da RACI ai diritti decisionali
Molte organizzazioni cercano di risolvere questa ambiguità attraverso una matrice RACI.
RACI è estremamente utile per chiarire responsabilità nell’esecuzione: chi è Responsible, chi Accountable, chi Consulted e chi Informed.
Ma una decisione non è semplicemente un’attività.
Possiamo sapere perfettamente chi debba preparare un business case senza sapere chi possa autorizzare l’investimento. Possiamo conoscere chi debba implementare una nuova policy senza avere chiarito chi possa scegliere tra due alternative incompatibili.
RAPID nasce precisamente per separare queste dimensioni.
Le cinque lettere identificanoRecommend, Agree, Perform, Input e Decide. È importante non interpretarle come una sequenza: lo stesso acronimo identifica ruoli decisionali, non cinque fasi da eseguire nell’ordine R-A-P-I-D.Asana
Recommend: costruire una proposta, non convocare un referendum
Il ruoloRha la responsabilità di portare la decisione verso una conclusione.
Chi possiede la Recommend raccoglie informazioni, costruisce alternative, valuta trade-off e formula una proposta.
Questo ruolo viene spesso sottovalutato. In molte organizzazioni una decisione arriva al management sotto forma di problema:
«Abbiamo questa situazione, cosa facciamo?»
RAPID richiede invece che qualcuno trasformi il problema in una raccomandazione argomentata.
La differenza è sostanziale.
Il management non dovrebbe essere costretto ogni volta a ricostruire il problema dal principio. Il recommender dovrebbe arrivare con una posizione:
sulla base di queste informazioni, considerando questi rischi e queste alternative, raccomandiamo questa scelta.
Input: ascoltare senza distribuire il potere di veto
Il ruoloInputrappresenta uno dei passaggi più importanti del framework.
Alcune persone possiedono informazioni indispensabili per prendere una buona decisione. Devono essere ascoltate.
Ma essere ascoltati non significa necessariamente avere il diritto di bloccare la decisione.
Questa distinzione appare banale finché non osserviamo il funzionamento reale delle organizzazioni.
Molti processi rallentano perché ogni stakeholder consultato viene implicitamente trasformato in approvatore. Il risultato è una progressiva espansione del numero di persone dalle quali ci si aspetta consenso.
RAPID separa nettamenteinformazione e autorità.
Un esperto può fornire un contributo fondamentale e contemporaneamente non possedere alcun veto.
Questa distinzione protegge sia la qualità della decisione sia la sua velocità.
Agree: rendere esplicito il vero veto
Agreenon significa semplicemente essere d’accordo.
Indica chi possiede un effettivo diritto di bloccare una raccomandazione in virtù di una responsabilità specifica. Le linee guida RAPID raccomandano infatti di utilizzare questo ruolo con parsimonia, tipicamente quando esistono vincoli legali, regolatori o analoghi.Bain Media
Legal può avere questo ruolo quando una scelta viola un requisito normativo. Cybersecurity quando viene superata una soglia di rischio non accettabile. Finance rispetto a determinati vincoli finanziari.
Il punto fondamentale è che gli Agree dovrebbero essere pochi.
Se ogni funzione possiede un veto, RAPID smette di funzionare e ricostruisce esattamente il problema che dovrebbe eliminare.
Il valore del framework consiste nel trasformare i veti informali indiritti espliciti, limitati e motivati.
Decide: qualcuno deve avere la D
Il cuore di RAPID è laD.
Per ogni decisione dovrebbe esistere un soggetto chiaramente identificabile che abbia l’autorità di chiuderla e impegnare l’organizzazione all’azione. Il modello prescrive esplicitamente una sola D per ciascuna decisione.Bain Media
Non necessariamente il manager gerarchicamente più alto.
Il diritto decisionale dovrebbe essere collocato dove esistono sufficiente competenza, visibilità delle conseguenze e responsabilità rispetto all’outcome.
La presenza di una singola D non significa leadership autoritaria. Il decisore può e deve ascoltare input, comprendere obiezioni e considerare alternative.
Ma alla fine qualcuno deve poter dire:questa è la decisione.
È una differenza profonda rispetto al consenso. Il consenso cerca una posizione che tutti possano accettare. RAPID cerca una decisione informata che qualcuno sia autorizzato ad assumere.
Perform: la decisione esiste soltanto quando modifica il sistema
L’ultimo ruolo riguarda l’esecuzione.
Una decisione strategica che non produce cambiamenti operativi rimane una dichiarazione di intenzioni.
Performidentifica chi deve trasformare la decisione in attività, comportamenti e risultati.
Separare Decide e Perform è utile perché evita un errore frequente: assumere che chi prende una decisione debba necessariamente essere anche chi la implementa.
Il management può decidere di modificare il pricing. Product, IT, Sales e Finance possono essere responsabili dell’esecuzione.
La chiarezza su questa transizione è fondamentale perché molti processi decisionali formalmente efficaci falliscono precisamente nel passaggio dalla scelta all’azione.
Un caso concreto: decidere se fermare un progetto
Consideriamo un’azienda che sta sviluppando una nuova piattaforma digitale B2B.
Il progetto dura da quattordici mesi. È stato consumato circa il 70% del budget previsto, ma i test con i clienti mostrano un’adozione molto inferiore alle attese.
Il Product Manager propone di interrompere il progetto e riallocare il budget verso un servizio differente emerso durante la discovery.
La decisione coinvolge numerosi stakeholder.
Senza una struttura chiara, il processo potrebbe trasformarsi in una lunga sequenza di riunioni. IT difende l’investimento tecnologico, Sales teme la reazione dei clienti ai quali il prodotto è stato anticipato, Finance evidenzia il sunk cost e Marketing ritiene prematuro giudicare l’adozione.
Applichiamo RAPID.
Recommend:il Product Manager costruisce la raccomandazione utilizzando dati di utilizzo, interviste, costi residui e scenari alternativi.
Input:CTO, Sales Director, Marketing e Customer Success forniscono informazioni tecniche, commerciali e di mercato.
Agree:Legal possiede un diritto limitato di veto esclusivamente se l’interruzione viola obblighi contrattuali già assunti.
Decide:il responsabile della business unit possiede la D perché risponde economicamente del portfolio.
Perform:Product, Technology e Customer Success implementano la chiusura e la transizione.
La decisione non diventa automaticamente facile.
Rimane possibile che CTO e Sales siano contrari.
Ma il disaccordo non impedisce più di decidere.
Questa è la differenza tragestire il conflitto e pretendere di eliminarlo prima di agire.
RAPID e Agile: autonomia non significa assenza di confini
A prima vista RAPID potrebbe sembrare un framework distante dalla cultura Agile. In realtà affronta uno dei problemi più frequenti delle trasformazioni Agile mature: la confusione tra empowerment e indeterminatezza dell’autorità.
Dire a un team«siete autonomi»serve a poco se non viene chiarito su quali decisioni possieda realmente autonomia.
Può modificare il backlog o cambiare una tecnologia? E’ in grado di rilasciare autonomamente e modificare il pricing? Può interrompere una feature già finanziata?
L’autonomia reale nasce da confini decisionali comprensibili.
RAPID può quindi essere utilizzato non per centralizzare, ma perrendere esplicita la decentralizzazione.
Un’organizzazione può decidere che alcune D appartengano ai team, altre ai Product Owner, altre ai responsabili di portfolio e soltanto poche al top management.
Il risultato può essere una struttura più distribuita, non più gerarchica.
Decision velocity: velocità senza fretta
La velocità decisionale è diventata una capacità organizzativa importante, ma la relazione con la performance è più sofisticata del semplicefaster is better. Una meta-analisi pubblicata nel 2025 ha aggregato127 studi e 239 effect size, rilevando effetti medi positivi sulla performance per decision speed (0,21), implementation speed (0,22) e response speed (0,10).Sage Journals
Questo introduce una distinzione fondamentale.
Decidere velocemente non significa decidere in fretta.
Un processo può essere analiticamente rigoroso e contemporaneamente rapido se è chiaro chi debba contribuire e chi possa chiuderlo.
Al contrario, una decisione relativamente semplice può richiedere settimane quando l’autorità è ambigua.
Ladecision velocitydipende quindi anche dall’architettura organizzativa.
Il rischio di burocratizzare RAPID
Come molti framework, RAPID può produrre l’effetto opposto se applicato indiscriminatamente.
Non tutte le decisioni meritano una matrice.
Applicare cinque ruoli alla scelta di una licenza software da cento euro sarebbe una forma di over-governance.
Lo stesso materiale metodologico sul framework suggerisce infatti di partire da poche decisioni realmente critiche, invece di mappare indiscriminatamente ogni scelta organizzativa.Bain Media
Il modello produce valore soprattutto sulle decisioni che sono contemporaneamente importanti, ricorrenti, cross-funzionali o frequentemente bloccate.
La domanda non dovrebbe quindi essere«possiamo usare RAPID?», ma:«Quali decisioni stanno generando abbastanza attrito da richiedere diritti decisionali espliciti ?»
Mappare le decisioni prima delle responsabilità
Molte trasformazioni organizzative iniziano dall’organigramma.
Disegniamo funzioni, ruoli e reporting line e successivamente cerchiamo di capire come far funzionare il sistema.
RAPID suggerisce implicitamente un percorso differente.
Partiamo dalle decisioni critiche.
Chi decide il pricing e l’ingresso in un nuovo mercato? Quali progetti interrompere e può modificare una roadmap? Chi decide una deroga agli standard tecnologici e quando un rischio è accettabile?
Una volta rese visibili queste decisioni, l’organizzazione reale diventa molto più leggibile.
Perché il potere organizzativo non è descritto soltanto dall’organigramma.
È descritto dachi possiede il diritto di dire sì, no o adesso.
Il management come architettura delle decisioni
La conseguenza più interessante di RAPID non è la matrice in sé.
È il cambiamento di prospettiva che introduce.
Il compito del management non consiste soltanto nel prendere decisioni. Consiste nel progettare un sistema nel qualele decisioni possano essere prese al livello appropriato senza richiedere continuamente l’intervento del management.
Questo significa distinguere consultazione da consenso, competenza da autorità, responsabilità esecutiva da diritto decisionale.
Significa anche accettare che una buona organizzazione non elimina il disaccordo.
Lo rende governabile.
Chi ha la D?
Quando una decisione importante rimane aperta per settimane, tendiamo a chiedere quali informazioni manchino, quale analisi debba essere completata o quale stakeholder non sia ancora stato coinvolto.
Talvolta sono domande corrette.
Ma ce n’è una che dovrebbe venire prima:chi ha la D?
Se la risposta non è immediata, probabilmente il problema non è ancora la qualità della decisione.
È la sua governance.
RAPID ci ricorda che organizzazioni collaborative non sono organizzazioni nelle quali tutti decidono tutto. Sono sistemi nei quali le persone giuste contribuiscono alle decisioni giuste e l’autorità necessaria per chiuderle è visibile prima che emerga il conflitto.
In contesti nei quali strategia, tecnologia e mercato cambiano rapidamente, questa chiarezza non rappresenta una rinuncia alla partecipazione.
Rappresenta una delle condizioni che permettono alla partecipazione di produrre risultati.
Perché il vero opposto della leadership autoritaria non è la decisione collettiva permanente.
È un’organizzazione nella qualeil potere decisionale è distribuito con intenzione, trasparenza e responsabilità.
