Human + AI Operating Model

Foundation e Practitioner Manual · v1.2 · Guido Brosca

1. Origine, dominio e titolarità del metodo

Il Human + AI Operating Model™ colma il vuoto tra strategia AI e lavoro quotidiano. Acquistare modelli, piattaforme o infrastrutture non stabilisce chi risponde di una raccomandazione, quali informazioni siano autorizzate, quando il ruolo digitale debba fermarsi, come gestire un’eccezione e come trasformare l’esperienza in conoscenza aziendale riutilizzabile.

Il dominio del framework è l’intersezione tra management, business process management, organization design, IT governance, data e knowledge governance, AI automation e value management. Il metodo non sostituisce queste discipline: le collega in una sequenza orientata a outcome, processi, decisioni, ruoli, memoria, controlli ed evidenze.

Il framework ha tra i suoi obiettivi quello di condividere con management interno (CEO, CIO, CTO, …) ed operatori del settore (sysyem integrator, advisor, consulenti, software house) un metodo che possa garantire il successo nella realizzazione di progetti di automazione e reingegnerizzazione di processo o creare nuove soluzioni per il mercato che sfruttano l’AI.

Come leggere il dominio del framework

Un operating model descrive il modo in cui un’organizzazione trasforma un intento in lavoro ripetibile: specifica chi decide, chi esegue, quali informazioni vengono utilizzate, come si gestiscono le eccezioni, quali controlli sono necessari e come si misura il risultato. Quando entra l’AI, queste domande non scompaiono; diventano più importanti perché raccomandazioni, contenuti e azioni possono essere prodotti a una velocità e con una variabilità superiori a quelle del lavoro umano tradizionale.

Il Human + AI Operating Model™ tratta quindi l’AI come una capacità organizzativa da inserire in un sistema socio-tecnico. Il termine “Human + AI” non indica una semplice collaborazione tra una persona e un chatbot: indica una configurazione esplicita di processo, decisioni, ruoli umani, Digital Role, Corporate Memory, controlli, tecnologia e misure di valore. Il segno “+” rappresenta l’integrazione progettata tra questi elementi, non la loro mera coesistenza.

Il problema di integrazione che il metodo risolve

Molte iniziative AI iniziano con una domanda incompleta: “Quale modello o piattaforma possiamo adottare?”. La domanda è legittima, ma arriva troppo presto. Prima occorre comprendere quale outcome aziendale deve cambiare, quale processo lo produce, quali decisioni ne determinano la qualità e quale parte del lavoro possa essere assegnata a una capacità digitale senza rendere opaca l’accountability. Se questo passaggio manca, il progetto può produrre una demo convincente ma non un modo di lavorare stabile.

Il vuoto tra strategia e operatività si manifesta tipicamente quando l’organizzazione possiede una dichiarazione di ambizione sull’AI e una soluzione tecnica, ma non dispone di un collegamento verificabile tra le due. Il framework colma tale vuoto attraverso una catena di progettazione: intento e outcome orientano la scelta dei processi; il processo AS-IS fa emergere le decisioni; le decisioni alimentano il redesign; il redesign delimita il Digital Role; governance e Corporate Memory ne rendono il comportamento controllabile; la misurazione stabilisce se il cambiamento merita di proseguire.

Che cos’è il framework e che cosa non è

Il framework integra discipline preesistenti senza appropriarsi delle loro finalità. Per esempio, utilizza il process mapping per comprendere il lavoro reale, ma non pretende di sostituire l’intero body of knowledge del BPM; richiede service readiness, ma non impone un’adozione completa di ITIL; incorpora sicurezza e privacy, ma non sostituisce la valutazione degli specialisti né gli obblighi normativi applicabili. Il suo contributo specifico consiste nel coordinare tali discipline intorno all’introduzione di un Digital Role.

Mappa concettuale integrale: la big picture del framework

Questa mind map riunisce in un’unica vista il perché, il come e il con che cosa del framework. Si legge dal centro verso l’esterno: il nucleo trasforma un problema in valore governato; gli otto rami mostrano le capacità che devono restare collegate affinché una soluzione sia utile, operabile, verificabile e sostenibile nel tempo.

La mappa non sostituisce la sequenza operativa. Funziona come una carta geografica: pilastri e Corporate Memory descrivono ciò che va progettato; lifecycle, gate e workshop indicano quando decidere; checklist, deliverable e registri rendono ogni decisione dimostrabile; modalità e overlay adattano la profondità dei controlli senza creare un secondo metodo.

Titolarità, neutralità e possibilità di evoluzione

La titolarità del framework è attribuita a Guido Brosca. Questa indicazione distingue la proprietà della foundation, dei concetti canonici e del toolkit dagli output specifici creati per un cliente e dalle componenti tecniche fornite da eventuali partner. La neutralità rispetto ai vendor consente di scegliere infrastrutture e strumenti dopo aver definito il target operating model, evitando che le caratteristiche di un prodotto diventino implicitamente le regole dell’organizzazione.

Caso reale ricorrente del manuale: Buyer Assistant

Buyer Assistant opera sul processo di riordino di un distributore IT con circa 8.000 prodotti e 120 brand. I buyer combinano dati dall’ERP, indicatori dall’analisi quantitativa e statistica, storico, disponibilità, lead time, promozioni, prezzo di acquisto e vendita, rotazione e conoscenza operativa espressa verbalmente. La pipeline elabora più di 50 indicatori e prepara raccomandazioni motivate, lasciando al buyer la verifica e la decisione finale.

Il framework non assume che l’automazione completa sia la soluzione. Nei capitoli successivi il caso verrà trasformato progressivamente: l’ambizione generica diventerà un outcome; il processo verrà osservato; le decisioni di riordino saranno scomposte; verrà progettato un Digital Role con autonomia limitata; controlli, memoria e KPI saranno definiti prima del pilot.

Applicazione sul campo: orientare la prima conversazione

Il capitolo 1 non produce ancora uno dei deliverable di engagement. Fornisce però il frame con cui il [R09 - Framework Facilitator] conduce le prime conversazioni e impedisce che l’incarico venga definito prematuramente come acquisto o sviluppo di una soluzione. La conversazione iniziale dovrebbe verificare se il cliente è disposto a discutere il sistema di lavoro e non soltanto la tecnologia:

1. Chiedere quale risultato aziendale si desidera modificare e perché è prioritario adesso.

2. Chiedere quale processo produce oggi quel risultato e chi ne risponde end-to-end.

3. Individuare almeno una decisione o un punto di giudizio che influenza l’outcome.

4. Verificare se il cliente accetta di osservare il processo reale, incluse varianti ed eccezioni.

5. Spiegare che tecnologia, livello di autonomia e partner verranno scelti dopo il target design.

6. Registrare assunzioni, vincoli e questioni aperte che dovranno essere verificate in [F01 - Orient] e [F02 - Assess].

Domande di verifica

Il problema è espresso come outcome e processo oppure soltanto come desiderio di acquistare AI?

È chiaro quale disciplina specialistica dovrà integrare il framework senza esserne sostituita?

Il committente accetta che l’assessment possa raccomandare process redesign, dati o automazione tradizionale prima dell’AI?

È preservata la distinzione tra foundation, output del cliente e componenti di partner o terze parti?

2. Tesi e principi normativi

Decision-first, ma process-grounded: si analizzano le decisioni dopo avere compreso il processo AS-IS che le genera.

Processes before AI: il processo target viene ridisegnato prima di assegnare capacità al ruolo digitale.

Digital Roles, not chatbots: ogni capacità AI riceve mandato, owner, limiti, KPI, escalation e regole di change.

Corporate Memory by design: fonti, razionali, eccezioni, esiti e apprendimento devono essere governati lungo tutto il lifecycle.

Governance proportional to impact: supervisione e controlli crescono con impatto, irreversibilità, autonomia e incertezza.

Value must be falsifiable: baseline, target e stop criteria sono definiti prima del pilot.

Technology is a consequence: architettura e vendor vengono selezionati dopo il target operating model.

No AI by default: l’assessment può concludere che servano prima standardizzazione, qualità dei dati, process redesign o automazione tradizionale.

Come usare i principi normativi

I principi normativi non sono slogan promozionali. Sono vincoli di progettazione utilizzati per valutare scelte, deliverable e richieste del cliente lungo l’intero engagement. Una soluzione può essere tecnicamente fattibile e tuttavia non conforme al metodo se, per esempio, assegna autonomia senza owner, misura il successo soltanto dopo il pilot o pubblica conoscenza non validata nella Corporate Memory.

Il consulente deve richiamare il principio pertinente quando formula una raccomandazione o rifiuta una scorciatoia. Non è sufficiente dichiarare che una scelta “non è consigliata”: occorre spiegare quale rischio organizzativo introduce, quale evidenza manca e quale remediation renderebbe la scelta accettabile. I principi diventano così criteri di coerenza condivisi, non opinioni personali del facilitatore.

Decision-first, ma process-grounded

La decisione è l’unità privilegiata di analisi perché concentra alternative, informazioni, responsabilità e conseguenze. Tuttavia una decisione isolata dal processo perde trigger, vincoli, handoff e condizioni reali. Per questo [P02 - Decision Mapping] inizia solo dopo [TR01 - Process screening e AS-IS Process Discovery].

Esempio. Nel Buyer Assistant, per esempio, “quanto ordinare” non è trattato come una formula astratta: il metodo osserva quando il buyer avvia l’analisi, quali eccezioni considera, quali dati corregge e che cosa accade dopo l’approvazione.

Processes before AI

L’AI non deve congelare inefficienze storiche. Prima si stabilisce quale lavoro sia ancora necessario, quali attività possano essere eliminate o semplificate e dove debbano trovarsi informazioni e controlli. Soltanto il processo target autorizza l’assegnazione delle capacità al Digital Role.

Esempio. Se due buyer copiano gli stessi dati tra fogli e ERP, il redesign elimina la duplicazione prima di chiedere all’AI di replicarla più velocemente.

Digital Roles, not chatbots

Una capacità diventa organizzativamente reale quando possiede un purpose, un owner, input e output ammessi, azioni vietate, autonomia differenziata, escalation, KPI e regole di change. Un agente o un’interfaccia conversazionale possono esistere, ma non definiscono da sola un ruolo.

Esempio. Nel Buyer Assistant, il ruolo digitale propone quantità e motivazioni, ma non modifica listini né invia autonomamente ordini. Le azioni sono attribuite e controllate separatamente.

Corporate Memory by design

Fonti, regole, eccezioni, feedback ed esiti devono avere owner, provenienza, stato e lifecycle. Memorizzare tutto non equivale ad apprendere: una lesson diventa riutilizzabile soltanto dopo validazione e pubblicazione governata.

Esempio. La nota “questo fornitore consegna spesso in ritardo” non entra come regola permanente perché compare in una chat; viene collegata a evidenze, validata dal responsabile e versionata.

Governance proportional to impact

Autonomia, frequenza di approvazione, profondità dei log e controlli aumentano con impatto, irreversibilità, incertezza e sensibilità dei dati. La proporzionalità evita sia controlli insufficienti sia burocrazia indiscriminata.

Esempio. Una proposta di riordino da 400 euro può richiedere conferma semplificata; una proposta da 80.000 euro o relativa a un articolo critico richiede soglie, approvazione ed escalation più forti.

Value must be falsifiable

L’ipotesi di valore deve poter essere smentita. Baseline, formula, target, periodo, costi, tolleranze e stop condition vengono definiti prima di osservare i risultati, così il successo non può essere ridefinito a posteriori.

Esempio. Nel Buyer Assistant, il feedback positivo degli utenti non è l’unica prova: vengono distinti tempo macchina, tempo di verifica del buyer, override, qualità della raccomandazione, stock-out, overstock e costo di supervisione.

Technology is a consequence

Modelli, architetture e vendor vengono selezionati in base ai requisiti generati dal target operating model: dati autorizzati, latenza, integrazioni, volumi, audit, sicurezza, costi e continuità. La tecnologia abilita il disegno; non lo sostituisce.

