Aumentare la capacità produttiva senza sostituire il software esistente

PharmaLink è un laboratorio farmaceutico nel Benelux che produce e distribuisce medicinali; il nome è fittizio, per proteggere la riservatezza del cliente. Quando sono arrivato, nel 2024, il problema non era la mancanza di software: ce n’erano diversi, sviluppati internamente o acquistati da terze parti, ognuno bravo a fare la sua parte. Il problema era che quei software non parlavano la stessa lingua — e spesso nemmeno le persone che li usavano.

Da dove partivamo

L’azienda gestisce due linee di produzione, diversi laboratori, magazzini e celle frigorifere programmabili. Ogni area aveva il suo modo di lavorare: fogli di calcolo per alcune pianificazioni, software interni sviluppati nel tempo per la produzione e la logistica, sistemi acquistati per contratti e fatturazione, e strumenti di terze parti o legacy. Ogni strumento era ottimo per il proprio compito, ma nessuno sapeva parlare con gli altri.

Il team di sviluppo era un piccolo gruppo dedicato, con budget separato e indipendenza rispetto al resto delle IT Operation. Non era il tipico reparto IT di una grande azienda: stava già provando a lavorare secondo valori e pratiche lean/agile, anche se il resto dell’organizzazione non lo era, e si trovava a difendere quel modo di lavorare. Era, in scala molto più ridotta, una situazione affine a quella che Henrik Kniberg racconta in Lean from the Trenches: un gruppo che cerca di portare lean e kanban dentro un’organizzazione strutturata e piena di legacy. Aveva potenziale inespresso: credeva nei principi, ma faticava a metterli a terra nel software. La trasformazione lean in produzione era iniziata nel 2023 con Max, un coach lean con cui avevo già lavorato in EFGC e che nella community è conosciuto come MadMax; il team di sviluppo non ne era il pioniere, ma il suo abilitatore, perché doveva fornire gli strumenti software che la rendessero possibile. Il mio lavoro iniziale è stato proprio aiutare quel team a esprimere il proprio potenziale. In un’organizzazione dove ogni dipartimento difendeva il proprio sistema, quel piccolo team era anche l’unico posto in cui il cambiamento poteva diventare codice.

L’evento scatenante non è stato tecnico. Max era stato chiamato per mappare gli sprechi nella produzione. L’azienda voleva ampliare il proprio mercato e aumentare la capacità produttiva, e per farlo serviva più efficienza e meno attrito.

Cosa non funzionava

La difficoltà principale non era nei singoli software, ma nelle zone di confine. Ogni dipartimento usava parole diverse per indicare la stessa cosa, e le materie prime — componenti e principi attivi dai nomi lunghi e complessi — erano facili da scrivere male. Un errore di lettura poteva propagarsi in ordini d’acquisto errati, spazio magazzino sbagliato, produzione sospesa.

I punti di attrito più evidenti erano tre:

1. Linea 2 e laboratori. La linea 2 produce farmaci con procedimenti complessi che richiedono i laboratori, ma i due software non si vedevano. Erano anche in due divisioni aziendali con regole diverse.
2. Linea 1 e linea 2. La linea 1 produce farmaci con procedimenti più semplici, gestiva volumi elevati ma spesso era sovraccarica; la linea 2 era sotto-utilizzata in modo rilevante. Spostare carichi dalla linea 1 alla 2 richiedeva esportazioni in Excel, stime manuali e re-inserimento nei due software, più l’approvazione di referenti diversi.
3. Produzione, magazzini e celle frigorifere. L’occupazione dei magazzini e delle celle veniva esportata manualmente, passata a chi pianificava, riportata su Excel e reinserita. Da lì, email ad acquisti e logistica per le spedizioni in uscita.

In pratica, la pianificazione era un flusso di email e fogli Excel che attraversavano dipartimenti con vocabolari diversi. Il software non agevolava la conversazione: la rallentava e la rendeva fragile. Il team di sviluppo non poteva cambiare da solo la cultura dell’azienda, ma poteva costruire gli strumenti che la rendessero possibile.

Cosa abbiamo fatto

1. Partire dalle fondamenta tecniche

Il primo contatto è stato un workshop tecnico di tre giorni in presenza su testing e architettura interna delle applicazioni: piramide dei test, test unitari solitary e sociable, architettura esagonale, disaccoppiamento dei componenti, protezione dello strato di dominio dai dettagli tecnologici. Dopo il workshop ho iniziato un mentoring di un giorno a settimana da remoto per aiutare il team ad applicare sulle applicazioni reali ciò che aveva visto.

A metà 2024 ho tenuto un secondo workshop su XP e DevOps: TDD, pair programming, observability, trunk-based development, customer test, E2E e pratiche affini, con attenzione ai limiti imposti dalla scrittura di software in ambito altamente regolato. Per tutto il 2024 il team si è concentrato su qualità, stabilità e riduzione del lead time: imparare a ricevere feedback e integrarli in modo rapido ed efficace.

2. Discovery del dominio

