| TESI FONDATIVA Il valore dell’AI deriva dalla qualità del sistema operativo che collega intento umano, processo, decisioni, memoria, responsabilità e misurazione, non dalla quantità di agenti o dalla potenza nominale del modello. |
|---|
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.
| REGOLA DI PREVALENZA Quando rapidità e controllo entrano in tensione, il metodo non applica automaticamente il massimo controllo. Applica una governance proporzionata all’impatto; tuttavia owner, tracciabilità, limiti e criteri di valore non possono essere eliminati per accelerare il pilot. |
|---|
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.
| Richiesta | Principio attivato | Risposta practitioner |
|---|---|---|
| “Partiamo dal tool e poi cerchiamo dove usarlo.” | Technology is a consequence | Ricondurre la discussione a outcome, processi e requisiti; il tool può restare un candidato, non il punto di partenza. |
| “Salviamo automaticamente tutti i feedback nel knowledge base.” | Corporate Memory by design | Distinguere osservazione, proposta e conoscenza pubblicata; definire owner e workflow di validazione. |
| “Valuteremo i KPI dopo aver visto cosa funziona.” | Value must be falsifiable | Non autorizzare il pilot finché baseline, metriche e criteri decisionali non sono concordati. |
| “Usiamo lo stesso controllo per ogni raccomandazione.” | Governance proportional to impact | Segmentare per impatto, reversibilità e incertezza; calibrare soglie e supervisione. |
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.