Esempio. La scelta tra cloud, on-premise o soluzione ibrida viene effettuata dopo aver chiarito quali dati di acquisto possono uscire dal perimetro, quale latenza serve e come devono essere registrate le decisioni.

No AI by default

Il framework mantiene aperta l’alternativa “non usare ancora l’AI”. Se il problema dipende da dati incoerenti, processo instabile o regole deterministiche, la remediation corretta può essere data quality, standardizzazione, reporting o automazione tradizionale.

Esempio. Nel Buyer Assistant, una disponibilità ERP non aggiornata o una promozione non registrata vengono trattate come eccezioni esplicite: un modello più sofisticato non deve amplificare un dato incoerente.

Procedura per applicare i principi a una scelta

1. Descrivere la scelta in termini osservabili: che cosa si vuole fare, su quale processo, con quale autonomia e per quale outcome.

2. Individuare i principi pertinenti e il rischio che ciascuno intende controllare.

3. Raccogliere l’evidenza necessaria per verificare la conformità, evitando valutazioni fondate soltanto su dichiarazioni.

4. Se emerge una non conformità, definire remediation, owner e scadenza oppure limitare il perimetro e l’autonomia.

5. Registrare nei deliverable e nei gate il principio utilizzato, la decisione assunta e l’eventuale rischio residuo.

Caso ricorrente: dal mandato tool-first a un problema verificabile

Nel progetto Buyer Assistant, l’ambizione di automatizzare il lavoro di approvvigionamento è stata riformulata in un outcome verificabile: aumentare la capacità dei buyer e migliorare precisione e coerenza delle valutazioni, senza delegare l’approvazione dell’ordine né aumentare il rischio oltre le soglie autorizzate.

La riformulazione non decide ancora che serva l’AI. Crea un outcome, introduce un guardrail economico e consente di cercare processi e decisioni pertinenti. Il capitolo successivo stabilirà se l’organizzazione, l’engagement e il processo candidato possiedono condizioni sufficienti per procedere con la vera automazione AI.

Criteri di comprensione e applicazione

Ogni principio è collegato a una conseguenza pratica e non viene usato come slogan generico.

Il consulente sa spiegare quale rischio viene introdotto quando un principio non è rispettato.

Le eccezioni ai principi non sono implicite: diventano limitazioni, remediation, waiver o decisioni di rischio tracciate.

La selezione tecnologica resta subordinata ai requisiti del target operating model.

L’alternativa no-AI rimane praticabile fino a quando l’evidenza non giustifica un Digital Role.

3. Target, stakeholder e tre livelli di fit

I criteri di fit non riguardano soltanto il primo pilot. Servono a tre decisioni diverse e devono essere riesaminati quando cambia il perimetro, entra un nuovo dipartimento o viene candidato un altro processo.

Il fit risponde a tre domande che sembrano simili ma sostengono decisioni diverse. [FIT01 - Organizational Fit] verifica se l’impresa possiede priorità, sponsorship e capacità minime per avviare un percorso Human + AI. [FIT02 - Engagement Fit] controlla se lo specifico incarico è eseguibile: owner, accesso a persone e fonti, perimetro, tempo e decisione richiesta. [FIT03 - Candidate Process & Pilot Fit] valuta infine se il processo candidato può essere compreso, circoscritto e sperimentato senza esporre l’organizzazione a rischi non governati.

Trattarli come un unico punteggio nasconde problemi importanti. Un’organizzazione può essere pronta ma proporre un caso senza dati; un engagement può avere sponsor e budget ma nessun Process Owner; un processo può essere promettente ma non reversibile. Il practitioner deve quindi chiudere tre serrature diverse: la chiave che apre una non compensa quella mancante nelle altre.

Ogni verifica produce uno dei tre esiti: avanzare, avanzare con condizioni oppure preparare/rinviare. Le condizioni devono indicare azione, owner, scadenza ed evidenza di chiusura; un anti-fit non viene mediato da altri punti positivi.

Che cosa significa pilot circoscritto, reversibile, osservabile e dotato di fallback

Un pilot è circoscritto quando dichiara con precisione utenti, sedi, prodotti, casistiche, volumi, sistemi, dati, decisioni e durata inclusi ed esclusi. È reversibile quando può essere sospeso senza produrre un danno non accettabile e il processo può tornare a una modalità nota. È osservabile quando input, output, tempi, errori, override, costi ed esiti possono essere ricostruiti. È dotato di fallback quando il lavoro può proseguire, con capacità e responsabilità definite, anche se l’AI è indisponibile, incerta o fuori soglia.

Il pilot funziona come una galleria del vento: non deve imitare tutta la produzione, ma deve riprodurre le condizioni decisive in modo controllato e misurabile. Se è piccolo ma non rappresentativo produce falsa sicurezza; se è realistico ma non reversibile espone l’azienda prima di avere evidenze sufficienti. La tabella seguente traduce questi principi in requisiti verificabili.

Perché il fit è articolato su tre livelli

Il termine fit indica la compatibilità tra il metodo e le condizioni reali in cui dovrebbe essere applicato. Un’organizzazione può essere un buon target per il framework e, nello stesso tempo, non essere pronta a mobilitare uno specifico engagement; analogamente, un engagement ben sponsorizzato può proporre un processo inadatto a un pilot. Separare [FIT01 - Organizational Fit], [FIT02 - Engagement Fit] e [FIT03 - Candidate Process & Pilot Fit] impedisce che una condizione positiva compensi impropriamente una criticità di livello diverso.

Il fit non è un’etichetta permanente. Deve essere rivalutato quando cambiano sponsor, perimetro, disponibilità delle evidenze, dipartimento, processo candidato o livello di autonomia richiesto. La rivalutazione può produrre quattro esiti: procedere, procedere con condizioni, rinviare per remediation oppure non accettare il caso.

[FIT01 - Organizational Fit] — l’azienda può sostenere il percorso?

Valuta se l’organizzazione possiede una motivazione abbastanza concreta, sponsorship, disponibilità a ridisegnare il lavoro e una capacità minima di assumere ownership e rischio. Non richiede maturità elevata: una PMI può partire con pratiche semplici, purché accetti ruoli chiari, evidenze e gate.

Segnali minimi da cercare:

Una priorità aziendale esplicita

Un executive sponsor raggiungibile

Disponibilità a coinvolgere process owner e utenti

Accettazione dell’esito no-AI o di una remediation preliminare

[FIT02 - Engagement Fit] — possiamo eseguire correttamente l’incarico?

Valuta le condizioni operative del lavoro consulenziale: decisione richiesta, scope, owner, accesso a persone e fonti, disponibilità di tempo, vincoli e regole di collaborazione. Un buon problema non è sufficiente se il consulente non può osservare il processo o se nessuno è autorizzato a validare gli output.

Segnali minimi da cercare:

Decisione finale attesa e [R02 - Accountable Decision Owner] identificato

Accesso a process owner, key user e sistemi pertinenti

Perimetro e assunzioni iniziali espliciti

Tempo e disponibilità per workshop, evidenze e remediation

[FIT03 - Candidate Process & Pilot Fit] — il caso è valutabile e sperimentabile?

Valuta un processo specifico. Il processo deve essere ricostruibile, contenere un outcome misurabile, consentire un pilot delimitato e offrire dati ed eventi sufficienti a osservare il comportamento. Il requisito va verificato per ogni nuovo processo, anche se l’azienda ha già completato con successo un altro pilot.

Segnali minimi da cercare:

AS-IS e varianti ricostruibili

Baseline o piano realistico per costruirla

Pilot boundary circoscritto

Fallback e capacità umana praticabile

Input, output e risultati osservabili

Stakeholder da coinvolgere e responsabilità nel fit

Il set di ruoli non è una RACI rigida: è un controllo di copertura. Nelle PMI una persona può ricoprire più ruoli, ma le decisioni devono restare distinguibili. Se il responsabile IT coincide con il Service Owner e con il Technical Lead, il Gate Decision Record deve chiarire con quale mandato approva, esegue o accetta un rischio.

Procedura di verifica del fit

1. Definire la decisione che la verifica deve supportare: mobilitare il programma, avviare l’engagement o selezionare un processo.

2. Raccogliere dichiarazioni preliminari, distinguendole dalle evidenze verificabili.

3. Intervistare almeno sponsor, owner e una persona che esegue realmente il processo candidato.

4. Classificare gap e anti-fit per livello [FIT01 - Organizational Fit], [FIT02 - Engagement Fit] o [FIT03 - Candidate Process & Pilot Fit], senza mediarli in un unico giudizio generico.

5. Per ogni gap recuperabile, definire remediation, owner, data attesa ed evidenza di chiusura.

6. Formulare un esito esplicito: proceed, proceed with conditions, defer/remediate oppure reject.

7. Registrare l’esito e le condizioni nel materiale che alimenta [G00 - Mobilize] o [G01 - Select].

Esempio di applicazione della procedura:

Come valutare la forza dell’evidenza

Progettare un pilot realmente controllabile

I requisiti [PIL01]–[PIL07 - Recovery] formano un sistema. Un perimetro può essere piccolo ma non osservabile; un fallback può esistere sulla carta ma essere impraticabile se il personale non ha capacità per assorbire la coda; un rollback tecnico può ripristinare una configurazione senza poter annullare un ordine già inviato. Il consulente deve quindi verificare la coerenza dell’insieme e non limitarsi a spuntare requisiti indipendenti.

La pilot boundary deve includere non soltanto utenti e durata, ma anche decisioni, valori economici, dati, sistemi, canali e casistiche. Le esclusioni sono importanti quanto le inclusioni: rendono chiaro che cosa non è stato provato e impediscono di generalizzare i risultati oltre la popolazione osservata.

Il perimetro è circoscritto, reversibile e osservabile. Prima dell’estensione vengono verificati fallback al processo manuale, stop condition, recovery, qualità della baseline e completezza dei log.

Caso ricorrente: esito della verifica iniziale

Il Buyer Assistant presenta [FIT01 - Organizational Fit] positivo: il problema è prioritario, sponsor e owner sono disponibili e il processo può essere ridisegnato. [FIT02 - Engagement Fit] è positivo per accesso a fonti, buyer e team tecnico. [FIT03 - Candidate Process & Pilot Fit] è positivo nel perimetro a raccomandazione controllata; nuovi prodotti, promozioni eccezionali e serie insufficienti seguono route dedicate.

La decisione corretta non è né “sì” né “no” all’intero progetto. È “mobilitare con condizioni”: nominare formalmente [R04 - Process Owner], assicurare l’accesso alle fonti e limitare la prima wave. In questo modo il fit diventa una decisione operativa e non un giudizio commerciale generico.

Gestire anti-fit e rinvio

Un anti-fit è una condizione incompatibile con un avanzamento responsabile: per esempio assenza di owner, impossibilità di osservare l’esito, richiesta di autonomia elevata senza fallback o rifiuto di accedere al processo reale. Non deve essere diluito da punteggi positivi su aspetti meno critici. Il facilitatore lo registra, spiega l’impatto e indica se esista una remediation realistica.

Rinviare non equivale a fallire l’engagement. Per una PMI può essere il risultato più utile: chiarisce quali capacità minime costruire prima di investire in sviluppo o integrazione. Un rinvio ben formulato contiene il gap, l’owner, l’azione, l’evidenza richiesta e il punto in cui la decisione verrà riesaminata.

Criteri di completamento del capitolo

[FIT01 - Organizational Fit], [FIT02 - Engagement Fit] e [FIT03 - Candidate Process & Pilot Fit] sono valutati separatamente e collegati alla decisione corretta.

Sponsor, Decision Owner, Process Owner e key user hanno contribuito con prospettive distinguibili.

Le conclusioni separano evidenze forti, parziali, segnali deboli e dichiarazioni non verificate.

Il pilot boundary esplicita inclusioni, esclusioni, decisioni, dati, durata, utenti, sistemi e soglie.

