AI Manager o software house: chi chiamare prima?

Cosa trovi in questo articolo

Perché il progetto viene prima dell’acquisto del software
Il ruolo dell’AI Manager e quello della software house
Come osservare il lavoro reale e non automatizzare processi sbagliati
Locale o cloud, privacy e AI Act da considerare mentre si progetta
Come scrivere un capitolato e valutare i preventivi
Che cosa significa per una PMI o per uno studio professionale

Una decisione che precede l’acquisto del software

Un imprenditore decide che è arrivato il momento di introdurre l’intelligenza artificiale in azienda. Da dove parte?

Nella maggior parte dei casi cerca qualcuno che possa realizzare la soluzione. Contatta una software house, guarda qualche demo, ascolta la presentazione di un prodotto e prova a capire se può essere adattato alla propria azienda.

È comprensibile. Il rischio compare quando si passa direttamente dalla necessità generica alla proposta di un prodotto. Si sta cercando chi costruirà la soluzione prima ancora di avere stabilito con precisione quale soluzione serva. Se dovessi costruire un capannone, difficilmente chiameresti per prima l’impresa edile dicendole: «Ho questo terreno, costruiscimi qualcosa che possa essermi utile».

Si comincia con un progetto che chiarisca la destinazione d’uso, i vincoli e le responsabilità. Qualcuno studia cosa vuoi costruire, verifica i vincoli, controlla le norme applicabili, decide come devono essere organizzati gli spazi, prepara il progetto e solo successivamente vengono coinvolte le imprese che materialmente realizzeranno l’edificio.

Con l’intelligenza artificiale nelle aziende, invece, molto spesso facciamo il contrario. Ed è uno dei motivi per cui vedo aziende acquistare strumenti che dopo pochi mesi vengono utilizzati poco, automazioni che risolvono solo una parte del problema e progetti costruiti fin dall’inizio sulle tecnologie conosciute dal fornitore che li realizza.

Chi progetta deve conoscere vincoli e obiettivi

Quando parlo del lavoro di un AI Manager utilizzo spesso la figura del geometra. Il paragone serve a spiegare la divisione dei ruoli.

Il geometra non arriva con la betoniera. Prima capisce cosa devi costruire. Studia il progetto, valuta i vincoli, verifica ciò che può essere fatto, si confronta con gli altri professionisti coinvolti e coordina le imprese che dovranno realizzarlo.

L’AI Manager dovrebbe fare qualcosa di molto simile. Con AI Manager, in questo articolo, non intendo semplicemente una persona che conosce ChatGPT o che sa utilizzare qualche strumento di automazione.

Parlo di qualcuno che segue continuamente l’evoluzione dei modelli di intelligenza artificiale, dei software disponibili, delle architetture locali e cloud, dei sistemi RAG, degli agenti AI, delle possibilità di integrazione e del quadro normativo. Il suo lavoro, però, non consiste nel vendere uno di questi strumenti.

Deve capire quale combinazione di tecnologie serve davvero a quella specifica azienda. Ed è una differenza sostanziale.

Il compito della software house

La software house costruisce. Può sviluppare un’applicazione, integrare due sistemi, creare un’automazione, collegare un modello AI al gestionale, realizzare un’interfaccia oppure installare e personalizzare un proprio prodotto.

Ed è esattamente ciò che deve fare. Una buona software house ha sviluppatori competenti, conosce molto bene determinate tecnologie e può essere indispensabile per trasformare un progetto in qualcosa che funziona realmente.

La criticità nasce quando affidiamo allo stesso soggetto due incarichi molto diversi: decidere cosa conviene costruire e vendere ciò che verrà costruito. È una distinzione che un imprenditore dovrebbe considerare prima di iniziare qualsiasi progetto AI.

Se chi analizza il problema vende anche la soluzione, la scelta parte già da un perimetro

Immaginiamo tre software house:

La prima lavora soprattutto con Microsoft Azure e modelli cloud.
La seconda ha investito molto nello sviluppo di sistemi locali.
La terza possiede una propria piattaforma AI che cerca di vendere alle aziende.

