La storia fin qui
Nella puntata precedente [1] abbiamo parlato delle conseguenze derivanti da una errata gestione di un processo di produzione di un qualche bene: nell’esempio specifico si utilizzava l’esempio della filiera di produzione, distribuzione e vendita di una marca birra di fantasia (la Lover’s), ma le dinamiche che si instaurano sono riscontrabili anche in altri contesti, come il generico manifatturiero, o le tematiche tipiche della nostra rivista nel settore della produzione del software.
La sequenza degli eventi
Ricapitoliamo brevemente la sequenza di eventi che si sono susseguiti:
Una piccola oscillazione nella domanda da parte dei consumatori finali viene prima sottovalutata dalla rete di vendita, poi presa in seria considerazione dal negoziante, che prima sopperisce con le scorte di magazzino, poi provvede ad aumentare gli ordinativi al grossista.
Le consegne avvengono con 4 settimane di “ritardo” dalla effettiva creazione dell’ordine: per 4 settimane quindi il negoziante non riceve alcun incremento della merce consegnata.
Il negoziante, prima gestisce la cosa in modo razionale, ma quando le scorte non bastano più, e non è in grado di soddisfare la sua clientela più affezionata, inizia a reagire in maniera impulsiva aumentando gli ordinativi in misura maggiore di quello realmente necessario: si confonde l’aumento della richiesta settimanale, con le richieste passate non soddisfatte, come se tutti i clienti che non hanno comprato nei giorni in cui la birra non era disponibile, si ripromettessero poi di comprare anche gli “arretrati”.
Questo andamento si verifica con lo stesso andamento presso gli altri nodi della filiera (distribuzione e produzione), cosa che porta al blocco delle consegne: la fabbrica non era pronta all’aumento improvviso delle richieste.
Non essendo disponibile prodotto già presso la fabbrica, i venditori finali dopo le 4 settimane canoniche cominciano a ricevere addirittura meno scorte di quelle ordinate. A questo, reagiscono in modo ancora più irrazionale aumentando le richieste.
Finalmente il processo si sblocca, perché la fabbrica si attrezza per moltiplicare la sua capacità produttiva. Ma a questo punto, le richieste da parte di venditori finali e distribuzione si bloccheranno, perché entrambi si son visti recapitare un quantitativo di merce enormemente maggiore rispetto alle necessità.
Ancora una volta è necessario sottolineare che la variazione della domanda finale era minima e che nessun cliente probabilmente avrebbe comprato tutta la birra che non era stato in grado di acquistare nelle settimane precedenti.
Il processo quindi si traduce in una specie di onda fra domanda e offerta, che ha messo in difficoltà tutti i nodi della filiera: il negoziante prima non ha saputo soddisfare la richiesta dei clienti; poi si è ritrovato nel magazzino una eccedenza di birra che per essere smaltita avrebbe richiesto molte settimane; il distributore ha subito una sorte analoga e quindi, come il negoziante, ha interrotto gli ordinativi quando si è trovato nel magazzino bancali pieni di birra.
In fabbrica inizialmente non sono stati in grado di evadere l’incremento degli ordinativi ma non hanno subito alcun danno economico diretto, se non mancanza di un ricavo concreto; poi, quando hanno fatto gli investimenti necessari per incrementare la produzione, hanno subìto l’arresto della domanda, con conseguente impossibilità di ripagare gli investimenti fatti, oltre anche in questo caso ai magazzini pieni.
In questo articolo, vediamo di dare una spiegazione formale a quanto accaduto per comprendere le cause ed evitare che ciò accada anche, per esempio, all’interno di una piccola azienda che produce software.
Effetto Forrester
Da un punto di vista teorico, il comportamento del sistema preso in esame e le conseguenze delle azioni intraprese dai vari attori, sono spiegabili mediante il cosiddetto Effetto Forrester, detto anche effetto frusta o Bullwhip. Tale fenomeno si verifica, in determinate condizioni, in una catena di produzione, con una oscillazione della domanda e dell’offerta tramite la formazione di una specie di onda che, proprio come la corda di una frusta, si propaga amplificandosi man mano che ci si allontana dal mercato finale e si risale la catena di produzione. È tipicamente applicabile ai sistemi di supply/chain ma, come vedremo, lo possiamo vedere in azione anche all’interno di un sistema IT come quello della “fabbrica” del software.
Cause principali dell’effetto “frusta”
Molteplici sono le cause che danno luogo alla serie di fenomeni descritti nell’esempio della birra. Da un lato si può certamente indicare nella presenza di attori che prendono decisioni sulla base di informazioni circoscritte al loro ambito di intervento e che, per questo, vengono chiamati decisori a “razionalità limitata” di cui parleremo più avanti.
Non avendo informazioni dalla periferia rispetto al loro contesto d’azione, o comunque non avendo sotto controllo tutto il sistema nel suo complesso, maggiore è la lunghezza della catena di produzione, maggiore sarà l’inefficienza del sistema complessivo; più precisamente tanto più ci si allontana dal cliente finale — o più genericamente dal punto di chiusura del processo, ossia del controllo — maggiore è l’inesattezza delle informazioni e la grossolanità delle azioni intraprese. Per questo si parla di onda, oscillazione o genericamente di effetto frusta (figura 1).
Filiera lunga
In agilità, quando si deve sviluppare un prodotto software, o genericamente un prodotto IT, la lunghezza, o meglio la cortezza, della filiera di produzione è un aspetto preso in seria considerazione, visto che è noto a cosa possa portare una catena lunga.
In Scrum per esempio si cerca di ridurre il numero di intermediari organizzando team in cui tutti gli attori si parlano, collaborano e decidono. Per questo si cerca di eliminare prima di tutto gli intermediari, di mettere in comunicazione direttamente il team con il cliente/utente e il team con il management.
È per questo per esempio che un Product Owner che faccia da intermediario fra il cliente e il team di sviluppo è un cattivo PO, o almeno un PO che incorre nel rischio di allungare la catena. È per questo per esempio che in Kanban, dopo una prima fase di mapping del processo, si prova ad accorciare il processo, per esempio abilitando la cross-capacità delle persone, o facendo in modo che il gruppo si autoorganizzi per compiere quelle operazioni impegnative magari in gruppi senza chiedere il contributo di attori esterni.
Tempi di lavorazione
Altro fattore che impatta negativamente e che si somma alla lunghezza della catena è il tempo di lavorazione del prodotto: come abbiamo avuto modo di vedere in modo estremamente dettagliato nella serie di articoli precedenti di questa serie in cui abbiamo parlato di Kanban, il tempo di lavorazione, o Lead Time, impatta sulle prestazioni.
In questo caso, è causa — o effetto, dipende dai punti di vista — delle decisioni prese da un lato o dall’altro della catena: se il negoziante avesse potuto avere la sua birra in tempi più rapidi, avrebbe potuto prendere le proprie decisioni in maniera più coerente con la realtà delle cose. Analogamente, se la fabbrica avesse evaso gli ordini in tempi minori, avrebbe potuto recepire i segnali dal mercato in modo più realistico e magari prendere le adeguate contromisure per tempo.
Latenza
Lunghezza della catena ed elevato Lead Time sono due fattori ci portano a considerare i problemi visti con un altro aspetto, quello della latenza nella risposta del sistema alle sollecitazioni esterne.
Questo fenomeno si può spiegare con un paio di esempi piuttosto semplici: uno che probabilmente molti lettori possono aver sperimentato direttamente; l’altro solo se si è partecipato a un corso per imparare a pilotare un aereo.
Il primo è quello che si prova quando per esempio si prova a guidare una bicicletta o una motocicletta con il tubo canotto dello sterzo che non si muove con la dovuta libertà (serraggio troppo alto o qualche cuscinetto bloccato): in questo caso il manubrio risponde in maniera dura o addirittura a scatti. Per guidare una bici normalmente si apportano delle piccole e costanti correzioni alla traiettoria per rimanere in equilibrio. In questo caso la bici non sterza ed è necessario applicare una forza maggiore, che di fatto porta la bicicletta a sbilanciarsi nella direzione opposta, richiedendo una correzione maggiore e più repentina nell’altra direzione. In questo caso, spesso il ciclista inizia con delle piccole oscillazioni per finire con degli ondeggiamenti più ampi, che portano a volte a cadere.
Un effetto simile capita a chi pilota un aereo: per correggere l’assetto egli tira la cloche per alzare il muso. Ma l’effetto della azione non è immediato, per cui il pilota inesperto tira la cloche più del dovuto; dopo poco il muso dell’aereo si alza più di quanto necessario, e per questo il pilota da una correzioni vistosa verso il basso. Ma siccome anche in questo caso l’effetto non è immediato, il pilota alle prime armi comincia ad avere un po’ di ansia… e abbassa troppo. Quando il muso si abbassa, allora tira di nuovo la cloche… e la tira troppo.
Di fatto in quel caso il tipo di risposta del sistema non può essere modificata, per cui pare che nell’addestramento i piloti vengano addestrati ad evitare questo loop pernicioso, portando piccole modifiche e riportando sempre la cloche in assetto.
Il tema della latenza nella risposta è uno degli aspetti più importanti su cui si fonda buona parte della filosofia agile: seguire iterazioni brevi in Scrum, organizzare frequenti incontri con il cliente/utente per fare delle demo, raccogliere il maggior numero di feedback possibili sono tutte azioni che vanno nella direzione di aumentare la reattività del sistema, ossia intraprendere decisioni i cui effetti siano verificabili prima possibile.
Cause dirette secondarie dell’effetto “frusta”
Operare sui tre fattori appena visti (accorciare la filiera, ridurre il lead time, aumentare la reattività) è sicuramente un modo già molto efficace per migliorare il sistema e ridurre gli effetti negativi della frusta. Esistono poi anche alcuni altri fattori secondari che possono essere causa di effetto Forrester. Li vediamo di seguito, tenendo presente che in genere sono sintomi che esprimono un’elevata oscillazione della tendenza domanda/offerta.
Da notare che non è necessario che queste cause si manifestino tutte contemporaneamente per poter affermare che il sistema è sotto l’effetto Forrester.
Eccessivo livello di scorte
Un eccessivo livello di scorte, soprattutto a monte della catena per evitare rotture di stock, ossia premunirsi dal trovarsi senza scorte. In Agile vuol dire avere nel backlog abbastanza cose pronte da fare (raffinate nel senso di refinement), ma non troppe. In kanban, se ci sono troppe card nella colonna ToDo, il rischio per esempio potrebbe essere quello di non riuscire a evadere delle richieste di assistenza, se stiamo gestendo un help desk o ufficio operation, con la consegneza che gli utenti finali potrebbero nuovamente telefonare per effettuare nuovamente la segnalazione, creando un loop vizioso (ricordiamoci l’esempio del pilota inesperto…).
Inefficacia delle previsioni di vendita
L’inefficacia frequente o costante delle previsioni di vendita è un altro esempio. In agilità questo aspetto è stato abbondantemente affrontato: fare previsioni è molto difficile, se non impossibile, per cui si preferisce fare delle sperimentazioni in un ambito protetto e con un coefficiente di rischio ridotto al minimo.
Sbalzi della capacità produttiva
Sbalzi nella richiesta di capacità produttiva, che risulta a volte insufficiente e a volte eccessiva). Per questo motivo si cerca di tenere il più stabile possibile il contesto di lavoro: limitare il turn over, stabilizzare il processo di alimentazione del backlog, coinvolgere il più possibile e con la maggior frequenza possibile gli utilizzatori in modo da raccogliere feedback e nuove richieste di da implementare. Maggiore è la cadenza con cui raccogliere tali feedback (tante piccole gocce), minore saranno gli sbalzi (aggiunta o rimozione di grosse fette di backlog).
Cambiamenti ai piani di produzione
Frequenti cambiamenti ai piani di produzione non aiutano a prevenire l’effetto frusta. In un progetto software, il piano di produzione potrebbe essere qualcosa che ricade nel contesto Product Ownership o, più in alto, parte della vision. In agile il cambiamento è benvenuto e per questo le metodologie come Scrum o Kanban riescono a reagire prontamente a eventuali variazioni. È noto però che un cambiamento “forte” ha implicazioni non banali sul processo di produzione. Per esempio è probabile che la velocity cambi, o che il trend delle cose da fare, ossia il Burn Down di Scrum, subisca una radicale perturbazione.
Cause indirette
Oltre alle cause viste fino a questo punto, ci sono alcuni aspetti che forse è più corretto chiamare effetti ma che condizionano il sistema stesso dando luogo a un qualcosa che rientra nella teoria dei system dynamics, circuiti caratterizzati da ciclicità e feedback rientrante.
Comportamenti irrazionali
In determinati momenti, gli attori del sistema mettono in atto comportamenti irrazionali, frutto dell’emotività, o che possono apparirlo a posteri, come nel caso dei decisori con razionalità limitata.
Si opera in un contesto a razionalità limitata durante il processo decisionale quando la razionalità di un individuo è limitata dalle informazioni che possiede, dai limiti cognitivi della sua mente, e dall’ammontare finito di tempo che egli ha a disposizione per prendere una decisione.
Svariati modelli economici danno per scontato che le persone abbiano una razionalità media, e possano in quantità sufficientemente grandi essere approssimati come agenti in accordo alle loro preferenze. Il concetto di razionalità limitata rivede questo assunto per tenere conto del fatto che decisioni perfettamente razionali spesso non sono realizzabili nella pratica, proprio a causa della quantità finita di risorse computazionali disponibili per prenderle [2].
Mancanza di coordinamento
Spesso manca un coordinamento nelle decisioni dei singoli membri della catena di produzione. Anche in questo caso la mancanza di coordinamento è spesso legata ad una razionalità limitata dei decisori, i quali sono quindi portati ad assumere un comportamento localmente opportunistico: ogni decisore pensa prima di tutto a ottimizzare il proprio limitato ambito operativo. In questo caso, poiché i decisori mancano delle capacità e delle risorse per arrivare alla soluzione ottimale, essi applicano invece la loro razionalità solo dopo aver enormemente semplificato le scelte disponibili. In pratica, il decisore cerca una soluzione soddisfacente piuttosto che la migliore in assoluto [2].
Conclusione
L’effetto Forrester impatta sul processo di produzione e vendita di un bene, cosa che nel campo IT potrebbe essere la messa in produzione o il rilascio di un determinato componente o prodotto software.
La tipica conseguenza in una catena di produzione e vendita è che tutti gli attori nel mezzo della catena sono portati a un più o meno cosciente aumento delle scorte di sicurezza: si cerca di evitare la rottura di stock. La formica che accumula scorte per l’inverno, infatti, non ha problemi di obsolescenza del prodotto, cambio di requisiti (mangia sempre le stesse cose) o richieste particolari.
In un progetto software, il magazzino in genere è rappresentato da tutto il software che non è ancora stato rilasciato e che rimane in attesa di essere quindi verificato e provato sul campo. Per questo, in un progetto agile si cerca di minimizzare questa forma di magazzino, proprio per limitare l’accumulo di parti di prodotto non testate e non provate sul campo.
In un progetto software gli accumuli di magazzino non sono né un obiettivo rincorso, né una forma di protezione (irrazionale) ma casomai manifestazione di scarsa organizzazione o mancanza di strumenti: per esempio non si fa continuous integration.
Si è visto con l’esempio della produzione della birra che a un certo momento il sistema nel suo complesso ha iniziato a funzionare in modo non ottimale, cosa resa evidente da ritardo nelle consegne ad ogni livello della organizzazione. Questo effetto si può avere anche in una organizzazione che produce software. Si pensi per esempio a un sistema di gestione dei bug di produzione gestito tramite Kanban. In questo caso la variabilità può essere molto alta e, contrariamente a quanto possano dire gli analisti di mercato che si lanciano in rocambolesche previsioni, molto poco prevedibile.
Questo è un tipico caso in cui ciclo di lavorazione lungo, scarsa visione di insieme, ottimizzazioni localizzate, scarso coinvolgimento del cliente finale possono amplificare l’onda dell’effetto frusta, dando come risultato più evidente un ritardo nella lavorazione dei ticket.