Stock, flow, delay, causal loop: la system dynamics di Forrester

Una vasca da bagno, un magazzino, una città e un pianeta obbediscono alla stessa matematica. Imparare a leggerla è imparare a non farsi ingannare dai sistemi con feedback e ritardo.

Perché questo capitolo

Nel 1956 un gruppo di manager della General Electric aveva un problema che non sapeva spiegare. Lo stabilimento di elettrodomestici in Kentucky assumeva e licenziava operai con un ciclo regolare di circa tre anni: ondate di assunzioni, poi ondate di licenziamenti, poi di nuovo assunzioni. La spiegazione che davano era quella ovvia: il ciclo economico esterno, la domanda del mercato che andava su e giù. Portarono il caso a Jay W. Forrester, un ingegnere che era appena passato dal laboratorio dei calcolatori del MIT alla sua scuola di management. Forrester prese le regole interne con cui l’azienda gestiva ordini, scorte e personale, le mise in fila, e fece i conti a mano. Il ciclo di tre anni veniva fuori da solo, anche tenendo la domanda del mercato perfettamente costante. L’oscillazione non arrivava da fuori. L’azienda la stava generando da sé, con le proprie politiche di gestione, e non se ne accorgeva.

Da quel calcolo nasce la system dynamics: un metodo per costruire e simulare modelli di sistemi complessi — aziende, città, economie, ecosistemi — fatti di accumuli, flussi, anelli di feedback e ritardi. Non è una teoria astratta. È un linguaggio di modellazione e una pratica di simulazione, nata per rispondere a una domanda molto concreta: perché i sistemi con molti anelli di retroazione si comportano in modi che nessuno aveva previsto, e spesso nel modo esattamente opposto a quello che ci si aspettava?

La risposta di Forrester è scomoda e riguarda chi legge da vicino. La sua tesi è che la mente umana, semplicemente, non è attrezzata per simulare il comportamento di un sistema con molti feedback e ritardi. La nostra intuizione si è formata su catene causa-effetto corte: tocco il fuoco, mi scotto. Di fronte a una supply chain, a una pipeline agentica con retry e cache, o a un’economia, quella stessa intuizione fallisce in modo prevedibile e sistematico. Capire la system dynamics serve a due cose: avere un vocabolario per dire dove e perché fallisce, e avere uno strumento — la simulazione esplicita — per rimediare.

C’è un motivo concreto per cui questo arriva proprio qui, in questa wiki. Chi costruisce sistemi con agenti AI lavora ogni giorno con oggetti che si accumulano — il budget di token, la memoria di un agente, la coda di task, il debito tecnico — e con anelli di feedback che hanno ritardi — retry che rimettono in coda dopo un timeout, cache con un TTL, approvazioni umane che arrivano il giorno dopo. È esattamente la classe di sistemi su cui Forrester aveva costruito un metodo. Il vocabolario di stock, flow, loop e delay non è un reperto storico da scuola di management: è la lente che fa la differenza tra capire perché una pipeline oscilla e cercare a vuoto un colpevole. Questo capitolo dà la lente; le sezioni applicative la puntano sugli agenti.

Contesto

La system dynamics non nasce dal nulla. Si colloca dentro la grande famiglia che questa Parte e la Parte IX descrivono. Dalla cibernetica di Norbert Wiener — il matematico del MIT che a metà Novecento mette il feedback al centro — eredita l’idea che un anello che misura un errore e agisce per ridurlo spiega il comportamento orientato a uno scopo. Dalla teoria del controllo, e dall’ingegneria dei servomeccanismi in cui Forrester si era formato, eredita l’analisi della stabilità, del ritardo e dell’oscillazione. Dalla teoria dei sistemi eredita il vocabolario di stato, confine, processo.

Il legame con la cibernetica e la teoria del controllo è una filiazione documentata, non un’analogia: Forrester veniva dall’ingegneria dei sistemi di controllo, aveva lavorato durante la guerra su meccanismi di puntamento radar, e cita esplicitamente questa eredità. Il suo contributo specifico è metodologico. La cibernetica classica restava largamente qualitativa, o si applicava a sistemi ingegneristici puliti — un circuito, un servomotore. Mancava un modo per costruire e simulare al calcolatore modelli quantitativi di sistemi grandi, disordinati, sociali. Forrester porta tre cose nuove: un linguaggio di modellazione (stock, flow, diagrammi causali), un calcolatore che integra le equazioni al posto della mente umana, e l’ambizione di applicare tutto questo non a un circuito ma a un’impresa, a una città, a un pianeta.

Conviene anche dire contro cosa la system dynamics si è definita. Negli anni Cinquanta, per studiare un’impresa o un’economia, gli strumenti erano altri. C’era l’econometria, che fitta relazioni statistiche su dati storici: brava a dire “queste variabili sono correlate così”, debole sul perché strutturale e sul comportamento fuori dall’intervallo osservato. C’era la ricerca operativa, brava a ottimizzare una decisione isolata — il livello di scorta ottimo, il percorso più corto — ma poco attrezzata per la dinamica di un intero sistema che reagisce a sé stesso nel tempo. Forrester sceglie una terza via: non fittare i dati e non ottimizzare una decisione, ma costruire la struttura — gli stock, i flow, gli anelli — e poi simularla per vedere quale comportamento genera. Il banco di prova non è “il modello riproduce i dati passati”, ma “il modello, con la struttura giusta, genera lo stesso tipo di comportamento che vediamo nel sistema reale”. È uno spostamento dal fitting alla spiegazione strutturale.

Chi è Forrester. Jay Wright Forrester (1918-2016) è un ingegnere elettrico statunitense, cresciuto in un ranch del Nebraska. Negli anni Quaranta dirige il Digital Computer Laboratory del MIT e lavora a Whirlwind, uno dei primi calcolatori digitali general-purpose; lì inventa la memoria a nuclei magnetici (la coincident-current magnetic core memory, minuscoli anelli di ferrite magnetizzati per immagazzinare bit), che resterà lo standard dell’industria informatica per circa vent’anni. Dirige poi il progetto SAGE, il sistema di difesa aerea statunitense. Nel 1956 cambia mestiere: lascia l’ingegneria del calcolo e passa alla neonata Sloan School of Management del MIT. È da management, non da ingegnere, che incontra il problema della General Electric — e con quello fonda un campo nuovo.

Questa traiettoria non è un dettaglio biografico curioso: spiega la system dynamics. Forrester aveva costruito i primi calcolatori e capiva il feedback dei sistemi di controllo. Quando arriva al management, vede un’azienda con lo sguardo dell’ingegnere dei servomeccanismi: scorte e personale sono accumuli, ordini e assunzioni sono tassi, la struttura delle decisioni è una rete di anelli di feedback con ritardi. Nessuno, prima, aveva guardato un’impresa in quel modo, perché nessuno arrivava al management dal laboratorio dei calcolatori. La system dynamics nasce dall’incontro improbabile di due competenze in una sola persona: l’ingegneria del controllo e la gestione d’impresa, più lo strumento — il calcolatore — che le lega.

Le date che contano: Industrial Dynamics nel 1961, Urban Dynamics nel 1969, World Dynamics nel 1971, e nello stesso anno il paper-testimonianza “Counterintuitive Behavior of Social Systems” — un documento nato come deposizione davanti a una sottocommissione del Congresso degli Stati Uniti sulla crescita urbana, e diventato poi uno dei testi più citati del campo. Nel 1972 il libro The Limits to Growth porta il metodo davanti a un pubblico di milioni di lettori.

Una parola sul nome. All’inizio Forrester chiama il suo metodo industrial dynamics, perché lo aveva applicato all’impresa. Quando il campo si allarga alle città, ai sistemi ecologici e al mondo intero, il nome diventa troppo stretto e si afferma system dynamics — la dinamica dei sistemi in generale. Il cambio di nome non è cosmetico: segnala che il metodo non riguarda un dominio, ma una classe di sistemi — quelli con accumuli, flussi, feedback e ritardi — indipendentemente da cosa quei sistemi siano fatti. È la stessa universalità che la cibernetica aveva rivendicato per il feedback, e che la teoria dei sistemi rivendica per il concetto di sistema.

Un’ultima collocazione, per chiudere il quadro. Nella mappa di questa Parte, la system dynamics arriva dopo la cibernetica di Wiener, l’omeostato di Ashby, la cibernetica di secondo ordine di von Foerster e il Viable System Model di Stafford Beer. Non è un’appendice di quella sequenza: è il filone che ha portato il feedback dalla teoria alla pratica di modellazione quantitativa su scala grande. Beer e Forrester, in particolare, affrontano lo stesso problema — rendere governabile un’organizzazione complessa — con due strumenti diversi: Beer con un’architettura di livelli ricorsivi, Forrester con stock, flow e simulazione. Vederli affiancati aiuta a capire che la cibernetica, applicata alle organizzazioni, non ha prodotto un metodo solo, ma una famiglia.

L’intuizione

Primo angolo — la vasca da bagno: stock e flow

La system dynamics riduce qualunque sistema dinamico a due tipi di variabile, e una sola immagine basta a tenerli distinti: una vasca da bagno.

Un stock (accumulo, o livello) è ciò che si accumula nel tempo. È il livello dell’acqua nella vasca. Nel mondo reale è l’inventario di un magazzino, la popolazione di una città, il saldo di un conto corrente, la quantità di anidride carbonica in atmosfera, le righe di codice di un progetto. Lo stock è la memoria del sistema: descrive il suo stato in un dato istante, e persiste anche se tutto il resto si ferma. Chiudi la fabbrica e il magazzino resta pieno. Lo stock è ciò che puoi fotografare.

Un flow (flusso, o tasso) è ciò che riempie o svuota uno stock per unità di tempo. È il rubinetto e lo scarico. Nel mondo reale è la produzione che entra in magazzino e le spedizioni che escono, le nascite e le morti per la popolazione, le entrate e le uscite per il conto corrente. Il flow esiste solo come tasso, misurato su un intervallo: non puoi fotografare “tre litri al minuto”, lo puoi solo misurare lasciando scorrere il tempo.

Figura in preparazione

fig-1: la metafora della vasca da bagno. Una vasca con il livello dell’acqua etichettato “STOCK (livello, accumulo)”, un rubinetto in alto con freccia spessa etichettata “FLOW in (inflow)”, uno scarico in basso etichettato “FLOW out (outflow)”. A lato l’equazione “stock(t) = stock(0) + integrale del flusso netto”. Stile editorial illustration didattico.

La chiave intuitiva, quella che vale tutto il capitolo: lo stock è l’integrale del flusso netto. In ogni istante,

$\text{stock}(t) = \text{stock}(0) + \int_0^t \big(\text{flusso\_in}(t') - \text{flusso\_out}(t')\big)\, dt'$

In parole povere, questo dice che il livello dell’acqua adesso è il livello di partenza più tutta l’acqua che è entrata meno tutta quella che è uscita, sommata istante per istante. La stessa relazione, scritta come tasso di cambiamento:

$\frac{d(\text{stock})}{dt} = \text{flusso\_in} - \text{flusso\_out}$