Fallback, rollback, stop condition e recovery non vengono confusi tra loro.

Gap e anti-fit generano condizioni, remediation, rinvio o rifiuto; non vengono nascosti nella media dello score.

Esempio completo — verifica del fit per un assistente di riordino

Una media impresa distributiva vuole assistere i buyer nella proposta d’ordine. [FIT01 - Organizational Fit] è positivo perché esistono priorità su capitale circolante, sponsor executive e capacità IT minima. [FIT02 - Engagement Fit] è positivo con condizioni: il Process Owner è nominato, ma l’accesso allo storico promozionale deve essere completato entro due settimane. [FIT03 - Candidate Process & Pilot Fit] è autorizzabile su tre brand e 255 SKU, non sull’intero catalogo.

4. Architettura del framework e transizioni

Vista armonica della versione 1.2

I sei pilastri descrivono ciò che deve essere progettato; non costituiscono sei workshop né una sequenza waterfall rigida. Il lavoro avanza attraverso transizioni esplicite: l’output di un passaggio diventa l’input verificato del successivo e può generare un ritorno controllato quando emergono lacune.

Il passaggio più importante è [TR01 - Process screening e AS-IS Process Discovery]. Lo Strategic Intent non produce direttamente una Decision Map. Produce criteri per cercare i processi rilevanti; il consulente esegue process screening, seleziona i candidati, documenta il processo AS-IS e solo allora individua dove persone o sistemi scelgono tra alternative.

Pilastri, transizioni e strumenti: entità diverse

L’architettura del framework è più facile da utilizzare quando si distingue ciò che deve essere progettato da ciò che organizza il lavoro. I sei pilastri rappresentano dimensioni del target operating model; le transizioni stabiliscono quando un output è sufficientemente solido per alimentare il pilastro successivo; lifecycle, servizi, attività, workshop, checklist, deliverable e gate organizzano invece l’esecuzione e la decisione.

Come scorre il lavoro attraverso l’architettura

1. [P01 - Strategic Intent] definisce outcome, priorità, sponsor, risk appetite e limiti; non seleziona direttamente la soluzione.

2. [TR01] ricerca i processi rilevanti, ricostruisce l’AS-IS e rende visibili le decisioni reali.

3. [P02 - Decision Mapping] analizza decision unit, alternative, informazioni, regole, errori, owner ed eccezioni.

4. [P03 - Process Redesign] costruisce un target process migliore, incluse varianti, handoff, fallback e recovery.

5. [P04 - Digital Role Design] assegna capacità, autonomia e limiti al ruolo digitale coerentemente con il target process.

6. [P05 - Governance & Trust] traduce impatto e autonomia in accountability, controlli, service readiness e risk decision.

7. [P06 - Value Measurement] rende falsificabile il beneficio e strumenta il pilot con baseline, KPI e criteri decisionali.

8. [CM01 - Corporate Memory] conserva fonti, razionali, eccezioni, esiti e lesson validate, alimentando la successiva iterazione.

[TR01 - Process screening e AS-IS Process Discovery] come ponte obbligatorio tra intento e decisioni

[TR01 - Process screening e AS-IS Process Discovery] è la transizione più delicata perché evita un salto logico frequente: passare da un outcome strategico a un elenco teorico di decisioni o funzionalità AI. Lo Strategic Intent indica dove cercare; il process screening confronta processi candidati; l’AS-IS Process Discovery ricostruisce il lavoro reale; soltanto a quel punto si produce il Decision Inventory.

L’AS-IS sufficiente non deve necessariamente essere una modellazione esaustiva di tutta l’azienda. Deve però rappresentare confini, trigger, attori, sistemi, oggetti informativi, varianti, attese, errori, workaround ed esiti necessari a comprendere le decisioni selezionate. Il livello di dettaglio è quindi guidato dalla decisione da progettare, non dal desiderio di documentare ogni attività.

Il passaggio è chiuso solo quando il Decision Owner può spiegare perché quel processo è stato scelto, il Process Owner riconosce l’AS-IS rappresentato e le decisioni candidate sono osservabili. Una lista di funzionalità AI non soddisfa TR01.

Le altre transizioni come contratti di passaggio

Ogni transizione può essere trattata come un piccolo contratto tra due passaggi del metodo: dichiara input, lavoro da svolgere, output, owner della validazione e questioni non risolte. Il criterio di passaggio non richiede perfezione assoluta, ma sufficienza rispetto alla decisione successiva. I gap residui devono essere visibili e non trasferiti implicitamente.

Esempio: l’obiettivo ‘ridurre il capitale immobilizzato’ non autorizza ancora a progettare un agente di riordino. [TR01 - Dall’intento al processo osservato] richiede di confrontare i processi candidati, ricostruire il riordino AS-IS, osservare eccezioni e workaround e isolare le decisioni ‘se ordinare’, ‘quanto ordinare’ e ‘quando derogare’. Solo allora [P02 - Decision Mapping] riceve un oggetto analizzabile.

Iterazione controllata, non waterfall

La sequenza dei pilastri indica dipendenze logiche, non un piano waterfall immutabile. Durante [P02 - Decision Mapping] può emergere una variante di processo che richiede nuovo discovery; durante [P05 - Governance & Trust] un controllo troppo costoso può richiedere la riduzione dell’autonomia in [P04 - Digital Role Design]; durante il pilot un pattern di override può far rivedere il target process o una fonte della Corporate Memory.

Un ritorno è controllato quando ne sono espliciti il trigger, l’oggetto da rivedere, l’owner, gli artefatti impattati e la nuova decisione richiesta. La semplice modifica informale di un output già approvato rompe la tracciabilità; una revisione versionata preserva invece il razionale e consente di comprendere perché il disegno è cambiato.

Caso ricorrente: attraversamento dei pilastri

Procedura practitioner per chiudere una transizione

1. Individuare la transizione e la decisione che deve rendere possibile.

2. Elencare gli input attesi e verificarne versione, owner e copertura.

3. Eseguire attività e workshop pertinenti senza confondere il workshop con il risultato.

4. Consolidare le conclusioni nei deliverable canonici, collegandole a Question ID ed Evidence ID quando applicabile.

5. Verificare il criterio di passaggio e rendere espliciti gap, assunzioni e limitazioni residue.

6. Ottenere la validazione dell’owner competente e aggiornare le versioni degli artefatti impattati.

7. Avanzare, tornare a un passaggio precedente oppure proporre una decisione al gate pertinente.

Criteri di completamento del capitolo

Il lettore sa distinguere pilastri, transizioni, fasi, servizi, workshop, checklist, deliverable e gate.

[TR01 - Process screening e AS-IS Process Discovery] include screening e AS-IS Process Discovery prima del Decision Mapping.

Ogni passaggio utilizza output verificati e non trasferisce implicitamente gap al pilastro successivo.

Le iterazioni sono versionate e motivate; non sono modifiche informali a output già validati.

[CM01 - Corporate Memory] attraversa l’intera architettura senza diventare un settimo pilastro.

Il caso può avanzare, ritornare, essere limitato o fermato in funzione dell’evidenza.

Esempio completo — attraversamento controllato dell’architettura

Nel Buyer Assistant, [P01 - Strategic Intent] fissa l’outcome: aumentare capacità e precisione del buyer senza delegare l’ordine. [TR01 - Dall’intento al processo osservato] seleziona il riordino, ricostruisce report, eccezioni e decisioni. [P02 - Decision Mapping] separa ‘se’, ‘quando’ e ‘quanto’ ordinare; [TR02 - Dalla decisione al processo target] trasferisce tali decisioni nel redesign.

[P03 - Process Redesign] elimina copie manuali, crea la coda di eccezioni e mantiene l’approvazione del buyer. [TR03 - Dal processo al ruolo digitale] assegna al ruolo digitale capacità di analisi e raccomandazione. [P04 - Digital Role Design] definisce AL1 Recommend e MA1 Propose; [TR04 - Dal ruolo ai controlli] traduce limiti e permessi in guardrail, logging e override.

[P05 - Governance & Trust] rende il servizio supportabile e reversibile; [TR05 - Dai controlli alla misura] collega eventi e soglie ai KPI. [P06 - Value Measurement] confronta capacità, qualità, rischio, adozione e TCO. [TR06 - Dall’evidenza all’apprendimento] produce decisione, remediation e lesson validate per la Corporate Memory. Ogni ritorno a un pilastro precedente è versionato e motivato.

5. [P01 - Strategic Intent]

Applicazione alle due modalità

Lo Strategic Intent traduce l’ambizione aziendale sull’AI in un mandato di trasformazione verificabile. Stabilisce quale outcome deve migliorare, quale capacità o dominio di processo è interessato, perché l’intervento è prioritario, chi ne risponde, quale rischio l’organizzazione è disposta ad assumere e quali limiti non possono essere superati. Non decide in anticipo che l’AI sia la soluzione corretta.

Scheda operativa

Attività passo per passo

1. [ACT-F01-01] Raccogliere obiettivi, problemi, vincoli e iniziative già attive.

2. [ACT-F01-02] Formulare outcome e decisione richiesta senza nominare una tecnologia.

3. [ACT-F01-03] Identificare sponsor, accountable owner e stakeholder influenzati.

4. [ACT-F01-04] Esplicitare risk appetite, non-negotiable principles e condizioni di stop.

5. [ACT-F01-05] Definire i criteri con cui selezionare processi e use case.

6. [ACT-F01-06] Approvare [DLV09 - Intent & Outcome Charter] e autorizzare il process screening.

Domande da porre

Quale risultato aziendale deve cambiare e perché adesso?

Quale decisione sarà presa al termine dell’engagement?

Che cosa non deve essere compromesso, anche se l’AI funzionasse?

Quale rischio è accettabile e quale richiede escalation?

Come sapremo che il problema richiede AI e non solo standardizzazione o automazione tradizionale?

Errori frequenti e anti-pattern

Partire da un prodotto già scelto.

Usare obiettivi vaghi come ‘innovare con l’AI’.

Confondere sponsor con owner operativo.

Definire target senza baseline possibile.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a tradurre ambizione, outcome, vincoli e risk appetite in un mandato verificabile. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Trasformare l’ambizione in un mandato falsificabile: outcome, sponsor, confini, risk appetite e decisione richiesta.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è tradurre ambizione, outcome, vincoli e risk appetite in un mandato verificabile.

In [WS00 - Executive Orientation] compilare [DLV09 - Intent & Outcome Charter], distinguere outcome da output, registrare assunzioni in [DLV10 - Evidence Register] e decidere [G00 - Mobilize].

Vedere in pratica — Buyer Assistant

Il caso mostra come tradurre ambizione, outcome, vincoli e risk appetite in un mandato verificabile senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant sostituisce “automatizzare gli acquisti” con “ridurre stock-out e tempo di analisi senza delegare l’approvazione dell’ordine”.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile tradurre ambizione, outcome, vincoli e risk appetite in un mandato verificabile; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Outcome e decisione richiesta sono misurabili.

Sponsor, owner e confini sono nominati.

Anti-goal e risk appetite sono espliciti.

6. [P02 - Decision Mapping]

Applicazione alle due modalità

Il Decision Mapping è conseguenza dell’AS-IS Process Discovery. Prima si documenta come il lavoro avviene realmente; poi si individuano i punti nei quali una persona o un sistema sceglie tra alternative. Una trasformazione, un calcolo deterministico o l’applicazione meccanica di una regola non sono automaticamente decisioni.

Scheda operativa

Attività passo per passo

1. [ACT-F02-01] Validare trigger, confini, output e varianti del processo AS-IS.

2. [ACT-F02-02] Marcare task, handoff, attese, eccezioni e punti di scelta.

3. [ACT-F02-03] Creare il decision inventory e distinguere decisioni da calcoli o regole automatiche.

4. [ACT-F02-04] Selezionare le decision unit per impatto, frequenza, incertezza e reversibilità.

