{"id":2857,"date":"2026-11-06T16:19:07","date_gmt":"2026-11-06T15:19:07","guid":{"rendered":"https:\/\/www.kanban.systems\/blog\/?p=2857"},"modified":"2026-11-06T16:19:11","modified_gmt":"2026-11-06T15:19:11","slug":"il-motore-calcola-lai-confronta-la-persona-decide-lapplicazione-in-un-caso-reale","status":"publish","type":"post","link":"https:\/\/www.kanban.systems\/blog\/2026\/11\/06\/il-motore-calcola-lai-confronta-la-persona-decide-lapplicazione-in-un-caso-reale\/","title":{"rendered":"Il motore calcola, l\u2019AI confronta, la persona decide: l\u2019applicazione in un caso reale"},"content":{"rendered":"\n

Al ritorno dal Kanban Leadership Retreat, ho scritto un articolo, \u201cPerch\u00e9 collegare l\u2019AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere\u201d<\/a>, su un tema che al retreat aveva occupato molto spazio: qual \u00e8 la corretta architettura per introdurre l\u2019AI in un sistema Kanban. La conclusione era che un agente AI da solo non basta, e che le cose vanno peggio se accede direttamente ai dati grezzi di flusso e li elabora in autonomia. Si ottiene una risposta plausibile ma non affidabile, che cambia quando cambia il workflow senza che nessuno se ne accorga.<\/p>\n\n\n\n

Il ruolo giusto per l\u2019AI \u00e8 quello di interfaccia di un motore di flow analytics, che applica sempre le stesse definizioni di misura, con una persona (lo human in the loop<\/em>) che quelle definizioni le ha decise e le mantiene. Nelle ultime settimane abbiamo applicato questa architettura a un lavoro vero: il Rolling Forecast dei progetti collegato al sistema Kanban di un\u2019organizzazione.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Lo scenario: come funziona il Rolling Forecast<\/h2>\n\n\n\n

Il Rolling Forecast, del quale ho gi\u00e0 parlato nell\u2019articolo \u201cOltre il Gantt: il Rolling Forecast per introdurre Kanban e una pianificazione dinamica orientata al flusso\u201d<\/a>, permette di pianificare i progetti rispettando il limite di lavoro in corso e la capacit\u00e0 disponibile. Se la capacit\u00e0 non c\u2019\u00e8, il progetto slitta in avanti, a volte anche all\u2019anno successivo. Le date che ne escono vengono poi riportate sulle card della Kanban board, come inizio e scadenza.<\/p>\n\n\n\n

Nel caso specifico su cui abbiamo lavorato, il Rolling Forecast \u00e8 collegato a un sistema Kanban di portfolio progetti e ne recepisce le policy. Ogni progetto ha una taglia assegnata, e la durata attesa si ricava dall\u201985\u00b0 percentile dei progetti gi\u00e0 completati della stessa taglia. I progetti in coda si ordinano per priorit\u00e0, poi per scadenza, poi per ordine di arrivo. Un progetto parte quando c\u2019\u00e8 capacit\u00e0, ovvero un posto libero nei limiti al lavoro in corso, sia quello complessivo sia quelli delle singole persone assegnate. Quando un progetto finisce, il posto si libera e il successivo pu\u00f2 partire. Il risultato \u00e8 per ogni progetto una data di inizio e una di fine attese, che si ricalcolano quando cambiano i dati.<\/p>\n\n\n\n

Due motori, un\u2019AI e una persona<\/h2>\n\n\n\n

L\u2019architettura nel nostro caso ha due motori. Il primo \u00e8 il sistema Kanban in cui il lavoro \u00e8 gestito, basato su Kanban Zone, che gestisce il flusso, raccoglie gli eventi e restituisce dati puliti: date di ingresso e uscita dalle colonne, taglie dei progetti, assegnatari. \u00c8 lui il motore di flow analytics di cui parlavo nell\u2019articolo precedente.<\/p>\n\n\n\n

Il secondo motore non esisteva e l\u2019abbiamo creato: un motore di calcolo del Rolling Forecast. Legge i dati del sistema Kanban e fa il forecast di pianificazione in funzione della capacit\u00e0 disponibile. Avremmo potuto chiedere il Rolling Forecast direttamente all\u2019AI, che lo avrebbe dato per approssimazione statistica, ma non lo abbiamo fatto. Invece ci siamo fatti aiutare dall\u2019AI a costruire un motore algoritmico, come il sistema Kanban, che faccia i calcoli corretti. Le regole che usa, cio\u00e8 il percentile per ogni taglia, l\u2019ordine in coda e i limiti per persona, sono scritte in un file di configurazione che chiunque pu\u00f2 leggere. Non sono nascoste nella testa di chi pianifica, e non dipendono da come un\u2019AI interpreta i dati.<\/p>\n\n\n\n

Accanto a ogni regola il file indica da dove viene: dalla board, dal lavoro di pianificazione gi\u00e0 esistente, oppure da un\u2019ipotesi. Chi ha la responsabilit\u00e0 del sistema pu\u00f2 quindi leggere una regola, discuterla, cambiarla, e il motore ricalcola applicandola sempre allo stesso modo. Sopra i due motori lavorano l\u2019AI e la persona, con compiti diversi: li descrivo nella sezione successiva.<\/p>\n\n\n\n

Chi fa cosa<\/h2>\n\n\n\n

I due motori calcolano, sempre allo stesso modo sugli stessi dati. Se un numero cambia, \u00e8 perch\u00e9 sono cambiati i dati o \u00e8 cambiata una regola scritta, mai perch\u00e9 qualcuno ha interpretato i dati in modo diverso. L\u2019AI non calcola. Confronta i dati e gli output dei due motori, mette in evidenza le incongruenze e aiuta a riconoscere i pattern che in un elenco lungo non si vedono a occhio. La persona decide le regole e analizza l\u2019esito del confronto.<\/p>\n\n\n\n

Rispetto all\u2019articolo precedente c\u2019\u00e8 un elemento in pi\u00f9, che \u00e8 opportuno tenere distinto. L\u2019AI ha scritto il codice del secondo motore, e la persona l\u2019ha controllato e testato sulla board, verificando che l\u2019output fosse quello previsto dalle regole.<\/p>\n\n\n\n

Cosa \u00e8 emerso<\/h2>\n\n\n\n

Il confronto fatto dall\u2019AI sui dati dei due motori ha fatto emergere alcune domande che fino a quel momento erano rimaste implicite. Alcuni esempi danno bene l\u2019idea di come funziona.<\/p>\n\n\n\n

Il primo riguarda il momento in cui finisce il progetto. Un progetto completato, poi riaperto e chiuso di nuovo, risultava con due durate molto diverse a seconda di quale chiusura si considerava. Il motore di calcolo del Rolling Forecast ne sceglieva una per convenzione, e l\u2019AI ha messo in evidenza l\u2019incongruenza del dato. Cosa significhi \u201cfinito\u201d per un lavoro che torna indietro \u00e8 una policy di processo, e la scelta spetta a una persona.<\/p>\n\n\n\n

Il secondo riguarda i limiti per persona. La policy della board fissa un numero massimo di progetti per ciascuna persona, ma non dice cosa fare quando un progetto \u00e8 assegnato a pi\u00f9 persone. Il motore di calcolo del Rolling Forecast ha bisogno di una regola per prevedere, e nella configurazione \u00e8 stato necessario scriverne una, che per ora resta un\u2019ipotesi: un progetto condiviso vale per ciascuno una frazione, da definire. L\u2019AI ha messo in evidenza l\u2019incongruenza tra ci\u00f2 che la policy dice e ci\u00f2 che il calcolo richiede. Completare la policy spetta a una persona.<\/p>\n\n\n\n

Il terzo riguarda la durata attesa, che si ricava dal percentile dei progetti gi\u00e0 completati della stessa taglia. Qui le incongruenze erano pi\u00f9 d\u2019una: i valori che avevamo ipotizzato inizialmente e quelli misurati non coincidevano per alcune taglie, il percentile si spostava molto a causa di pochi progetti lunghi, e due taglie quasi non si distinguevano per durata. Su quale base calcolare un valore su cui impegnarsi \u00e8 una decisione ancora aperta che spetta a una persona.<\/p>\n\n\n\n

Il confronto serve a capire<\/h2>\n\n\n\n

L\u2019analisi fatta con il supporto dell\u2019AI mette in evidenza le incongruenze, di qualunque tipo siano, e lo fa individuando dei pattern che in un insieme articolato di dati difficilmente si vedono a occhio. Ma l\u2019AI si ferma l\u00ec: segnala delle incongruenze e pu\u00f2 suggerire dei perch\u00e9.<\/p>\n\n\n\n

Ogni incongruenza pu\u00f2 avere pi\u00f9 cause. Pu\u00f2 mancare una policy che il motore non conosce, perch\u00e9 esiste gi\u00e0 nella pratica ma nessuno l\u2019ha mai scritta. Pu\u00f2 non essere aggiornata la board. Oppure pu\u00f2 servire una policy nuova, che finora nessuno aveva avuto bisogno di definire e che il calcolo ha reso necessaria. Capire quale sia la causa, e quindi cosa fare, \u00e8 il compito della persona che conosce davvero il sistema. L\u2019analisi fatta con il supporto dell\u2019AI le d\u00e0 il punto da cui partire per evolvere il sistema, e la comprensione resta della persona.<\/p>\n\n\n\n

Solo dopo aver capito arrivano le decisioni: introdurre una nuova policy, completarne una esistente, aggiornare la board. Ogni decisione di questo tipo rende il funzionamento del sistema pi\u00f9 coerente, e le esecuzioni successive dei motori lo riflettono.<\/p>\n\n\n\n

Conclusione<\/h2>\n\n\n\n

Il caso mostra all\u2019opera l\u2019architettura di cui scrivevo nell\u2019articolo precedente: i motori calcolano su dati puliti, l\u2019AI confronta e individua i pattern, la persona capisce e decide. Le incongruenze emerse riguardano il funzionamento del flusso e le policy del sistema: dove finisce un progetto, come si conta un limite, su quale base si stima una durata. Sono emerse perch\u00e9 i motori applicano sempre le stesse regole e il calcolo ne richiede di esplicite. Rieseguiti sugli stessi dati, producono gli stessi output, e le stesse incongruenze restano visibili. Usando i dati grezzi un\u2019AI avrebbe potuto notarne qualcuna, ma senza regole stabili a ogni domanda avrebbe potuto dare una risposta diversa.<\/p>\n\n\n\n

C\u2019\u00e8 poi un\u2019aggiunta rispetto all\u2019articolo precedente, che riguarda un possibile uso dell\u2019AI: l\u2019AI ha abbassato il costo di costruire un pezzo di motore che mancava, lasciando per\u00f2 il controllo alla persona.<\/p>\n\n\n\n

Ora i due motori girano insieme. A ogni esecuzione producono dati su cui l\u2019AI individua i pattern, e la persona li usa per capire e migliorare il sistema.<\/p>\n\n\n\n

Ho pubblicato originariamente questo articolo per il portale Kanban Help<\/a>, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help<\/a> – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.<\/em><\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Al ritorno dal Kanban Leadership Retreat, ho scritto un articolo, \u201cPerch\u00e9 collegare l\u2019AI ai vostri dati di flusso non basta: le decisioni che qualcuno deve prendere\u201d, su un tema che al retreat aveva occupato molto spazio: qual \u00e8 la corretta architettura per introdurre l\u2019AI in un sistema Kanban. La conclusione era che un agente AI … Continua a leggere Il motore calcola, l\u2019AI confronta, la persona decide: l\u2019applicazione in un caso reale<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[618,8,130,467,4,7,437],"tags":[373,652,211,199,621,99,653,169,440,343],"class_list":["post-2857","post","type-post","status-publish","format-standard","hentry","category-ai-intelligenza-artificiale","category-idee","category-kanban","category-lean","category-project-management","category-riflessioni","category-rolling-forecast","tag-ai","tag-flow-analytics","tag-flusso-di-lavoro","tag-gestione-del-flusso","tag-human-in-the-loop","tag-kanban","tag-motore-di-calcolo","tag-policy","tag-rolling-forecast","tag-wip-limit"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t