Nel 2025 siamo entrati nel vivo. La prima fase è stato uno sprint di discovery con Event Storming per mappare i flussi operativi già studiati da Max e collegarli al software esistente. Il dominio era già stato modellato dal punto di vista del processo produttivo; mancava la relazione con le applicazioni.

Abbiamo poi dedicato uno sprint a degli spike tecnici per capire come raccogliere i dati dalle applicazioni esistenti e presentarli in un punto unico, e come far tornare informazioni dalla nuova applicazione alle vecchie per allineare lo stato e validare le pianificazioni. Durante questa fase abbiamo adottato una visione olistica, usando system thinking per disegnare l’architettura di massima ad alto livello.

Nel 2025 il mio impegno è sceso a circa tre giorni al mese: abbastanza per fare da coach tecnico e advisor sui nuovi sviluppi preparatori all’integrazione.

3. Costruire la nuova applicazione, un pezzo alla volta

Lo sviluppo della nuova applicazione è iniziato nel 2026. In spirito lean, abbiamo scelto di partire da due interventi che massimizzavano l’impatto con il minimo cambiamento:

• una visualizzazione centralizzata delle informazioni, per dare a chi pianifica una visione d’insieme che prima non esisteva;
• un tool di mapping dei nomi tra i diversi domini e divisioni, integrato nella visualizzazione delle informazioni. Questo è il punto di partenza per cominciare a costruire quel lessico comune che mancava, permettendo a tutti di continuare a parlare la propria lingua… ci vorranno anni per uniformare il lessico e il primo passo è comunicare in modo chiaro ed efficace.

Nel corso del 2026 il mio ruolo è diventato principalmente di advisor e reviewer, circa due giorni al mese: vengo chiamato quando c’è un dubbio o serve un parere esterno.

A metà 2026 abbiamo fatto uno sprint tecnico di revisione e refactor della nuova applicazione: non perché ci fosse un’emergenza, ma per ridurre il naturale debito tecnico accumulato, riportandola a un simple design, correggere piccole derive architetturali e consolidare le competenze acquisite. In quel momento ho lavorato fianco a fianco come membro del team.

4. Un’architettura ibrida, non un sostituto

La scelta è stata quella di non sostituire i software esistenti in un colpo solo. La nuova applicazione dialoga con le applicazioni legacy raccogliendo dati, restituendone altri e offrendo quel punto di visione d’insieme che mancava. È un’integrazione progressiva, non un big bang.

Cosa è cambiato

Il progetto non è terminato: stimiamo che servirà ancora diverso tempo per coprire la parte critica del processo. Ma i primi risultati sono già significativi:

• Tempi di pianificazione ridotti in modo sostanziale.
• Errori di pianificazione ridotti drasticamente.
• Capacità produttiva aumentata, semplicemente riducendo gli errori che prima causavano acquisti errati di materie prime o semi-lavorati, sospensioni della produzione per mancanza di spazio nei magazzini o nelle celle frigorifere.
• Linea 2: era sotto-utilizzata in modo rilevante; il suo uso è cresciuto sensibilmente, anche se resta ancora margine di miglioramento.
• Linea 1: ha avuto un incremento di produzione non previsto inizialmente.
• Sprechi di materie prime e semi-lavorati quasi azzerati: meno acquisti per errore, meno prodotti buttati dopo la consegna perché non c’era spazio adeguato in magazzino o nelle celle frigorifere.

Il risultato più interessante, però, è di natura culturale. Max sta lavorando con i vari dipartimenti per semplificare il processo di pianificazione in ottica olistica, e l’applicazione che stiamo costruendo sta diventando l’abilitatore di un cambio di mentalità verso un approccio lean alla produzione.

Cosa dicono

The development team understood lean principles, but they needed help translating that into working software. What Gianni brought was the bridge between lean thinking and technical implementation—now we have tools that don’t just track data, they enable the conversation between departments that makes lean actually work.

Cosa mi ha insegnato

Questa collaborazione non rientra nel modello di partnership di sei mesi che propongo oggi, ma contiene alcune lezioni che riporto con me.

La prima è che il problema spesso non è nel software, ma nel linguaggio: se persone e sistemi non condividono un lessico comune, ogni integrazione tecnica rimane una pezza. La seconda è che il cambiamento organizzativo e quello tecnico vanno d’accordo: l’applicazione funziona da abilitatore, ma è il lavoro sul processo — con Max e con il team — che ne sfrutta il valore. La terza è che un piccolo team in un’organizzazione grande può essere un abilitatore di cambiamento, se ha autonomia e costruisce gli strumenti giusti: non deve essere il pioniere della trasformazione, può essere chi la rende possibile. La quarta è che un intervento a basso regime può reggere un cambiamento lungo, purché ci sia continuità: da workshop intensivo a mentoring settimanale, da advisor mensile a sprint mirati, la mia presenza si è modulata sulle esigenze reali del team.

Da qui ho tratto anche la conferma che partire dalla visibilità — dare agli operatori una visione d’insieme che prima non avevano — può creare più valore di una riscrittura totale, e che il system thinking è uno strumento essenziale quando il problema è la relazione tra parti, non una singola parte.

Approfondimenti

Il workshop da cui tutto è partito: l’Event Storming come punto di partenza.