5. [ACT-F02-05] Documentare trigger, alternative, informazioni, regole, conoscenza tacita ed error taxonomy.

6. [ACT-F02-06] Proporre ruolo AI e livello iniziale di autonomia senza autorizzarli.

7. [ACT-F02-07] Validare [DLV03 - Decision Map] con Decision Owner e Process Owner.

Domande da porre

In quale punto qualcuno potrebbe scegliere diversamente a parità di input?

Quali alternative sono realmente disponibili?

Quali informazioni vengono usate, da dove provengono e quanto sono affidabili?

Quali regole sono esplicite e quali dipendono dall’esperienza?

Che cosa accade se la decisione è errata, tardiva o non presa?

La decisione è reversibile e chi può fare override?

Quali elementi devono essere conservati nella decision memory?

Errori frequenti e anti-pattern

Intervistare soltanto il manager e non chi esegue il lavoro.

Descrivere decisioni astratte non collocate nel flusso.

Confondere un calcolo con una decisione.

Assegnare autonomia prima di avere analizzato impatto ed eccezioni.

Artefatti distinti del Decision Mapping

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a scomporre il lavoro reale in decisioni osservabili con owner, regole, eccezioni e informazioni. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Il Decision Mapping parte dal processo osservato: una decisione isolata perde trigger, attese, workaround ed eccezioni.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è scomporre il lavoro reale in decisioni osservabili con owner, regole, eccezioni e informazioni.

Dopo [WS02 - AS-IS Process Discovery], scomporre le decision unit in [WS03 - Decision Walkthrough]; per ciascuna registrare alternative, informazioni, regole, error cost, owner ed escalation in [DLV03 - Decision Map].

Vedere in pratica — Buyer Assistant

Il caso mostra come scomporre il lavoro reale in decisioni osservabili con owner, regole, eccezioni e informazioni senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant scopre che il buyer non decide soltanto “quanto ordinare”: decide anche se escludere una promozione, se fidarsi del lead time e quando chiedere conferma al commerciale.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile scomporre il lavoro reale in decisioni osservabili con owner, regole, eccezioni e informazioni; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

L’AS-IS è approvato prima della Decision Map.

Ogni decision unit ha un owner umano.

Eccezioni e costo dell’errore sono osservabili.

7. [P03 - Process Redesign]

Applicazione alle due modalità

Il Process Redesign costruisce il processo target a partire da outcome, AS-IS e Decision Map. Il consulente elimina lavoro non necessario, sposta informazioni nel punto della decisione, ridisegna handoff e controlli e rappresenta sia l’happy path sia eccezioni, fallback, rollback e recovery.

L’happy path è il percorso nominale in cui input, sistemi e regole si comportano come previsto. È utile per comprendere la sequenza principale, ma da solo non descrive un processo reale. Il fallback è il percorso alternativo che mantiene il lavoro operativo quando l’AI non può o non deve procedere; per esempio, il buyer torna al report manuale o riceve soltanto i dati grezzi.

Il rollback riporta una configurazione, una decisione non ancora eseguita o un dato a uno stato precedente noto. Non sempre può annullare l’effetto nel mondo reale: un ordine già trasmesso può richiedere una procedura di storno. Il recovery comprende le attività necessarie per ristabilire servizio e processo dopo l’errore — riconciliare dati, smaltire la coda, informare gli utenti e verificare che i controlli siano di nuovo efficaci.

Scheda operativa

Attività passo per passo

1. [ACT-F03-01] Confermare problemi e cause del processo AS-IS.

2. [ACT-F03-02] Eliminare, semplificare, accorpare o parallelizzare attività.

3. [ACT-F03-03] Ricollocare decisioni e informazioni nel punto di lavoro corretto.

4. [ACT-F03-04] Disegnare handoff Human + AI ed eccezioni.

5. [ACT-F03-05] Definire pilot boundary, fallback, rollback, stop e recovery.

6. [ACT-F03-06] Validare scenari e criteri di accettazione.

Domande da porre

Quali passaggi esistono solo per limiti storici?

Quali attese o rilavorazioni possono essere eliminate?

Dove è necessario il giudizio umano?

Che cosa accade nei casi incompleti, conflittuali o urgenti?

Il processo resta praticabile se il ruolo digitale viene sospeso?

Errori frequenti e anti-pattern

Automatizzare l’AS-IS senza ridisegno.

Disegnare solo l’happy path.

Spostare responsabilità senza nominarne l’owner.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a ridisegnare il processo prima di assegnare capacità all’AI e governare handoff ed eccezioni. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Il target process elimina lavoro inutile prima di assegnare capacità all’AI; conserva handoff, fallback e rollback necessari.

Un handoff è il punto in cui lavoro, informazione o responsabilità passa tra persone, ruoli digitali o sistemi. Ogni handoff può introdurre attesa, perdita di contesto e ambiguità: va quindi descritto indicando oggetto trasferito, mittente, destinatario, condizione di completezza, tempo atteso ed escalation. Nel Buyer Assistant, la proposta passa dal ruolo digitale al buyer insieme a fonti e razionale; senza questi elementi l’handoff è formalmente avvenuto, ma non è verificabile.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è ridisegnare il processo prima di assegnare capacità all’AI e governare handoff ed eccezioni.

In [WS04 - Process Redesign] confrontare AS-IS e target, rimuovere copie e attese, posizionare controlli nel punto di lavoro e aggiornare [DLV02 - Candidate Process Card].

Vedere in pratica — Buyer Assistant

Il caso mostra come ridisegnare il processo prima di assegnare capacità all’AI e governare handoff ed eccezioni senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant elimina il doppio trasferimento Excel–ERP; il ruolo digitale prepara una coda di eccezioni e il buyer approva soltanto i casi rilevanti.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile ridisegnare il processo prima di assegnare capacità all’AI e governare handoff ed eccezioni; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Il target non replica sprechi dell’AS-IS.

Handoff Human + AI e fallback sono testabili.

Il Process Owner approva il nuovo flusso.

8. [P04 - Digital Role Design]

Applicazione alle due modalità

Il Digital Role è una capacità AI formalmente inserita nel processo. Il suo design traduce il target process in un mandato operativo: ciò che può osservare, produrre e fare; ciò che non può fare; chi ne risponde; come viene supervisionato e modificato.

Scheda operativa

Attività passo per passo

1. [ACT-F03-07] Definire purpose, utenti e outcome del ruolo.

2. [ACT-F03-08] Collegare task e decisioni al processo target.

3. [ACT-F03-09] Specificare input, output, strumenti e permessi minimi.

4. [ACT-F03-10] Assegnare autonomia per singola decisione o azione.

5. [ACT-F03-11] Definire negative requirements, escalation e human oversight.

6. [ACT-F03-12] Assegnare memory authority e change authority.

7. [ACT-F03-13] Approvare KPI e criteri di accettazione.

Domande da porre

Qual è il mandato in una frase?

Quali azioni sono vietate anche se tecnicamente possibili?

Quale autonomia è necessaria per ciascuna decisione?

Quando l’utente deve approvare, campionare o poter contestare?

Quali fonti e oggetti di memoria può leggere, proporre o modificare?

Errori frequenti e anti-pattern

Descrivere la tecnologia invece del ruolo.

Usare un solo livello di autonomia per tutte le azioni.

Omettere azioni vietate e condizioni di stop.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a definire il ruolo digitale come posizione organizzativa con mandato, permessi, limiti e KPI. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Un Digital Role è un ruolo organizzativo con mandato, permessi, limiti e accountability; l’interfaccia non lo definisce.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è definire il ruolo digitale come posizione organizzativa con mandato, permessi, limiti e KPI.

Compilare [DLV04 - Digital Role Card] per capacità; assegnare livelli [AL0–AL4 - livelli di autonomia operativa] e [MA0–MA4 - livelli di autorità sulla memoria] separati; elencare azioni vietate, soglie ed escalation.

Vedere in pratica — Buyer Assistant

Il caso mostra come definire il ruolo digitale come posizione organizzativa con mandato, permessi, limiti e KPI senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

L’assistente Buyer Assistant può proporre quantità e motivazioni [AL1 - Recommend], ma non emette ordini; una bozza ERP è ammessa solo dopo approvazione umana [AL2 - Act with approval].

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile definire il ruolo digitale come posizione organizzativa con mandato, permessi, limiti e KPI; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Purpose e negative requirements sono espliciti.

Autonomia operativa e autorità sulla memoria non sono confuse.

Il Digital Role Owner accetta KPI e limiti.

9. [P05 - Governance & Trust] e service management proporzionato

Applicazione alle due modalità

Regulatory Essentials: screening minimo

Lo screening considera finalità, ruoli, territorio, dati personali, profilazione o decisioni automatizzate, categorie biometriche o sentiment/emotion, trasparenza, supervisione, logging, alfabetizzazione AI, terze parti, incidenti, diritti e ritiro. L’esito determina soltanto la profondità dei controlli e l’eventuale necessità di una review specialistica.

[SCR01 - Regulatory Essentials] è uno screening iniziale e ricorrente: non certifica la conformità, ma impedisce che questioni regolatorie emergano soltanto al go-live. Il practitioner registra intended purpose, territorio, soggetti coinvolti, ruoli di provider/deployer e terze parti, categorie di dati, presenza di profilazione o decisioni automatizzate, destinatari degli output e possibilità di contestazione. Se il caso tratta dati personali, verifica finalità, base giuridica, minimizzazione, accessi, conservazione, trasparenza, diritti, sicurezza, trasferimenti e necessità di coinvolgere DPO o specialisti.

Per l’AI Act lo screen esclude innanzitutto pratiche vietate, classifica il ruolo dell’organizzazione e verifica se il sistema ricade in trasparenza o alto rischio. Controlla inoltre istruzioni d’uso, supervisione umana, logging, competenza degli utenti, incidenti, change e ritiro. Alla data della v1.2, gran parte dell’AI Act è applicabile dal 2 agosto 2026; alcune regole per sistemi ad alto rischio seguono le scadenze differite introdotte nel 2026. Per questo la classificazione deve essere confermata su fonti ufficiali e, quando necessario, da professionisti competenti.

La governance costruisce fiducia rendendo espliciti accountability, controlli, tracciabilità, contestabilità e operabilità. Il core obbligatorio non richiede ITIL: richiede che ogni Digital Role destinato al pilot abbia un service model minimo e praticabile.

[SM01 - Minimum Viable AI Service Management]

È il set minimo di decisioni e pratiche necessario affinché un ruolo digitale non resti una demo. È obbligatorio per tutti i pilot, anche quando l’azienda non usa ITIL e non intende adottarlo.

[SM01 - Minimum Viable AI Service Management] rende il ruolo digitale esercibile anche in organizzazioni che non adottano formalmente ITIL. Ogni componente [SMC01–SMC07] deve produrre una risposta operativa, non una policy astratta. L’esempio seguente mostra il set minimo per un servizio di raccomandazione di riordino.

[ITIL01 - ITIL Compatibility Profile]

È un profilo opzionale che mappa le capacità minime sugli strumenti e sulle pratiche ITSM dell’organizzazione. È utile se l’azienda è già ITIL-oriented, dispone di processi ITSM strutturati o prevede concretamente di implementarli. Se ITIL non è presente né previsto, il profilo non si attiva: imporlo aggiungerebbe terminologia, ruoli e artefatti senza un beneficio proporzionato.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a rendere il servizio governabile, supportabile, conforme e reversibile. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Governance e service management rendono il ruolo digitale controllabile nel lavoro quotidiano, non soltanto conforme in teoria.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è rendere il servizio governabile, supportabile, conforme e reversibile.

Applicare [SM01 - Minimum Viable AI Service Management] sempre; aggiungere [ITIL01 - ITIL Compatibility Profile] solo se proporzionato. Definire ownership, supporto, monitoring, incident, change, continuity e retirement in [DLV06 - Minimal Governance & AI Service Card].

Vedere in pratica — Buyer Assistant