Possiamo chiedere a tutte e tre di analizzare i processi della nostra azienda. Probabilmente faranno anche un buon lavoro. Ma è ragionevole aspettarsi che le soluzioni proposte saranno influenzate dalle competenze, dai prodotti e dalle tecnologie sulle quali quelle aziende hanno investito.

Chi analizza e vende insieme parte già da un perimetro: Prima software house; Seconda software house; Terza software house. — Non c’è necessariamente malafede: è il loro mestiere. Ma le soluzioni proposte saranno influenzate da ciò su cui hanno investito.

Non c’è necessariamente malafede. È semplicemente il loro mestiere. Se possiedo una piattaforma che automatizza il servizio clienti, cercherò aziende alle quali possa essere utile quella piattaforma. Se la mia squadra di sviluppatori lavora principalmente su una determinata infrastruttura, tenderò a proporre sistemi che posso realizzare con quell’infrastruttura.

La situazione diventa ancora più delicata quando la soluzione migliore richiede competenze che quel fornitore non possiede. Supponiamo che, dopo aver analizzato un processo, emerga che la soluzione ideale richiede una tecnologia molto specifica che viene sviluppata particolarmente bene da un’altra azienda.

Cosa dovrebbe fare la software house? Mandare il cliente dal concorrente? Può succedere. Esistono aziende molto serie che lo fanno. Ma stiamo comunque chiedendo a un fornitore di prendere una decisione che potrebbe andare contro il proprio interesse commerciale.

Un consulente indipendente parte da una posizione diversa. Può dire: «Per questa parte utilizziamo il fornitore A, per questa il prodotto B, mentre questa attività non ha senso svilupparla perché esiste già un software che la fa bene e costa 200 euro al mese». Ed è proprio questa libertà di scelta che considero uno dei principali valori di un AI Manager indipendente.

Il progetto AI non dovrebbe iniziare parlando di AI

Quando entro in un’azienda, la prima domanda che mi interessa non è: «Quale modello linguistico volete utilizzare?» E nemmeno: «Volete farlo in cloud o in locale?» La prima cosa che voglio capire è molto più semplice. Dove state perdendo tempo?

Per scoprirlo non basta fare una riunione con l’imprenditore. Bisogna entrare nei reparti. Occorre parlare con le persone e osservare come lavorano, perché il racconto di un’attività spesso non restituisce tutti i passaggi concreti.

Questa parte viene spesso sottovalutata. Un dipendente può raccontarmi che ogni mattina «gestisce gli ordini». Ma cosa significa concretamente?

Magari apre una mail. Scarica un PDF. Controlla il codice cliente. Apre il gestionale. Inserisce manualmente cinque campi. Controlla se il materiale è disponibile. Apre il sito del trasportatore. Chiede un preventivo. Torna sul gestionale. Poi scrive una mail al cliente.

Se mi limito alla frase «gestisco gli ordini», non ho capito quasi nulla del processo. Devo sedermi accanto a quella persona e vedere quali finestre apre, quali dati copia, cosa controlla, dove deve prendere una decisione e cosa succede quando trova un’eccezione. È da lì che bisogna partire.

Lo stesso vale per molte altre attività che in tante aziende si fanno ancora a mano: ricopiare i dati delle email nel gestionale, scrivere i preventivi, sollecitare i fornitori, sollecitare i pagamenti dei clienti. Prima di parlare di AI conviene capire come vengono fatte davvero, un passaggio alla volta, da chi le fa ogni giorno.

Automatizzare un processo sbagliato significa farlo sbagliare più velocemente

C’è poi un altro errore molto comune. Si prende il processo esistente e lo si automatizza così com’è. Ma non è detto che sia la scelta corretta.

Prima bisogna chiedersi se tutti i passaggi abbiano ancora senso. Magari un’informazione viene copiata da Excel al gestionale soltanto perché dieci anni fa i due sistemi non comunicavano.

Magari un PDF viene stampato perché il dipendente ha sempre lavorato in quel modo. Magari tre persone controllano la stessa informazione perché negli anni nessuno ha mai ridisegnato il flusso. Mettere l’intelligenza artificiale sopra un processo di questo tipo significa spendere soldi per automatizzare anche le inefficienze.

