Metodo RADICE
Come progettiamo i sistemi informativi che governano flussi critici regolati
RADICE è il metodo proprietario di Schema31. Sei fasi consecutive: Ricognizione · Analisi · Diagnosi · Integrazione · Costruzione · Efficienza. Codificate in vent’anni di pratica sui sistemi critici di organizzazioni complesse. Ogni fase ha un input definito, un output verificabile e una funzione specifica nella struttura del progetto.
Fonte: McKinsey & Oxford University Saïd Business School, analisi su 5.400+ progetti IT enterprise.
Perché un metodo specifico
La letteratura sui progetti IT enterprise documenta un problema ricorrente: sforamenti di budget, ritardi e scostamenti tra sistema progettato e realtà operativa. In molti casi la causa non è la tecnologia in sé, ma la mancanza di competenza di dominio prima dell’avvio del progetto.
Sui flussi critici regolati non è un rischio statistico. È un fenomeno strutturale.
La normativa europea, nazionale e regionale, le eccezioni operative codificate nei manuali interni delle organizzazioni, le relazioni tra enti che non risultano da nessun documento: tutto questo non si impara durante lo sviluppo. O lo si conosce prima, o il progetto accumula ritardo sulla realtà operativa.
RADICE nasce da questa osservazione. Non è un acronimo costruito per descrivere un metodo, ma il risultato di oltre vent’anni di lavoro su sistemi critici: la prima fase di un progetto complesso non è scrivere codice, è acquisire e formalizzare la competenza di dominio necessaria. Le sei fasi che lo compongono sono il distillato operativo di questa esperienza.
Il metodo
Le sei fasi di RADICE
Le fasi non operano in parallelo. Operano in sequenza, ciascuna costruita sull’output della precedente. La struttura è progettata in modo che ogni fase risolva le ambiguità che renderebbero strutturalmente debole la successiva.
Ricognizione
L’ingresso nell’organizzazione, prima delle scelte progettuali definitive.
La Ricognizione è la fase che precede le decisioni progettuali più vincolanti. Consiste nell’osservazione diretta dei processi reali dell’organizzazione: come operano gli attori, dove i flussi si interrompono, quali eccezioni vivono nella memoria delle persone e non nei documenti, quali decisioni dipendono da relazioni interne non formalizzate. Non si tratta di una raccolta requisiti tradizionale. È un periodo strutturato di osservazione in cui le interviste hanno l’obiettivo di far emergere ciò che non è stato ancora detto, non di validare uno schema preesistente.
Documento di Ricognizione: mappa degli attori, mappa dei processi reali, inventario delle eccezioni rilevanti, dipendenze critiche identificate.
La conoscenza acquisita qui è il presupposto di tutte le fasi successive. Senza di essa, l’Analisi opera su un’organizzazione idealizzata.
Analisi
Dalla realtà osservata alla mappa delle frammentazioni.
L’Analisi prende il materiale prodotto in Ricognizione e lo organizza in modo strutturato. Rende visibili le frammentazioni operative: processi senza un responsabile chiaramente identificato, flussi non documentati, sistemi che non comunicano, dipendenze critiche che non sono state mai formalizzate. È il passaggio da una raccolta di osservazioni a una rappresentazione coerente dell’organizzazione, in cui ogni discontinuità ha un nome e una collocazione precisa.
Rappresentazione strutturata delle frammentazioni operative, dei processi e delle loro discontinuità, dei sistemi esistenti e delle loro relazioni reali, non quelle teoriche.
L’Analisi precede la Diagnosi perché un problema non può essere diagnosticato prima di avere una rappresentazione coerente della sua struttura.
Diagnosi
Distinguere il sintomo dalla causa strutturale.
La Diagnosi è il punto di passaggio dall’osservazione alla comprensione. La richiesta iniziale del committente descrive quasi sempre un effetto, raramente la causa che lo genera. Un’organizzazione che lamenta problemi di tracciabilità può richiedere un nuovo sistema di reportistica, mentre la causa strutturale è una frammentazione informativa a monte. Diagnosticare significa rispondere alla domanda: perché il problema esiste in questa forma, in questo momento, in questa organizzazione.
Documento di Diagnosi che identifica la causa o le cause strutturali del problema, distinguendole dai sintomi che lo manifestano.
La Diagnosi orienta tutta la progettazione successiva. Un’errata diagnosi produce un sistema che risolve il sintomo lasciando intatta la causa: il sintomo riemerge dopo il go-live.
Integrazione
Progettare dentro la realtà operativa esistente.
L’Integrazione è la fase in cui la causa diagnosticata incontra l’ecosistema operativo. I sistemi che progettiamo non operano in isolamento: si collegano a REGIS per il PNRR, al Sistema di Interscambio per la fatturazione elettronica, a PagoPA per i pagamenti, a NSIS per la sanità, ai sistemi ministeriali e regionali esistenti. Queste integrazioni non vengono aggiunte alla fine. Sono requisiti di progettazione fin dalle prime decisioni architetturali, perché la coerenza con l’ecosistema è una proprietà strutturale del sistema, non un’aggiunta successiva.
Architettura del sistema, integrazioni nazionali e istituzionali richieste, flussi dati con i sistemi esistenti, compliance normativa applicabile.
Progettare le integrazioni dopo aver iniziato lo sviluppo costringe a riarchitetture costose. Considerarle prima permette al codice di nascere già coerente.
Costruzione
La fase di scrittura del codice.
La Costruzione inizia solo quando le fasi precedenti hanno risolto le ambiguità. Ricognizione, Analisi, Diagnosi e Integrazione hanno trasformato la richiesta iniziale in specifiche operative chiare, deliverable architetturali precisi, integrazioni progettate. Il codice nasce in un contesto in cui le scoperte in corso d’opera sono state ridotte al minimo, perché le decisioni che le generavano sono state prese prima. Procedure di sviluppo certificate ISO 9001, code review sistematiche, test funzionali e di integrazione: standard operativi maturati su vent’anni di rilasci in produzione.
Sistema sviluppato secondo standard certificati: codice versionato, code review sistematiche, test funzionali e di integrazione, deploy ripetibile, ambienti controllati.
La scrittura del codice come ultima fase tecnica del progetto è la conseguenza di tutto ciò che è stato fatto prima. Se questa fase è rapida, è perché le precedenti hanno funzionato.
Efficienza
Il go-live come punto di partenza, non come traguardo.
I sistemi critici non si concludono con il go-live. Evolvono con l’organizzazione che li usa. La fase di Efficienza copre la manutenzione evolutiva, l’adeguamento normativo continuo, il monitoraggio operativo, l’estensione a nuovi domini d’uso. È la fase in cui il sistema dimostra di essere stato progettato per durare oltre la committenza iniziale, attraverso cicli di programmazione, evoluzioni normative e cambi di legislatura.
Continuità operativa del sistema nel tempo: manutenzione strutturata, monitoraggio in produzione, evoluzione tracciata, adeguamento normativo come attività ordinaria.
Senza una fase di Efficienza strutturata i sistemi critici degradano lentamente: la normativa cambia, le integrazioni evolvono, i requisiti si modificano. La continuità è il completamento del metodo.
Mapping operativo
Dalle sei fasi al ciclo ingegneristico
RADICE è il metodo. Il ciclo produttivo è la sua esecuzione operativa. Le sei fasi metodologiche si traducono in altrettante fasi ingegneristiche, ciascuna con procedure certificate ISO 9001, deliverable verificabili e controlli sistematici.
Questa traduzione non è un’astrazione documentale. È la struttura concreta del lavoro quotidiano dei team di Schema31. Ogni step del ciclo produttivo ha procedure tracciate, criteri di accettazione, indicatori di qualità misurati.
Intelligenza artificiale integrata
Come l’intelligenza artificiale accelera RADICE
L’intelligenza artificiale produce risultati misurabili quando opera su processi già compresi. Per questa ragione, in RADICE l’IA non sostituisce le fasi di Ricognizione, Analisi e Diagnosi, fasi in cui la comprensione del dominio è ancora in costruzione e va condotta dalle persone. Interviene a partire da quando i dati sono organizzati e le decisioni hanno un fondamento strutturato.
L’IA è un potenziamento operativo della competenza umana, non un suo sostituto. Le decisioni strutturali del progetto restano alle persone. L’intelligenza artificiale accelera ciò che è già stato compreso e libera tempo per le attività in cui il giudizio professionale è insostituibile.
Perimetro di applicabilità
Quando RADICE è il metodo appropriato
RADICE è progettato per una categoria precisa di progetti. Non è un metodo universale. È il metodo necessario quando il dominio è regolato, le integrazioni istituzionali sono numerose e la continuità operativa è una condizione vincolante.
Quando RADICE non è il metodo appropriato. Su MVP da validare rapidamente, prototipi tecnologici esplorativi e progetti dove il dominio è semplice e ben noto, una struttura come RADICE può essere sproporzionata. In quei casi possono essere più adatti approcci più leggeri, iterativi e orientati alla validazione rapida. RADICE è il metodo dei sistemi che non possono fallire, non il metodo universale.
Applicazione operativa
RADICE applicato ai nostri ambiti
RADICE è il metodo trasversale che attraversa tutti e tre i nostri ambiti operativi. La sequenza delle fasi resta la stessa. Cambiano le specificità di dominio che ciascuna fase deve affrontare.
Acquisire la mappa della governance dei fondi
Fondi Strutturali EU e PNRR
La Ricognizione include la mappa degli attori della governance dei fondi: Autorità di Gestione, Autorità di Audit, Autorità di Certificazione, Commissione Europea. L’Integrazione si concentra su REGIS e Sistema Nazionale di Monitoraggio.
Mappare il procedimento nelle sue varianti regionali
Concessioni e Autorizzazioni
La fase di Analisi si concentra sulla mappatura del procedimento autorizzativo nelle sue varianti regionali. L’Integrazione affronta PagoPA, firma remota massiva e i requisiti Open Data.
Distinguere ritardo di pagamento da frammentazione strutturale
Amministrativo-Contabile e Sanità
La Diagnosi distingue tra sintomo (ritardi di pagamento) e causa strutturale (frammentazioni nei flussi tra SDI, Aziende Sanitarie e Tesoreria). L’Integrazione opera nativamente con SDI e NSIS.
Continua il percorso
Da dove vuoi proseguire?
Se vuoi capire come applichiamo RADICE al tuo contesto specifico, scegli il percorso più vicino alla tua situazione.
