Ultimamente si è parlato molto della promessa di valore legata alle potenzialità dell’intelligenza artificiale (AI). La discussione è stata spesso incentrata sulle tecnologie, fondamentali e abilitanti, ma di per sé non sufficienti per generare i risultati di business attesi. In questa prima fase di sfruttamento dell’AI, l’attenzione da parte della maggior parte delle organizzazioni è stata sugli artifact, ossia sulla delivery dei modelli analitici e di machine learning (ML). Di contro, si è trascurato l’aspetto della loro integrazione con i processi di delivery IT e di business, ossia sull’aspetto della loro “operazionalizzazione”.
Aspetto quest’ultimo fondamentale per ridurre il “time-to-value”, considerando che occorrono in media 8 mesi per integrare un modello di ML all’interno di un workflow di business e per conseguire i primi benefici.
Ancora pochi i progetti per trasformare l’esperienza cliente sui canali digitali
Se da un lato sono numerosissime in ogni settore industriale le iniziative pilota, dall’altro sono ancora pochi i progetti che si sono trasformati in prodotti o servizi digitali lanciati sul mercato o rilasciati in produzione per trasformare l’esperienza cliente sui canali digitali.
Ancora oggi solo una organizzazione su dieci è in grado di promuovere in produzione oltre il 75% dei modelli di AI sviluppati. E ancora: una previsione formulata dagli analisti Gartner ipotizza che da qui al 2023 almeno il 50% dei responsabili di funzioni di Data & Analytics incontreranno difficoltà nel fare superare la fase di Proof of Concept (PoC) ai loro progetti di AI, raggiungendo un livello di maturità necessario per farli diventare produttivi. Questo, per esempio, a causa dell’incompatibilità delle soluzioni di AI sviluppate in ambiente di laboratorio con le componenti tecnologiche utilizzate in ambiente produttivo.
Le motivazioni alla base della complessità sono diverse. Security e privacy, volume e qualità non adeguata dei dati, vincoli all’accessibilità, limitata comprensione dei casi d’uso e dei relativi benefici, competenze interne non adeguate, solo per citarne alcune.
Il rischio concreto di una tale situazione è di creare scetticismo da parte di importanti stakeholder sui benefici e l’impatto trasformativo dell’AI per la propria organizzazione.
Operazionalizzazione: le pratiche di lavoro da sviluppare
Cosa fare per gestire questa complessità? L’elemento comune alla base delle interdipendenze sono i dati. Occorre lavorare non solo sulle tecnologie ma considerare anche l’aspetto delle pratiche di lavoro e dei modelli operativi. Ossia di tutto ciò che è necessario per integrare dati ed AI in modo industrializzato nell’operatività e nei processi aziendali.
Più in dettaglio, esistono alcuni processi e pratiche di lavoro che è necessario sviluppare. Sono oggi definite come XOps (primariamente ModelOps e DataOps), e sono accumunate dalla necessità di realizzare economie di scala, affidabilità, riuso e ripetibilità, indipendentemente dall’infrastruttura tecnologica sottostante (Public, Hybrid, Private Cloud o on-premise).
ModelOps
La prima componente, quella di ModelOps deriva il nome dal concetto di AI Model Operationalization (Operazionalizzazione) ed è senza dubbio al centro di una strategia di AI. Queste pratiche portano nel mondo dell’AI governo e un approccio di life-cycle mgmt, ossia di gestione dell’intero ciclo di vita di un modello decisionale di AI. Gestione di un repository per i modelli, del versioning per consentirne un’evoluzione ordinata e senza difetti causati da regressioni, model training (ossia la gestione del processo di apprendimento dei modelli algoritmici), roll-out/roll-back, Continuous Integration & Continuous Delivery, sono tutti esempi di queste pratiche.
Tra i benefici che l’adozione di queste pratiche comporta vi sono una riduzione dei re-work attraverso la definizione a monte di scenari di deployment predefiniti, la tracciabilità (data lineage) per finalità di audit e di compliance e infine il monitoraggio e alerting sulle performance dei modelli al fine di identificare il momento in cui sia necessario un re-training degli stessi. Rispetto a quest’ultimo aspetto è quanto mai opportuno definire delle soglie e dei meccanismi di alerting per identificare comportamenti anomali dei modelli nel loro utilizzo reale.
Tipicamente i responsabili per le attività di ModelOps sono gli AI engineers che creano e gestiscono le “pipeline” di dati, lavorando a stretto contatto con i data engineers, referenti per i processi di build, test e deployment dei dati in produzione. Sono questi ultimi infatti a dover rendere accessibili e disponibili i dati al momento giusto ai diversi utilizzatori (e.g., data scientist o business analyst).
DataOps
La seconda pratica di lavoro è quella cosiddetta di DataOps. Essa deve assicurare un ordinato flusso di dati dalla loro origine sino ai punti di utilizzo e consumo. L’obiettivo ultimo è quello di generare valore dai dati quanto più semplicemente e rapidamente possibile.
Le DataOps operano sulle date pipeline per le quali definiscono aspetti di data architecture, data modeling, data configuration, data quality e data integration.
Queste pratiche devono essere ispirate a principi di agilità. Per esempio, è in questo ambito che vengono progettate le Canary Release, ossia i rilasci graduali e controllati di nuove feature a un sottoinsieme di utenti. L’obiettivo ultimo di questa pratica è quello di “democratizzare” l’utilizzo dei dati a livello organizzativo, creando allineamento tra chi i dati li produce e chi li utilizza.
ModelOps e DataOps hanno un elemento in comune rappresentato dalla governance. Essa deve consentire un adeguato bilanciamento tra istanze di controllo, accessibilità, accountability e tracciabilità nell’utilizzo dei dati.
Cosa richiede l’operazionalizzazione dell’AI
Quelle che abbiamo descritto sono pratiche operative che hanno implicazioni sia sul modello operativo e potenzialmente anche su quello organizzativo. Di certo l’operazionalizzazione dell’AI richiede di lavorare con team cross funzionali, i cosiddetti data product team, spesso posti a riporto in forma matriciale di una linea di business e del Chief data officer (CDO).
Questi team sono guidati da figure di product management che devono concepire (attraverso un product visioning), disegnare, testare, deployare e monitorare l’evoluzione di prodotti digitali, sempre in funzione del valore di business generato. I team, caratterizzati da grande autonomia, sono solitamente composti da un numero di risorse che varia tra tre e otto per ogni singolo data product.
AIOps non rappresentano dunque una tecnologia e nemmeno una metodologia, quanto piuttosto un insieme di pratiche di lavoro e di modelli operativi diversificati. Non si tratta di una soluzione “a scaffale” che si può acquistare sul mercato quanto di un percorso progressivo di sviluppo di competenze che richiede adeguata maturità organizzativa e cultura.
Conclusioni
Siamo agli inizi del nuovo anno e di una fase di accelerazione della trasformazione digitale. Le organizzazioni che sapranno cogliere la natura cross funzionale e multi-disciplinare dell’AI, efettuando l’operazionalizzazione, combinando mestieri tradizionali (e.g., data architect, data modeler, data steward) e nuovi mestieri (e.g., data engineer, AI engineer, data scientist, ML validators) avranno le possibilità maggiori di estrarre valore cogliendo le opportunità trasformative di queste tecnologie.