Il lavoro dell’AI Manager comincia quindi prima della tecnologia. Osserva il processo attuale, lo ricostruisce, elimina i passaggi che non servono, individua quelli che possono essere automatizzati e stabilisce quali decisioni devono continuare a essere prese da una persona. Solo a quel punto ha senso parlare di software.

Una soluzione tecnicamente perfetta può non essere utilizzata da nessuno

C’è un’altra variabile che sulla carta viene spesso ignorata: le persone. Prendiamo un’impiegata amministrativa che svolge la stessa attività da otto anni.

Sa esattamente dove trovare ogni informazione. Conosce le eccezioni. Ha costruito il proprio metodo. Adesso arriva un nuovo software.

Il software può funzionare dal punto di vista tecnico, pur modificando completamente il modo in cui lei riceve le informazioni, cambia l’ordine delle operazioni e produce un risultato in un formato diverso da quello che usa da anni.

Cosa può succedere? Che dopo una settimana l’impiegata torni al proprio Excel. Non perché sia contraria all’intelligenza artificiale. Semplicemente perché il nuovo sistema le rende il lavoro meno comprensibile o più scomodo.

Per questo considero fondamentale coinvolgere chi svolge realmente l’attività. Una buona automazione non dovrebbe nascere da una presentazione fatta alla direzione. Dovrebbe nascere osservando il lavoro reale e progettando il nuovo processo insieme alle persone che dovranno utilizzarlo.

A volte significa cambiare radicalmente il metodo. Altre volte conviene lasciare quasi identico ciò che vede il dipendente e automatizzare tutto quello che succede dietro. Alla fine conta una cosa molto semplice: il lunedì mattina qualcuno deve aprire il computer e riuscire a fare in dieci minuti ciò che prima richiedeva un’ora.

Prima il requisito, poi la tecnologia

Dopo aver capito il processo si può iniziare a parlare seriamente di tecnologia. A questo stadio, l’indipendenza di chi progetta permette di valutare alternative anche molto diverse tra loro.

La soluzione potrebbe essere un software già esistente.
Potrebbe bastare collegare due programmi che l’azienda possiede già.
Potrebbe servire una piccola automazione.
Potrebbe essere necessario sviluppare qualcosa su misura.
Potrebbe servire un sistema RAG, cioè un sistema che permette a un modello AI di cercare informazioni all’interno dei documenti dell’azienda prima di formulare una risposta.
Oppure potrebbe emergere che l’intelligenza artificiale non serve affatto.

Anche questa dovrebbe essere una risposta possibile. Se per risolvere il problema basta modificare una funzione del gestionale esistente, costruire un agente AI sarebbe probabilmente uno spreco di denaro. Chi progetta il sistema dovrebbe poterlo dire senza preoccuparsi di perdere la vendita di un software.

Locale o cloud? Dipende dal processo

Un altro esempio riguarda l’infrastruttura. Negli ultimi anni la discussione sull’AI aziendale si è spesso trasformata in una contrapposizione tra chi vuole mettere tutto nel cloud e chi sostiene che qualsiasi dato debba rimanere dentro l’azienda.

Nella realtà le situazioni sono molto più sfumate. Un’azienda può avere attività per le quali un servizio cloud è perfettamente adeguato e altre nelle quali è opportuno mantenere determinati dati o elaborazioni sulla propria infrastruttura.

Può avere senso utilizzare un modello locale per una parte del processo e interrogare un modello cloud più potente per un’altra. Si può anche costruire un’architettura nella quale alcune informazioni vengono rimosse o sostituite prima che il testo venga inviato a un servizio esterno. In alcuni progetti, quindi, la soluzione migliore può essere ibrida.

Chi vende esclusivamente soluzioni cloud tenderà naturalmente a guardare il problema da quel punto di vista. Lo stesso può accadere, al contrario, a chi ha costruito il proprio lavoro esclusivamente sui sistemi locali. La scelta deve dipendere dal processo, dai dati utilizzati, dai rischi, dai costi e dalle prestazioni richieste.

Privacy e AI Act vanno considerati mentre si progetta