cioè: la velocità con cui il livello cambia è il flusso netto. Qui $\frac{d(\text{stock})}{dt}$ è la derivata dello stock rispetto al tempo, la sua pendenza istantanea; il resto sono i due flussi. Questo collega la system dynamics in modo diretto al capitolo equazioni differenziali a intuizione della Parte VI: un modello di system dynamics, sotto il cofano, è un sistema di equazioni differenziali ordinarie. Che lo stock sia l’integrale del flusso netto non è un’analogia né una scelta di notazione: è la definizione stessa di integrale applicata a questo dominio. È un legame della classe teorema.

Da questa relazione discendono due conseguenze che non sono ovvie e che il resto del capitolo userà di continuo. Primo: lo stock non può saltare. È un integrale; cambia in modo continuo, e per cambiare bruscamente servirebbe un flusso infinito. Un flusso invece può cambiare di colpo. Secondo: lo stock e il flusso hanno comportamenti diversi nel tempo, e leggere l’uno come se fosse l’altro è l’errore percettivo più comune di tutti — ci torniamo nella sezione “Dove si rompe”.

Un test rapido per distinguere uno stock da un flow, quando non è ovvio: il test dell’istantanea. Immagina di fermare il tempo, di congelare il sistema in un istante. Cosa ha ancora senso misurare? Il livello dell’acqua: sì, ha senso, c’è — è uno stock. Il rubinetto a “tre litri al minuto”: no, se il tempo è fermo non scorre niente, “al minuto” non significa nulla — è un flow. Lo stesso per gli agenti: a tempo fermo, “100 token rimasti nel budget” ha senso, è uno stock; “consumo 20 token al turno” non ha senso a tempo fermo, è un flow. Il test dell’istantanea sembra banale, ma risolve la quasi totalità dei dubbi di classificazione, ed è il primo gesto da fare quando si imposta un modello.

C’è anche un terzo fatto, più sottile, che vale la pena nominare ora. Lo stock disaccoppia l’inflow dall’outflow. In un mondo senza accumuli, ciò che entra deve uscire subito, e i due tassi sono incollati l’uno all’altro. Lo stock spezza questo legame: il magazzino può ricevere merce a un ritmo e spedirla a un altro, e la differenza si accumula. Questo disaccoppiamento è ciò che dà al sistema inerzia e memoria — e, insieme ai ritardi, è la ragione per cui un sistema con stock può oscillare mentre un sistema senza stock no. Ogni volta che in un sistema vedi qualcosa che “assorbe gli shock”, che fa da cuscinetto, che ricorda — lì c’è uno stock. La cache di una pipeline, il buffer di una coda, il saldo di un budget: cuscinetti, cioè stock.

Conviene anche dire che lo stock non è solo materia. Si accumulano cose fisiche — acqua, merci, persone — ma anche informazione, fiducia, conoscenza, reputazione. La fiducia di un team in un agente è uno stock: si costruisce lentamente, un successo per volta, e può crollare in fretta dopo un errore grave. La conoscenza che un agente ha accumulato di un codebase è uno stock. Anche un’aspettativa — la domanda media percepita dal responsabile del magazzino — è uno stock: una media mobile è letteralmente l’integrale ritardato di un flusso di osservazioni. Riconoscere gli stock immateriali è dove la system dynamics smette di essere idraulica e diventa uno strumento per ragionare su organizzazioni e sistemi socio-tecnici.

Una nota terminologica per non perdersi tra le fonti. Forrester chiamava gli stock levels (livelli) e i flow rates (tassi); la letteratura più recente, a partire dal manuale di Sterman, dice stocks e flows. Sono gli stessi due oggetti. La parola “livello” rende bene l’immagine della vasca; la parola “stock” rende bene l’idea di scorta accumulata. Useremo stock e flow, ma se in un testo trovi “level” e “rate”, sai che si parla della stessa coppia.

Un trucco di controllo che la system dynamics insegna e che vale sempre la pena usare: guardare le unità di misura. Uno stock si misura in una quantità pura — litri, persone, token, dollari, task. Un flow si misura nella stessa quantità diviso un tempo — litri al minuto, persone all’anno, token al turno, task al secondo. Questa differenza nelle unità è una verifica gratuita: se in un modello una variabile che hai chiamato stock ha unità “qualcosa al secondo”, l’hai classificata male, è un flow. E quando in un’equazione sommi due termini, le loro unità devono coincidere — non puoi sommare litri e litri-al-minuto. Il controllo dimensionale scova una buona parte degli errori di modellazione prima ancora di far girare la simulazione, ed è la stessa disciplina che un fisico applica a una formula.

Secondo angolo — la mappa degli anelli: causal loop diagram

Sopra il livello stock/flow c’è un secondo linguaggio, più veloce e più qualitativo: il causal loop diagram (CLD, diagramma dei cicli causali). Mentre lo stock-flow descrive quanto e come si calcola, il CLD descrive quali cose si influenzano e in che verso.

Un CLD è un grafo, e si legge come una mappa di influenze. I nodi sono variabili. Le frecce sono relazioni causali, e ogni freccia porta una polarità:

• Polarità positiva (segnata +): se la causa cresce, l’effetto cresce, a parità di tutto il resto. Più conigli, più nascite di conigli.
• Polarità negativa (segnata -): se la causa cresce, l’effetto diminuisce. Più volpi, meno conigli.

Quando le frecce si chiudono in un anello, hai un feedback loop. E qui sta l’idea centrale del CLD: ogni anello si classifica in due specie, e la specie si determina con una regola di conteggio semplice — conta i segni negativi lungo il giro.

• Un loop di rinforzo, marcato R, ha un numero pari di link negativi (incluso lo zero). Si auto-amplifica: un cambiamento iniziale viene rilanciato e ingrandito a ogni giro. È il motore della crescita esponenziale, ma anche del collasso esponenziale. Esempi: l’interesse composto su un conto, il contagio di un’epidemia nelle prime fasi, il passaparola.
• Un loop di bilanciamento, marcato B, ha un numero dispari di link negativi. Si auto-corregge: resiste al cambiamento, riporta il sistema verso un obiettivo. È il motore dell’avvicinamento a un setpoint. Esempi: il termostato, il riempimento di un bicchiere mentre guardi quanto manca, la fame che ti porta a mangiare.

Perché la regola del conteggio funziona, in due righe di intuizione. Segui un cambiamento lungo l’anello: ogni link + lo lascia nello stesso verso, ogni link - lo ribalta. Se torni al punto di partenza con un numero pari di ribaltamenti, il cambiamento è tornato nello stesso verso in cui era partito — e quindi si rinforza. Se i ribaltamenti sono dispari, torna rovesciato — e quindi si oppone a sé stesso, cioè si bilancia. Provalo sull’esempio del termostato: più temperatura nella stanza (partenza), più scarto sopra il setpoint? No — -: più temperatura, meno scarto da colmare. Più scarto, più riscaldamento? Qui dipende da come orienti la variabile; nel modo standard più riscaldamento alza la temperatura, +. Un solo - lungo il giro: numero dispari, loop B. Torna: il bilanciamento è ciò che riporta la stanza al setpoint.

Figura in preparazione

fig-2: due causal loop diagram affiancati. A sinistra un loop di rinforzo etichettato “R” con due variabili e frecce positive (esempio: “saldo conto” e “interessi”). A destra un loop di bilanciamento etichettato “B” con una freccia negativa (esempio: “temperatura stanza”, “scarto dal setpoint”, “riscaldamento”). Sotto, la regola: “pari negativi = R, dispari negativi = B”.

Il CLD richiama direttamente il capitolo feedback-loop: un loop R è feedback positivo, un loop B è feedback negativo, disegnati. La differenza di registro vale però la pena di essere detta. Il feedback-loop classico della cibernetica studia tipicamente un anello, ben definito, con il suo errore e il suo setpoint. Il CLD della system dynamics nasce per disegnare molti anelli intrecciati che competono fra loro, e per ragionare su quale loop domina il comportamento in una certa fase. Quasi nessun comportamento reale è prodotto da un solo loop. La crescita a S che vedremo fra poco è esattamente un loop R che domina all’inizio e un loop B che gli strappa il controllo quando il sistema si avvicina a un limite.

Un avvertimento da tenere a mente fin da subito: il CLD è uno strumento di comunicazione e di prima approssimazione, non un modello che si possa eseguire. Non distingue gli stock dai flow, non produce numeri, e — punto delicato — un CLD ben disegnato non dice ancora quale loop vince. Per quello serve lo stock-flow diagram con le sue equazioni. Il CLD è la mappa; lo stock-flow è il territorio calcolabile.

Terzo angolo — il punto di vista endogeno

C’è un terzo modo di entrare nella system dynamics, ed è meno una tecnica che un cambio di sguardo. Torniamo allo stabilimento della General Electric. I manager spiegavano il ciclo di assunzioni con una causa esterna: il mercato. Forrester mostra che la causa era interna: le regole di gestione dell’azienda. Questo spostamento — dal cercare la causa fuori al cercarla dentro — è il cuore della system dynamics, e si chiama punto di vista endogeno (endogeno: che ha origine dentro il sistema).

L’idea è questa. Quando un sistema mostra un comportamento dinamico — oscilla, cresce, crolla — la spiegazione di default è puntare il dito su uno shock esterno: il mercato, la concorrenza, la sfortuna. A volte è vero. Ma molto più spesso di quanto l’intuizione creda, il comportamento è generato dalla struttura interna del sistema: dai suoi stock, dai suoi anelli, dai suoi ritardi. Un sistema con i loop giusti oscilla anche se lo si stimola con un input perfettamente costante — l’abbiamo visto: la domanda del Beer Game è quasi piatta, eppure la catena oscilla.

La conseguenza pratica è potente. Se il comportamento è endogeno, allora la leva per cambiarlo è dentro, nella struttura, e non serve aspettare che il mondo esterno cambi. Se la tua pipeline agentica oscilla, la domanda da farsi non è solo “cosa è cambiato fuori” ma “quale anello interno, con quale ritardo, può generare questa oscillazione da solo”. Spostare lo sguardo da fuori a dentro è spesso metà della soluzione. È anche, di nuovo, la tesi di Forrester sui sistemi sociali: incolpiamo le cause esterne perché la struttura interna che genera il problema è invisibile all’intuizione.

L’iconografia: come si disegna un modello

Tra il CLD qualitativo e le equazioni nude c’è una notazione intermedia, lo stock-flow diagram, che la system dynamics ha standardizzato e che vale la pena saper leggere. È un piccolo alfabeto di quattro simboli.

Lo stock si disegna come un rettangolo: è la vasca, l’accumulo. Il flow si disegna come una freccia spessa che entra o esce dal rettangolo, con sopra una piccola icona a forma di valvola — la “valvola” è la decisione o il processo che regola il tasso. Una cloud (nuvola) chiude il flow quando la sua sorgente o il suo pozzo stanno fuori dal confine del modello e non interessa rappresentarli: l’acqua viene dalla nuvola, l’acqua va nella nuvola. Infine le frecce sottili (connettori di informazione) portano un valore — il livello di uno stock, un parametro — verso una valvola, e sono ciò che chiude i feedback loop: è la freccia sottile che dice alla valvola “regolati in base a quanto è pieno lo stock”.

Figura in preparazione