Il caso mostra come rendere il servizio governabile, supportabile, conforme e reversibile senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant definisce un fallback al report manuale, un owner del servizio e un playbook per dati stock non aggiornati; non introduce un CAB completo per ogni modifica minore.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile rendere il servizio governabile, supportabile, conforme e reversibile; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Owner e sostituto sono reperibili.

Incident e change hanno trigger e registro.

Fallback e continuità sono provati prima del pilot.

10. [P06 - Value Measurement]

Applicazione alle due modalità

[P06 - Value Measurement] trasforma il pilot da dimostrazione interessante a esperimento decisionale. Prima dell’avvio il practitioner definisce baseline, target, formula, popolazione, fonte, frequenza e owner per un insieme bilanciato di metriche: outcome, qualità, rischio, adozione, servizio e TCO. Il valore non coincide con il numero di task prodotti dall’AI; misura il cambiamento osservato nel processo e le condizioni che lo hanno reso possibile.

L’attribuzione deve essere proporzionata. Se durante il pilot cambiano assortimento, domanda o organico, il confronto prima/dopo va interpretato con cautela e supportato da cohort, campioni o note sui fattori esterni. Un miglioramento può essere reale ma non ancora attribuibile; una metrica può raggiungere il target mentre il rischio o il carico di supporto rendono non conveniente la scala.

Il valore è progettato prima del pilot e verificato dopo. Il consulente distingue outcome business, efficienza di processo, qualità decisionale, rischio, affidabilità del servizio, adozione, impatto sulle persone, costi e valore della Corporate Memory.

Scheda operativa

Attività passo per passo

1. [ACT-F04-01] Formulare la value hypothesis e il meccanismo causale.

2. [ACT-F04-02] Definire baseline, popolazione, periodo, fonti e maturità.

3. [ACT-F04-03] Selezionare pochi KPI di outcome e i driver di processo/qualità.

4. [ACT-F04-04] Definire metriche di rischio, servizio, adozione, costi e memoria.

5. [ACT-F04-05] Stabilire target, tolleranze, orizzonte e attribuzione.

6. [ACT-F04-06] Predefinire scale, revise, restrict e stop criteria.

Domande da porre

Quale cambiamento produce valore e attraverso quale meccanismo?

La baseline è ricostruibile e comparabile?

Quale comportamento potrebbe migliorare il KPI senza creare vero valore?

Quali costi umani di supervisione e change vanno inclusi?

Quale risultato ci farebbe decidere di fermarci?

Errori frequenti e anti-pattern

Definire KPI dopo aver visto i risultati.

Misurare solo utilizzo o accuratezza tecnica.

Ignorare costo di supervisione e fattori esterni.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a misurare outcome, qualità, rischio, adozione, servizio e TCO con attribuzione proporzionata. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Il valore deve poter essere smentito: baseline, formula, target, finestra e attribuzione precedono il pilot.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è misurare outcome, qualità, rischio, adozione, servizio e TCO con attribuzione proporzionata.

Costruire [DLV07 - KPI & Value Scorecard] con pochi outcome KPI, metriche di processo, qualità decisionale, rischio, adozione, memoria e TCO; fissare le decision rule.

Vedere in pratica — Buyer Assistant

Il caso mostra come misurare outcome, qualità, rischio, adozione, servizio e TCO con attribuzione proporzionata senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant separa il tempo macchina dal tempo del buyer e misura override, errori, stock-out e capitale immobilizzato, evitando di dichiarare valore dalla sola accuracy del modello.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile misurare outcome, qualità, rischio, adozione, servizio e TCO con attribuzione proporzionata; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Baseline e fonti sono versionate.

Target e tolleranze sono predefiniti.

Scale/revise/restrict/stop sono decisi prima del test.

11. [CM01 - Corporate Memory]

Memoria di prodotto e memoria operativa

In MODE02 la Corporate Memory distingue conoscenza comune di prodotto, configurazione del cliente, dati operativi e lesson generalizzabili. Nessuna informazione di un tenant diventa conoscenza condivisa senza base, diritti e approvazione espliciti.

La Corporate Memory è la memoria persistente e governata dell’azienda aumentata dall’AI. Non coincide con un singolo database, vector store o repository: comprende oggetti, metadati, diritti, workflow, qualità, retention, provenienza e autorità che rendono la conoscenza utilizzabile nel punto della decisione.

Il ciclo canonico [MCL01 - Memory Lifecycle] è capture → classify → validate → publish → use → monitor → revise → retire. Una correzione automatica non diventa conoscenza aziendale valida senza owner, stato, evidenza e diritto di pubblicazione.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a trasformare fonti, decisioni, correzioni ed esiti in memoria governata e riusabile. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

La Corporate Memory è conoscenza governata con provenienza, owner, stato e lifecycle; non è un archivio indiscriminato.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è trasformare fonti, decisioni, correzioni ed esiti in memoria governata e riusabile.

Inventariare fonti e oggetti in [DLV05 - Data & Corporate Memory Readiness], applicare [MEM01–MEM05], distinguere read da write-back e misurare freshness e riuso.

Vedere in pratica — Buyer Assistant

Il caso mostra come trasformare fonti, decisioni, correzioni ed esiti in memoria governata e riusabile senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant trasforma una nota sul ritardo del fornitore in regola solo dopo verifica sui dati e approvazione del Memory Owner.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile trasformare fonti, decisioni, correzioni ed esiti in memoria governata e riusabile; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Ogni oggetto ha fonte, owner e stato.

Write-back e retention sono autorizzati.

Conoscenza scaduta o contestata è ritirabile.

12. Autonomia operativa e autorità sulla memoria

L’autonomia è divisa in due assi perché agire sul processo e modificare la memoria producono rischi diversi. [AL0 - Observe] consente soltanto di osservare; [AL1 - Recommend] produce raccomandazioni; [AL2 - Act with approval] prepara o esegue dopo approvazione; [AL3 - Act within guardrails] agisce entro soglie e regole; [AL4 - Autonomous domain execution] governa un dominio circoscritto con supervisione ed escalation. Il livello si assegna a una specifica azione o decisione, non all’intero sistema.

La Memory Authority segue un asse separato: [MA0 - Read] legge fonti approvate; [MA1 - Propose] propone un nuovo oggetto o una correzione; [MA2 - Write draft] scrive in area bozza; [MA3 - Publish within policy] pubblica entro regole e controlli; [MA4 - Govern domain memory] governa un dominio di memoria con responsabilità esplicita. Un agente può avere AL3 su un’azione a basso impatto e restare MA1 perché una memoria errata si propagherebbe a molte decisioni future.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a calibrare separatamente autonomia operativa e autorità sulla memoria. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Autonomia sulle azioni e autorità sulla memoria sono assi indipendenti: un sistema può agire poco ma contaminare molto la conoscenza.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è calibrare separatamente autonomia operativa e autorità sulla memoria.

Assegnare [AL0–AL4 - livelli di autonomia operativa] per azione e [MA0–MA4 - livelli di autorità sulla memoria] per tipo di memoria; documentare soglie, approvazioni e rollback.

Vedere in pratica — Buyer Assistant

Il caso mostra come calibrare separatamente autonomia operativa e autorità sulla memoria senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant mantiene [AL1 - Recommend] per il riordino e [MA1 - Propose] per annotazioni proposte: nessuna regola di acquisto viene pubblicata automaticamente.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile calibrare separatamente autonomia operativa e autorità sulla memoria; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Livelli assegnati per capacità, non al sistema in blocco.

Ogni incremento ha evidenza e gate.

Declassamento e revoca sono possibili.

13. Evidence architecture, scoring e gate

L’evidence architecture è la catena di custodia che collega una domanda a una decisione. Le entità principali sono Question ID, risposta, rationale, Evidence ID, fonte, data, owner, forza, rischio, remediation, deliverable e gate. Gli indicatori sintetici — score di implementazione, [ECI - Evidence Coverage Index] e indice corretto per forza — descrivono dimensioni diverse e devono essere letti insieme.

Lo score risponde a ‘quanto è implementata la condizione?’. L’ECI risponde a ‘quanti item applicabili sono coperti da evidenza approvata?’. L’indice corretto per forza riduce il contributo di evidenze parziali o deboli. Nessuna media può compensare un anti-fit, un obbligo di gate o una stop condition. Il practitioner conserva inoltre il razionale, perché due score identici possono nascondere rischi molto diversi.

Lo score misura il grado di implementazione della condizione; l’evidenza misura quanto quella valutazione è dimostrata. Un’affermazione, una riunione o un’intenzione futura non equivalgono a un controllo implementato.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a collegare domande, evidenze, score, remediation e gate senza nascondere anti-fit. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Scoring e gate supportano il giudizio ma non sostituiscono evidenze, anti-fit o decision authority.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è collegare domande, evidenze, score, remediation e gate senza nascondere anti-fit.

Classificare ogni evidenza per classe, forza e stato; calcolare score ed ECI; portare gap, rischio residuo e waiver nel [DLV11 - Gate Decision Record].

Vedere in pratica — Buyer Assistant

Il caso mostra come collegare domande, evidenze, score, remediation e gate senza nascondere anti-fit senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant mostra uno score alto ma ECI medio perché la baseline degli errori è incompleta: [G03 - Authorize Pilot] autorizza un pilot ristretto, non la scala.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile collegare domande, evidenze, score, remediation e gate senza nascondere anti-fit; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Score ed ECI sono entrambi visibili.

Anti-fit non sono mediati via.

Ogni gate ha decisione, owner e data.

14. Maturity model organizzativo

Il maturity model descrive la capacità organizzativa di ripetere il metodo, non il successo di un singolo progetto. [MM0 - Fragmented] indica iniziative isolate e dipendenti da individui; [MM1 - Repeatable Foundations] introduce linguaggio e pratiche riusabili; [MM2 - Governed Pilots] governa pilot con owner, evidenze e gate; [MM3 - Scaled Operating Model] riusa capacità su più processi; [MM4 - Portfolio Learning System] coordina portafoglio, Corporate Memory e riallocazione del valore.

La maturità può variare per funzione e non cresce automaticamente con il numero di proof of concept. Un’azienda con dieci demo senza owner o incident management può restare MM0; una PMI con due pilot ben governati e pattern riusabili può raggiungere MM2. Il livello di uscita richiede evidenze osservabili, non una dichiarazione reputazionale.

PARTE II

Consulting delivery system

Il sistema operativo che collega lifecycle, servizi, attività, workshop, checklist, deliverable, QA e gate.

Il Consulting Delivery System è il sistema operativo con cui il practitioner trasforma la foundation in un incarico eseguibile e verificabile. Collega lifecycle, servizi, attività, workshop, checklist, deliverable, QA e gate; stabilisce che cosa preparare, chi coinvolgere, quale evidenza raccogliere, quale output consegnare e quale decisione può essere assunta.

Serve quando il metodo deve essere applicato a un cliente, a un programma interno o a una soluzione per il mercato. Non sostituisce project management, sviluppo software, change management o consulenza legale: li coordina attorno alle decisioni del framework. Può essere usato per l’intero lifecycle o per uno stage circoscritto, purché scope, esclusioni, dipendenze e acceptance siano espliciti.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a valutare capacità organizzative ripetibili senza confonderle con la readiness del singolo caso. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

La maturity descrive capacità organizzative osservabili e non un voto reputazionale; può variare per processo.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è valutare capacità organizzative ripetibili senza confonderle con la readiness del singolo caso.

Valutare governance, processo, dati/memoria, ruoli, service e valore; associare a ogni livello evidenze e next capability.

Vedere in pratica — Buyer Assistant

Il caso mostra come valutare capacità organizzative ripetibili senza confonderle con la readiness del singolo caso senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant è matura sul processo di riordino ma meno sulla misurazione dell’errore; il pilot include quindi strumentazione prima di autonomia.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile valutare capacità organizzative ripetibili senza confonderle con la readiness del singolo caso; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Il livello è sostenuto da evidenze.