Quando un sistema AI entra nei processi aziendali può trattare email, documenti, informazioni sui dipendenti, dati dei clienti, contratti, conversazioni, fatture o informazioni riservate. Non ha senso progettare tutto il sistema e, due giorni prima della messa in produzione, chiedere al consulente privacy se va bene.

Il GDPR prevede già il principio della protezione dei dati fin dalla progettazione e per impostazione predefinita. In concreto significa che il trattamento dei dati deve essere pensato fin dall’inizio cercando di utilizzare soltanto le informazioni necessarie e adottando misure tecniche e organizzative adeguate. A questo si aggiunge l’AI Act europeo, che introduce obblighi diversi in base al tipo di sistema e all’utilizzo che ne viene fatto.

Questo non significa che l’AI Manager debba sostituire un avvocato, un DPO o un consulente privacy. Deve però conoscere abbastanza bene la materia da capire quando coinvolgerli e quali scelte tecniche devono essere riviste insieme a loro. Perché una decisione apparentemente tecnica può cambiare completamente il modo in cui vengono trattati i dati.

Anonimizzare i dati non significa semplicemente togliere il nome

Anche su questo tema bisogna essere precisi. Immaginiamo che un sistema debba elaborare una mail contenente il nome di un cliente, il numero di contratto e altre informazioni personali.

Si potrebbe progettare un passaggio intermedio che sostituisce alcuni dati prima di inviare il testo al modello esterno. Per esempio: «Mario Rossi, contratto 48372» potrebbe diventare: «CLIENTE_17, CONTRATTO_04».

Una volta ricevuta la risposta dal modello, il sistema interno può reinserire i dati originali. È una soluzione tecnica interessante in molti contesti.

Dal punto di vista giuridico, però, bisogna utilizzare le parole corrette. Se esiste un’informazione separata che permette di risalire alla persona, generalmente stiamo parlando di pseudonimizzazione e non necessariamente di anonimizzazione.

Può sembrare una distinzione da addetti ai lavori, ma ha conseguenze molto concrete. Il modo in cui progettiamo l’architettura determina quali dati escono dall’azienda, quali informazioni può vedere il fornitore esterno e quali misure di sicurezza dobbiamo predisporre. Per questo tecnologia, privacy e organizzazione devono essere affrontate insieme.

Prima il progetto, poi chi lo costruisce. — Il progetto viene prima, e con gli stessi requisiti si possono confrontare fornitori diversi.

Il lavoro dell’AI Manager arriva prima del preventivo della software house

Prima di chiedere a qualcuno quanto costa sviluppare una soluzione, bisognerebbe avere risposte abbastanza chiare ad alcune domande:

Quale attività vogliamo migliorare e quanto tempo assorbe oggi?
Come viene svolta davvero dalle persone che se ne occupano?
Ci sono passaggi che possiamo eliminare prima ancora di automatizzarli?
Quali dati vengono utilizzati e dove si trovano?
Quali decisioni può prendere il sistema e quali devono continuare a essere prese da una persona?
Esiste già un prodotto che risolve bene il problema oppure serve uno sviluppo personalizzato?
Conviene utilizzare servizi cloud, sistemi locali oppure una combinazione dei due?
Quali vincoli di sicurezza, privacy e normativa devono essere considerati?
E soprattutto: come capiremo, una volta installato il sistema, se è servito davvero?

Solo dopo queste risposte chiederei un preventivo per lo sviluppo. A quel punto la software house non riceve più una richiesta vaga come: «Vorremmo utilizzare l’AI nel nostro ufficio amministrativo. Cosa ci proponete?»

Riceve un progetto. Sa cosa deve realizzare. Sa quali sistemi deve collegare. Sa quali dati può utilizzare. Sa quale risultato deve produrre. E l’azienda può finalmente confrontare fornitori diversi partendo dagli stessi requisiti.

Senza un progetto è difficile confrontare anche i preventivi

Una software house propone una piattaforma da 30.000 euro. Un’altra propone uno sviluppo da 18.000. Una terza propone un abbonamento da 1.500 euro al mese. Qual è l’offerta migliore? Guardando solo il prezzo è impossibile dirlo, perché con ogni probabilità stanno proponendo tre soluzioni diverse.