fig-3: l’alfabeto dello stock-flow diagram. Quattro elementi etichettati: un rettangolo “stock”, una freccia spessa con valvola “flow”, una nuvola “sorgente/pozzo fuori confine”, una freccia sottile “connettore di informazione”. Sotto, un esempio minimo che li combina: stock “popolazione” con inflow “nascite” e outflow “morti”, e una freccia sottile da “popolazione” verso la valvola “nascite”.

Questa iconografia non è decorazione: rende visibile a colpo d’occhio la distinzione che la mente fatica a tenere — i rettangoli sono accumuli, le valvole sono tassi — e mostra dove si chiudono gli anelli. È la grammatica che strumenti come STELLA e Vensim fanno disegnare trascinando icone sullo schermo.

Vale la pena vedere come si passa da un CLD qualitativo a uno stock-flow eseguibile, perché è il salto che separa “ho un’idea” da “ho un modello”. Si parte dal CLD e ci si fa una domanda per ogni variabile: questa cosa si accumula o è un tasso? La popolazione si accumula: è uno stock. Le nascite sono un tasso: sono un flow. La domanda smista ogni nodo del CLD in un rettangolo o in una valvola. Poi si guarda ogni freccia del CLD: una freccia che entra in una variabile-stock deve in realtà passare per una valvola — non si “aumenta uno stock” direttamente, lo si fa aumentando il suo inflow. Le frecce che restano sono connettori di informazione. Infine, per ogni valvola si scrive l’equazione: da quali stock e parametri dipende quel tasso. Quando ogni valvola ha la sua equazione e ogni stock il suo valore iniziale, il modello è eseguibile. Il CLD diceva che due cose si influenzano; lo stock-flow dice di quanto, e solo lui si può far girare.

La meccanica

Il ritardo, e perché è il vero cattivo della storia

Tra una causa e il suo effetto, nei sistemi reali, c’è quasi sempre un ritardo (delay). L’ordine che mandi al fornitore oggi arriva fra sei settimane. L’operaio che assumi oggi diventa pienamente produttivo fra mesi. L’investimento in formazione paga fra anni. Il ritardo ha due forme. C’è il ritardo di materiale: la cosa fisica impiega tempo a transitare — la merce in viaggio, l’acqua nei tubi. E c’è il ritardo di informazione: ci vuole tempo per percepire un segnale, mediarlo, fidarsene — ti accorgi che le vendite stanno calando solo dopo qualche settimana di dati, e ci metti ancora un po’ a crederci abbastanza da agire.

Una distinzione che conviene fissare: il ritardo non è una pausa morta in cui non succede niente. Durante un ritardo di materiale c’è uno stock — la merce in transito, gli ordini in coda — e durante un ritardo di informazione c’è un processo di mediazione, una media che si aggiorna lentamente. Il ritardo, in un modello di system dynamics, si rappresenta proprio così: con uno o più stock intermedi attraverso cui la cosa transita. Questo spiega anche perché un ritardo dia inerzia al sistema: dove c’è un ritardo c’è uno stock nascosto, e dove c’è uno stock c’è memoria.

Il ritardo è la sorgente principale del comportamento controintuitivo, e l’intuizione è questa. Un loop di bilanciamento senza ritardo si avvicina dolcemente al suo obiettivo: vedi lo scarto, lo correggi, lo scarto si riduce, ti fermi. Lo stesso identico loop con un ritardo significativo nell’anello di correzione produce overshoot e oscillazione. Il motivo: stai correggendo sulla base di un’informazione vecchia. Continui a spingere quando il sistema ha già raggiunto l’obiettivo, perché il segnale che ti direbbe di fermarti non è ancora arrivato. Superi il bersaglio. Poi te ne accorgi, correggi all’indietro, e per lo stesso motivo superi di nuovo dall’altra parte. Se il guadagno della correzione è troppo aggressivo rispetto alla lunghezza del ritardo, l’oscillazione invece di smorzarsi cresce, e il sistema diverge.

Questo è esattamente il contenuto del capitolo stabilità, ritardi, oscillazioni. La system dynamics non lo scopre: lo eredita dalla cibernetica e dalla teoria del controllo. Quello che fa è applicarlo dove nessuno lo aveva applicato prima — a una supply chain, a un mercato del lavoro aziendale, alla popolazione di una città — e mostrare che lì il ritardo fa esattamente lo stesso danno che fa in un servomeccanismo.

C’è una sottigliezza che vale la pena marcare. Il ritardo non rende solo il sistema più lento — quello sarebbe innocuo. Lo rende qualitativamente diverso: un loop B che senza ritardo converge dolcemente, con ritardo può oscillare, e con ritardo abbastanza grande rispetto al guadagno può divergere fino a rompere il sistema. Lo stesso anello, la stessa intenzione di chi lo governa, e tre comportamenti diversi a seconda di quanto è lungo il ritardo. È questo che rende il ritardo controintuitivo: chi corregge non sta sbagliando la direzione né l’intensità, sta solo reagendo a un’informazione vecchia — e basta quello a trasformare il controllo in caos. Per questo, davanti a un sistema che oscilla, la prima domanda del praticante di system dynamics non è “chi ha sbagliato” ma “dov’è il ritardo”.

I cinque comportamenti tipici

La system dynamics insegna a riconoscere un piccolo repertorio di “modi” dinamici. Sono pochi, e quasi ogni curva reale che incontrerai è una combinazione di questi. Saperli leggere è metà del mestiere.

Crescita esponenziale. Dominata da un loop R. Lo stock alimenta il proprio inflow: più popolazione, più nascite, più popolazione. Raddoppia in un tempo costante. Inganna perché all’inizio sembra quasi piatta, e quando “si vede” è già tardi — la mente, abituata alle rette, sottostima sistematicamente l’esponenziale. Un dettaglio utile: il tempo di raddoppio è all’incirca 70 diviso il tasso di crescita percentuale. Un debito che cresce del 7% l’anno raddoppia in dieci anni; una coda che cresce del 10% al minuto raddoppia in sette minuti. Tenere a mente questa regoletta è il modo più rapido per non lasciarsi sorprendere da un loop R.

Avvicinamento all’obiettivo (goal-seeking). Dominata da un loop B. Lo stock si avvicina a un setpoint, rapido all’inizio quando lo scarto è grande, sempre più lento man mano che lo scarto si riduce. È la curva del caffè che si raffredda verso la temperatura della stanza, o del magazzino che converge verso la scorta desiderata. Matematicamente, è un decadimento esponenziale dell’errore. Nota la simmetria con la crescita esponenziale: lì lo stock si allontana da dove parte, qui si avvicina a dove deve arrivare, e la differenza è solo il segno del feedback. Un loop di rinforzo allontana, un loop di bilanciamento avvicina; la matematica è quasi la stessa, capovolta.

Crescita a S (logistica). Un loop R domina presto, un loop B domina tardi. All’inizio il sistema cresce come un esponenziale; poi, avvicinandosi a un limite — la capacità di carico, la saturazione del mercato — il loop di bilanciamento prende il sopravvento e la crescita si appiattisce. La curva è una sigmoide. È la diffusione di una tecnologia, la crescita di una popolazione con risorse limitate. La crescita a S è il caso pulito in cui il limite viene percepito in tempo: il sistema rallenta prima di sfondarlo. È la stessa struttura dell’overshoot-and-collapse, meno il ritardo nella percezione del limite — ed è esattamente quel ritardo a separare un atterraggio morbido da uno schianto.

Overshoot-and-collapse. Comincia come una crescita a S, ma con una differenza crudele: il limite stesso è uno stock erodibile. La risorsa che sostiene la crescita viene consumata dalla crescita. Quando la risorsa crolla, lo stock che ci si appoggiava crolla con lei. Perché succeda l’overshoot — cioè perché il sistema superi il limite invece di fermarsi — serve un ritardo nella percezione del limite: il sistema non si accorge in tempo di aver sfondato. È lo scenario centrale dei modelli mondiali di cui parleremo fra poco. Un esempio concreto e piccolo: una popolazione di cervi su un’isola con erba limitata. La popolazione cresce (loop R), l’erba cala. Se i cervi percepissero subito la scarsità, la crescita si fermerebbe per tempo e si avrebbe una crescita a S. Ma la natalità di oggi dipende dalla nutrizione di mesi fa — c’è un ritardo. Così i cervi continuano a riprodursi sulla base di un’abbondanza che non c’è già più, l’erba viene rasa, e quando la fame colpisce la popolazione non si stabilizza: crolla, e con essa la possibilità che l’erba si rigeneri. La firma di questo modo è sempre la stessa: crescita, limite erodibile, ritardo nella percezione.

Oscillazione. Un loop B con ritardo. Il magazzino che oscilla sopra e sotto il livello desiderato, il ciclo di assunzioni e licenziamenti della General Electric, la dinamica predatore-preda di volpi e conigli. L’oscillazione è il modo più frainteso dei cinque, perché sembra chiedere una causa esterna ritmica — qualcosa che “batte il tempo” — mentre invece nasce tutta da dentro: basta un loop di bilanciamento e un ritardo, e il sistema si dà un ritmo da solo. Quando vedi qualcosa oscillare con regolarità, la prima ipotesi non è “c’è un orologio esterno”, è “c’è un anello correttivo con un ritardo”.

Figura in preparazione

fig-4: cinque piccoli grafici tempo-valore affiancati, ciascuno con titolo. “Crescita esponenziale”, “Avvicinamento all’obiettivo”, “Crescita a S”, “Overshoot-and-collapse”, “Oscillazione”. Ogni grafico mostra la curva caratteristica e, sotto, quale combinazione di loop la genera (R, B, R+B).

Una raccomandazione su come usare questo repertorio. Non serve memorizzare cinque curve: serve interiorizzare la regola generatrice. Ogni modo nasce da una combinazione di tre ingredienti — quali loop ci sono (R, B, o entrambi), se c’è un limite erodibile, se c’è un ritardo. Cinque modi sono solo le combinazioni che si incontrano più spesso; padroneggiare gli ingredienti permette di leggere anche le curve composte, quelle che non assomigliano perfettamente a nessuno dei cinque casi-tipo.

Vale la pena vedere i primi due in formula, perché chiariscono come i loop diventano matematica. La crescita esponenziale nasce quando l’inflow è proporzionale allo stock stesso: $\frac{d S}{dt} = r\, S$, dove $S$ è lo stock e $r$ è un tasso di crescita costante. In parole povere: più ce n’è, più ne nasce, in proporzione. La soluzione è $S(t) = S(0)\, e^{r t}$ — l’esponenziale. L’avvicinamento all’obiettivo nasce invece quando l’inflow è proporzionale allo scarto dall’obiettivo: $\frac{d S}{dt} = k\,(S^* - S)$, dove $S^*$ è il setpoint e $k$ regola quanto in fretta si corregge. In parole povere: più sei lontano dall’obiettivo, più forte spingi; quando ci arrivi, ti fermi. La soluzione è uno scarto che decade esponenzialmente. La differenza fra i due è solo cosa moltiplica il tasso: lo stock stesso (loop R, esplode) oppure lo scarto dall’obiettivo (loop B, converge). La crescita a S è la somma dei due: un termine $r S$ che domina quando $S$ è piccolo, e un termine che frena quando $S$ si avvicina alla capacità.

