Se il software del tuo fornitore si può replicare facilmente, quanto è al sicuro la tua azienda?
La sicurezza dipende dal controllo che hai sui programmi da cui dipende il lavoro. L’AI rende più accessibile costruire software su misura, ma bisogna conoscere i propri processi, sapere dove sono i dati e individuare i programmi che non sapresti sostituire. Se un fornitore chiude, chi ha già una mappa e dati recuperabili decide con più tempo.
Roberto GhilardiniAggiornato il 33 minuti di lettura
Cosa trovi in questo articolo
- Perché costruire software su misura diventa accessibile alle aziende
- Cosa significa che il software diventa una commodity
- Come riconoscere i software che non sapresti sostituire
- Cosa può succedere se il fornitore chiude
- Come mappare processi, dipendenze e priorità
- Cosa fare nei prossimi novanta giorni e come provare l’esportazione dei dati
Nei primi giorni di ottobre ho letto una notizia che mi ha fatto pensare a quanto dipendiamo dai software che utilizziamo in azienda.
Un progetto chiamato ArtCraft ha presentato alternative open source a programmi molto diffusi, da Photoshop a Word, Excel e AutoCAD, sviluppate con l’aiuto dell’intelligenza artificiale. Fra queste c’è PhotoCraft, un programma che riprende funzioni e modalità di lavoro di Photoshop. Il codice è disponibile pubblicamente: chiunque può consultarlo e utilizzarlo secondo le condizioni della sua licenza.
Le applicazioni sono presentate nella pagina del progetto ArtCraft su GitHub, il sito sul quale vengono pubblicati e gestiti moltissimi progetti software. Si può andare direttamente anche alla pagina del progetto PhotoCraft.
Ho esaminato la documentazione pubblicata: PhotoCraft è ancora in fase alpha, cioè in una fase iniziale di sviluppo, e gli autori dichiarano che non sostituisce ancora Photoshop nel lavoro professionale quotidiano. Guardando quello che stanno costruendo, mi aspetto conseguenze anche per i programmi utilizzati ogni giorno nelle aziende.
Ritengo probabile che strumenti di sviluppo sempre più accessibili permetteranno anche alle imprese di dimensioni contenute di costruire una parte dei software di cui hanno bisogno. Non significa che qualunque azienda potrà realizzare e mantenere da sola un gestionale completo: resteranno necessari competenze, controlli e risorse.
Gli strumenti continueranno a maturare. Le imprese potranno costruire applicazioni intorno ai propri processi, invece di dover scegliere sempre un prodotto progettato per migliaia di organizzazioni diverse. Per questo inizierei a prepararmi adesso.
Per capire perché, lasciamo per un momento Photoshop e pensiamo al programma che apri ogni mattina per lavorare. Quello con cui gestisci i clienti, controlli gli ordini, organizzi il magazzino o segui la contabilità. Quanto del funzionamento della tua azienda dipende da quel programma? E quanto controllo hai davvero sul suo futuro?
Costruire un software su misura diventa accessibile alle aziende
Per molti anni un’azienda che aveva bisogno di un programma si trovava davanti a una scelta abbastanza obbligata. Poteva acquistare un prodotto già esistente oppure pagare qualcuno per svilupparne uno su misura.
La seconda strada richiedeva risorse che molte piccole e medie imprese non erano disposte a investire. Bisognava spiegare il lavoro agli sviluppatori, progettare il sistema, realizzarlo, correggerlo e mantenerlo. Per ogni modifica bisognava tornare dallo sviluppatore, concordare il prezzo e aspettare che trovasse il tempo di realizzarla.
Così l’azienda comprava quello che trovava sul mercato. L’organizzazione finiva così per adattare parte delle proprie procedure ai limiti e alle funzioni del prodotto acquistato.
Chiunque abbia vissuto questa situazione conosce il seguito. Il programma copre buona parte delle esigenze, mentre tutto ciò che rimane fuori viene gestito con fogli Excel, email, messaggi e telefonate. Nel tempo quelle soluzioni provvisorie diventano indispensabili. Una parte del lavoro rimane fuori dal programma, affidata a procedure che conoscono soltanto le persone che le svolgono.
L’intelligenza artificiale sta intervenendo proprio sul costo e sulla difficoltà di trasformare un’esigenza in un’applicazione. Un agente AI è un sistema che può svolgere una sequenza di attività: leggere istruzioni, lavorare sul codice, eseguire verifiche e modificare ciò che ha costruito. Affidargli compiti di sviluppo rende accessibili possibilità che prima richiedevano molto più lavoro specialistico.
Un’impresa potrà partire da una descrizione precisa di come lavora e usarla per costruire gli strumenti che le servono. Il lavoro tecnico verrà organizzato diversamente, con una parte crescente affidata a questi sistemi.
L’azienda potrà decidere che cosa deve fare il programma e seguirne la realizzazione, coinvolgendo le competenze necessarie e mantenendo il controllo sul risultato.
Che cosa intendo quando dico che il software diventa una commodity
La parola commodity può sembrare lontana dalla vita di un ufficio. In questo contesto indica una cosa semplice: qualcosa che prima era difficile e costoso da ottenere diventa più accessibile, riproducibile e sostituibile.
Il prezzo di molti software incorpora anche la difficoltà di costruire un’alternativa. Se per ricreare determinate funzioni servono anni di lavoro e una squadra di programmatori, chi vende quelle funzioni dispone di una barriera importante. Il cliente può lamentarsi del prezzo o dei limiti, ma le sue possibilità di scelta rimangono ristrette.
Quando il lavoro necessario diminuisce, quella barriera si abbassa. L’azienda utilizzatrice può cominciare a confrontare il costo della licenza con il costo di avere uno strumento proprio, progettato esattamente per ciò che le serve.
È in questo senso che considero il software avviato verso una progressiva trasformazione in commodity. La possibilità di produrre le funzioni diventa più diffusa e il semplice possesso del codice perde parte della sua forza commerciale.
Per chi lo utilizza, il programma continua ad avere un’utilità enorme. Un sistema che organizza bene gli ordini serve ogni giorno, anche quando diventa più economico costruirlo. A cambiare è il rapporto fra quell’utilità e il prezzo che siamo disposti a pagare per ottenerla da un fornitore esterno.
Posso attribuire moltissimo valore a uno strumento indispensabile per la mia azienda e, nello stesso tempo, scegliere di realizzarlo invece di continuare ad acquistare il diritto di utilizzarlo.
L’opportunità per l’imprenditore è avere una nuova possibilità di scelta. Il rischio per chi vende software è continuare a valutare il proprio prodotto come se il cliente non potesse mai costruirsi un’alternativa.
Dal reverse engineering al software fatto per la tua azienda
Insieme ai progetti di nuove applicazioni stanno emergendo strumenti che aiutano l’AI a comprendere quelle esistenti. Uno di questi è REA, Reverse Engineer Anything.
Il reverse engineering consiste nello studiare un sistema per capire come funziona. REA collega gli agenti AI a strumenti di analisi e li aiuta a ricostruire il comportamento di componenti e applicazioni. È un progetto distinto da PhotoCraft. Lo cito perché mostra come l’AI possa aiutare anche a comprendere il funzionamento di un programma esistente.
Per un imprenditore questo significa avere più strumenti per trasformare un’esigenza conosciuta in un programma funzionante.
Immaginiamo un’azienda che utilizza un programma molto ampio, del quale sfrutta soltanto alcune procedure. Gestisce le offerte, registra gli ordini, controlla le consegne e produce un riepilogo per l’amministrazione. Tutto il resto del prodotto rimane quasi inutilizzato.
L’azienda conosce già il risultato che le serve. I dipendenti sanno quali passaggi funzionano, quali sono scomodi e quali richiedono un foglio esterno. Questo patrimonio di esperienza diventa la base per progettare un programma proprio.
Si può partire dai requisiti del lavoro, dalle regole aziendali e dai dati disponibili. L’analisi del sistema esistente aiuta a capire che cosa mantenere e che cosa migliorare. L’obiettivo è ottenere un’applicazione adatta all’impresa, costruita nel rispetto dei diritti e delle licenze dei componenti utilizzati.
L’azienda potrà concentrarsi sulle funzioni che utilizza e aggiungere quelle che ha sempre dovuto gestire a parte, perché il prodotto acquistato non le prevedeva.
Immagina il tuo ufficio commerciale fra qualche tempo
Prendiamo un esempio ipotetico, vicino a tante realtà italiane. Un’azienda vende prodotti in Italia e all’estero. I commerciali ricevono richieste via email e WhatsApp. I listini cambiano in base al cliente, alle quantità e alle condizioni concordate. Per preparare un’offerta bisogna controllare disponibilità, trasporto e tempi di consegna.
Oggi il lavoro passa attraverso diversi strumenti. Il CRM, cioè il programma che tiene traccia dei clienti e delle trattative, contiene i contatti. Il gestionale contiene ordini e disponibilità. Le condizioni particolari sono in un file. Alcune informazioni si recuperano chiedendo alla persona che segue quel cliente da anni.
L’impiegato apre una richiesta e comincia a ricostruire il contesto. Cerca la precedente offerta, controlla il prezzo, telefona in magazzino, recupera la scheda tecnica e prepara la risposta. Quando il cliente conferma, una parte delle informazioni viene inserita di nuovo.
Ora immaginiamo di costruire un’applicazione intorno a questo lavoro. La richiesta viene associata al cliente. Il sistema recupera condizioni e documenti, consulta le disponibilità, prepara una proposta e la presenta alla persona incaricata di approvarla. Dopo la conferma, le informazioni già raccolte vengono utilizzate per le attività successive.
Ogni passaggio segue le regole di quell’impresa. Le eccezioni vengono definite da chi le affronta tutti i giorni. Se cambia una procedura, si interviene sul proprio sistema.
Con un sistema del genere, l’azienda potrà modificare il proprio modo di lavorare senza aspettare che il produttore accolga una richiesta magari interessante soltanto per pochi clienti.
Il software più importante è spesso quello che non sapresti sostituire
Per arrivarci bisogna fare i conti con i programmi che utilizziamo già. Oggi molte imprese vi hanno accumulato anni di dati e di lavoro, tanto da avere difficoltà anche solo a immaginare di sostituirli.
Il rapporto comincia con una scelta commerciale. Si valuta una dimostrazione, si firma un contratto, si importano i dati e si formano le persone. Poi passano gli anni.
Nel programma finiscono lo storico dei clienti, gli ordini, i documenti, le regole di prezzo, le scadenze e le abitudini operative. Vengono aggiunti collegamenti con altri sistemi. Nascono personalizzazioni che risolvono problemi specifici. I nuovi dipendenti imparano a lavorare dentro quell’ambiente.
A un certo punto, cambiare software significa intervenire sul funzionamento dell’azienda. Serve capire che cosa trasferire, come ricostruire i collegamenti e come continuare a lavorare durante il passaggio.
Questa dipendenza non coincide con l’importo del canone. Un piccolo programma che prepara i documenti necessari alle spedizioni può essere decisivo quanto un sistema molto più costoso. Se smette di funzionare, la merce rimane ferma.
Per capire quanto un software sia strategico, chiederei alle persone che lo usano quali attività si fermerebbero se domani non fosse disponibile.
Se la risposta coinvolge incassi, consegne, contabilità, produzione o relazioni con i clienti, quel sistema merita attenzione. La sua continuità riguarda direttamente l’imprenditore, anche quando il contratto viene seguito dall’amministrazione e l’assistenza viene chiamata dall’ufficio informatico.
Quando i clienti cominceranno a costruire i propri strumenti
La trasformazione che prevedo riguarda anche il modo in cui si sostiene economicamente chi vende software.
Un produttore organizza persone, assistenza e sviluppo contando sui ricavi delle licenze e degli abbonamenti. Quei ricavi finanziano il lavoro necessario a mantenere il prodotto e a farlo evolvere. Il modello regge finché un numero sufficiente di clienti continua a pagare.
Se una quota crescente di aziende sceglie di costruire gli strumenti di cui ha bisogno, il produttore perde una parte della domanda. Una funzione per la quale ieri era necessario acquistare una licenza entra nel sistema realizzato direttamente dal cliente.
Il cambiamento può cominciare dalle applicazioni più semplici e raggiungere progressivamente attività più importanti. L’impresa fa esperienza, comprende il processo e amplia il controllo sui propri strumenti. Per chi vive della vendita di quei prodotti, significa dover affrontare una pressione sul proprio modello economico.
Consideriamo adesso il caso di un fornitore che perda ricavi e riduca gli investimenti. I tempi di assistenza si allungano. Gli aggiornamenti diventano meno frequenti. Alcuni moduli vengono abbandonati. Nei casi più gravi, l’azienda interrompe l’attività.
Da cliente, mi chiederei quali conseguenze avrebbe una difficoltà del fornitore sul mio lavoro e quanto tempo mi servirebbe per trovare una soluzione.
Chi riesce a preparare un’alternativa dispone di tempo e potere contrattuale. Chi scopre la dipendenza quando il servizio si interrompe deve affrontare una migrazione in emergenza, proprio mentre l’organizzazione ha meno spazio per gestirla.
Il problema arriva in amministrazione, in magazzino e sulle scrivanie
Immaginiamo che l’azienda dell’esempio riceva una comunicazione: il gestionale utilizzato verrà dismesso. La scadenza del servizio impone di trovare una soluzione e trasferire anni di informazioni.
L’amministrazione chiede dove siano le fatture e come si recuperino gli allegati. I commerciali vogliono mantenere lo storico delle offerte. Il magazzino deve continuare a conoscere disponibilità e impegni. Nel frattempo arrivano nuovi ordini e i clienti si aspettano risposte.
Il danno comprende il tempo sottratto al lavoro, le informazioni da ricostruire, le verifiche manuali e le decisioni affrettate. Anche quando tutti i dati sono recuperabili, il trasferimento richiede un’organizzazione.
Se il programma viene utilizzato attraverso il sito del fornitore, la cessazione del servizio può togliere l’accesso all’applicazione. Se è installato sui computer aziendali, la copia può continuare a funzionare, mentre vengono meno manutenzione, compatibilità e aggiornamenti. In entrambi i casi bisogna organizzarsi per continuare a lavorare.
Pensiamo alla contabilità. Il valore del programma comprende il suo aggiornamento nel tempo e la corretta gestione delle attività richieste. Un sistema lasciato senza manutenzione diventa progressivamente più difficile da utilizzare con fiducia, anche se continua ad aprirsi.
Per capire che cosa verificare, partirei da come viene utilizzato ciascun programma. Le conseguenze della chiusura di un fornitore cambiano a seconda di dove si trova il software e dei servizi ai quali è collegato.
La stessa azienda può trovarsi in più righe di questa tabella. Il gestionale può essere locale, il CRM online e il programma per preparare le spedizioni sviluppato su misura. Ciascuno richiede una verifica propria.
Per questo considero la mappatura dei software strategici parte integrante di un progetto AI. Mentre progetta le automazioni, l’impresa deve sapere quali attività dipendono da ciascun fornitore e come potrebbe continuare a svolgerle senza di lui.
Prima di automatizzare, bisogna capire come lavora davvero l’azienda
Quando un imprenditore pensa all’AI, spesso immagina subito il risultato: meno inserimenti manuali, risposte più rapide, documenti preparati automaticamente. Per arrivarci occorre ricostruire il percorso che produce quel risultato.
Torniamo all’ordine ricevuto dall’ufficio commerciale. Chi lo apre? Come riconosce il cliente? Dove trova il prezzo corretto? Che cosa fa quando manca un codice? Chi autorizza uno sconto? In quale momento l’informazione diventa un ordine confermato?
Le risposte descrivono il processo reale. Ed è frequente che siano distribuite fra più persone. L’imprenditore conosce l’obiettivo, il responsabile conosce la procedura e chi svolge il lavoro conosce gli ostacoli quotidiani.
Per questo l’analisi deve coinvolgere i dipendenti. Una persona che ripete la stessa attività da anni sa indicare subito le operazioni inutili, i dati che arrivano sempre incompleti e i passaggi che richiedono un controllo. Queste informazioni permettono di progettare un’applicazione che corrisponda al lavoro effettivo.
Durante i colloqui chiederei di mostrarmi come portano a termine un’attività, aprendo i programmi e i documenti che usano normalmente. È più facile capire ciò che serve osservando il lavoro, comprese le interruzioni e i passaggi fuori procedura.
Nella mappa dei processi queste informazioni diventano una descrizione che tutti possono consultare: quali dati arrivano, chi li utilizza, quali operazioni svolge e che cosa deve ottenere. Il tempo impiegato, la frequenza e gli errori aiutano poi a scegliere le priorità.
Con questa base l’AI riceve istruzioni molto più precise. L’azienda conserva inoltre una descrizione del proprio funzionamento che può usare con qualsiasi tecnico o strumento scelga in futuro.
Accanto alla mappa del lavoro serve la mappa delle dipendenze
Mentre si ricostruisce un processo, bisogna seguire anche il percorso dei dati. Ogni passaggio avviene dentro un programma, un archivio o un servizio. Sapere dove si trovano le informazioni consente di capire quanto controllo abbiamo su di esse.
Nell’azienda dell’esempio, l’anagrafica del cliente potrebbe essere nel CRM, i prezzi nel gestionale, i contratti in una cartella e le conferme in una casella email. Per costruire un sistema proprio occorre riconoscere queste fonti e stabilire quale faccia fede quando due informazioni sono diverse.
La mappa dei software deve quindi collegare ogni programma al lavoro che sostiene. Per ciascuno servono un responsabile interno, una descrizione dei dati contenuti e un elenco dei collegamenti con altri strumenti.
Per raccogliere queste informazioni, partirei da alcune domande. Chi ha gli accessi amministrativi? Dove sono i contratti? Possiamo esportare le informazioni? In quale formato? Sono comprese le note, gli allegati e lo storico? Qualcuno ha già provato a utilizzare quei dati fuori dal programma originale?
Il pulsante “esporta” va provato, controllando che cosa contiene il file scaricato. Un elenco di nomi non restituisce un rapporto commerciale fatto di offerte, trattative, condizioni e documenti collegati.
La stessa attenzione va dedicata alle personalizzazioni. Se il gestionale calcola una condizione in un modo particolare, bisogna conoscere la regola. Altrimenti il giorno della sostituzione ci si ritrova a ricostruirla osservando vecchi risultati e chiedendo alle persone di ricordare decisioni prese anni prima.
Per tenere insieme le risposte userei una scheda per ogni software. La compilerei con chi lo utilizza e con chi ne segue la gestione tecnica.
Le risposte mancanti indicano dove approfondire. Se nessuno sa come recuperare gli allegati o chi possiede l’accesso amministrativo, c’è già un’attività da assegnare prima di parlare di sviluppo.
Raccogliendo queste informazioni si evita di doverle ricostruire durante lo sviluppo o, peggio, quando il vecchio programma sta per essere dismesso.
Il primo software aziendale può nascere dove oggi c’è un foglio Excel
Con le schede davanti, separerei le urgenze dai progetti che possiamo affrontare con più tempo. Per ogni programma guarderei quanto pesa un suo fermo e quanto sarebbe difficile sostituirlo.
Un programma per le spedizioni dal quale dipendono tutte le consegne viene prima di uno strumento usato saltuariamente per un report. Il costo della licenza, da solo, non basta a stabilire la priorità.
Per il primo sviluppo cercherei poi un’attività ben delimitata, frequente e abbastanza importante da produrre un beneficio visibile. Nel frattempo, sui sistemi più critici vanno avviate le verifiche di continuità indicate nella tabella.
Nell’ufficio commerciale potrebbe essere la preparazione delle offerte. In uno studio professionale, la raccolta dei documenti e la gestione delle richieste ai clienti. In un’azienda produttiva, il controllo dell’avanzamento di una lavorazione oggi aggiornato manualmente.
I fogli Excel creati dai dipendenti sono particolarmente interessanti. Spesso contengono la risposta a un’esigenza che i programmi ufficiali non soddisfano. Le colonne indicano quali dati servono. Le formule mostrano alcuni calcoli. I colori e le annotazioni raccontano priorità ed eccezioni.
Quel foglio è una prima descrizione del software di cui l’azienda ha bisogno. Analizzandolo insieme a chi lo usa, si può trasformare una soluzione personale in uno strumento condiviso, con accessi definiti, controlli e collegamenti alle altre informazioni.
Si costruisce una prima versione, la si utilizza su casi reali e si verifica il risultato. Le persone che conoscono l’attività controllano che il sistema restituisca le risposte corrette. Gli errori vengono corretti prima di estendere l’utilizzo.
In questo modo l’impresa comincia ad acquisire autonomia attraverso un progetto gestibile. Impara a descrivere un’esigenza, a valutarne la realizzazione e a mantenere uno strumento proprio. L’esperienza diventa il metodo con cui affrontare il progetto successivo.
Procedendo in questo modo, l’azienda potrà affidare una parte crescente del lavoro ad applicazioni costruite sulle proprie necessità.
Dal primo strumento al controllo di CRM, contabilità ed ERP
Questi progetti devono essere coordinati fra loro. Se ogni reparto costruisce qualcosa per conto proprio, si rischia di moltiplicare gli archivi e rendere più difficile il lavoro degli altri.
Serve quindi una regia che stabilisca dove stanno i dati, come vengono aggiornati e quali regole devono essere comuni. Il cliente registrato dal commerciale deve essere riconoscibile anche dall’amministrazione. Un ordine confermato deve produrre le conseguenze corrette sul magazzino.
Qui entra in gioco l’ERP, sigla che indica il sistema con cui un’impresa coordina attività come acquisti, vendite, magazzino e produzione. La sua importanza dipende proprio dai collegamenti fra questi ambiti.
Per prendere il controllo di un sistema così centrale bisogna procedere conoscendone le relazioni. Si identifica una funzione, si costruisce la soluzione aziendale, si verifica lo scambio dei dati e si trasferisce il lavoro quando il risultato è stato controllato. Le funzioni successive vengono affrontate con lo stesso metodo.
Nella contabilità, la progettazione deve includere chi conosce gli adempimenti e le regole del lavoro amministrativo. Nel commerciale deve coinvolgere chi gestisce clienti e condizioni. In produzione deve ascoltare chi organizza tempi, materiali ed eccezioni.
L’AI rende più accessibile la realizzazione tecnica; la conoscenza dell’azienda permette di darle una direzione. Con procedure e regole ben documentate sarà più semplice affrontare anche gli altri programmi utilizzati dall’azienda.
Per questo prepararsi adesso ha valore anche per chi affronterà la sostituzione dei sistemi principali più avanti. La mappa, i dati e le regole sono il lavoro preliminare che rende possibile quella decisione.
Avere un software proprio significa poter decidere chi lo mantiene
Quando parlo di software proprietario, mi riferisco al controllo necessario per utilizzarlo, modificarlo e affidarne la gestione a chi l’azienda sceglie. Questo controllo deve essere previsto nel progetto e negli accordi con chi partecipa alla realizzazione.
L’impresa deve disporre del codice, delle configurazioni, degli accessi e delle istruzioni che consentono di far funzionare il sistema. Deve sapere quali componenti esterni utilizza e quali diritti accompagnano il loro impiego. Chi subentra deve poter capire come è organizzato il programma e come vengono gestiti i dati.
Immaginiamo che il tecnico che ha seguito il progetto cambi lavoro. L’azienda dovrebbe poter incaricare un’altra persona, consegnarle il materiale e continuare la manutenzione senza ricominciare da zero.
Lo verificherei già durante il progetto: un secondo tecnico prepara un ambiente nuovo, installa il software, recupera una copia dei dati ed esegue un’attività concordata.
La prova rende visibili eventuali informazioni mancanti. Se serve una password conosciuta soltanto dal primo sviluppatore, viene recuperata e gestita correttamente. Se un passaggio dipende da un’impostazione mai documentata, quella conoscenza viene consegnata all’azienda.
A quel punto l’azienda può scegliere chi incaricare della manutenzione in base al servizio offerto. L’impresa mantiene la possibilità di cambiarlo conservando il proprio sistema e la propria storia operativa.
È una posizione molto diversa da quella di chi può soltanto rinnovare il contratto perché non sa come uscire dal prodotto che utilizza.
Comprare software oggi significa anche progettare come uscirne
Durante questa trasformazione le aziende continueranno ad avere necessità immediate. Un ufficio deve lavorare oggi, i documenti devono essere gestiti e gli ordini devono essere evasi. Ogni nuovo acquisto dovrebbe quindi essere valutato anche rispetto al percorso di autonomia che si vuole costruire.
Prima di firmare, chiederei come si recuperano i dati completi, quali collegamenti sono disponibili, come vengono consegnate le personalizzazioni e che cosa succede alla fine del rapporto. Sono domande da porre quando si sta scegliendo, nel momento in cui l’azienda ha maggiore libertà negoziale.
Valuterei anche l’ampiezza dell’impegno. Un contratto lungo, accompagnato da molte personalizzazioni difficili da trasferire, può condizionare per anni le scelte successive. Nel costo dell’acquisto considererei anche quanto sarà impegnativo cambiare programma in futuro.
Nel confronto economico inserirei il lavoro che il sistema richiede alle persone: dati da ricopiare, controlli manuali, passaggi esterni e richieste di assistenza. Sono costi sostenuti dall’azienda anche quando non compaiono nella fattura del software.
Dall’altra parte, il progetto di una soluzione propria deve comprendere sviluppo, verifiche, trasferimento dei dati e manutenzione. Mettere queste voci nello stesso ragionamento permette di scegliere quali parti conviene continuare ad acquistare durante il passaggio e quali iniziare a costruire.
Prima di scegliere vorrei sapere quanto mi costa svolgere quell’attività nel suo complesso e quali possibilità avrò di cambiare soluzione. Due canoni simili possono accompagnare condizioni molto diverse.
Perché l’hardware acquista un peso sempre maggiore
Rendere più accessibile la costruzione del software porta l’attenzione anche sulle macchine necessarie a far lavorare l’intelligenza artificiale.
Scrivere un’applicazione ed eseguire un modello AI sono attività diverse. Il programma organizza il lavoro; il modello viene chiamato, per esempio, per interpretare un documento, comprendere una richiesta o preparare un testo. Ogni volta che svolge quell’attività utilizza capacità di calcolo.
Nella mia lettura, una parte crescente del peso economico si sposterà verso questa capacità: macchine, memoria, disponibilità del servizio ed energia. Il software può essere copiato e adattato; la potenza necessaria per elaborare molte richieste deve essere disponibile nel momento in cui il lavoro arriva.
Nel progetto del software aziendale bisogna quindi prevedere anche le macchine e i servizi che lo faranno funzionare. Possedere il proprio programma consente di governarne le funzioni. Bisogna poi decidere dove eseguire le operazioni AI e come sostenerne il costo nel tempo.
Un sistema aziendale può usare un modello eseguito su macchine interne oppure collegarsi a un servizio esterno. Può anche distribuire attività diverse fra le due soluzioni. Questa scelta va fatta in base al lavoro richiesto e alle caratteristiche dei dati trattati.
La progettazione dovrebbe conservare la possibilità di cambiare il modello o il servizio utilizzato senza dover riscrivere tutta l’applicazione. L’azienda potrà così sfruttare gli strumenti che matureranno nei prossimi mesi mantenendo il controllo sul processo costruito.
Se esce un modello più adatto o cambia il prezzo del servizio, l’azienda potrà sostituire quel componente conservando le procedure e i collegamenti già costruiti.
Far girare l’AI in ufficio richiede un progetto, soprattutto quando il lavoro cresce
Sui social si vede spesso un computer che esegue un modello e si conclude che l’AI può essere portata dentro qualsiasi azienda con estrema facilità. Per chi deve organizzare un servizio utilizzato ogni giorno, la valutazione parte dal carico reale.
Immaginiamo più persone che, nello stesso momento, chiedono al sistema di leggere documenti, recuperare informazioni e preparare risposte. La macchina deve gestire quelle richieste in tempi accettabili. Se l’attività è strategica, bisogna anche sapere che cosa succede quando si guasta o deve essere fermata per manutenzione.
Contano quindi le dimensioni del modello, la lunghezza dei documenti, il numero delle richieste contemporanee e la rapidità necessaria. La documentazione tecnica di vLLM, un sistema usato per erogare modelli AI, distingue proprio fra le risorse necessarie a ospitare un modello e quelle richieste per sostenere il volume di lavoro.
In un’impresa strutturata, un utilizzo intenso può richiedere un investimento importante in hardware e gestione. Le dimensioni aziendali indicano il contesto; sono le prove sul lavoro effettivo a stabilire di quale infrastruttura ci sia bisogno.
Per questo partirei da un campione rappresentativo: documenti reali, richieste realistiche e più utenti contemporanei. Misurerei tempi, correttezza delle risposte e costo del servizio, includendo le persone necessarie per gestirlo.
Con queste misure l’imprenditore può valutare l’investimento e sapere quando sarà necessario aumentare la capacità delle macchine o del servizio acquistato.
Che cosa fare nei prossimi novanta giorni
Per cominciare questo percorso propongo di dedicare i primi trenta giorni alla conoscenza della situazione. Si incontrano le persone, si osservano le attività ripetitive e si raccolgono i programmi utilizzati. Si segue il percorso di un ordine, di una pratica o di un documento, dall’arrivo alla conclusione.
Alla fine di questa fase l’azienda dovrebbe sapere quali sistemi sono strategici, dove si trovano i dati e quali attività assorbono lavoro manuale. Dovrebbe inoltre avere un responsabile per ciascun ambito, capace di partecipare alle decisioni successive.
Nel secondo mese si sceglie il primo processo sul quale intervenire. Si descrivono i risultati attesi e si prepara una prova circoscritta. Nell’azienda dell’esempio potremmo iniziare dalla raccolta delle informazioni necessarie a un preventivo, mantenendo l’approvazione in mano al commerciale.
La prova deve mostrare come lavora il nuovo strumento e quali informazioni utilizza. Le persone coinvolte confrontano il risultato con quello atteso, segnalano le eccezioni e aiutano a migliorare il sistema. Contemporaneamente si verifica che i dati siano recuperabili e che il collegamento con gli altri programmi sia documentato.
Nel terzo mese si consolida ciò che funziona. Si consegnano codice, accessi e istruzioni, si organizza la manutenzione e si prova il recupero del sistema. Si decide poi il passaggio successivo sulla base dell’esperienza acquisita.
Al termine dei novanta giorni l’azienda avrà provato il metodo su un’attività e potrà valutarne il risultato. Il percorso verso i sistemi più complessi continuerà con priorità definite, invece di dipendere dall’urgenza del momento.
Il patrimonio da costruire comincia dalla conoscenza del tuo lavoro
Per costruire un programma adatto alla propria azienda bisogna saper spiegare come si lavora e che cosa si vuole migliorare. Più diventa semplice svilupparlo, più pesa la qualità di queste indicazioni.
Le regole commerciali, le eccezioni, le informazioni sui clienti e l’esperienza dei dipendenti diventano materiale di progetto. Se rimangono sparse fra email, fogli e memoria personale, l’impresa deve ricostruirle ogni volta. Se vengono raccolte e organizzate, possono guidare lo sviluppo di strumenti nuovi.
Per un dipendente significa poter contribuire direttamente al miglioramento del proprio lavoro. Chi conosce una procedura può aiutare a definirne l’automazione, verificarne il risultato e riconoscere i casi che richiedono attenzione. La sua esperienza entra nella costruzione del sistema.
Per un professionista significa progettare strumenti coerenti con il modo in cui segue i clienti, organizza le pratiche e controlla le scadenze. Per l’imprenditore significa mantenere dentro l’organizzazione la conoscenza necessaria a scegliere e cambiare tecnologia.
Questo patrimonio rimane utile anche quando cambiano i modelli AI, i tecnici incaricati o le macchine utilizzate. L’azienda conserva la descrizione dei propri processi, i dati e le regole con cui produce risultati.
Queste informazioni serviranno a costruire il software aziendale. Conviene raccoglierle mentre si lavora con tranquillità, avendo il tempo di confrontarsi con le persone e verificare i dettagli.
Da dove inizierei nella tua azienda
La direzione che vedo è quella di aziende sempre più capaci di costruire i propri software, farli evolvere e adattarli al lavoro. I progetti citati all’inizio sono il motivo per cui comincerei a occuparmene già adesso.
Nel percorso che prevedo, il codice diventerà più accessibile e il vantaggio si sposterà verso chi conosce bene i propri processi, controlla i dati e sa organizzare la tecnologia intorno alle proprie esigenze. Una parte delle licenze acquistate oggi lascerà spazio a strumenti realizzati direttamente per l’azienda.
Nella tua azienda partirei dal lavoro quotidiano. Occorre identificare le attività ripetitive, ascoltare le persone che le svolgono, ricostruire i collegamenti fra i sistemi e capire quali software tengono in piedi l’organizzazione. Poi si costruiscono, una alla volta, le condizioni per governarli in autonomia.
È per questo che ritengo incompleto un progetto AI che si occupi soltanto di automatizzare qualche operazione. L’impresa deve uscire dal progetto con una maggiore capacità di decidere sul proprio funzionamento e sul proprio futuro tecnologico.
Immagina di ricevere, fra qualche tempo, la comunicazione con cui un fornitore annuncia la fine del supporto al prodotto che utilizzi. Puoi trovarti a cercare in fretta informazioni, persone e alternative. Oppure puoi avere già una mappa dei processi, dati recuperabili e una parte del tuo sistema sotto controllo diretto.
Avere già fatto questo lavoro ti permette di decidere con più tempo a disposizione, senza dover ricostruire tutto mentre cerchi di tenere aperto l’ufficio.
Comincerei chiedendo ai responsabili quali programmi tengono in piedi il loro lavoro, quali informazioni contengono e come le recupererebbero. Dalle risposte saprai quali dipendenze affrontare per prime e dove iniziare a costruire il software della tua azienda.
Un piano di continuità per i software che non puoi permetterti di perdere
Prima di decidere se sostituire un programma, vale la pena preparare un esercizio semplice. Scegli il software che un reparto considera indispensabile e immagina che domani non sia disponibile per un’intera giornata lavorativa. Quali attività si fermerebbero? Quali informazioni sarebbero ancora accessibili? Chi sarebbe in grado di contattare il fornitore e chi saprebbe coordinare il lavoro provvisorio?
Le risposte aiutano a distinguere il disagio operativo da una vera dipendenza critica. Un programma per organizzare le ferie può creare un problema relativamente gestibile se non funziona per qualche ora. Un sistema che governa ordini, spedizioni o dati indispensabili per gli adempimenti può fermare l’attività di più reparti. La gravità dipende anche dalla disponibilità delle informazioni e dalla possibilità di continuare con procedure temporanee.
Per ogni applicazione importante conviene documentare il responsabile interno, i contratti di assistenza, le procedure di esportazione dei dati, le integrazioni con altri strumenti e il percorso per ripristinare il servizio dopo un guasto. Il documento deve essere abbastanza semplice da essere compreso anche da chi non ha partecipato alla scelta del software. Altrimenti il giorno dell’emergenza si scoprirà che tutte le informazioni essenziali erano nella testa di una sola persona.
La prova di esportazione: un controllo da fare davvero
Molte aziende sanno di poter esportare i propri dati perché il contratto lo prevede o perché nel menu del programma compare una funzione dedicata. Questo però non dimostra che i dati siano immediatamente riutilizzabili in un altro ambiente. Un’esportazione potrebbe contenere codici senza descrizioni, collegamenti che perdono significato fuori dal programma o allegati che richiedono una procedura separata.
Una verifica utile consiste nel scegliere un piccolo insieme di informazioni, esportarlo e controllare che una persona diversa da quella che ha eseguito l’operazione riesca a interpretarlo. Per un gestionale commerciale, per esempio, si possono utilizzare dati di prova relativi a clienti, offerte, ordini e righe di prodotto. Bisogna verificare che le relazioni fra questi elementi restino ricostruibili. Per un archivio documentale occorre controllare anche nomi, versioni, permessi e metadati.
La prova non richiede di migrare davvero l’azienda, ma permette di scoprire in anticipo problemi che durante un cambio di fornitore diventerebbero costosi. Se non si dispone dei permessi necessari per esportare o se i dati non possono essere compresi senza strumenti proprietari, è importante chiarire subito con il fornitore quali alternative siano previste.
Che cosa chiedere a chi propone di ricostruire un software con l’AI
Quando uno sviluppatore afferma di poter realizzare rapidamente un’alternativa a un prodotto esistente, chiederei di vedere un elenco delle funzioni effettivamente coperte e delle eccezioni ancora da gestire. La velocità di creazione di una schermata non è una misura sufficiente. Serve capire come vengono protetti i dati, come funzionano i permessi, quali prove sono state svolte e chi seguirà aggiornamenti e incidenti.
Un prototipo può essere una buona occasione per chiarire i requisiti. Per esempio, può mostrare un flusso di inserimento ordini più semplice di quello attuale o un nuovo modo di trovare documenti. Il passaggio a un uso quotidiano richiede però test su volumi realistici, procedure di backup, controlli sugli accessi e un piano di manutenzione. Anche il rispetto delle licenze e dei diritti sui componenti utilizzati deve essere verificato prima di distribuire il prodotto.
È utile chiedere chi possederà il codice realizzato, dove sarà conservata la documentazione e come un secondo fornitore potrebbe intervenire in caso di necessità. Un programma costruito su misura può ridurre una dipendenza e crearne un’altra, se soltanto chi lo ha sviluppato sa come mantenerlo. Per questo la sostituibilità del fornitore va considerata fin dal progetto.
Il momento di confrontare davvero acquisto e sviluppo
Per decidere se continuare a pagare una licenza o realizzare una soluzione propria non basta confrontare il canone annuale con il costo iniziale dello sviluppo. Bisogna includere le operazioni che oggi il fornitore svolge per l’azienda: aggiornamenti, sicurezza, correzione dei difetti, assistenza, adeguamenti a nuove regole e mantenimento delle integrazioni. Quando si sviluppa internamente, queste responsabilità non scompaiono.
Conviene stimare anche il costo delle interruzioni, della formazione delle persone e del periodo in cui i due sistemi potrebbero dover convivere. In alcuni casi la soluzione migliore sarà mantenere il software principale e costruire piccole applicazioni intorno ai suoi limiti. In altri sarà possibile sostituire una funzione specifica, verificando con calma che i dati rimangano accessibili. Soltanto in presenza di requisiti chiari e di un piano sostenibile avrà senso valutare la sostituzione dell’intera piattaforma.
La maggiore accessibilità dello sviluppo software offre alle PMI una possibilità che in passato era spesso fuori portata. Per sfruttarla occorre però conoscere il proprio lavoro abbastanza bene da poterlo descrivere e controllare. La libertà tecnologica comincia dalla conoscenza dei processi, dalla disponibilità dei dati e dalla capacità di verificare quello che un programma fa davvero.
Parliamo della tua azienda.
Nella videocall gratuita di trenta minuti mi racconti come è organizzato il lavoro e ti dico se e come l’intelligenza artificiale può esserti utile, e da quale dei miei servizi partire.
Nella pagina dei casi trovi sei interventi raccontati con i numeri e il mio ruolo. Le guide gratuite sono tre: l’intelligenza artificiale per le aziende, quella per gli studi professionali e la guida all’AI Act.