Con un progetto funzionale già definito, il confronto cambia. L’azienda può chiedere a più fornitori come realizzerebbero lo stesso risultato. Può scoprire che una parte conviene comprarla, una parte svilupparla e un’altra lasciarla sul software già presente.

Può anche decidere di dividere il lavoro tra aziende differenti. Questo riduce anche il rischio di trovarsi, dopo alcuni anni, completamente dipendenti da un unico fornitore che conosce e controlla tutta l’architettura AI dell’azienda.

Il progettista deve poter scegliere anche concorrenti tra loro

Per un progetto potrei ritenere migliore un prodotto Microsoft. Per un altro una soluzione open source. Per una parte potrei utilizzare OpenAI. Per un’altra Anthropic.

Per alcune elaborazioni potrei scegliere un modello eseguito localmente. Potrei affidare un’integrazione a una software house e un’applicazione specialistica a un’altra.

Chi progetta dovrebbe essere libero di scegliere ogni componente in base a ciò che serve all’azienda. Non in base a ciò che deve vendere.

AI Manager e software house possono lavorare benissimo insieme

Non credo che le aziende debbano scegliere tra AI Manager e software house. Nella maggior parte dei progetti servono entrambi.

L’AI Manager lavora a fianco dell’azienda per capire cosa costruire, come costruirlo e quali fornitori coinvolgere. La software house trasforma quel progetto in un sistema funzionante. E naturalmente una software house può avere al proprio interno professionisti molto capaci anche nella fase di analisi e progettazione.

Il titolo conta poco. Quello che conta davvero è capire se chi ti consiglia una soluzione sta facendo l’interesse della tua azienda oppure sta cercando di venderti quello che sa già fare. È questa la distinzione che un imprenditore dovrebbe avere chiara.

Cosa significa concretamente per una PMI o uno studio professionale?

Significa cambiare l’ordine delle operazioni. Se hai uno studio di commercialisti con dodici persone e vuoi utilizzare l’intelligenza artificiale, non partire cercando «software AI per commercialisti». Prima osserva cosa fanno quelle dodici persone durante la giornata:

Quante volte cercano documenti?
Quante informazioni copiano da un PDF?
Quante richieste dei clienti richiedono di recuperare dati già presenti nell’archivio?
Quante mail vengono scritte partendo ogni volta da informazioni che esistono già?
Dove vengono commessi gli errori?
Dove si accumula il lavoro?

Lo stesso vale per un’azienda manifatturiera. Prima di cercare «AI per ufficio commerciale», bisogna vedere cosa succede quando arriva un ordine:

Da dove arriva.
Chi lo legge.
Dove vengono copiati i dati.
Come viene verificata la disponibilità.
Quando interviene il commerciale.
Come viene comunicata la risposta al cliente.

A quel punto iniziano a emergere opportunità concrete. E solo allora possiamo decidere se quella specifica attività richiede un’automazione da 2.000 euro, un software già esistente, un progetto da 50.000 euro oppure nessuna intelligenza artificiale.

Per una PMI l’AI Manager non deve necessariamente essere un dipendente

Una grande azienda può costruire internamente un team dedicato. Per una PMI da dieci, venti o cinquanta dipendenti sarebbe spesso poco sensato assumere a tempo pieno una persona che faccia soltanto questo.

Prima di cercare software, osserva cosa succede nel lavoro: Uno studio di commercialisti; Un’azienda manifatturiera. — Prima di cercare software si osserva cosa fanno le persone durante la giornata: da lì emergono opportunità concrete.

Qui entra in gioco il modello del Fractional AI Manager. È una figura esterna che affianca l’azienda per il tempo necessario.

Analizza i processi, definisce le priorità, scrive i requisiti, valuta le soluzioni disponibili, seleziona i fornitori e segue la realizzazione. Una volta che il sistema è stato consegnato, verifica anche se il risultato corrisponde a quanto era stato progettato.