Il punto pedagogico di Forrester è qui. Dato un causal loop diagram, prevedere a mente quale di questi cinque modi emergerà è difficile, e diventa praticamente impossibile quando i loop sono molti. La simulazione lo rende ovvio. E il modo che emerge dipende da quale loop domina — una dominanza che può cambiare nel tempo (si parla di loop dominance shift): la crescita a S è letteralmente il passaggio di consegne dal loop R al loop B.

Il loop dominance shift merita un’ultima riga, perché è ciò che rende i sistemi reali insidiosi. Un sistema che per mesi cresce come un esponenziale rassicurante può, senza nessun cambiamento esterno, passare di colpo sotto il controllo di un loop di bilanciamento o di una risorsa che si esaurisce — e cambiare comportamento da un giorno all’altro. Non è successo niente fuori; è solo che un anello che era marginale è diventato dominante. Chi osserva il sistema vede una “rottura improvvisa” e cerca una causa esterna; chi conosce la system dynamics sa che il cambio di regime era scritto nella struttura fin dall’inizio, in attesa che le grandezze in gioco lo attivassero.

C’è un uso diagnostico di questo repertorio che vale per chi guarda un sistema reale. Davanti a una curva — il grafico di una metrica nel tempo — la system dynamics insegna a chiedersi: a quale dei cinque modi assomiglia? Se è una crescita esponenziale, cerca il loop R che si auto-alimenta. Se converge a un livello, cerca il loop B e il suo obiettivo. Se è una S, cerca entrambi e il limite che li separa. Se oscilla, cerca un loop B e il ritardo nascosto. Se cresce e poi crolla, cerca un loop R e una risorsa erodibile. La curva è un indizio sulla struttura: il modo dinamico restringe drasticamente le ipotesi su quali anelli ci sono sotto. È un ragionamento all’indietro — dal comportamento alla struttura — e funziona perché i modi sono pochi.

Come gira un modello, passo per passo

Sotto il cofano, far girare un modello di system dynamics significa integrare numericamente il suo sistema di equazioni differenziali. Lo schema più semplice — il metodo di Euler — in pseudocodice:

stock = stock_iniziale
t = 0
finché t < t_finale:
    inflow  = funzione_di(stock, parametri, t)   # i flussi dipendono
    outflow = funzione_di(stock, parametri, t)   # dallo stato corrente
    flusso_netto = inflow - outflow
    stock = stock + flusso_netto * dt            # integrazione: un passo
    t = t + dt

Riga per riga. Si parte da un valore iniziale dello stock. A ogni passo si calcolano i flussi nel loro valore corrente: e qui sta il feedback, perché i flussi sono funzione dello stock stesso — l’inflow di nascite dipende da quanta popolazione c’è ora. Si calcola il flusso netto. Lo si moltiplica per il passo temporale dt e lo si somma allo stock: questa moltiplicazione-e-somma è l’integrazione, l’approssimazione discreta dell’integrale visto sopra. Si avanza il tempo e si ripete. Strumenti reali usano integratori più precisi di Euler (per esempio Runge-Kutta), ma l’idea è questa: il calcolatore traccia, passo dopo passo, le conseguenze di interazioni che la mente non riesce a seguire. È esattamente il rimedio che Forrester proponeva.

Un dettaglio che separa un modello sensato da uno rotto: la scelta del passo dt. Se dt è troppo grande rispetto ai tempi caratteristici del sistema — i ritardi più corti, i tempi di svuotamento degli stock più rapidi — l’integrazione di Euler produce oscillazioni che non esistono nel sistema reale, artefatti puramente numerici. La regola pratica è tenere dt ben più piccolo del ritardo più breve presente nel modello. È una trappola concreta: chi modella una pipeline agentica con un passo da un minuto mentre il sistema ha ritardi da pochi secondi vedrà oscillare il modello, e rischierà di credere che oscilli la pipeline.

Perché l’intuizione fallisce: la tesi di Forrester

Vale la pena fermarsi sul perché esatto per cui tutto questo è difficile, perché è il cuore del lascito di Forrester. Nel paper del 1971 lui lo dice senza giri: “the human mind is not adapted to interpreting how social systems behave” — la mente umana non è adatta a interpretare come si comportano i sistemi sociali. La sua diagnosi ha tre parti.

Primo: i sistemi sociali — e, aggiungiamo noi, i sistemi socio-tecnici con AI — appartengono alla classe dei multi-loop nonlinear feedback systems, sistemi con molti anelli di retroazione intrecciati, non lineari. L’evoluzione non ci ha mai chiesto di simulare mentalmente sistemi del genere; la nostra intuizione si è formata su catene causa-effetto corte e locali.

Secondo: di fronte a un sintomo, la mente cerca la causa vicino, nello spazio e nel tempo. Trova qualcosa di plausibile lì accanto e lo elegge a causa. Ma in un sistema con feedback e ritardi la vera causa può stare lontana — un altro anello, settimane prima — e ciò che si trova vicino è spesso solo un altro effetto dello stesso meccanismo, non la causa. Si scambia una correlazione locale per una causa.

Terzo, e più scomodo: i sistemi con feedback hanno pochi punti in cui un intervento conta davvero, dei “punti di leva”. L’intuizione spesso li individua bene — su quello la mente non è cieca. Ma poi spinge la leva nella direzione sbagliata, perché si aspetta che il sistema reagisca come una catena corta, e il sistema invece reagisce come un anello. Da qui un’osservazione che Forrester ripete: una politica che migliora le cose nel breve periodo è spesso la stessa che le degrada nel lungo. Il sollievo immediato e il danno differito hanno la stessa origine, e il ritardo tra i due nasconde il legame.

La conclusione operativa è il manifesto della system dynamics: poiché la mente non riesce a tracciare queste interazioni, serve un modello esplicito, scritto in modo non ambiguo e fatto girare da un calcolatore. Non perché il modello sia infallibile — non lo è — ma perché rende le assunzioni visibili, testabili, e traccia le conseguenze in modo affidabile dove la mente improvvisa. È un’affermazione sulla pratica, non sulla metafisica: meglio un modello modesto ed esplicito che un modello mentale grandioso e implicito.

C’è un punto che vale la pena difendere dall’obiezione facile. Si potrebbe dire: “ma anche il modello parte da assunzioni umane, quindi non aggiunge niente”. Non è così, e la differenza è precisa. Un modello mentale e un modello esplicito possono partire dalle stesse assunzioni; ciò che cambia è cosa succede dopo le assunzioni. La mente, date le assunzioni, deve dedurre il comportamento — e qui sbaglia, perché tracciare molti anelli con ritardi è oltre la sua portata. Il calcolatore, date le stesse assunzioni, le esegue senza errori di deduzione. Il modello non rende le assunzioni più vere; rende le conseguenze delle assunzioni affidabili. È una divisione del lavoro: all’essere umano il giudizio su cosa mettere nel modello, al calcolatore il calcolo di cosa ne segue.

Il ciclo di modellazione

Costruire un modello di system dynamics non è scrivere equazioni dal nulla: è un ciclo, e conoscerne i passi aiuta anche solo a fare un modellino veloce per un problema di lavoro.

Si parte dal problema, non dal sistema. Non “modelliamo l’azienda”, ma “perché le scorte oscillano con periodo di tre anni”: un comportamento preciso, osservato, da spiegare. Forrester insisteva che senza un problema definito il modello si gonfia e non spiega niente.

Secondo: si traccia il comportamento di riferimento — il grafico nel tempo della variabile che ci preoccupa, com’è stato e come temiamo che sarà. È il bersaglio: il modello, alla fine, dovrà generare una curva di quel tipo.

Terzo: si ipotizza la struttura. Quali sono gli stock (cosa si accumula)? Quali i flow che li riempiono e svuotano? Quali i ritardi? Quali anelli si chiudono? Spesso si parte da un CLD qualitativo e lo si traduce in stock-flow.

Quarto: si scrivono le equazioni per ogni flow — come dipende dagli stock e dai parametri — e si simula. Il modello produce una curva.

Quinto: si confronta la curva con il comportamento di riferimento. Se non somiglia, la struttura ipotizzata è incompleta o sbagliata: si torna al terzo passo. Se somiglia, si passa a testare le politiche: cosa succede se cambio questo parametro, se accorcio quel ritardo, se aggiungo quell’anello?

Il punto da non perdere: il successo non è “il modello indovina i numeri”, è “il modello genera lo stesso tipo di comportamento a partire da una struttura plausibile, e quindi possiamo usarlo per ragionare sulle leve”. È lo spostamento dal fitting alla spiegazione strutturale già richiamato nel contesto storico.

Vale anche la pena dire cosa non è questo ciclo: non è un processo che si fa una volta e si archivia. Un modello è uno strumento di pensiero che si tiene vivo. Quando il sistema reale fa qualcosa che il modello non prevedeva, non è il sistema a sbagliare — è il modello a essere incompleto, e quel disaccordo è informazione preziosa: indica un anello mancante o un ritardo non considerato. I modelli migliori non sono quelli che azzeccano tutto al primo colpo, ma quelli che vengono corretti abbastanza spesso da restare aderenti al sistema che descrivono. Anche un modellino di trenta righe per una pipeline agentica segue questa regola: lo si aggiorna quando la pipeline sorprende.

Esempi

Esempio numerico — la vasca che continua a salire

Una vasca contiene 100 litri. Per 10 minuti il rubinetto versa 8 litri al minuto e lo scarico ne fa uscire 5. Il flusso netto è $8 - 5 = +3$ litri al minuto, costante. Dopo 10 minuti la vasca contiene $100 + 3 \times 10 = 130$ litri. Fin qui niente di strano.

Ora il colpo di scena, quello su cui quasi tutti sbagliano. Al minuto 10 chiudi un po’ il rubinetto: l’inflow scende da 8 a 6 litri al minuto, e ci resta. Domanda: la vasca, dopo il minuto 10, sale o scende?

L’istinto di molti è “il rubinetto è calato, quindi la vasca cala”. Sbagliato. L’inflow è sceso, ma è ancora 6, e l’outflow è 5. Il flusso netto è ancora positivo, $6 - 5 = +1$. La vasca continua a salire, solo più lentamente, di 1 litro al minuto invece di 3. Lo stock cresce finché il flusso netto è positivo, e smette di crescere solo quando il flusso netto tocca lo zero — non quando l’inflow tocca il suo massimo. Lo stock raggiungerà il massimo, e comincerà a calare, soltanto se l’inflow scendesse sotto 5. Tenere distinti “il flusso sta calando” e “lo stock sta calando” è la lezione numero uno, e l’esempio numerico la rende inevitabile.

Questo esempio è volutamente banale come scenario, ma il punto che dimostra non lo è affatto, e il modo migliore per fissarlo è seguire i numeri. Messa in tabella, minuto per minuto attorno al cambio:

minuto	inflow	outflow	flusso netto	livello vasca
8	8	5	+3	124
9	8	5	+3	127
10	8	5	+3	130
11	6	5	+1	131
12	6	5	+1	132
13	6	5	+1	133

Si vede il punto a occhio: al minuto 10 l’inflow crolla da 8 a 6 — una discontinuità netta nella colonna del flusso — ma la colonna del livello non ha nessuna discontinuità. Cambia solo la pendenza: prima saliva di 3 per minuto, ora sale di 1. Lo stock è un integrale, e l’integrale non copia la forma del suo integrando: la liscia. Questa è anche la dimostrazione, in numeri, del fatto che lo stock non può saltare visto nell’intuizione.