Gap e capacità successive sono nominati.

La maturity non viene confusa con readiness del singolo caso.

15. Architettura a quattro livelli

L’architettura a quattro livelli separa ciò che deve rimanere stabile da ciò che cambia con cliente, progetto e tecnologia. [AR01 - Foundation] contiene principi, entità, relazioni e regole canoniche. [AR02 - Consulting Delivery System] traduce il metodo in servizi, workshop, attività, QA e gate. [AR03 - Toolkit] comprende workbook, canvas, checklist e template. [AR04 - Case Library] conserva applicazioni, pattern, anti-pattern e lesson.

Ogni livello ha un versioning distinto. Una correzione a un template non modifica automaticamente la foundation; una lesson di caso entra nella Case Library e diventa regola soltanto dopo una decisione esplicita. Questo evita che una tecnologia scelta per un progetto o una preferenza di un cliente diventi accidentalmente parte del metodo.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a separare foundation, delivery system, toolkit e case library mantenendo versioning coerente. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

I quattro livelli collegano business, operating model, Digital Role e tecnologia senza invertire la dipendenza.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è separare foundation, delivery system, toolkit e case library mantenendo versioning coerente.

Congelare outcome/processo/decisioni prima del ruolo; congelare ruolo, memoria e controlli prima dell’architettura tecnica.

Vedere in pratica — Buyer Assistant

Il caso mostra come separare foundation, delivery system, toolkit e case library mantenendo versioning coerente senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant valuta edge, cloud e ibrido solo dopo aver definito volumi, latenza, sovranità, aggiornamento e fallback.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile separare foundation, delivery system, toolkit e case library mantenendo versioning coerente; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Ogni requisito tecnico risale a un requisito operativo.

Dipendenze e exit sono trasparenti.

Il vendor non determina il metodo.

16. Tre lifecycle coordinati

Lo stesso lifecycle per automazione e prodotto

I tre lifecycle governano oggetti diversi ma condividono decisioni ed evidenze. [LC01 - Portfolio Lifecycle] seleziona opportunità e coordina wave e capacità comuni. [LC02 - Use-case Lifecycle] conduce il singolo caso da orientamento a decisione di scala, revisione o ritiro. [LC03 - AI Service Lifecycle] governa il servizio una volta esercibile: supporto, incidenti, change, monitoring, continuità e retirement.

Le modalità MODE01 e MODE02 attraversano la stessa sequenza. Nel prodotto per il mercato cambiano alcuni contenuti — cliente, intended purpose, release, canali, supporto ed economics — ma non i gate. Il portfolio può selezionare un prodotto, il use case può autorizzarne il pilot presso clienti designati e il service lifecycle può governarne le versioni; nessuno dei tre sostituisce gli altri.

Il lifecycle non si applica soltanto al primo pilot. Il primo pilot è la prima istanza del lifecycle del singolo use case e spesso costruisce capability riutilizzabili. In un programma multi-pilot, opportunità e servizi procedono a velocità diverse e vengono coordinati da tre lifecycle.

In un programma con più dipartimenti, [F01 - Orient] può essere svolta una volta a livello aziendale e poi raffinata per dominio; [F02 - Assess] alimenta un portfolio; i casi selezionati entrano in wave e percorrono autonomamente [F03–F06]. Corporate Memory, policy, piattaforme e capability possono essere condivise, ma ogni caso mantiene owner, baseline, rischi, evidenze e Decision Record propri.

Lifecycle del singolo use case

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a coordinare portafoglio, singolo use case e servizio in esercizio. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Portfolio, use case e servizio hanno lifecycle differenti ma devono condividere evidenze e decisioni.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è coordinare portafoglio, singolo use case e servizio in esercizio.

Mantenere registri separati e collegati: portfolio [PF], use case [F01–F06 - da Orient a Decide & Scale], servizio [LC03 - AI Service Lifecycle]; coordinare gate e owner.

Vedere in pratica — Buyer Assistant

Il caso mostra come coordinare portafoglio, singolo use case e servizio in esercizio senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant può ritirare un caso dal portfolio mentre il servizio comune di forecast resta operativo per altri processi.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile coordinare portafoglio, singolo use case e servizio in esercizio; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Stato e owner di ciascun lifecycle sono visibili.

Le transizioni non sono implicite.

Retirement e riuso sono pianificati.

17. Due entry path

Gli entry path descrivono da dove nasce l’opportunità. [EP01 - Portfolio-first] parte da priorità e inventario dei processi, confronta più candidati e seleziona il caso più adatto. [EP02 - Use-case-first] parte da un’idea già proposta — per esempio ‘creiamo un agente per le gare’ — ma la sottopone comunque a Strategic Intent, fit, AS-IS e gate. Entrambi convergono prima che il design venga congelato.

EP01 riduce il rischio di scegliere il caso più visibile anziché quello con miglior rapporto valore/fattibilità/rischio. EP02 evita di scartare opportunità nate dall’esperienza o dall’innovazione tecnica, ma impedisce che una demo salti la verifica del problema. Cambia il punto di ingresso, non la soglia di evidenza.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a far convergere opportunità portfolio-first e use-case-first sugli stessi gate. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Il metodo accetta sia un portfolio da costruire sia un caso già proposto, ma non salta fit, AS-IS o gate.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è far convergere opportunità portfolio-first e use-case-first sugli stessi gate.

Scegliere [EP01 - Portfolio-first] o [EP02 - Use-case-first]; documentare perché. Per un caso proposto, eseguire comunque screening comparativo minimo e readiness.

Vedere in pratica — Buyer Assistant

Il caso mostra come far convergere opportunità portfolio-first e use-case-first sugli stessi gate senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant entra con un “assistente acquisti” già proposto, ma lo confronta con promo ingestion e trasferimenti stock prima di [G01 - Select].

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile far convergere opportunità portfolio-first e use-case-first sugli stessi gate; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Entry path registrato.

Il caso proposto non è trattato come decisione già presa.

Gli stessi criteri di evidenza restano applicabili.

18. Service catalogue e relazione con il lifecycle

Il service catalogue non è una sequenza alternativa al lifecycle. I servizi sono moduli commerciali e operativi che eseguono attività di una o più fasi. Un engagement può acquistare un solo servizio o combinarne più di uno, ma ogni proposta deve dichiarare quali fasi e gate copre.

Scheda minima di ogni servizio

ID, outcome e decisione resa possibile.

Prerequisiti, entry gate e exit gate.

Attività e workshop inclusi.

Deliverable, criteri di accettazione e dipendenze.

Ruoli del cliente, del consulente e dell’eventuale partner.

Assunzioni, esclusioni, effort driver e logica di pricing.

Evidenze richieste, QA applicabile e handover al servizio successivo.

[SRV05 - Implementation & Pilot Enablement] è un servizio distinto e specifico del Human + AI Operating Model™. Può essere eseguito dal consulente o da un partner specializzato scelto per l’opportunità. La responsabilità tecnica non trasferisce al partner la titolarità del framework né la decisione del cliente su risk appetite, accettazione e gate.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a rendere servizi e work package acquistabili senza delegare al fornitore i decision rights. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Il catalogo servizi modularizza il delivery senza frammentare la responsabilità end-to-end.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è rendere servizi e work package acquistabili senza delegare al fornitore i decision rights.

Selezionare [SRV01–SRV08], mappare fasi, output, gate, dipendenze e esclusioni nella SOW; non vendere implementazione implicita.

Vedere in pratica — Buyer Assistant

Il caso mostra come rendere servizi e work package acquistabili senza delegare al fornitore i decision rights senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant acquista discovery e design; l’implementazione [SRV05 - Implementation & Pilot Enablement] è opzionale e può essere affidata a un partner mantenendo invariati i gate.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile rendere servizi e work package acquistabili senza delegare al fornitore i decision rights; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Ogni servizio ha decisione finale e acceptance.

Dipendenze ed esclusioni sono esplicite.

Il cliente conserva decision rights.

19. Ruoli e decision rights

I decision rights chiariscono chi può proporre, decidere, approvare, eseguire, contestare, fare override e accettare un rischio. Sono più precisi di una RACI generica perché si riferiscono a decisioni concrete e possono cambiare tra gate, pilot ed esercizio. Nelle PMI più ruoli possono coincidere nella stessa persona, ma accountability e mandato devono restare distinguibili.

Il practitioner facilita e custodisce la tracciabilità, ma non assume la risk acceptance del cliente. Il Technical Delivery Lead può scegliere come implementare un controllo, non se il rischio residuo sia accettabile. Il Product Owner decide roadmap e release in MODE02, mentre il Service Owner governa operabilità e continuità. Il Gate Decision Record rende visibile quale ‘cappello’ una persona indossa quando i ruoli coincidono.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a attribuire accountability e diritti decisionali anche quando più ruoli coincidono. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

I ruoli separano sponsorship, accountability, ownership operativa, assurance e delivery tecnico.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è attribuire accountability e diritti decisionali anche quando più ruoli coincidono.

Compilare una RACI decisionale per gate e deliverable; verificare conflitti, sostituti ed escalation.

Vedere in pratica — Buyer Assistant

Il caso mostra come attribuire accountability e diritti decisionali anche quando più ruoli coincidono senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

In Buyer Assistant il buyer lead è Decision Owner del riordino, il procurement director è Business Owner e l’IT service manager è AI Service Owner.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile attribuire accountability e diritti decisionali anche quando più ruoli coincidono; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Ogni gate ha una sola decision authority.

Owner di processo, ruolo digitale, dati e servizio sono nominati.

Il facilitatore non accetta il rischio per il cliente.

20. Workshop system e mappatura end-to-end

Il Workshop System è una sequenza di sessioni decisionali, non un calendario di riunioni. Ogni workshop ha una domanda, input minimi, partecipanti, attività, output, evidenze e criteri di chiusura. La mappatura end-to-end collega [WS00 - Executive Orientation] fino a [WS07 - Executive Gate Review] con fasi, checklist e deliverable, evitando workshop isolati che producono slide ma non decisioni.

Prima della sessione il practitioner prepara fonti e casi reali; durante distingue processo dichiarato e processo osservato, fatti e assunzioni, consenso e decisione; dopo versiona gli output, assegna gap e richiede approvazioni. Se un input minimo manca, il workshop può produrre discovery, ma non deve essere dichiarato chiuso.

Attivazione dei due screen

I workshop sono meccanismi operativi utilizzati dai servizi per eseguire attività del lifecycle. Non sostituiscono analisi documentale, profiling, test o produzione degli output. Lo stesso workshop [WS07 - Executive Gate Review] viene eseguito in due momenti: prima del pilot per [G03 - Authorize Pilot] e dopo il pilot per [G05 - Scale / Revise / Retire], usando la stessa struttura di decisione senza creare due tipi distinti di workshop.

Standard di esecuzione di ogni workshop

Esempio di agenda per [WS02 - AS-IS Process Discovery]

1. Confermare trigger, confini, cliente/beneficiario e output del processo.

2. Ricostruire l’happy path con evidenze e sistemi realmente usati.

3. Aggiungere varianti, eccezioni, attese, code, rilavorazioni e workaround.

4. Marcare ruoli, handoff, informazioni, applicazioni e punti di controllo.

5. Raccogliere volumi, tempi, errori, backlog e campioni.

6. Evidenziare i punti in cui qualcuno sceglie tra alternative, senza ancora progettare l’AI.

7. Confermare gap, owner, evidenze mancanti e criteri per passare a [WS03 - Decision Walkthrough].

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a condurre workshop che producano evidenze, output e decisioni, non soltanto consenso. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

I workshop producono decisioni ed evidenze, non soltanto allineamento; [WS02 - AS-IS Process Discovery] precede [WS03 - Decision Walkthrough].

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è condurre workshop che producano evidenze, output e decisioni, non soltanto consenso.

Preparare input, domande, ruoli e output per [WS00–WS07 - workshop canonici]; chiudere ogni sessione con decisioni, gap, owner e prossimo gate.