E continua a guardare cosa succede sul mercato. Perché nell’intelligenza artificiale c’è un problema ulteriore: una soluzione che dodici mesi fa richiedeva uno sviluppo personalizzato potrebbe oggi essere disponibile dentro un prodotto già esistente a poche centinaia di euro al mese.

Chi progetta sistemi AI deve sapere cosa sta cambiando

I modelli cambiano velocemente. Cambiano i prezzi. Cambiano le capacità. Nascono nuovi prodotti.

Funzioni che un anno fa richiedevano settimane di sviluppo possono diventare caratteristiche standard di un servizio esistente. Contemporaneamente cambiano norme, linee guida e interpretazioni.

Per questo trovo rischioso progettare un’infrastruttura AI come se fosse un normale software gestionale destinato a rimanere praticamente immutato per dieci anni. Serve qualcuno che continui a verificare se le decisioni prese sei mesi prima siano ancora convenienti.

Questo non significa inseguire ogni nuovo modello presentato su X. Anzi. Conoscere ciò che esce serve soprattutto a scartare rapidamente tutto quello che non cambia nulla per l’azienda e riconoscere quelle poche novità che possono far risparmiare tempo, ridurre i costi o rendere possibile qualcosa che prima non lo era.

Dal problema aziendale a un incarico verificabile

Se dovessi sintetizzare tutto in una frase, utilizzerei questa. Prima il progetto. Poi i mattoni.

La software house diventa fondamentale quando arriva il momento di costruire. Prima, però, qualcuno dovrebbe avere deciso cosa costruire, perché farlo, quali dati utilizzare, quali rischi considerare, quanto dovrebbe costare e come misurare il risultato.

Altrimenti si parte da un prodotto o da una tecnologia e si cerca successivamente un problema aziendale al quale applicarli. Ed è esattamente l’ordine che cercherei di evitare.

Un esempio completo: il preventivo che attraversa quattro uffici

Consideriamo una PMI che produce componenti su ordinazione. Un cliente invia una richiesta commerciale per posta elettronica. Il commerciale recupera lo storico dei prezzi, chiede alla produzione una verifica dei tempi, aspetta una risposta dal magazzino sulla disponibilità di un materiale e infine prepara il preventivo. Una volta inviato il documento, qualcuno ricopia parte delle informazioni nel gestionale. Questo esempio è una simulazione utile a descrivere il metodo, senza attribuire risultati a un’azienda reale.

La direzione potrebbe essere tentata da un prodotto che promette di scrivere preventivi con l’AI. Sarebbe una possibilità, ma prima conviene capire dove si perde effettivamente il tempo. Se il commerciale scrive il documento in pochi minuti e impiega due giorni ad aspettare tre approvazioni, un generatore di testo interviene sulla parte meno rilevante. Se invece il ritardo nasce dal fatto che le informazioni vengono cercate in quattro sistemi, il problema potrebbe richiedere collegamenti fra archivi e procedure di autorizzazione.

L’analisi deve ricostruire ogni passaggio: chi riceve la domanda, quali informazioni controlla, dove le trova, chi può modificarle e quando una richiesta diventa un impegno commerciale. A questo punto è possibile separare le operazioni basate su regole dalle decisioni che richiedono responsabilità. Un programma può raccogliere i dati di partenza e proporre una bozza, mentre un responsabile verifica prezzi e condizioni prima che il documento venga spedito al cliente.

Il progetto tecnico arriva dopo questa ricostruzione. Potrebbe prevedere un collegamento tra il sistema di posta e il gestionale, un archivio dei listini e un semplice flusso di approvazione. L’AI potrebbe servire soltanto a interpretare la richiesta in linguaggio naturale, soprattutto quando i clienti non usano un formato standard. In altri casi il risultato potrebbe essere ottenuto con funzioni già disponibili nei programmi acquistati. Il valore della progettazione indipendente sta anche nel riconoscere quando sviluppare una nuova applicazione non serve.

Che cosa deve contenere un buon capitolato

Dopo l’analisi dei processi conviene scrivere un capitolato, cioè un documento che permetta a più fornitori di capire il lavoro richiesto e di formulare proposte confrontabili. Non occorre che un piccolo progetto abbia centinaia di pagine. Occorre però descrivere con precisione quali attività devono essere gestite, quali dati saranno coinvolti, quali integrazioni sono autorizzate e quali operazioni richiedono l’approvazione di una persona.