Esempio in codice — la coda di task che esplode

Un orchestratore di agenti mantiene una coda di task. La coda è uno stock. Un agente “planner” decompone obiettivi in sottotask e li mette in coda: è l’inflow. Gli esecutori prendono task dalla coda e li completano: è l’outflow. Modelliamolo con lo schema di Euler.

coda = 0            # stock: task in attesa
dt = 1              # un passo = un secondo
storico = []

for t in range(600):                  # 10 minuti
    inflow  = 12                       # il planner genera 12 task/s
    capienza = 10                      # gli esecutori ne smaltiscono 10/s
    outflow = min(capienza, coda / dt + inflow)  # non si svuota oltre il vuoto
    coda = coda + (inflow - outflow) * dt
    storico.append(coda)

print(storico[-1])   # la coda non si stabilizza: diverge

Finché l’inflow (12 task al secondo) supera stabilmente la capacità di outflow (10 al secondo), il flusso netto resta positivo e la coda diverge in linea retta: dopo 10 minuti sono circa 1200 task in attesa. Non è un bug nel codice degli agenti. È la stessa matematica della vasca che trabocca: nessun accumulo regge un inflow strutturalmente più grande dell’outflow. La leva non è “fai correre più in fretta gli esecutori” una volta sola: è riportare il flusso netto a zero o sotto, alzando la capacità oppure mettendo un freno al planner. Un piccolo modello come questo, fatto girare prima del deploy, mostra il problema in trenta righe; in produzione lo stesso problema si manifesta come una coda che cresce per ore prima che qualcuno se ne accorga.

Vale la pena notare cosa rende questo esempio diverso da una semplice disuguaglianza. Si potrebbe dire “ovvio, se entra più di quanto esce, si accumula” — e fermarsi lì. Ma il valore del modello sta in cosa permette di fare dopo. Con il modello in mano puoi chiudere il loop di feedback: e se il planner rallentasse quando la coda è lunga? Aggiungi una riga — l’inflow diventa funzione decrescente della coda — e il sistema da divergente diventa goal-seeking, la coda si stabilizza su un livello. E se quel feedback avesse un ritardo, perché il planner vede la lunghezza della coda con qualche secondo di latenza? Aggiungi il ritardo e la coda, invece di stabilizzarsi, oscilla. Tre righe di modello, tre comportamenti qualitativamente diversi. Questo è ciò che un modello dà e una disuguaglianza no: la possibilità di provare le politiche prima di scriverle nel codice vero.

Esempio con ritardo — il magazzino che oscilla

Riprendiamo lo stabilimento della General Electric, in versione minima. Un magazzino (stock) ha una scorta desiderata di 100 unità. Ogni settimana il responsabile guarda lo scarto tra scorta reale e desiderata e ordina per colmarlo. Se non ci fosse ritardo, il magazzino convergerebbe dolcemente a 100: classico avvicinamento all’obiettivo, un loop B pulito.

Mettiamo ora un ritardo di consegna di tre settimane: l’ordine fatto oggi arriva tra tre settimane. Il responsabile vede la scorta sotto 100, ordina per colmare. La settimana dopo la scorta è ancora bassa — l’ordine è in viaggio, non è arrivato — e lui ordina di nuovo. E ancora la terza settimana. Quando finalmente la prima ondata di ordini arriva, sullo stock si rovesciano tre settimane di ordini accumulati: la scorta sfonda 100 e va a 160. Adesso c’è troppo: il responsabile smette di ordinare, anzi taglia. Ma anche il taglio impiega tre settimane a farsi sentire, e nel frattempo la scorta crolla sotto 100 dall’altra parte. Il magazzino oscilla — 160, 50, 130, 70 — attorno a un obiettivo verso cui, senza ritardo, sarebbe arrivato liscio. Nessuno è incompetente. Il ritardo da solo, dentro un loop B altrimenti sano, ha trasformato la convergenza in oscillazione. È, in piccolo, il ciclo di tre anni che Forrester trovò nei conti della General Electric.

Il difetto profondo, qui, è che il responsabile non tiene conto degli ordini già in viaggio. Ordina per coprire lo scarto visibile, ignorando che tre settimane di ordini stanno arrivando. È un errore di percezione preciso e ricorrente: in un sistema con un ritardo c’è uno stock nascosto — la merce in transito — che va contato. Chi modella la situazione lo vede subito; chi decide a sensazione lo dimentica, e il dimenticarlo è la causa dell’oscillazione. La correzione strutturale non è “ordina meglio”, è “rendi visibile lo stock in transito e sottrailo dallo scarto da colmare”. Di nuovo: la leva è strutturale, non motivazionale.

Esempio scenario — il Beer Game e l’effetto frusta

All’inizio degli anni Sessanta, al MIT, viene creato un gioco da tavolo che è ancora oggi una delle simulazioni più usate nelle scuole di management: il Beer Distribution Game (il “Beer Game”), poi reso celebre da John Sterman, il professore della Sloan School che dirige il gruppo di system dynamics del MIT. Quattro giocatori, o quattro squadre, occupano i quattro anelli di una catena di distribuzione della birra: dettagliante, grossista, distributore, fabbrica. Ognuno vede solo gli ordini che gli arrivano dal cliente immediatamente a valle e decide quanto ordinare a monte. Non possono parlarsi. Tra l’ordine e la consegna c’è un ritardo di alcune settimane.

La domanda del cliente finale, nel gioco, è quasi piatta: cambia una volta sola, di poco, e poi resta costante. Eppure, partita dopo partita, succede sempre la stessa cosa. Il dettagliante, vedendo le scorte calare per via del ritardo di consegna, ordina un po’ troppo. Il grossista vede arrivare quell’ordine gonfiato, e per coprirsi ne ordina ancora di più. Il distributore amplifica ancora. Quando l’onda arriva alla fabbrica, una variazione minuscola della domanda reale è diventata un’oscillazione violenta della produzione e delle scorte. È il bullwhip effect, l’effetto frusta: la variabilità di ogni stadio a monte è sempre maggiore di quella dello stadio a valle. Ogni anello ha il suo stock di scorte e i suoi ordini in transito; i ritardi di informazione e di materiale fanno sì che ciascuno reagisca in eccesso a un segnale che non capisce. Era una delle scoperte di Industrial Dynamics nel 1961. La lezione del Beer Game è netta e scomoda: l’oscillazione è una proprietà strutturale della catena, non la colpa di giocatori incapaci. Cambia i giocatori, mettici esperti: l’onda si ripresenta. Per toglierla devi cambiare la struttura — condividere l’informazione sulla domanda reale, ridurre i ritardi — non i giocatori.

Il Beer Game ha un valore che va oltre la supply chain, e riguarda chi orchestra agenti. Una catena di sottoagenti che si passano task — un planner che alimenta degli esecutori che alimentano dei verificatori — è strutturalmente una supply chain: ogni anello ha la sua coda (uno stock), riceve “ordini” dal nodo a monte, e c’è un ritardo prima che un task completato torni indietro come segnale. Se ogni sottoagente reagisce solo a quello che vede dal vicino — più richieste arrivano, più ne genera per coprirsi — il bullwhip si ripresenta: la variabilità del carico si amplifica risalendo la catena, e i nodi a monte oscillano tra sovraccarico e inattività. La contromisura è la stessa che funziona nelle supply chain reali: dare a ogni nodo visibilità sulla domanda vera a valle, non solo sull’ordine del vicino, e accorciare i ritardi del segnale di completamento.

Le tre applicazioni storiche e gli strumenti

I tre libri di Forrester sono anche tre prove di scala progressiva del metodo: l’impresa, la città, il pianeta. Vale la pena vedere cosa ognuno ha modellato, perché definiscono insieme la portata e i limiti della system dynamics.

Industrial Dynamics (1961). Il primo libro modella l’impresa come sei reti accoppiate: cinque reti di “cose” che fluiscono — materiali, ordini, denaro, attrezzature capitali, personale — e una sesta, la rete dell’informazione, che fa da tessuto connettivo tra le altre cinque. Ogni rete ha i suoi stock e i suoi flow; sono i ritardi di informazione a far sì che le sei reti, accoppiate, generino instabilità anche quando ogni singola decisione, presa da sola, sembra ragionevole. Il bullwhip effect, l’effetto frusta visto nel Beer Game, è la dimostrazione più nota di questa instabilità strutturale: trent’anni dopo, nel 1997, un articolo della MIT Sloan Management Review lo rimette al centro dell’attenzione manageriale, segno che la scoperta di Forrester non era folklore.

L’idea che vale la pena estrarre da Industrial Dynamics — e che si applica a qualunque sistema, non solo a un’impresa — è che la rete dell’informazione non è neutra. I cinque flussi fisici di un’azienda potrebbero anche essere puliti; è il modo in cui l’informazione su di essi viene raccolta, mediata, ritardata e usata per decidere a generare il comportamento. Tradotto per chi costruisce sistemi con agenti: la maggior parte dei comportamenti dinamici fastidiosi non vive nei flussi di lavoro reali, ma nei segnali — nelle metriche con cui li osservi, nei ritardi con cui quei segnali ti arrivano, nelle soglie con cui ci reagisci. È un invito a guardare la rete di informazione del proprio sistema con lo stesso sospetto con cui Forrester guardava quella della General Electric.

Urban Dynamics (1969). Il secondo libro nasce da un incontro: l’ex sindaco di Boston John Collins diventa vicino di ufficio di Forrester al MIT. Il modello rappresenta la città come stock di alloggi, di imprese e di popolazione divisa in fasce di reddito. Il risultato che fa discutere: nel modello, alcune politiche di aiuto urbano apparentemente ovvie — per esempio costruire molte case popolari a basso reddito — peggiorano la situazione nel lungo periodo, perché attraggono popolazione povera e occupano suolo che avrebbe potuto ospitare attività generatrici di lavoro. È un risultato controverso, contestato a lungo da urbanisti ed economisti. Va preso per quello che è: un’illustrazione vivida della tesi sulla controintuitività, non un verdetto urbanistico definitivo.

World Dynamics (1971) e The Limits to Growth (1972). Il terzo salto di scala porta al modello dell’intero pianeta. Nasce da un incarico: il Club di Roma chiede a Forrester un modello che colleghi crescita della popolazione, industrializzazione e ambiente. Forrester risponde con World2, poi il team di Donella Meadows lo raffina in World3. La sezione “Dove si rompe” entra nei dettagli, perché World3 è anche il caso che insegna di più sui limiti del metodo. Qui basti dire la portata: The Limits to Growth diventa uno dei libri più venduti e più discussi del secolo sul rapporto fra economia e ambiente, citato e attaccato per cinquant’anni. Pochi modelli costruiti con stock e flow hanno avuto un impatto pubblico comparabile — e pochi hanno offerto un caso di studio altrettanto chiaro su cosa un modello di system dynamics può e non può promettere.