Vedere in pratica — Buyer Assistant

Il caso mostra come condurre workshop che producano evidenze, output e decisioni, non soltanto consenso senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant osserva un ciclo reale di riordino in [WS02 - AS-IS Process Discovery] prima di discutere come l’AI potrebbe supportarlo in [WS03 - Decision Walkthrough].

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile condurre workshop che producano evidenze, output e decisioni, non soltanto consenso; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Agenda collegata a un deliverable.

Assunzioni non confermate entrano nel registro evidenze.

Decisioni e azioni sono chiuse entro 24 ore.

21. Assessment, checklist e scoring process

Le checklist sono strumenti di verifica e non la sequenza completa dell’engagement. La tabella seguente è un indice: le domande normative sono riportate nell’Appendice C con Question ID, evidenza, rischio e azione. Le checklist alimentano più deliverable e un deliverable usa più checklist.

Procedura di assessment

1. [ACT-AS-01] Registrare engagement, entry path, use case, owner e decisione richiesta.

2. [ACT-AS-02] Preparare l’evidence request e distinguere documenti attesi da controlli implementati.

3. [ACT-AS-03] Eseguire le checklist nella sequenza coerente con lifecycle e workshop, non come intervista unica.

4. [ACT-AS-04] Registrare response, rationale, owner, Evidence ID, forza, rischio e gate per ogni item.

5. [ACT-AS-05] Trattare N/A come eccezione motivata e approvata; escluderla dallo score.

6. [ACT-AS-06] Collegare ogni conclusione ai campi dei deliverable che alimenta.

7. [ACT-AS-07] Aprire remediation con containment, owner, scadenza, closure evidence ed effectiveness review.

8. [ACT-AS-08] Applicare gate override prima della raccomandazione.

9. [ACT-AS-09] Congelare Decision Record e data della review successiva.

Criteri di risposta

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a usare le checklist come indagine evidence-based e non come autovalutazione meccanica. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Le 118 domande sono un sistema di raccolta evidenze, non una sequenza rigida di intervista o un questionario auto-valutativo.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è usare le checklist come indagine evidence-based e non come autovalutazione meccanica.

Selezionare le domande pertinenti per workshop; registrare risposta, evidenza, forza, gap e remediation nel workbook; ricalcolare ai gate.

Vedere in pratica — Buyer Assistant

Il caso mostra come usare le checklist come indagine evidence-based e non come autovalutazione meccanica senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant risponde “sì” sulla disponibilità dei dati ma “parzialmente” sulla loro freshness; lo score resta distinto dall’evidenza.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile usare le checklist come indagine evidence-based e non come autovalutazione meccanica; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Tutte le 118 domande hanno un ID stabile.

N/A è motivato.

Score, ECI e anti-fit sono leggibili insieme.

22. Deliverable standard e tracciabilità checklist-output

I deliverable standard sono oggetti decisionali, non documenti prodotti per completezza. [DLV01–DLV15 - deliverable canonici] costruiscono una catena: opportunità, processo, decisioni, ruolo digitale, dati e memoria, governance e servizio, valore, roadmap, evidenze, gate, remediation, restituzione, osservazioni e retrospettiva. Una checklist può alimentare più deliverable e un deliverable può essere verificato da più checklist.

La tracciabilità minima collega Question ID, Evidence ID, rischio, remediation, deliverable, acceptance criterion e gate. Il practitioner non duplica lo stesso contenuto: mantiene una fonte autorevole e usa riferimenti. La versione del deliverable deve permettere di ricostruire quale evidenza e quale decisione erano valide in quel momento.

La relazione non è uno-a-uno. Le checklist generano evidenze e conclusioni che alimentano campi di più output; gli output integrano prospettive provenienti da checklist diverse. Ogni campo materiale deve poter indicare Question ID ed Evidence ID.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a costruire una catena di deliverable coerenti, versionati e accettabili. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

I 15 deliverable formano un pacchetto decisionale tracciabile; non sono documenti decorativi.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è costruire una catena di deliverable coerenti, versionati e accettabili.

Usare i template v1.2, collegare campi a question/evidence ID e applicare ACC-DLVxx-yy prima del gate.

Vedere in pratica — Buyer Assistant

Il caso mostra come costruire una catena di deliverable coerenti, versionati e accettabili senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant non presenta [DLV13 - Executive Restitution] finché [DLV10 - Evidence Register] non distingue risultati, stime e ipotesi dell’applicazione.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile costruire una catena di deliverable coerenti, versionati e accettabili; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

DLV01–DLV15 hanno schema e acceptance.

Le relazioni tra output sono coerenti.

La versione approvata è rintracciabile.

23. Quality assurance trasversale

La Quality Assurance non è una fase autonoma e non è un secondo lifecycle. È una sequenza di controlli trasversali eseguiti prima dei gate. La QA verifica che il framework sia stato applicato correttamente; gli owner del cliente assumono le decisioni. [SRV06 - Pilot Assurance] verifica invece comportamento, incidenti, evidenze e risultati durante il pilot.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a eseguire QA proporzionata prima dei gate e assurance durante il pilot. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

La QA è trasversale e proporzionata; l’indipendenza del reviewer è una misura possibile, non un requisito universale.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è eseguire QA proporzionata prima dei gate e assurance durante il pilot.

Applicare [QA01–QA07 - controlli di quality assurance], scegliere profondità in base a impatto e autonomia, campionare evidenze e registrare non conformità.

Vedere in pratica — Buyer Assistant

Il caso mostra come eseguire QA proporzionata prima dei gate e assurance durante il pilot senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant usa una challenge session business–IT per il gate pilota; non istituisce un assurance board separato per un caso AL1.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile eseguire QA proporzionata prima dei gate e assurance durante il pilot; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

QA scope e campione sono dichiarati.

Issue critici bloccano il gate.

Waiver e rischio residuo sono approvati dall’autorità corretta.

24. Gate e decisioni

Un gate è un punto di decisione governata: stabilisce se mobilitare, selezionare, congelare il design, autorizzare o limitare il pilot, continuare o fermare, scalare, rivedere o ritirare. Non coincide con una data di progetto e non si supera per inerzia. Il Gate Decision Record contiene decisione richiesta, evidenze, rischi residui, raccomandazione, condizioni, owner, scadenze, waiver e prossima review.

Le possibili decisioni sono verbi operativi. ‘Proceed’ autorizza entro il perimetro; ‘Restrict’ riduce autonomia o popolazione; ‘Revise’ riapre il design; ‘Pause/Stop’ sospende; ‘Scale’ estende con condizioni; ‘Retire’ chiude capacità e dipendenze. Un gate scaduto non resta valido: viene riesaminato alla luce di nuovi dati, incidenti e change.

PARTE III

Productization

Come rendere il metodo quotabile, replicabile e vendor-neutral mantenendo chiari confini e titolarità.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a assumere decisioni esplicite di avanzamento, limitazione, revisione, stop o scala. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

I gate sono decisioni organizzative basate su evidenze: non milestone automatiche di progetto.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è assumere decisioni esplicite di avanzamento, limitazione, revisione, stop o scala.

Per [G00–G05 - da Mobilize a Scale / Revise / Retire] preparare decision requested, evidence pack, rischio residuo, raccomandazione, condizioni e next review in [DLV11 - Gate Decision Record].

Vedere in pratica — Buyer Assistant

Il caso mostra come assumere decisioni esplicite di avanzamento, limitazione, revisione, stop o scala senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant supera [G02 - Design Freeze] ma riceve in [G03 - Authorize Pilot] un’autorizzazione ristretta: nessun invio automatico ordine e campione di brand progressivo.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile assumere decisioni esplicite di avanzamento, limitazione, revisione, stop o scala; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

La decisione usa il verbo previsto dal gate.

Condizioni e owner hanno data.

Un gate scaduto viene riesaminato.

25. Cinque linee di valore

Le linee di valore sono famiglie di outcome professionali distinguibili e quotabili. Non coincidono con i servizi: una linea raggruppa servizi e work package affini; un servizio è un pacchetto acquistabile; il work package è la porzione contrattuale dello specifico engagement.

La lettura è dall’alto verso il basso: una Value Line raggruppa servizi; il servizio viene contrattualizzato attraverso uno o più Work Package; attività e deliverable realizzano lo scope; gli acceptance criterion rendono verificabile la consegna.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a distinguere linee di valore, servizi, work package, attività, deliverable e acceptance. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Le cinque linee di valore impediscono di ridurre il business case al risparmio di tempo.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è distinguere linee di valore, servizi, work package, attività, deliverable e acceptance.

Mappare [VL01–VL05] a metriche e decisioni; evitare doppio conteggio; distinguere valore potenziale, osservato e attribuito.

Vedere in pratica — Buyer Assistant

Il caso mostra come distinguere linee di valore, servizi, work package, attività, deliverable e acceptance senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant misura capacità del buyer, qualità della decisione, servizio, capitale e conoscenza riusabile, non soltanto ore evitate.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile distinguere linee di valore, servizi, work package, attività, deliverable e acceptance; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Ogni valore ha formula e owner.

Benefici e costi non sono duplicati.

Le evidenze supportano il livello di claim.

26. Risk appetite e decisioni di rischio

La gestione del rischio distingue quattro concetti. [RA01 - Risk Capacity] è il massimo rischio sostenibile senza compromettere continuità o vincoli essenziali. [RA02 - Risk Appetite] indica quali rischi l’organizzazione è disposta ad assumere per perseguire l’outcome. [RA03 - Risk Tolerance] traduce l’appetite in soglie operative e scostamenti accettabili. [RA04 - Risk Acceptance] è la decisione autorizzata di accettare uno specifico rischio residuo per condizioni e durata definite.

Il practitioner parte dagli scenari, non da un colore. Descrive evento, cause, impatto, probabilità, controlli, rischio residuo, owner e trattamento; collega poi le soglie ad autonomia, monitoring e gate. La capacity è un limite, l’appetite una scelta strategica, la tolerance una soglia misurabile e l’acceptance un atto puntuale: confonderli produce controlli incoerenti.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a tradurre capacity, appetite e tolerance in scenari, soglie, controlli e acceptance. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

Il risk appetite traduce tolleranza aziendale in limiti operativi, soglie, escalation e decisioni di rischio.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è tradurre capacity, appetite e tolerance in scenari, soglie, controlli e acceptance.

Registrare scenario, impatto, probabilità, controllo, rischio residuo, owner e trattamento; collegare a autonomia e gate.

Vedere in pratica — Buyer Assistant

Il caso mostra come tradurre capacity, appetite e tolerance in scenari, soglie, controlli e acceptance senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant accetta raccomandazioni errate correggibili prima dell’ordine, ma non accetta invii autonomi o memoria non validata.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile tradurre capacity, appetite e tolerance in scenari, soglie, controlli e acceptance; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Rischio inerente e residuo sono distinti.

Acceptance è esplicita e time-bound.

Controlli sono testabili e osservabili.

27. Quattro macro-stage commerciali

Ogni proposta indica quali macro-stage include e quali esclude. I quattro stage non sostituiscono le fasi [F01–F06 - da Orient a Decide & Scale]: aggregano il lavoro in blocchi comprensibili e quotabili. La scala è inclusa nell’Assurance perché la decisione di scalare deriva dalle evidenze e continua a richiedere governo di portafoglio.

La tabella dei confini della proposta non descrive gli stage; descrive ciò che una SOW deve dichiarare per lo stage acquistato. Per esempio, una proposta può includere [ST01 - Discovery] e [ST02 - Design] ma escludere [ST03 - Implementation]; in tal caso deve consegnare un target design implementabile senza implicare che lo stesso fornitore realizzerà la soluzione.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a aggregare il lifecycle in stage quotabili mantenendo scope ed esclusioni trasparenti. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

I quattro macro-stage rendono il lavoro acquistabile; il ciclo sperimentale rende l’implementazione apprendibile e controllata.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è aggregare il lifecycle in stage quotabili mantenendo scope ed esclusioni trasparenti.