Un capitolato utile include esempi concreti di input e output. Per un sistema che legge ordini, può mostrare un’email di prova e la scheda che dovrebbe essere compilata. Deve indicare cosa fare quando mancano dati o quando il documento contiene indicazioni contraddittorie. Anche i criteri di accettazione vanno definiti: quali errori sono tollerabili, come si misurano, quante prove si fanno e chi ha il potere di decidere se il progetto può entrare in esercizio.

È importante chiedere al fornitore di distinguere il costo iniziale dai costi che resteranno ogni mese: licenze, modelli AI, assistenza, server, aggiornamenti e nuove integrazioni. Un’offerta economica bassa per lo sviluppo può diventare onerosa se ogni piccola modifica richiede un intervento esclusivo dello stesso fornitore. L’azienda dovrebbe inoltre sapere chi possiederà il codice sviluppato, come potrà esportare i propri dati e che cosa accadrà se interromperà il rapporto commerciale.

L’AI Manager può aiutare a tradurre le esigenze dell’azienda in questo documento, ma anche la software house deve poter proporre miglioramenti e segnalare vincoli scoperti durante lo sviluppo. Una buona divisione dei ruoli non produce due gruppi contrapposti. Crea condizioni in cui chi progetta, chi realizza e chi usa il sistema possono correggersi a vicenda sulla base di fatti verificabili.

Come valutare le proposte senza farsi guidare soltanto dalla demo

Durante una dimostrazione commerciale tutto può sembrare semplice. Il prodotto riconosce un documento preparato appositamente, restituisce una risposta fluida e presenta un’interfaccia ordinata. L’attività reale, però, comprende allegati incompleti, file di qualità mediocre, clienti che scrivono in modi diversi e informazioni che cambiano durante la giornata. Per valutare un’offerta conviene preparare una piccola raccolta di casi rappresentativi, senza esporre dati riservati nella fase esplorativa.

A ogni fornitore chiederei di mostrare come la soluzione affronta lo stesso gruppo di situazioni. Il confronto dovrebbe riguardare precisione, facilità di correzione, gestione delle eccezioni, tempo necessario al personale e modalità con cui si interviene in caso di errore. Occorre anche esaminare quali parti siano configurazioni standard e quali richiedano sviluppo personalizzato. Questa distinzione permette di stimare come il sistema reagirà ai cambiamenti del processo.

La proposta migliore non coincide necessariamente con quella che usa il modello più recente. Se un’azienda deve classificare documenti e proporre campi da confermare, un modello meno complesso può essere sufficiente. Se deve collegare numerosi sistemi con permessi diversi, la qualità delle integrazioni può contare più della capacità di scrittura del modello. Se i documenti sono molto riservati, l’architettura e il contratto sul trattamento dei dati possono diventare criteri decisivi.

Per formulare una decisione controllabile, le valutazioni possono essere riassunte in una tabella che metta in relazione requisiti, evidenze raccolte e limiti residui. I punteggi servono soltanto se qualcuno può spiegare perché siano stati assegnati. Una casella colorata di verde senza una prova alle spalle rischia di essere poco diversa da una promessa commerciale.

Chi conserva il controllo dopo il collaudo

Quando il programma entra in funzione, il lavoro di progettazione non è davvero finito. Le persone possono cambiare abitudini, i clienti possono inviare documenti diversi e i fornitori di modelli possono modificare le proprie tecnologie. Serve un responsabile aziendale del processo, che sappia raccogliere gli errori, distinguere i problemi organizzativi da quelli tecnici e decidere se interrompere temporaneamente una funzione.

Anche il contratto di assistenza deve chiarire chi interviene e con quali tempi. Se un’automazione gestisce un’attività che blocca la spedizione delle merci, l’azienda deve conoscere la procedura manuale da utilizzare quando il sistema è indisponibile. Se la soluzione prepara documenti destinati ai clienti, qualcuno deve verificare che i controlli umani previsti non siano stati eliminati di fatto dalla fretta o dall’abitudine.