Tre libri, tre scale: l’impresa, la città, il pianeta. La progressione mostra la forza del metodo — lo stesso linguaggio di stock, flow e loop regge a ogni scala — e ne mostra anche il rischio: più il sistema modellato è grande e aggregato, più le conclusioni vanno maneggiate con prudenza. È una tensione che il capitolo non risolve per decreto, ma che chiede di tenere sempre presente.

La system dynamics non è rimasta ferma agli anni Settanta. Esiste una società scientifica dedicata, la System Dynamics Society, una rivista, e il metodo è insegnato nelle scuole di management e di ingegneria; Business Dynamics di John Sterman (2000) è il manuale che ha rinnovato il campo per la generazione successiva. Negli usi recenti il metodo si applica a epidemiologia, politica sanitaria, sostenibilità, dinamica di progetti software. Resta uno strumento di nicchia rispetto al machine learning o all’ottimizzazione, ma il suo vocabolario — stock, flow, loop, delay — è entrato nel linguaggio comune del “systems thinking” ben oltre i confini della modellazione formale.

Gli strumenti. Senza un calcolatore, la system dynamics resterebbe carta: un sistema di equazioni differenziali con decine di variabili non si integra a mano. La filiera degli strumenti racconta mezzo secolo di informatica applicata. Prima viene SIMPLE (acronimo di Simulation of Industrial Management Problems with Lots of Equations), scritto da Richard Bennett nel 1958. Subito dopo arriva DYNAMO (1959), il linguaggio in cui sono scritti i modelli di Industrial Dynamics, Urban Dynamics e World3: resta lo standard di fatto per oltre trent’anni. Negli anni Ottanta cambia tutto con l’interfaccia grafica: STELLA (Barry Richmond, High Performance Systems, 1985 — l’acronimo sta per Systems Thinking Experimental Learning Laboratory with Animation) fa costruire i modelli trascinando rettangoli e valvole sullo schermo, senza scrivere equazioni a mano. Seguono Vensim (Ventana Systems) e Powersim. Sotto il cofano, però, fanno tutti la stessa cosa che faceva DYNAMO e che fa lo pseudocodice di Euler visto sopra: integrazione numerica passo-passo di un sistema di ODE.

Applicazioni pratiche

Per chi costruisce sistemi con LLM e agenti, la system dynamics non è folklore da scuola di management. La distinzione stock/flow è prima di tutto uno schema mentale, e si applica con sorprendente precisione. Un avvertimento sulla classe di affermazione: quello che segue è un’analogia strutturale, un’applicazione di schema. Non c’è discendenza storica fra la system dynamics e il design degli agenti — Forrester non pensava agli LLM e i progettisti di harness non leggono Industrial Dynamics. Semplicemente la matematica degli accumuli e dei flussi è la stessa ovunque ci sia qualcosa che si accumula: vale per l’acqua in una vasca, per le scorte di un magazzino e per i token di una sessione, non perché questi siano “la stessa cosa”, ma perché condividono la stessa struttura formale. Tenere ferma questa distinzione — analogia strutturale, non filiazione — è ciò che rende l’applicazione onesta invece che suggestiva.

Il budget di token di una sessione è uno stock. Il consumo per turno è un flow in uscita; il refill — una nuova finestra, un nuovo budget concesso — è un flow in entrata. Ragionare su “quanto budget mi resta” (uno stock) è un’operazione diversa dal ragionare su “quanto consumo per turno” (un flow), e confondere i due porta a stime di costo sbagliate nello stesso identico modo in cui si sbaglia la vasca da bagno. L’errore tipico: vedere il consumo per turno calare e concludere che si è “al sicuro” sul budget. Falso, per lo stesso motivo della vasca: finché il consumo resta positivo il budget continua a scendere, e va a zero anche mentre il tasso di consumo diminuisce. La domanda giusta è sul livello dello stock, non sulla pendenza del flow.

La memoria di un agente è uno stock. L’ingestione di nuovo contesto è il suo inflow; l’oblio, la compaction, l’eviction sono i suoi outflow. Una memoria con inflow ma senza outflow cresce senza limite finché esplode — finché sfonda la finestra di contesto; una con outflow troppo aggressivo perde stato che sarebbe servito. Progettare la memoria di un agente è, letteralmente, bilanciare due flussi sopra uno stock. E qui la system dynamics suggerisce una domanda precisa che il design “a sensazione” non pone: qual è il tempo di residenza di un’informazione nella memoria? In un sistema stock-flow stazionario, il tempo medio che qualcosa passa nello stock è il rapporto tra il livello dello stock e il flusso che lo attraversa. Se la memoria contiene 50 elementi e ne entra ed esce 5 al turno, in media un elemento resta 10 turni prima di essere dimenticato. Sapere questo numero — e decidere se 10 turni sono giusti per il compito — è ingegneria; ignorarlo è sperare.

La coda di task di un orchestratore, come nell’esempio in codice, è uno stock con un inflow di generazione e un outflow di completamento: se l’inflow supera stabilmente l’outflow, diverge.

Il debito tecnico è forse l’esempio più puro, e quello dove l’errore stock-flow costa di più nella pratica. È uno stock: si accumula a ogni scorciatoia presa (inflow) e si riduce solo con refactoring deliberato (outflow). Una squadra che dice “questo sprint abbiamo introdotto poco debito” sta parlando dell’inflow, e si rassicura sul flow mentre lo stock — il debito totale accumulato — continua a salire, perché l’outflow di refactoring è fermo a zero. Il debito tecnico, inoltre, alimenta un loop di rinforzo sgradevole: più debito c’è, più lento è ogni cambiamento, più si è tentati di prendere altre scorciatoie per stare nei tempi, più debito si crea. Riconoscerlo come R spiega perché il debito raramente resta stabile da solo: o lo si gestisce con un outflow esplicito, o cresce in modo composto.

C’è poi un uso del causal loop diagram come strumento leggero di progettazione. Un sistema socio-tecnico con AI mescola persone, modelli e codice, ed è pieno di anelli di feedback che conviene disegnare prima di scrivere l’harness. Proviamo a disegnarne uno per esteso. Prendiamo un agente di coding che apre pull request, e seguiamo le variabili.

Più l’output dell’agente è percepito come buono, più cresce la fiducia del team; più fiducia, più ampia è la delega — gli si affidano task più grandi e con meno supervisione; più delega, più pull request l’agente produce. E qui il giro si chiude, in due modi opposti. Se la qualità tiene, più pull request approvate alimentano la percezione di qualità: è un loop di rinforzo R virtuoso, l’adozione che si auto-sostiene. Ma c’è un secondo anello: più pull request, più carico di review sul team; più carico, meno tempo per ogni review; meno tempo per review, più difetti che passano; più difetti in produzione, meno fiducia. Questo secondo giro è un loop di bilanciamento B che frena l’adozione. Quale dei due domina decide se il rollout dell’agente si stabilizza, esplode o oscilla — ed è esattamente il tipo di domanda che a mente non si risponde, mentre su un CLD disegnato si vede.

Figura in preparazione

fig-5: un causal loop diagram di un agente di coding in adozione. Variabili: “qualità percepita”, “fiducia del team”, “ampiezza della delega”, “pull request prodotte”, “carico di review”, “difetti in produzione”. Un loop marcato “R” (qualità percepita -> fiducia -> delega -> pull request -> qualità percepita) e un loop marcato “B” che passa per “carico di review” e “difetti in produzione”. Frecce con polarità + e - indicate.

Un esempio più semplice, sempre B: più errori l’agente commette in produzione, più si stringono le approvazioni manuali, che riducono gli errori. Anello sano — ma se le approvazioni introducono un ritardo (l’umano risponde domani, non subito), lo stesso B fa oscillare il sistema tra troppa e troppo poca autonomia, esattamente come il magazzino dell’esempio con ritardo.

Il guadagno di disegnare questi anelli prima di scrivere il codice è concreto. Un CLD costa dieci minuti e una lavagna; rivela se nel sistema che stai per costruire ci sono loop di rinforzo che possono scappare, o loop di bilanciamento la cui combinazione con un ritardo produrrà oscillazione. È molto più economico scoprire un loop pericoloso su una lavagna che scoprirlo in produzione come un costo che esplode a ondate. La system dynamics, in questo uso leggero, non chiede di costruire un modello simulabile: chiede solo di prendere l’abitudine di chiudere i cerchi a mano e contare le polarità prima di affidarsi a un sistema fatto di anelli che nessuno ha guardato come anelli.

E qui arriva la lezione più importante di Forrester per chi fa debug di pipeline agentiche. Una pipeline con retry, cache con TTL, rate limiter, sottoagenti e code è un multi-loop nonlinear feedback system con ritardi — la stessa classe di sistemi che Forrester diceva ingovernabili dalla sola intuizione. Il sintomo — la latenza che oscilla, il costo che esplode a ondate, il throughput che crolla periodicamente — si manifesta lontano, nel tempo e nello spazio, dalla sua causa: una soglia di retry, un TTL scelto male. La mente cerca la causa “vicino al sintomo” e trova un colpevole plausibile ma sbagliato — esattamente l’errore che Forrester descrive per i sistemi sociali. E la leva giusta è spesso controintuitiva: aumentare un timeout per ridurre il carico, rallentare un retry per aumentare il throughput, perché un retry aggressivo è un loop di rinforzo che amplifica la congestione che pretende di curare.

Da cui l’ultima applicazione, la più diretta: la simulazione come strumento. Quando un sistema agentico è abbastanza complesso, ragionare a mente sul suo comportamento dinamico non basta — è la tesi di Forrester, parola per parola. Un modello esplicito, anche minimo — un foglio di calcolo, uno script di trenta righe che integra le code, i ritardi e i tassi — rivela overshoot e oscillazioni prima che si manifestino in produzione. Si collega al capitolo modelli e sistemi della Parte IX: un modello esplicito e simulabile batte un modello mentale implicito proprio nel punto in cui l’intuizione fallisce.

Un caso concreto: il costo che esplode a ondate

Mettiamo insieme tutto in uno scenario realistico. Una pipeline agentica in produzione mostra un sintomo fastidioso: il costo in token, invece di essere stabile, esplode a ondate periodiche — tre ore tranquille, poi un picco, poi di nuovo calma. Il primo istinto del team è cercare la causa vicino al sintomo: “qualcuno lancia job pesanti ogni tre ore”. Si cerca un colpevole nel calendario dei cron. Non si trova niente.

Proviamo a leggerlo con gli occhi di Forrester. Identifichiamo gli stock: una cache di risultati intermedi, una coda di task. Identifichiamo i flow: richieste che entrano in cache, scadenze (TTL) che le tolgono; task generati, task completati. Identifichiamo i ritardi: il TTL della cache è proprio un ritardo, e così la latenza con cui un retry rimette in coda un task fallito. E identifichiamo i loop: quando la cache si svuota per scadenza, i cache miss aumentano, ogni miss costa una chiamata al modello, le chiamate rallentano, i timeout scattano, i timeout generano retry, i retry aumentano il carico — un loop di rinforzo che amplifica la congestione. Poi il carico cala, la cache si ripopola, e il ciclo ricomincia. Il picco di costo ogni tre ore non è un job esterno: è il periodo naturale di oscillazione di un loop B (la cache che si ripopola) accoppiato a un loop R (i retry) con un ritardo (il TTL). Lo scopre un modello stock-flow di venti righe; non lo scopre, in genere, la ricerca del colpevole nel calendario. E la leva giusta è controintuitiva: allungare il TTL della cache riduce i picchi di costo, perché smorza il loop che li genera.

