Ricerca e scoperta · Fase 01 · Come lavoriamo
Ogni collaborazione con OpenQCore inizia con un'indagine strutturata. Prima di proporre intelligenza artificiale, automazione, software o infrastruttura, studiamo il problema come un sistema: i suoi obiettivi, gli stakeholder, i flussi di lavoro, le decisioni, i dati, le tecnologie, le dipendenze, i vincoli, i rischi e i risultati misurabili.
Il nostro processo di discovery combina ricerca, pensiero sistemico, analisi ingegneristica e ragionamento aziendale per passare da una sfida osservata a una definizione del problema difendibile.
Perché la prima domanda non dovrebbe essere:
Non questa domanda
"Quale tecnologia dovremmo implementare?"
Questa domanda, invece
"Quale problema stiamo effettivamente risolvendo — quali prove lo supportano, cosa lo causa, e quale risultato deve cambiare?"
Ricerca · Evidenza · Analisi dei sistemi · Analisi aziendale · Misurazione
Perché la fase di discovery viene prima
L'intelligenza artificiale è diventata sostanzialmente più facile da sperimentare. Convertire la sperimentazione in valore organizzativo misurabile rimane invece molto più difficile.
74%
delle aziende non avevano ancora dimostrato e scalato un valore tangibile dall'IA.
BCG, Where's the Value in AI?, 2024 · n=1.000 dirigenti senior.
La ricerca BCG del 2024, basata su 1.000 CxO e dirigenti senior in più di 20 settori e 59 paesi, ha rilevato che solo il 26% delle aziende aveva sviluppato le capacità necessarie per andare oltre i proof of concept e generare valore tangibile dall'IA.
Questo non significa che la tecnologia sia inefficace. Significa che la tecnologia da sola è insufficiente.
Le organizzazioni possono iniziare con un modello, una piattaforma o una tecnologia di automazione e scoprire solo più tardi che il vincolo sottostante risiede altrove: processi frammentati, dati inaccessibili, responsabilità poco chiare, limitazioni di integrazione, controlli inadeguati, obiettivi mal definiti o un problema che inizialmente non era stato misurato.
OpenQCore quindi inverte la sequenza: la tecnologia dovrebbe essere selezionata come conseguenza della comprensione del problema — non come sostituto della comprensione dello stesso.
Un approccio multidisciplinare
I problemi organizzativi complessi raramente appartengono a una sola disciplina. OpenQCore li analizza attraverso tre prospettive complementari.
Osservare · Porsi domande · Formulare ipotesi · Testare · Validare
Il ragionamento scientifico ci aiuta a distinguere le osservazioni dalle supposizioni, a formulare domande, a esaminare spiegazioni concorrenti e a determinare quali evidenze supporterebbero o contraddirebbero un'ipotesi. Non diamo per scontato che la prima spiegazione sia quella corretta.
Sistemi · Interfacce · Dati · Dipendenze · Vincoli · Affidabilità
L'analisi ingegneristica esamina come i componenti interagiscono all'interno del sistema più ampio — software, infrastrutture, dati, persone, processi, interfacce, sistemi esterni e dipendenze operative.
Questa prospettiva è coerente con il pensiero moderno dell'ingegneria dei sistemi. ISO/IEC/IEEE 15288:2023 definisce i processi del ciclo di vita dei sistemi applicabili a singoli elementi di sistema e a sistemi-di-sistemi, con il coinvolgimento degli stakeholder per tutto il ciclo di vita.
Obiettivi · Economia · Processi · Rischio · Valore · Misurazione
L'analisi aziendale stabilisce perché il problema è importante. Esaminiamo l'esito desiderato, gli stakeholder coinvolti, l'impatto operativo, le considerazioni economiche, i vincoli organizzativi e come verrebbe misurato il miglioramento.
La trasformazione AI è spesso discussa principalmente in termini di modelli e algoritmi. Le evidenze di implementazione suggeriscono un quadro più ampio: la ricerca di BCG del 2024 ha rilevato che circa il 70% delle sfide affrontate dalle aziende nelle iniziative di AI riguardava persone e processi, circa il 20% la tecnologia, e solo il 10% gli algoritmi.
10%
Algoritmi
BCG Build for the Future 2024 Global Study · n=1.000.
20%
Tecnologia e Dati
BCG Build for the Future 2024 Global Study · n=1.000.
70%
Persone e Processi
BCG Build for the Future 2024 Global Study · n=1.000.
Queste percentuali sono il quadro di ricerca di BCG, non una legge universale. Tuttavia rafforzano un principio ingegneristico importante: il modello è un componente di un più ampio sistema sociotecnico. Per OpenQCore, la fase di discovery quindi esamina non solo il livello di intelligenza, ma l'ambiente operativo nel quale tale intelligenza verrebbe introdotta.
La metodologia di ricerca di OpenQCore
La fase di discovery è condotta come una sequenza strutturata di indagine. La profondità esatta varia in base all'intervento, ma la struttura analitica rimane coerente.
Quale risultato conta — e per chi?
Iniziamo identificando le persone, le funzioni e i sistemi interessati dal problema. La richiesta dichiarata di un'organizzazione non viene automaticamente interpretata come l'obiettivo sottostante — "abbiamo bisogno di un agente AI" descrive una possibile implementazione, non ancora il problema aziendale o ingegneristico.
Esaminiamo
Stakeholder · Titolari delle decisioni · Utenti · Obiettivi aziendali · Obiettivi operativi · Incentivi · Dipendenze · Requisiti in conflitto
Output
Modello di stakeholder e obiettivi
Come opera effettivamente il sistema oggi?
Ricostruiamo il processo operativo attuale invece di fare affidamento esclusivamente su come tale processo è documentato. Quando opportuno, definiamo baseline quantitative per il flusso di lavoro esistente.
L'analisi può includere
Processi · Attività · Decisioni · Passaggi di consegna · Code · Eccezioni · Intervento umano · Colli di bottiglia · Rielavorazioni · Flusso di informazioni
Output
Modello operativo dello stato attuale
In quale ambiente tecnico stiamo operando?
Esaminiamo l'architettura che circonda il problema e analizziamo separatamente l'ambiente dati. Questo è importante perché una capacità di IA che funziona sperimentalmente potrebbe comunque risultare inadatta alla produzione se le informazioni richieste non sono accessibili in modo affidabile, sicuro o con qualità sufficiente.
Esaminiamo
Applicazioni · Servizi · API · Database · Infrastruttura · Integrazioni · Identità · Sicurezza · Dipendenze esterne — e la disponibilità, accessibilità, struttura, qualità, origine e tracciabilità, proprietà, copertura, aggiornamento e sensibilità dei dati
Output
Panoramica dei sistemi e dei dati
Quale contesto esterno influenza il problema?
Una soluzione tecnicamente valida può comunque essere inappropriata dal punto di vista operativo o commerciale. L'ambito dipende dall'incarico — un sistema sanitario regolamentato, una piattaforma finanziaria e uno strumento di produttività interno non richiedono gli stessi tipi di indagine contestuale.
Quando pertinente, esaminiamo
Condizioni di mercato · Struttura dell'industria · Regolamentazione · Standard tecnici · Ambiente competitivo · Panorama tecnologico · Aspettative dei clienti · Dipendenze esterne
Output
Modello del contesto e dell'ambiente esterno
Cosa limita lo spazio delle soluzioni?
I vincoli sono trattati come input di progettazione piuttosto che come sorprese scoperte durante l'implementazione. Separiamo anche esplicitamente fatti noti, assunzioni, incertezze note, dipendenze e rischi — perché l'incertezza dovrebbe essere documentata, non convertita silenziosamente in certezza.
Identifichiamo
Vincoli tecnici, operativi, di budget e di tempo · Requisiti di sicurezza, privacy e normativi · Vincoli organizzativi · Rischi di adozione · Dipendenze di integrazione · Limiti dei dati
Output
Registro di vincoli, assunzioni e rischi
Cosa deve cambiare esattamente?
La discovery converge su una definizione precisa del problema, che copre la condizione osservata, le evidenze, le cause profonde, il sistema interessato, lo stato di riferimento, lo stato obiettivo, i criteri di successo, i vincoli e i non-obiettivi espliciti.
La definizione include
Condizione osservata · Evidenze · Cause profonde · Sistema interessato · Stato di riferimento · Stato obiettivo · Criteri di successo · Vincoli · Non-obiettivi
Output
Definizione del problema validata
Il ciclo di scoperta
La scoperta non è semplicemente una checklist completata una volta, da sinistra a destra.
Osservare
Analizzare
Mappare
Formulare ipotesi
Validare
Definire
Quando si raggiunge un livello di fiducia sufficiente: Problema convalidato → Strategia e Architettura.
Applicazione della metodologia
Un problema osservato e la sua causa sottostante non sono necessariamente la stessa cosa. Considera un esempio operativo semplificato.
Condizione osservata: Le richieste dei clienti richiedono 48 ore per essere elaborate.
Evidenza del flusso di lavoro: Le richieste passano attraverso più approvazioni manuali.
Evidenza del sistema: Le informazioni rilevanti sono distribuite su applicazioni disconnesse.
Evidenza dei dati: Le stesse informazioni vengono ripetutamente recuperate e verificate.
Ipotesi della causa principale: Il flusso di lavoro frammentato e le informazioni inaccessibili generano lavoro umano ripetuto.
A questo punto, aggiungere semplicemente un'interfaccia conversazionale può migliorare l'esperienza verso il cliente senza risolvere il vincolo di processo sottostante. La questione ingegneristica quindi cambia da "Come aggiungiamo l'IA?" a "Quale intervento modifica il meccanismo causale che produce l'esito indesiderato?" — quella distinzione è centrale per Ricerca e Scoperta.
Osservazione: La verifica manuale dei documenti è associata a un significativo collo di bottiglia nel processo.
Ipotesi: Un flusso di lavoro controllato di intelligenza documentale può ridurre la revisione manuale pur mantenendo i controlli di verifica necessari.
Evidenza richiesta: Documenti rappresentativi · Tassi di errore esistenti · Schemi di eccezione · Requisiti di revisione · Tempi di elaborazione
Valutazione: Qualità dell'estrazione · Tasso di eccezioni · Tasso di revisione umana · Tempo di elaborazione · Modalità di guasto
Decisione: Sostenere · Modificare · Rifiutare l'ipotesi
L'obiettivo non è dimostrare che una tecnologia proposta funzioni. L'obiettivo è stabilire se le prove giustificano il suo utilizzo.
Definire il successo prima dell'implementazione
Se il successo viene definito solo dopo l'implementazione, quasi qualsiasi risultato può essere interpretato come tale. OpenQCore quindi stabilisce baseline rilevanti e criteri di valutazione durante la fase di discovery.
Tempo di ciclo
Quanto tempo richiede il processo?
Costo per operazione
Quali risorse consuma ogni transazione?
Tasso di errore
Quanto spesso il processo produce un risultato errato?
Capacità di elaborazione
Quanto lavoro può elaborare il sistema?
Sforzo umano
Quanto intervento manuale è necessario?
Affidabilità
Quanto coerentemente il sistema opera?
Qualità delle decisioni
Quanto accuratamente o coerentemente vengono prese le decisioni?
Tasso di automazione
Quali operazioni possono essere completate senza intervento manuale?
Esposizione al rischio
Quali rischi operativi, di sicurezza o di conformità esistono?
Metriche dell'esperienza
In che modo il processo influisce sui clienti, sui dipendenti o su altri utenti?
La struttura è semplice: Valore di riferimento → Intervento → Obiettivo → Misurazione → Valutazione.
Se il cambiamento desiderato non può essere descritto, il successo della soluzione non può essere valutato in modo significativo.
L'IA richiede un'analisi del rischio contestuale
Per gli interventi relativi all'IA, la fase di discovery esamina anche se l'uso proposto dell'IA sia appropriato per il contesto in cui opererà. Il Framework di gestione del rischio dell'IA del NIST organizza le attività di gestione del rischio attorno a quattro funzioni e descrive la gestione del rischio come continua lungo l'intero ciclo di vita dell'IA piuttosto che come un esercizio di conformità una tantum.
Il framework identifica inoltre le caratteristiche associate a un'IA affidabile, tra cui validità e affidabilità, sicurezza, protezione e resilienza, responsabilità e trasparenza, spiegabilità e interpretabilità, tutela della privacy e gestione dei bias dannosi.
Uso previsto
Potenziali modalità di guasto
Supervisione umana
Sensibilità dei dati
Conseguenze delle decisioni
Sicurezza
Affidabilità
Requisiti di valutazione
Controlli operativi
Requisiti di governance
Ciò non significa che ogni progetto richieda la stessa architettura di governance. I controlli di rischio dovrebbero essere proporzionati al sistema, al suo contesto e alle conseguenze di un guasto.
Evidenza prima della raccomandazione
Stiamo cercando l'intervento sostenuto dalle evidenze. Le evidenze più recenti continuano a ribadire l'importanza di riprogettare il lavoro anziché limitarsi a sovrapporre l'IA ai processi esistenti.
~2/3
delle organizzazioni non avevano ancora iniziato a scalare l'IA a livello aziendale.
McKinsey, The State of AI: Global Survey 2025.
39%
hanno riportato un impatto sull'EBIT legato all'IA a livello aziendale.
McKinsey, The State of AI: Global Survey 2025.
La stessa ricerca individua la riprogettazione del flusso di lavoro come caratteristica chiave delle organizzazioni che ottengono maggior valore dall'IA — uno dei motivi per cui OpenQCore esamina il modello operativo che circonda la tecnologia piuttosto che considerare la sua implementazione come obiettivo.
OpenQCore non avvia la fase di discovery con una soluzione tecnica predeterminata. Le evidenze possono indicare che l'intervento appropriato sia la riprogettazione dei processi, l'integrazione dei sistemi, l'ingegneria del software convenzionale, l'architettura dei dati, l'automazione dei flussi di lavoro, l'analitica, l'intelligenza artificiale o una loro combinazione. In alcuni casi, le evidenze possono indicare che non è affatto giustificata la creazione di nuova tecnologia.
OpenQCore non raccomanda l'intelligenza artificiale perché è di moda. La raccomandiamo quando il problema, le evidenze, l'economia e i vincoli operativi ne giustificano l'uso — e indichiamo chiaramente quando ciò non avviene.
Problema → Evidenze → Requisiti → Vincoli → Interventi candidati → Valutazione → Approccio più adatto — non: IA → Cercare un posto dove usarla.
La selezione della tecnologia segue l'indagine.
Le assunzioni sono identificate piuttosto che presentate come fatti.
Le conclusioni importanti dovrebbero essere collegate alle evidenze che le supportano.
Quando esiste incertezza, dovrebbero essere considerate spiegazioni alternative.
I criteri di successo sono definiti prima dell'implementazione, quando praticabile.
Gli aspetti sconosciuti e le limitazioni rimangono visibili.
Il livello di analisi dovrebbe riflettere il costo, la complessità e il rischio della decisione.
Cosa produce la scoperta
Ricerca e scoperta non hanno lo scopo di terminare con una presentazione piena di osservazioni. Dovrebbero produrre artefatti che possano informare una decisione ingegneristica. A seconda dell'ambito dell'incarico, questi possono includere:
Il contesto del problema, le evidenze, le osservazioni e i principali risultati.
Chi è coinvolto, chi prende le decisioni e quali risultati contano.
Come il lavoro e le informazioni si muovono nell'organizzazione oggi.
Applicazioni, interfacce, fonti di dati, dipendenze e vincoli tecnici.
Spiegazioni basate su evidenze per la condizione osservata.
Prestazioni attuali rispetto agli indicatori operativi o tecnici rilevanti.
Requisiti funzionali, tecnici, operativi e di governance identificati durante la fase di discovery.
Fattibilità tecnica, dei dati, di integrazione e operativa ove necessario.
Interventi potenziali prioritizzati in base a evidenze, valore, fattibilità e rischio.
Limitazioni note, ipotesi, dipendenze e rischi rilevanti.
Obiettivi, metriche e approccio di valutazione.
Il Gate decisionale della discovery
Lo scopo della discovery non è garantire che un progetto proceda. È stabilire se debba farlo. Un'attività di discovery può quindi concludersi con una delle seguenti direzioni:
Il problema è sufficientemente definito, le evidenze supportano l'intervento e sembra fattibile un percorso ingegneristico.
Permane un'incertezza importante e sono necessarie ulteriori evidenze.
Il problema originale o l'intervento proposto non corrispondono a quanto emerso dall'indagine.
L'obiettivo rimane valido, ma è più appropriato un intervento tecnico o operativo diverso.
Il valore atteso, la fattibilità o il rischio non giustificano l'implementazione.
Non costruire il sistema sbagliato può essere prezioso quanto costruire quello giusto.
Dalla ricerca all'architettura
Ricerca e discovery non esistono separatamente dal ciclo di vita dell'ingegneria. I loro output diventano input per la fase successiva: Evidenze → Definizione del problema convalidata → Requisiti → Vincoli e rischi → Criteri di successo → Strategia e architettura.
L'architettura non dovrebbe iniziare come una collezione di tecnologie preferite. Dovrebbe emergere da una comprensione difendibile di ciò che il sistema deve realizzare, entro quali vincoli, per quali stakeholder, a quale livello accettabile di rischio e rispetto a quali risultati misurabili.
Fase 02
Trasforma un problema validato in una direzione ingegneristica del sistema.
Non è necessario presentarsi con una strategia AI. Porta la sfida operativa, il vincolo tecnico, la domanda di ricerca o l'obiettivo di business. Iniziamo determinando cosa sta effettivamente accadendo — e cosa le evidenze indicano debba succedere dopo.
Riferimenti di ricerca e metodologici
Citiamo direttamente queste fonti invece di nasconderle, perché la nostra metodologia si basa su principi consolidati dell'indagine scientifica, dell'ingegneria dei sistemi, dell'ingegneria dei requisiti, dell'analisi aziendale e della gestione del rischio.
Boston Consulting Group — Dov'è il valore nell'AI? (2024)
Basato su un sondaggio su 1.000 CxO e dirigenti senior in oltre 20 settori e 59 Paesi; la fonte delle cifre 74% / 26% e del principio 10–20–70 citato sopra.
McKinsey & Company — Lo stato dell'AI: Indagine globale 2025
Fonte dei dati sull'espansione e sull'impatto dell'EBIT a livello aziendale, e della constatazione sull'importanza della riprogettazione dei flussi di lavoro nelle organizzazioni ad alte prestazioni.
ISO/IEC/IEEE 15288:2023 — Ingegneria dei sistemi e del software — Processi del ciclo di vita del sistema
Il riferimento ingegneristico principale per trattare i sistemi, i loro elementi, il ciclo di vita e gli stakeholder in modo strutturato.
ISO/IEC/IEEE 29148:2018 — Ingegneria dei requisiti
Specifica processi e elementi informativi per l'ingegneria dei requisiti attraverso i cicli di vita di sistemi e software; ISO ha confermato l'edizione come corrente a seguito di una revisione nel 2024.
NIST — Framework per la gestione del rischio dell'intelligenza artificiale (AI RMF 1.0)
Supporta il pensiero sul rischio dell'AI in contesto attraverso Govern, Map, Measure and Manage, con gestione continua del rischio lungo il ciclo di vita dell'AI. L'AI RMF 1.0 del NIST è in revisione attiva, perciò indichiamo esplicitamente la versione invece di implicare che sia sempre l'ultima release finale.