Un progetto ben disegnato conserva documentazione e competenze sufficienti a cambiare fornitore. Non significa che ogni software possa essere sostituito senza costi: significa che la direzione sa da quali componenti dipende il servizio, quali dati possiede e quali passaggi sarebbero necessari per modificarlo. Questa capacità di scelta nel tempo è parte del valore economico del progetto, anche quando non compare nella prima dimostrazione.

Un percorso proporzionato alle dimensioni della PMI

Non tutte le aziende hanno bisogno di assumere un AI Manager a tempo pieno, e non tutti i progetti richiedono una figura distinta dalla software house. Un intervento circoscritto può essere gestito da una persona interna che conosce il processo, affiancata da un fornitore competente e da consulenti per gli aspetti specifici di sicurezza e diritto. L’importante è che qualcuno rappresenti gli interessi dell’azienda nella definizione dei requisiti e possa valutare le proposte senza dover vendere una particolare soluzione.

Quando l’integrazione riguarda più reparti, diversi gestionali e dati riservati, una funzione di coordinamento dedicata diventa più utile. Può essere interna oppure affidata temporaneamente a un professionista esterno. In entrambi i casi deve rispondere a obiettivi chiari, lavorare con i responsabili di reparto e misurare risultati concreti. La relazione con chi sviluppa dovrebbe essere collaborativa e trasparente, con la possibilità di rivedere le scelte tecniche quando emergono nuove informazioni.

Per iniziare, una PMI può preparare un elenco di problemi operativi, sceglierne uno per la prima analisi e descrivere come si lavora oggi. Una volta raccolte le eccezioni e stabilito che cosa si vuole migliorare, si possono decidere i requisiti e richiedere preventivi. Procedere in questo ordine riduce il rischio di acquistare un prodotto convincente che però non risolve il problema che aveva motivato l’investimento.

Domande frequenti

Chi devo chiamare prima per introdurre l’AI in azienda, un AI Manager o una software house?

Conviene chiamare prima chi fa il progetto e poi la software house. Chi analizza il problema non dovrebbe vendere ciò che verrà costruito, perché prima va stabilito quale soluzione serve davvero. Dopo, la software house trasforma il progetto in un sistema funzionante. Nella maggior parte dei progetti servono entrambi, ciascuno con il proprio ruolo.

Che differenza c’è tra un AI Manager e una software house?

L’AI Manager lavora a fianco dell’azienda per capire cosa costruire, come costruirlo e quali fornitori coinvolgere, senza vendere uno strumento. La software house costruisce: sviluppa applicazioni, integra sistemi, crea automazioni o installa un proprio prodotto. Sono due incarichi diversi e, nella maggior parte dei progetti, si completano a vicenda.

Posso far analizzare i miei processi alla stessa software house che poi sviluppa la soluzione?

Meglio di no, perché chi vende una soluzione tende a proporre ciò che sa già fare. Una software house può lavorare soprattutto sul cloud, un’altra sui sistemi locali, un’altra ancora ha una piattaforma propria da vendere. Non c’è necessariamente malafede, ma le soluzioni proposte saranno influenzate dalle tecnologie su cui ha investito.

Come si confrontano i preventivi di più software house per un progetto di AI?

Si parte da un progetto con requisiti chiari e si chiede a più fornitori come realizzerebbero lo stesso risultato. Senza progetto il confronto è quasi impossibile: un preventivo da 30.000 euro, uno da 18.000 e un abbonamento da 1.500 euro al mese possono descrivere tre soluzioni diverse. Con i requisiti definiti si può anche dividere il lavoro tra fornitori diversi.

Una PMI deve assumere un AI Manager a tempo pieno?

Spesso no. Per una PMI da dieci, venti o cinquanta dipendenti assumere a tempo pieno una persona che faccia soltanto questo sarebbe poco sensato. L’articolo descrive il modello del Fractional AI Manager, una figura esterna che affianca l’azienda per il tempo necessario: analizza i processi, definisce le priorità, scrive i requisiti, seleziona i fornitori e segue la realizzazione.