In [ST03 - Implementation] eseguire [DEV01] discovery tecnica, [DEV02] thin slice, [DEV03] esperimenti, [DEV04] feedback utenti, [DEV05] hardening e [DEV06] transizione al pilot. Se cambia il target, tornare a [G02]/[G03 - Authorize Pilot].

Vedere in pratica — Buyer Assistant

Il caso mostra come aggregare il lifecycle in stage quotabili mantenendo scope ed esclusioni trasparenti senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant passa da un brand e 255 SKU a campioni crescenti; ogni ciclo modifica razionali, exception queue e strumentazione prima della scala.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile aggregare il lifecycle in stage quotabili mantenendo scope ed esclusioni trasparenti; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

La SOW separa stage, servizi e acceptance.

Ogni ciclo DEV ha ipotesi ed evidenza.

Modifiche sostanziali riaprono i gate pertinenti.

28. Architettura vendor-neutral ed ecosistema di partner

Il target operating model definisce outcome, processo, decisioni, ruoli, dati, memoria, controlli e KPI. Solo dopo si definisce la technology architecture. Un partner può contribuire a infrastruttura, piattaforme, integrazione o formazione senza entrare nella governance o nella titolarità della foundation.

Esempio: MSI può essere valutata come partner o fornitore di piattaforma/infrastruttura EdgeXpert quando sovranità del dato, bassa latenza, costi prevedibili o capacità locale risultano requisiti del target design. Non partecipa alla realizzazione del framework e non è una destinazione automatica dell’assessment.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a derivare la tecnologia dal target operating model e governare portabilità e lock-in. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

La tecnologia consegue al target operating model e resta sostituibile entro vincoli espliciti.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è derivare la tecnologia dal target operating model e governare portabilità e lock-in.

Valutare [TA01–TA05] con requisiti, opzioni, trade-off, dipendenze, portabilità, exit e TCO; citare prodotti solo come esempi.

Vedere in pratica — Buyer Assistant

Il caso mostra come derivare la tecnologia dal target operating model e governare portabilità e lock-in senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant sceglie un’infrastruttura locale per dati e carico, ma la decisione non modifica ownership o regole del framework.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile derivare la tecnologia dal target operating model e governare portabilità e lock-in; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Requisiti precedono vendor shortlist.

Portabilità e lock-in sono valutati.

Partner e Method Owner hanno ruoli separati.

29. Proprietà intellettuale, licensing e riuso

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a separare framework IP, dati, output, implementation IP, terze parti e diritti di caso. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

La v1.2 è proprietaria: foundation e toolkit restano del Method Owner; dati e informazioni riservate restano del cliente.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è separare framework IP, dati, output, implementation IP, terze parti e diritti di caso.

Applicare [IP01–IP08] e [SOW09 - IP & Confidentiality]; concedere diritti d’uso interni solo per contratto; definire separatamente implementation IP e componenti terze.

Vedere in pratica — Buyer Assistant

Il caso mostra come separare framework IP, dati, output, implementation IP, terze parti e diritti di caso senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Buyer Assistant riceve gli output del proprio engagement e un diritto d’uso interno; non acquisisce il diritto di rivendere il framework o pubblicare il caso senza consenso.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile separare framework IP, dati, output, implementation IP, terze parti e diritti di caso; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Titolarità e diritti d’uso non sono confusi.

Case study richiede consenso o anonimizzazione approvata.

Gli aspetti legali applicabili richiedono la valutazione di un professionista competente; il framework non costituisce parere legale.

30. Case library: esempi, non componenti

StorIA: dalla customer intelligence a un prodotto governato

StorIA è una piattaforma reale orientata a marketing e customer behaviour. Integra video AIoT e computer vision con data warehouse, business intelligence e modelli di business per produrre metadati e indicatori su ingressi, permanenza, code, flussi, heatmap, conversione, segmenti demografici stimati, sentiment, promozioni di prossimità, digital signage e raccomandazioni operative tramite AIdvisor.

I case history illustrano livelli diversi di applicazione e rendono osservabili i pattern del metodo. Non determinano i pilastri e non obbligano altri contesti a replicarne architettura o soluzione.

Comprendere — sintesi practitioner

La domanda di controllo è se l’engagement riesca davvero a usare i casi per apprendere senza trasformare tecnologie o contesti in norme del metodo. Il practitioner esplicita oggetto, owner, evidenza e decisione; se uno di questi elementi resta implicito, la comprensione non è ancora sufficiente per alimentare il passaggio successivo.

La case library rende concreti i pattern applicativi senza trasformare esempi e tecnologie in norme del metodo.

Applicare — sequenza minima

Operativamente: preparare fonti e casi; facilitare il confronto sul lavoro reale; registrare gap, assunzioni e alternative; assegnare owner e scadenze; aggiornare gli artefatti collegati; chiudere la sessione con una decisione verificabile. L’obiettivo specifico è usare i casi per apprendere senza trasformare tecnologie o contesti in norme del metodo.

Classificare ogni caso per fonte, contesto, evidence strength, pattern e limiti; separare retrospettive da engagement prospettici.

Vedere in pratica — Buyer Assistant

Il caso mostra come usare i casi per apprendere senza trasformare tecnologie o contesti in norme del metodo senza rendere obbligatorie le tecnologie adottate. Il practitioner deve trasferire il pattern — evidenza, responsabilità, limite e misura — e non copiare architettura o soluzione fuori contesto.

Il Buyer Assistant illustra decision support nel procurement; non rende SARIMAX, N8N o EdgeXpert componenti obbligatorie del framework.

Verificare — definition of done

La sezione è chiusa quando il Decision Owner può ricostruire dalle evidenze se e a quali condizioni è stato possibile usare i casi per apprendere senza trasformare tecnologie o contesti in norme del metodo; gap residui, N/A, condizioni e prossima review sono registrati, non affidati alla memoria dei partecipanti.

Fatti, stime, inferenze e assunzioni sono etichettati.

Il caso non modifica gli ID canonici.

Riuso pubblico rispetta IP e confidenzialità.

Toolkit operativo e riferimenti

Appendici operative per applicare il metodo con un linguaggio comune.

Le appendici trasformano il linguaggio del framework in strumenti di lavoro. Il Registro degli identificatori consente di citare lo stesso oggetto senza ambiguità; il Glossario stabilisce un significato canonico; il Checklist Pack traduce i principi in domande verificabili; lo Schema dei deliverable definisce contenuti minimi e criteri di accettazione.

Il practitioner usa le appendici come reference operativa, non come sequenza da leggere sempre integralmente. Durante workshop e QA richiama gli ID pertinenti, evita sigle prive di significato e collega ogni compilazione al contesto dell’engagement. Gli ID restano stabili nella release; istanze, evidenze e decisioni ricevono codici specifici del progetto.

Appendice A — Registro degli identificatori

Gli ID sono stabili all’interno della release. Un oggetto rinominato conserva l’ID; un oggetto con significato diverso riceve un nuovo ID. Gli ID di istanza includono il codice engagement per evitare collisioni tra clienti e casi.

A.1 Pilastri

A.2 Ruoli

A.3 Servizi

A.4 Deliverable

A.5 Lifecycle e fasi

A.6 Workshop

A.7 Work package di riferimento

A.8 Convenzioni per istanze

A.9 Registro canonico esteso v1.2

Le famiglie seguenti completano il registro degli ID già definiti. I codici di istanza includono l’engagement ID e non modificano gli ID del metodo.

A.10 Ciclo sperimentale di implementation

Appendice B — Glossario canonico

A.14 Modalità e screen essenziali

Appendice C — Checklist pack con Question ID

Le checklist sono strumenti di indagine e verifica. Le 118 domande rendono esplicite condizioni che altrimenti resterebbero affidate all’intuizione del consulente; non sono un questionario da inviare senza facilitazione né una certificazione automatica. Ogni risposta richiede rationale, owner ed evidenza proporzionata.

Il practitioner seleziona gli item applicabili, registra N/A motivati, distingue implementazione e forza probatoria e usa i risultati per orientare deliverable, remediation e gate. Le domande proteggono da rischi specifici; le azioni tipiche sono esempi di remediation e vanno adattate al contesto.

Le 118 domande sono il nucleo di verifica dell’assessment. Per ogni item il consulente registra risposta, rationale, owner, Evidence ID, forza dell’evidenza, rischio, gate e remediation. La colonna ‘rischio’ descrive ciò che la domanda protegge; la colonna ‘azione’ indica una remediation tipica, da adattare al contesto.

[CHK01 - Human + AI Readiness]

CHK01 verifica se l’organizzazione può mobilitare responsabilmente un percorso Human + AI. Si usa prima di investire sul singolo caso e osserva priorità, sponsorship, owner, dati, capacità IT, guardrail, utenti, rischio, misura, service management e apprendimento.

[CHK02 - Opportunity]

CHK02 confronta processi e use case candidati. Aiuta a evitare la selezione del caso più visibile o tecnologicamente attraente, valutando impatto, frequenza, componente cognitiva, dati, verificabilità, reversibilità, owner, tempo di pilot, valore e riuso.

[CHK03 - Decision]

CHK03 analizza le decision unit emerse dall’AS-IS. Per ogni decisione chiarisce trigger, outcome, frequenza, impatto, owner, informazioni, regole, eccezioni, spiegabilità, supervisione, errori, autonomia e write-back.

[CHK04 - Process]

CHK04 verifica che il processo reale e quello target siano sufficientemente compresi. Confini, baseline, varianti, handoff, eccezioni, fallback, dati, integrazioni e criteri di accettazione devono rendere il pilot eseguibile e osservabile.

[CHK05 - Data & Corporate Memory]

CHK05 valuta dati e Corporate Memory lungo l’intero lifecycle: fonti, qualità, provenienza, accessi, retention, oggetti di memoria, validazione, retrieval, write-back, dipendenze da persone chiave, sovranità e portabilità.

[CHK06 - Digital Role]

CHK06 trasforma una capacità AI in un Digital Role organizzativo. Verifica purpose, input/output, strumenti, permessi, limiti, negative requirements, autonomia, supervisione, KPI, owner, change e memory authority.

[CHK07 - Governance & Trust]

CHK07 rende verificabili governance e fiducia. Collega rischi, controlli, accountability, audit, sicurezza, privacy, trasparenza, contestazione, incidenti, review periodiche e decisioni di limitazione o stop.

[CHK08 - AI Service Readiness]

CHK08 verifica la readiness minima del servizio AI: ownership, supporto, incident, problem, change, release, monitoring, continuità, capacità, miglioramento e retirement. ITIL01 resta un mapping opzionale.

[CHK09 - Value]

CHK09 verifica che il valore sia misurabile e decisionale. Baseline, target, formule, fonti, attribuzione, qualità, rischio, adozione, servizio, TCO e regole scale/revise/restrict/stop devono essere definite prima di interpretare il pilot.

Appendice D — Schema dei deliverable

I quindici deliverable formano il pacchetto decisionale del metodo. La tabella seguente indica i campi minimi e l’acceptance essenziale; il template può essere adattato nella forma, ma non deve perdere owner, evidenze, razionale, versioning e collegamento al gate.

Un deliverable è sufficiente quando sostiene la decisione prevista, non quando è lungo. Campi non applicabili sono motivati come N/A; assunzioni e inferenze restano distinguibili dai fatti; riferimenti ad altri artefatti sostituiscono duplicazioni incoerenti.

D.1 Criteri di accettazione identificati

I criteri ACC-DLVxx-yy rendono verificabile la qualità di ogni deliverable. Sono condizioni osservabili, non giudizi estetici: completezza dei campi applicabili, tracciabilità delle evidenze, approvazione dell’autorità corretta ed efficacia delle condizioni specifiche. Se un criterio non è soddisfatto, l’output viene rivisto oppure il gate registra una condizione o un waiver autorizzato.