Nella prima visita a uno stabilimento non si porta una lista di funzionalità. Si portano tre domande, affinate nel tempo attraverso l'osservazione diretta di contesti produttivi diversi. Non sono domande tecniche.
Non chiedono quali sistemi usa l'azienda: quelle informazioni arrivano dopo. Prima arrivano le domande operative — e dalle risposte nasce ogni progetto.
Non dal software. Non dall'architettura. Non dalla lista delle macchine da connettere. Dalle risposte a queste tre domande capiamo quale informazione manca, dove si trova il dato che potrebbe generarla e quale sarebbe il valore concreto di averla. Da lì nasce il primo caso d'uso. Da lì inizia il pilota.
La Practice ha due mondi. AQ custodisce l'identità di aqumo: chi siamo e in cosa crediamo. OI custodisce il metodo dell'Operational Intelligence: come osserviamo, diagnostichiamo, progettiamo e realizziamo. Il percorso è sempre lo stesso, indipendentemente dalla dimensione del progetto.
Attraverso tutte e tre le fasi corrono due livelli che non appartengono a nessuna in particolare: la conoscenza condivisa — il lessico, il modello di lettura, la casistica dei pattern ricorrenti — e la governance, le decisioni che fanno evolvere la Practice nel tempo.
Il pilota non è una tecnica di vendita. È una verifica metodologica: serve a capire se il problema identificato corrisponde al problema reale, e se l'approccio che proponiamo è quello giusto per affrontarlo.
Uno dei motivi per cui le aziende rimandano la digitalizzazione è la percezione del rischio. Nelle organizzazioni manifatturiere la resistenza all'adozione di nuovi strumenti è raramente economica: è quasi sempre percettiva — memoria di progetti che non hanno consegnato i risultati attesi, timore della complessità implementativa.
Per questo la barriera all'ingresso è azzerata di proposito. Nessun CAPEX, nessun impegno pluriennale, nessuna disruption della produzione.
Collegamento della sorgente dati scelta tramite aSkimmer, configurazione del modello dati, prime correlazioni fra domini.
Primo cruscotto operativo, prima risposta alla domanda manageriale definita insieme, presentazione al management.
Fa parte della fase «dimostrare», non è un servizio a parte: dopo l'assessment, insieme alla diagnosi, valutiamo se e come il progetto è finanziabile. Gli strumenti di agevolazione hanno requisiti precisi su cosa è ammissibile e in che forma — se il progetto viene costruito conoscendoli, resta finanziabile senza essere distorto per inseguire un bando.
La sequenza abituale è al contrario: prima si compra, poi si cerca il contributo, e si scopre che quella voce di spesa non rientra, che serviva una perizia da richiedere prima dell'ordine, o che l'investimento andava avviato dopo la domanda e non prima.
Ogni voce di costo ha una natura — bene materiale, licenza immateriale, digitalizzazione, consulenza, formazione, costo ricorrente. È quella classificazione, non l'importo, a determinare cosa è recuperabile e con quale strumento. Separare correttamente hardware e licenze fin dal preventivo, per dire, cambia il risultato: per il finanziamento contano in modo diverso.
È un lavoro di struttura del progetto, non di ricerca di bandi. E si fa quando il progetto si sta ancora definendo — dopo, si può solo prendere atto.
Quando due strumenti sono regimi alternativi sullo stesso investimento, se ne può usare uno solo. Presentare la somma di tutto come «recuperabile» è la scorciatoia più diffusa e la meno onesta.
L'interlocutore fiscale resta il commercialista dell'azienda, che conosce la posizione complessiva e se ne assume la responsabilità. Noi portiamo l'esperienza su come si struttura un progetto industriale perché resti ammissibile, e gli forniamo gli elementi tecnici che servono a valutare: natura delle spese, tempistiche, documentazione richiesta. Non ci sostituiamo a lui e non presentiamo domande al posto suo.
Al termine dell'assessment, insieme alla diagnosi operativa, valutiamo se e come il progetto è finanziabile. Non perché siamo consulenti di finanza agevolata — non lo siamo, e quando serve quel tipo di competenza lo diciamo. Ma perché la struttura di un progetto industriale determina la sua ammissibilità, e quella struttura la disegniamo noi.
Per farlo abbiamo costruito uno strumento interno che mantiene aggiornata una banca dati di bandi e agevolazioni — europei, nazionali, regionali e settoriali — e confronta il profilo dell'azienda e le voci di costo reali del progetto con i requisiti di ciascuno strumento.
L'analisi dei requisiti è affidata a modelli linguistici, che leggono i bandi reali della banca dati e valutano la compatibilità. Gli importi però non li stima l'AI: li calcola codice deterministico, a partire dalle percentuali di copertura e dai massimali dichiarati dallo strumento, applicando cumulabilità e soglie. È la stessa regola che seguiamo ovunque — il modello ragiona, il codice calcola.
Il materiale è pensato per essere portato al vostro commercialista: contiene gli elementi tecnici che servono a lui per decidere, non una pratica già istruita.
È consegnato quando il cliente sa usarlo, il team sa mantenerlo e la documentazione riflette ciò che è stato costruito. Questa è la regola che tiene insieme tutta la fase di costruzione.
Il solution design consegna l'architettura: cosa costruire e come, in senso architetturale. Il disegno di dettaglio la trasforma in specifiche che uno sviluppatore può seguire senza dover chiedere chiarimenti ogni ora — versioni specifiche, schemi fisici, endpoint precisi, configurazioni esatte.
Il disegno di dettaglio è il momento più critico. Le scelte fatte qui — schema del database, contratti API, stack tecnologico, configurazione della piattaforma — sono difficili da cambiare dopo. Si investe tempo qui e si taglia altrove.
Dopo il primo deploy in produzione, lo schema del database non si modifica senza una migration numerata e versionata. Mai. Nemmeno «per un fix veloce».
Un disegno di dettaglio è completo quando permette a uno sviluppatore che non era al kickoff di iniziare a lavorare il giorno dopo.
Il metodo è documentato per intero: dai principi che lo guidano alle guide operative per l'assessment, la diagnosi, la progettazione e la realizzazione. Non è materiale di marketing — è la codifica di un modo di lavorare costruito visitando stabilimenti, osservando gli stessi problemi e cercando di descriverli con precisione.
Le osservazioni che attraversano questi documenti non sono inventate: sono note raccolte sul campo nel tempo, pattern ricorrenti, errori commessi e corretti. Il metodo cresce con ogni progetto.
È un pattern ricorrente nella consulenza industriale: nelle prime fasi di un percorso si porta una lista di funzionalità. Con l'esperienza si impara a portare domande. La differenza non sta nel prodotto: sta nel livello di comprensione del problema prima di qualsiasi proposta.
È lo stesso motivo per cui la nostra documentazione dice apertamente quando non siamo la risposta giusta. Chi è onesto su quando il proprio prodotto non serve guadagna la fiducia necessaria dove serve davvero.
Nessuna presentazione di prodotto. Un'ora per capire quali decisioni prendete ogni settimana senza i dati giusti per prenderle bene.