Questo è il valore pratico della system dynamics per chi fa agent coding. Non serve costruire World3. Serve l’abitudine: davanti a un comportamento dinamico strano, chiediti quali sono gli stock, quali i flow, dove sono i ritardi, quali anelli si chiudono — e, se il sistema è abbastanza intrecciato, scrivi il modellino invece di fidarti dell’intuizione.

Una precisazione onesta sul costo. Costruire un modello, anche piccolo, richiede tempo: identificare gli stock, ipotizzare le equazioni, scegliere i parametri, far girare la simulazione. Non ogni problema lo merita — se il sistema ha un solo anello e nessun ritardo, l’intuizione basta, e tirare fuori la simulazione è spreco. La system dynamics ripaga il suo costo quando il sistema ha abbastanza feedback e ritardi da mettere in crisi l’intuizione: e questa, non a caso, è la condizione che caratterizza le pipeline agentiche serie. La regola pratica: se riesci a prevedere a mente con sicurezza come si comporterà il sistema, non ti serve il modello; se non ci riesci — e davanti a retry, cache, code e sottoagenti spesso non ci riesci — il modello è l’investimento che ti evita di scoprire il comportamento in produzione.

I punti di leva

C’è un’ultima idea che la system dynamics regala a chi progetta sistemi, e che Donella Meadows ha reso celebre con un saggio dal titolo “Leverage Points”: l’idea di punto di leva. In un sistema con molti anelli, non tutti i punti di intervento sono uguali. Alcuni sono leve deboli: ci spingi forte e il sistema si sposta di poco, perché un loop di bilanciamento riassorbe la spinta. Altri sono leve forti: un piccolo intervento nel posto giusto cambia il comportamento dell’intero sistema.

La gerarchia, in versione semplificata, va più o meno così. In fondo alla scala — leve deboli — ci sono i parametri: cambiare un numero, una soglia, una tariffa. È quello su cui l’intuizione si fionda sempre, ed è quasi sempre la leva più debole. Più in alto ci sono la forza dei loop di bilanciamento e la lunghezza dei ritardi: accorciare un ritardo o rinforzare un anello correttivo cambia il comportamento molto più che ritoccare un parametro. Più in alto ancora c’è la struttura degli anelli stessa: aggiungere o togliere un loop. E in cima ci sono gli obiettivi del sistema e il paradigma che lo informa — le leve più potenti e le più difficili da muovere.

La lezione operativa per chi fa agent coding: quando una pipeline si comporta male, l’istinto è ritoccare un parametro — alzare un timeout, abbassare una soglia di retry. È la leva più debole. Spesso l’intervento che conta è strutturale: aggiungere un anello di feedback che prima non c’era (un monitor che chiude un loop di correzione), togliere un loop di rinforzo dannoso (spezzare la catena retry-che-genera-carico), o accorciare un ritardo (rendere più veloce il segnale che dice all’agente di fermarsi). Cercare la leva forte invece di quella ovvia è il modo concreto di mettere in pratica la tesi di Forrester sulla controintuitività.

C’è anche un avvertimento dentro questa idea, ed è importante quanto la gerarchia. Le leve forti sono potenti in entrambi i versi: lo stesso punto di intervento che, spinto nel verso giusto, raddrizza un sistema, spinto nel verso sbagliato lo manda fuori strada più in fretta di qualunque parametro. Ed è proprio sulle leve forti che l’intuizione tende a sbagliare il verso, come notava Forrester. La conclusione non è “tocca sempre la leva più forte”, ma “quando tocchi una leva forte, fallo con un modello in mano, non a sensazione” — perché lì il margine di errore è piccolo e il costo dell’errore è grande.

Dove si colloca rispetto a controllo e RL

Un’ultima messa a fuoco, utile perché i capitoli vicini parlano di controllo e di reinforcement learning. La system dynamics, la control theory e l’RL guardano tutti sistemi con stato che evolve nel tempo sotto feedback, ma con obiettivi diversi, e tenerli distinti evita confusioni.

La system dynamics è prima di tutto descrittiva ed esplicativa: costruisce la struttura di un sistema per capire perché si comporta così e per confrontare politiche. Non cerca la politica ottima; cerca di mostrare quali politiche evitano l’overshoot, il collasso, l’oscillazione. La control theory (Parte XI, in preparazione) parte invece da un sistema e progetta un controllore che lo porti e lo tenga su un obiettivo: è prescrittiva, e ottimizza. Il reinforcement learning va oltre: apprende una politica per tentativi, senza che nessuno scriva a mano né la struttura completa né il controllore.

Il modo onesto di dirlo: condividono il DNA — feedback, stato, dinamica nel tempo — ma la system dynamics è lo strumento del capire, il controllo e l’RL sono strumenti del governare. Un buon flusso di lavoro li usa in quest’ordine: prima un modello di system dynamics per capire la struttura e i punti di leva, poi controllo o RL per agire su quei punti. Saltare il primo passo significa progettare un controllore per un sistema di cui non si è capita la dinamica — ed è esattamente la situazione in cui Forrester diceva che l’intuizione spinge la leva nel verso sbagliato.

C’è anche un legame storico, non solo concettuale, che vale la pena nominare: la system dynamics e la teoria del controllo bevono alla stessa sorgente, la cibernetica e l’ingegneria dei servomeccanismi degli anni Quaranta e Cinquanta. Il reinforcement learning, dal canto suo, formalizza il decision making sequenziale con il framework dei processi di decisione di Markov e l’equazione di Bellman — un filone che ha radici parzialmente diverse ma che condivide con la system dynamics l’idea centrale di un sistema il cui stato evolve sotto le proprie decisioni. I capitoli-ponte di questa Parte verso il reinforcement learning e verso gli agenti rendono questi collegamenti espliciti; qui basti aver fissato che la system dynamics non è un vicolo cieco storico, ma uno dei rami di un albero le cui altre fronde sono il controllo e l’RL.

Dove si rompe

La system dynamics è uno strumento che fa vedere cose invisibili, e proprio per questo è facile usarla male. Un metodo che mostra il comportamento di sistemi che la mente non sa simulare è anche un metodo che può produrre comportamenti convincenti a partire da assunzioni sbagliate, e farli sembrare verità. I suoi limiti e i suoi fraintendimenti tipici contano quanto i suoi meccanismi — e i fraintendimenti più gravi non sono errori di calcolo, sono errori su cosa il metodo promette.

Confondere lo stock con il flusso: lo “stock-flow failure”. È l’errore percettivo più documentato di tutti. John Sterman e Linda Booth Sweeney, in esperimenti ripetuti su persone istruite — studenti di master del MIT inclusi — hanno mostrato che la maggioranza sbaglia compiti elementari: data la curva dell’inflow e dell’outflow di una vasca, disegnare l’andamento del livello. L’errore tipico è il pattern matching: credere che lo stock segua la stessa forma del flusso, o del flusso netto. Non è così. Lo stock cresce finché il flusso netto è positivo, anche mentre il flusso netto sta calando; raggiunge il massimo quando il flusso netto passa per zero, non quando l’inflow è al suo picco. È l’esempio numerico della vasca, e il fatto che persone con formazione tecnica ci cadano in massa è la prova migliore della tesi di Forrester sulla controintuitività.

Confondere il causal loop diagram con lo stock-flow diagram. Il CLD è veloce e comunicativo, e proprio per questo seduce. Ma non distingue gli accumuli dai tassi, e sono gli stock a determinare l’inerzia, il ritardo, la possibilità stessa di oscillare. Un CLD può sembrare di “spiegare” un comportamento mentre nasconde dove sono gli stock. Per dire qualcosa sul comportamento — e soprattutto su quale loop domina — serve lo stock-flow diagram con le equazioni. Il CLD da solo è una mappa senza scala.

Leggere troppo da un singolo CLD. C’è un fraintendimento più sottile del precedente: anche restando dentro i limiti del CLD, è facile concludere troppo. Un causal loop diagram con un loop R e un loop B non dice quale dei due vince — dipende da numeri che il CLD non contiene. Due persone possono guardare lo stesso CLD e prevedere comportamenti opposti, entrambe “coerenti col diagramma”, semplicemente perché immaginano forze diverse per i due loop. Questo non rende il CLD inutile: lo rende uno strumento per generare ipotesi sulla struttura, non per concludere sul comportamento. La conclusione si guadagna solo con il modello quantitativo. Trattare un CLD come se fosse una dimostrazione è il modo più comune di ingannarsi con un disegno che sembra rigoroso.

Credere che R sia “buono” e B sia “cattivo”. La polarità descrive la dinamica, non il valore. Un loop di rinforzo può essere un circolo virtuoso o un circolo vizioso: il debito che genera interessi che generano altro debito è un R, e nessuno lo definirebbe virtuoso. Un loop di bilanciamento non è un nemico da abbattere: è ciò che tiene in vita un sistema — l’omeostasi del corpo è fatta di loop B. R e B sono descrizioni di comportamento, non giudizi.

Pensare che World3 abbia “previsto” il collasso. È il fraintendimento con le conseguenze pubbliche più grandi, e va affrontato di petto. Negli anni Settanta Forrester costruisce World Dynamics (1971), chiamato anche World2: un modello dell’intero pianeta con cinque variabili intrecciate — popolazione, capitale industriale, produzione di cibo, risorse non rinnovabili, inquinamento. Un team guidato da Donella Meadows (scienziata ambientale statunitense, 1941-2001), Dennis Meadows, Jørgen Randers e William Behrens lo raffina nel modello World3, che sta alla base del libro The Limits to Growth (1972), commissionato da un gruppo internazionale di intellettuali e industriali chiamato Club di Roma. Lo scenario di riferimento del libro — lo “standard run” — mostra un overshoot-and-collapse nel corso del XXI secolo se la crescita di popolazione e consumi continua senza cambi di politica: popolazione e capitale industriale crescono, le risorse non rinnovabili si esauriscono con un ritardo che impedisce di accorgersene in tempo, e il sistema crolla. Il libro vende milioni di copie e diventa un riferimento — e un bersaglio — del dibattito ambientale.

Figura in preparazione

fig-6: lo scenario “standard run” di World3 come grafico tempo-valore stilizzato, dal 1900 al 2100. Curve etichettate: “popolazione”, “capitale industriale”, “cibo pro capite”, “risorse non rinnovabili”, “inquinamento”. Le prime tre salgono e poi crollano (overshoot-and-collapse); le risorse calano in modo monotono. Sotto, in evidenza, la nota: “uno scenario condizionale, non una previsione”.

Il punto è questo: gli autori hanno sempre dichiarato che World3 non è un modello predittivo. Non produce date di collasso. Esplora scenari condizionali — “se le politiche restano queste, allora il sistema si comporta così” — per capire i meccanismi e confrontare politiche alternative, non per fissare un calendario. Il libro stesso presenta più scenari, alcuni dei quali con stabilizzazione, non solo lo standard run.

La distinzione tra previsione e scenario condizionale non è cavillo accademico; è una classe di affermazione, e confonderla è l’errore. “Il sistema collasserà nel 2040” è una previsione, e una previsione si valuta confrontandola con il 2040. “Se la crescita resta esponenziale e le risorse restano finite, allora la struttura genera overshoot-and-collapse” è un’affermazione condizionale sulla struttura, e si valuta verificando se la struttura del modello è plausibile e se le sue assunzioni reggono. World3 fa la seconda; il dibattito pubblico, in larga parte, l’ha letta come se facesse la prima — e poi ha celebrato o demolito il libro a seconda che una data tornasse. Entrambe le reazioni sbagliano bersaglio.

Le critiche più serie al modello — l’aggregazione estrema (un solo “stock di risorse” per tutto il pianeta, una sola “popolazione” mondiale), la difficoltà reale di stimare quei parametri globali, la forte sensibilità del risultato ad alcune assunzioni — colpiscono le pretese predittive forti che lettori e commentatori hanno attribuito al libro, non l’uso della system dynamics come metodo di esplorazione. La distinzione è netta e va tenuta: la system dynamics-come-metodologia di modellazione è una cosa; la pretesa di prevedere il futuro di un sistema planetario con un modello aggregato è un’altra. Confonderle danneggia entrambe — fa credere ai sostenitori che il metodo prometta più di quanto può, e dà ai critici un facile bersaglio per liquidare l’intero metodo quando una data non torna. Lo stesso vale, in scala minore, per Urban Dynamics (1969): alcuni dei suoi risultati controintuitivi sulle politiche urbane sono stati discussi e contestati a lungo, e valgono come illustrazione della tesi sulla controintuitività, non come verdetto urbanistico definitivo.

La lezione generale, applicabile ben oltre World3: un modello di system dynamics è bravo a mostrare quali comportamenti una struttura può generare — può oscillare? può collassare? può stabilizzarsi? — e molto meno bravo a dire quando esattamente e con quali numeri precisi. Usarlo per il primo scopo è solido; spacciarlo per il secondo è dove si rompe. Vale per un modello del pianeta e vale per un modello di una pipeline agentica: il modello ti dice che la coda può divergere e in quali condizioni, non a che ora preciso lo farà in produzione.

Credere che un CLD più grande sia un modello migliore. Un diagramma con cinquanta variabili e venti loop non è più esplicativo: è più difficile da capire e quasi sempre nasconde i pochi loop che contano davvero per il problema in esame. Forrester stesso predicava modelli piccoli, mirati a una domanda precisa. Un modello che prova a contenere tutto non spiega niente.

Dimenticare di confrontare il modello con la realtà. Un modello che gira e produce belle curve è seducente, e c’è il rischio di affezionarsi al modello invece che al sistema che dovrebbe descrivere. Un modello di cui non si è mai verificato se genera il comportamento osservato — il comportamento di riferimento del ciclo di modellazione — è un’opinione formalizzata, non uno strumento di conoscenza. La domanda da farsi sempre, prima di fidarsi di un modello: questo modello, con questa struttura e questi parametri, riproduce davvero ciò che il sistema reale ha fatto? Se non lo sai, il modello non ha ancora guadagnato il diritto di guidare una decisione.

Confondere un sistema lento con un sistema con ritardo. Sono due manopole diverse e producono comportamenti diversi. Un guadagno basso rende l’avvicinamento all’obiettivo lento, ma dolce: nessun overshoot. Un ritardo nell’anello di correzione produce overshoot e oscillazione anche con un guadagno moderato. Se un sistema oscilla, abbassare genericamente “la velocità” può non bastare: la domanda giusta è dove sia il ritardo.

Dimenticare che il metodo è deterministico e aggregato. La system dynamics classica modella dinamiche continue e deterministiche: gli stock sono quantità continue, le equazioni non hanno rumore casuale, e una popolazione è un numero, non un insieme di individui distinti. Questo è un’astrazione potente ma con un costo. Se il fenomeno che ti interessa nasce dall’eterogeneità dei singoli — un’epidemia in una rete sociale dove conta chi conosce chi, un mercato dove i singoli agenti hanno strategie diverse — la system dynamics, che li tratta come un unico stock omogeneo, può mancare il bersaglio. Per quei casi esiste un metodo cugino, l’agent-based modeling (la simulazione che rappresenta ogni individuo separatamente), trattato altrove nella wiki. Non è un difetto della system dynamics, è il suo confine: sceglierla significa accettare l’aggregazione. Per il contrasto con la modellazione stocastica vedi processi-stocastici.

Modellare variabili “soft” con falsa precisione. Molti modelli interessanti includono variabili difficili da misurare: la “fiducia del team”, la “pressione percepita”, la “motivazione”. La system dynamics permette di metterle nel modello, ed è giusto — ometterle perché non si misurano facilmente è peggio che includerle. Il rischio è il contrario: una volta che la variabile “fiducia” ha un numero e un’equazione, il modello sembra preciso quanto le sue parti misurabili. Non lo è. Un modello con variabili soft va trattato come uno strumento per ragionare sulla struttura dei feedback, non come un misuratore. La fiducia ben calibrata in un modello come questo è: usarlo per le forme delle curve, non per i valori.

Usare la system dynamics dove non serve. Non ogni problema chiede un modello dinamico. Se un sistema non ha accumuli significativi, o non ha feedback, o il comportamento di interesse non è dinamico ma statico — qual è la configurazione ottima, qual è la risposta a una singola domanda — allora la system dynamics è uno strumento sovradimensionato, e altri approcci (l’ottimizzazione, una semplice analisi statistica, un calcolo diretto) servono meglio. Il metodo dà il meglio quando ci sono almeno uno stock, almeno un loop di feedback, almeno un ritardo, e una domanda che riguarda come il sistema si comporta nel tempo. Fuori da quel profilo, tirar fuori stock e flow è cerimonia, non chiarezza. Riconoscere quando un problema non è un problema di system dynamics fa parte del saperla usare.

Collegamenti

• feedback-loop — un causal loop diagram non è altro che feedback loop disegnati su scala; il loop R è feedback positivo, il loop B è feedback negativo. Il CLD ne è la notazione per molti anelli insieme.
• stabilita-ritardi-oscillazioni — il delay che genera overshoot nei modelli di system dynamics è esattamente il fenomeno analizzato lì: la system dynamics lo eredita e lo applica ai sistemi sociali.
• cibernetica-definizione — Forrester eredita il concetto di feedback dalla cibernetica di Wiener; la system dynamics è una delle vie con cui la cibernetica diventa pratica di modellazione quantitativa.
• omeostasi-ashby — il loop di bilanciamento goal-seeking è la forma matematica dell’omeostasi: un sistema che si riporta verso un setpoint.
• equazioni-differenziali-intuizione — un modello stock-flow è, sotto il cofano, un sistema di equazioni differenziali ordinarie; lo stock è l’integrale del flusso netto.
• modelli-sistemi — un modello di system dynamics è un modello descrittivo-esplicativo simulabile; la system dynamics è un caso d’uso concreto della distinzione fra modelli descrittivi, predittivi e prescrittivi.
• teoria-sistemi-intro — stato, confine, processo: la system dynamics è un’istanza operativa del vocabolario della teoria dei sistemi, con lo stock nel ruolo di variabile di stato.
• sistemi-viabili-beer — Stafford Beer e Forrester sono due modi diversi e contemporanei di rendere operativa la cibernetica sulle organizzazioni: il Viable System Model e la system dynamics.
• processi-stocastici — utile per contrasto: la system dynamics modella dinamiche deterministiche e continue, mentre i processi stocastici trattano l’aleatorietà; molti sistemi reali chiedono entrambi.
• stato-spazio-dinamica — gli stock di un modello di system dynamics sono le variabili di stato del sistema; lo spazio degli stock è il suo spazio di stato.
• equilibrio-stabilita — un punto in cui tutti i flussi netti sono zero è un equilibrio del modello; che sia stabile o instabile dipende dai loop e dai ritardi.
• feedback-feedforward — i loop di un causal loop diagram sono tutti retroazione; capire la differenza con il feedforward aiuta a leggere quali parti del modello reagiscono allo stato e quali no.

Il filo che lega questi rimandi è semplice: la system dynamics non è un’isola. È il punto in cui il vocabolario dei sistemi (Parte IX), la matematica delle equazioni differenziali (Parte VI) e l’idea cibernetica di feedback (questa Parte) si incontrano in un metodo unico e operativo. Ognuno di quei capitoli illumina una faccia di ciò che qui si è messo insieme; leggerli accanto a questo capitolo rende lo stock-flow meno una tecnica isolata e più un nodo di una rete di idee.

Se dovessi portare via una sola cosa da questo capitolo, sarebbe l’abitudine di fermarti, davanti a un sistema che si comporta in modo strano, e farti quattro domande nell’ordine: cosa si accumula qui (gli stock), cosa li riempie e svuota (i flow), dove passa del tempo tra causa ed effetto (i ritardi), quali anelli si chiudono (i loop, R o B). Quattro domande che la system dynamics ha reso precise e che, poste con disciplina, smontano gran parte della controintuitività che Forrester aveva diagnosticato. Non serve il software, non serve World3: serve la lente. Il resto — la simulazione, le equazioni, gli strumenti — è il modo di affilarla quando il sistema è troppo intricato perché la sola lente basti.

Per andare oltre

• Jay W. Forrester, Industrial Dynamics, MIT Press, 1961. Il libro fondativo: l’impresa come reti accoppiate di stock e flow, e la prima analisi del bullwhip effect.
• Hau L. Lee, V. Padmanabhan, Seungjin Whang, “The Bullwhip Effect in Supply Chains”, MIT Sloan Management Review, 1997. L’articolo che riporta l’effetto frusta al centro del management moderno, con un’analisi delle sue cause strutturali.
• Jay W. Forrester, “Counterintuitive Behavior of Social Systems”, Technology Review, gennaio 1971. La testimonianza al Congresso USA che articola la tesi: la mente non è adatta a interpretare i sistemi con molti feedback e ritardi.
• John D. Sterman, Business Dynamics: Systems Thinking and Modeling for a Complex World, McGraw-Hill, 2000. Il manuale moderno di riferimento: stock, flow, causal loop diagram, il Beer Game, lo stock-flow failure. È il testo da cui partire per imparare a costruire modelli sul serio.
• Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green, 2008. Introduzione accessibile e non tecnica al pensiero per stock, flow e feedback, scritta da una delle autrici di The Limits to Growth.
• Donella H. Meadows, Dennis L. Meadows, Jørgen Randers, William W. Behrens III, The Limits to Growth, Universe Books, 1972. Il libro del Club di Roma basato su World3: da leggere tenendo a mente che è esplorazione di scenari, non previsione.
• Jay W. Forrester, “Some Basic Concepts in System Dynamics”, 2009. Una sintesi tarda dell’autore stesso, breve e accessibile, sui mattoni del metodo: utile per sentire come Forrester definiva stock, flow e feedback con parole proprie.
• System Dynamics Society, “Origin of System Dynamics” (systemdynamics.org). La storia del campo curata dalla società scientifica: la vicenda della General Electric, la filiera DYNAMO, gli sviluppi successivi.
• Donella H. Meadows, “Leverage Points: Places to Intervene in a System”, 1999. Il saggio che ordina i punti di intervento in un sistema dal più debole (i parametri) al più forte (gli obiettivi e il paradigma).