Il software ha un'opinione sul tuo business

Il modello prima del software

Ogni software gestionale incorpora una visione di come un’azienda dovrebbe funzionare. Definisce cosa sia un cliente, quali fasi attraversi un ordine, come vada organizzato un magazzino, cosa meriti di essere misurato. Chi lo adotta riceve queste definizioni insieme al prodotto, spesso senza rendersene conto, perché si presentano come scelte tecniche (campi da compilare, flussi da seguire, report da consultare) quando in realtà sono scelte di significato.

Il punto è semplice e scomodo: la maggior parte del software in commercio è progettata per modellare il business, mentre un buon software dovrebbe modellarsi sul business. La direzione della deformazione è opposta, e con essa è opposto il senso dell’intera operazione. Nel primo caso l’impresa diventa un caso particolare di un modello generico; nel secondo il software diventa la formalizzazione di un modello specifico che già esisteva nell’impresa, anche se in forma implicita.

Un CRM che classifica ogni contatto come lead, prospect o customer ha già deciso che la relazione commerciale segue un percorso lineare. Un sistema di magazzino che ragiona per giacenza media ha già stabilito che tutte le referenze seguono la stessa logica di rotazione. Le conseguenze di queste decisioni si accumulano lentamente. L’azienda comincia ad adattarsi al software, a lavorarci intorno, a creare fogli Excel paralleli per catturare ciò che il sistema non prevede, a usare i campi note come contenitori improvvisati per informazioni che non trovano posto altrove. Un anno dopo, il business si è riarrangiato intorno al gestionale, e quello che era nato come strumento è diventato il riferimento.

I sistemi più sofisticati promettono ampia flessibilità: campi su misura, flussi configurabili, automazioni costruibili a piacere. Nella pratica il quadro è meno generoso. Configurare seriamente un gestionale enterprise ha un costo che opera su due piani diversi. Il primo è economico e immediato: richiede quasi sempre integratori esterni, produce assemblaggi fragili che si rompono agli aggiornamenti del software, e che pochi sanno mantenere senza chiamare di nuovo chi li ha costruiti. Il secondo è progettuale e prospettico, meno visibile ma più insidioso: ogni configurazione è una stratificazione di personalizzazioni dentro un’architettura che non è stata pensata per quel business, e questa stratificazione si accumula nel tempo come debito. Cambiare strada diventa più costoso a ogni nuovo intervento, e l’azienda si trova legata non al software ma all’insieme di aggiustamenti che lo hanno reso vagamente compatibile con la propria operatività. Anche dopo investimenti significativi, il livello di precisione che si raggiunge resta quasi sempre al di sotto di quello che il business avrebbe bisogno di esprimere. La flessibilità di superficie poggia su una rigidità di fondo che torna a farsi sentire ogni volta che qualcosa di importante cambia nel modo di lavorare.

Il costo di questa deformazione è interamente in attenzione. Ogni giorno, una quota di tempo e concentrazione viene assorbita dal colmare la distanza tra il modello del software e la realtà operativa. Una quota piccola ma costante, sottratta a tutto il resto.

Per decenni questo costo era parte del prezzo da pagare per avere un sistema, e si accettava come tale. Negli ultimi anni è diventato negoziabile: si stanno aprendo alternative che fino a poco tempo fa richiedevano risorse fuori portata per la maggior parte delle imprese, e con loro un campo nuovo di scelte e di rischi che prima non si ponevano.

Il software come atto di comprensione

La domanda preliminare a qualunque scelta di software è capire il proprio business con sufficiente precisione da distinguere dove un modello generico è adeguato e dove sta producendo danni silenziosi. È un passaggio che viene saltato quasi sempre, perché sembra ovvio per chi quel business lo gestisce ogni giorno, e quasi sempre non lo è.

Costruire un sistema operativo interno parte da qui, dalla mappatura di ciò che esiste davvero. Come funzionano i processi nella pratica quotidiana, non come dovrebbero funzionare. Quali informazioni servono alle decisioni, quali vengono prodotte e mai guardate, dove il flusso si inceppa. Il software arriva dopo, come formalizzazione di una conoscenza che prima viveva distribuita tra le persone, le abitudini, i fogli di calcolo, e che proprio per questo era fragile.

Il primo risultato di questo esercizio è di solito meno gratificante di quanto chi lo conduce si aspetti: la maggior parte dei processi che un’impresa sente come propri è in realtà standard, riconducibile a pattern condivisi con mille altre aziende dello stesso tipo. La specificità vera, quella che giustifica un’attenzione particolare e, eventualmente, un sistema costruito intorno a essa, è quasi sempre più ristretta di quanto la percezione interna suggerisca. Riconoscerla con precisione è il valore reale del lavoro di comprensione: separa ciò che vale la pena costruire da ciò che basta scegliere bene.

La narrazione corrente sull’intelligenza artificiale applicata allo sviluppo tende a saltare questo passaggio. Sottintende che il collo di bottiglia sia la capacità di costruire, quando in realtà la difficoltà sta nel sapere cosa modellare. Un’impresa sa fare il proprio lavoro, ma saperlo descrivere con la precisione necessaria a trasformarlo in un sistema è un esercizio diverso: significa rendere esplicite strutture che funzionano proprio perché nessuno le ha mai dovute formalizzare.

Il valore sta proprio qui. Formalizzare un flusso operativo in un software obbliga a prendere decisioni che prima restavano implicite o venivano rinviate: cosa rende un cliente buono, quando un prodotto va riordinato, quale informazione deve arrivare a chi. Sono decisioni che l’impresa prende già ogni giorno, per intuizione o per abitudine. Il processo di costruzione le porta in superficie, dove diventano oggetto di confronto invece di rimanere assunzioni invisibili.

Mi è successo costruendo il sistema con cui leggo i miei clienti. Sembrava banale: un cliente fermo da più di sessanta giorni è inattivo, vai a riattivarlo. È la primitiva che trovi in qualsiasi CRM e in qualsiasi corso di customer lifecycle. Quando ho provato a tradurla in codice, non ha retto. Sessanta giorni per un cliente che ordina ogni due settimane sono una crisi conclamata; per uno che ordina ogni novanta sono metà del suo ritmo normale. La categoria “attivo / inattivo” non descriveva il cliente, descriveva una soglia universale applicata a clienti che vivono ritmi diversi. Per uscirne ho dovuto smontare l’idea che “attivo” fosse un attributo del cliente e ricostruirla come una relazione tra il cliente e il proprio ritmo storico. Quel lavoro è poi diventato un piccolo framework che ho descritto in un altro pezzo; qui interessa solo l’episodio. Quello che ho visto, formalizzando, è una categoria che davo per scontata da anni perdere consistenza nel momento in cui ho dovuto scriverla in modo esplicito.

Due trappole speculari

La trappola del software generico è nota e descritta: impone un modello che non corrisponde alla realtà dell’impresa, e col tempo il business si deforma per adattarsi. C’è una variante meno discussa di questa trappola, che riguarda il software pesantemente configurato. Una configurazione fatta bene può essere stabile e funzionale per anni; ma man mano che le personalizzazioni si stratificano, l’azienda inizia a ereditare oneri proporzionali al livello di intervento (manutenzione perpetua, dipendenza da chi ha costruito le configurazioni, fragilità rispetto agli aggiornamenti del software sottostante) senza ottenere il beneficio principale di chi costruisce davvero, cioè un modello che rispecchi come si lavora. Oltre una certa soglia di personalizzazione, ci si trova in una posizione ibrida che porta i costi di chi costruisce e i vincoli di chi adotta.

Il software su misura ha una trappola opposta, meno discussa e altrettanto concreta. Quando il vincolo del modello generico scompare, il perimetro di ciò che si potrebbe costruire diventa aperto. Ogni processo potrebbe essere catturato con più precisione, ogni interfaccia potrebbe aderire meglio al flusso reale. La rincorsa verso il sistema perfetto può diventare permanente: il software non viene rilasciato, o viene rilasciato e immediatamente percepito come insufficiente.

C’è una differenza importante rispetto alla logica delle startup, dove si rilascia un prodotto minimo e si aggiusta in corsa. Un sistema operativo interno deve funzionare bene dal primo utilizzo, perché le persone ci lavorano sopra e gli errori ricadono sull’operatività quotidiana. La logica del rilascio precoce, qui, opera diversamente: invece di rilasciare a tutti un prodotto incompleto, si rilascia a pochi un prodotto solido. Il perimetro iniziale va tenuto stretto, un singolo processo o un gruppo limitato di utenti, abbastanza da contenere le imperfezioni inevitabili senza farle ricadere sull’intera operatività. Da quel perimetro si espande, si raffina, si corregge ciò che il primo modello aveva semplificato troppo. Il principio per cui si impara solo dall’uso resta valido; cambia il modo in cui si organizza il rischio.

Cosa sta cambiando

Per decenni la scelta è stata sbilanciata. Il software commerciale era rapido da adottare ed economico, ma generico. Lo sviluppo su misura era preciso, ma richiedeva budget e tempi che la maggior parte delle imprese non poteva giustificare. Il compromesso col generico era quasi sempre obbligato. Negli ultimi quindici anni questo compromesso ha preso una forma specifica: il SaaS, il software venduto come servizio in abbonamento, è diventato la modalità dominante con cui le aziende acquistano funzionalità digitali. La promessa era ragionevole: niente installazioni da gestire, aggiornamenti continui, costi prevedibili. Il rovescio della medaglia, meno discusso, è che il SaaS è la forma più pura del software-che-impone-un-modello: per restare economico per il fornitore, deve essere abbastanza generico da servire migliaia di clienti con la stessa logica.

Gli strumenti di intelligenza artificiale stanno modificando questa asimmetria, e lo fanno in modi che la narrazione corrente cattura solo in parte. Il livello più visibile è la velocità di costruzione: quello che richiedeva settimane può richiedere giorni, e una persona con competenze operative può avviare ciò che prima richiedeva un gruppo di lavoro dedicato.

Gli stessi strumenti aiutano in un lavoro che viene prima della costruzione, quello di formalizzazione del business: strutturare osservazioni e interviste, organizzare appunti sparsi, far emergere contraddizioni tra come si dice di lavorare e come si lavora davvero. La conoscenza tacita resta dove è sempre stata, dentro le persone che operano e nelle loro abitudini, ed è da lì che va estratta. L’AI non garantisce che salti fuori da sola, e non sostituisce il mestiere di chi sa interrogare il proprio business con metodo: aumenta la produttività di un esercizio che resta difficile, e non per questo cessa di richiedere attenzione, tempo e disciplina. Per un imprenditore che conosce il proprio mestiere ma non ha mai avuto il tempo o gli strumenti per descriverlo in modo sistematico, la possibilità più significativa è proprio questa: rendere praticabile un lavoro di esplicitazione che prima richiedeva mesi e una persona dedicata.

Si sta materializzando, intanto, una pressione di mercato che converge nella stessa direzione. Le imprese che hanno accumulato negli anni decine di abbonamenti SaaS iniziano a chiedersi se valga la pena pagare ricorsivamente per funzionalità che oggi possono essere costruite internamente con costi diversi e con un controllo maggiore. Il fenomeno non riguarda solo la spesa: riguarda anche dove sta il valore. Quando una funzione è davvero specifica, tenerla dentro un sistema che ne è proprietario diventa più sensato che noleggiarla da un fornitore che la sta vendendo a centinaia di altre aziende con la stessa interfaccia.

C’è una conseguenza ulteriore, che cambia la natura stessa del processo: il costo di sbagliare si è ridotto in modo radicale. Quando costruire richiedeva mesi e budget importanti, ogni errore di modellazione era costoso da correggere, e questo incentivava la paralisi, il tentativo di prevedere tutto prima di partire. Oggi si può provare, verificare che il modello regga nella pratica, buttare via quello che non funziona e ricalibrare. I costi di iterazione (che non sono solo economici, ma anche di tempo, di attenzione, di complessità che si accumula nel sistema) sono scesi al punto da rendere praticabile un approccio che prima era un lusso: lasciare che il software evolva col business, accettando che la fotografia iniziale sarà sempre incompleta e che le correzioni continue sono parte del modo in cui il sistema funziona. Questa iterazione non richiede di scrivere il codice in prima persona; richiede consapevolezza di ciò che va cambiato e capacità, direttamente o attraverso un collaboratore, di tradurre quel cambiamento nel sistema. È una differenza importante rispetto al passato, quando ogni iterazione era un progetto a sé.

Quando il vincolo economico smette di scoraggiare le riscritture, prende il suo posto la disciplina di scegliere cosa vale la pena rimettere in discussione. Il giudizio si sposta da “possiamo permettercelo” a “ne abbiamo davvero bisogno”, e qui torna decisiva la conoscenza del business.

Il vincolo nuovo

La domanda che un’impresa si pone davanti al software è cambiata. Per decenni era una domanda di reperibilità: quale soluzione sul mercato si avvicina di più a ciò che ci serve? Oggi, almeno per i processi che fanno la differenza, è diventata una domanda diversa: capiamo abbastanza bene come lavoriamo davvero da poter costruire qualcosa che ci somigli?

Il vincolo è scivolato dalla disponibilità di strumenti alla chiarezza con cui un imprenditore sa descrivere il proprio mestiere. Una chiarezza che fino a ieri restava privata, depositata nell’esperienza di chi ha costruito il business e nelle abitudini di chi ci lavora dentro, e che oggi può diventare la base concreta del sistema con cui l’impresa lavora. Lo spostamento è poco rumoroso ma sostanziale: il vantaggio competitivo della specificità, fino a poco tempo fa difficilmente difendibile perché difficilmente formalizzabile, ha trovato un canale in cui può consolidarsi.

Una scelta più chirurgica

Il vincolo nuovo apre la possibilità di una scelta più chirurgica. La maggior parte di un’impresa funziona con processi che mille altre aziende condividono, e che strumenti standard gestiscono adeguatamente. La specificità sta nel sottoinsieme, spesso piccolo e identificabile solo da dentro, dove il modo di lavorare costituisce davvero un vantaggio competitivo. Costruire intorno a quel sottoinsieme, e solo a quello, mantiene sostenibili i costi di costruzione e di manutenzione successiva, e rende la promessa del software-che-ci-somiglia un obiettivo realizzabile invece di un orizzonte che si allontana.

Costruire, in questo senso, non significa scrivere ogni componente da zero. Significa partire dall’ecosistema esistente (librerie, API, servizi, pattern già consolidati) senza escludere nulla a priori, e usarlo come materia prima al servizio di un modello che è il proprio. La qualità di ciò che ne esce dipende interamente dalla direzione in cui le scelte vengono prese: se il punto di partenza è il modello del business e gli strumenti vengono dopo, la composizione si organizza intorno a una logica coerente e l’oggetto finale si modella sul modo in cui l’impresa lavora; se il punto di partenza sono gli strumenti disponibili, la composizione finisce per imporre al business la propria geometria, e si torna nella deformazione di partenza con un livello di sofisticazione maggiore. Il software moderno è quasi sempre composizione; quello che cambia è chi sta guidando l’assemblaggio.

Come cambia il rapporto con chi costruisce

Per la maggior parte degli imprenditori, oggi, “costruire” significa ancora affidare a qualcuno che costruisce. Il costruttore, lo sviluppatore, il consulente tecnico restano figure necessarie, e la qualità del risultato dipende in misura significativa dalla qualità di quel rapporto. La differenza rispetto al passato è che il committente arriva al confronto con le idee molto più chiare, e questo cambia la natura del rapporto stesso: meno traduzione approssimativa di esigenze vaghe, più collaborazione tra chi conosce il business e chi sa renderlo software.

È ragionevole aspettarsi che, su un orizzonte non lontano, una parte di questa relazione cambi forma. La direzione di marcia degli strumenti è chiara: la costruzione vera e propria, dalla scrittura del codice alla messa in opera di un primo sistema funzionante, sta diventando una commodity. Non l’intera relazione, però. Da una parte, nessun imprenditore può aspettarsi di sostituire da solo l’intero arco di competenze che servono per portare in produzione un sistema affidabile: gli strumenti hanno modi propri di sbagliare, spesso poco visibili a chi non ha esperienza tecnica, e quegli errori si pagano nell’operatività quotidiana. Dall’altra, il bisogno di un confronto esterno non si dissolve insieme al costo del codice; resta utile, e probabilmente necessario, qualcuno che faccia da specchio, sollevi obiezioni che dall’interno non si vedono, porti esperienza accumulata su problemi simili.

La natura di questa figura cambia di conseguenza. La sua proposta di valore si sposta dalla scrittura del codice alla produzione di soluzioni concrete, e quasi certamente prenderà la forma di una combinazione tra AI e umano, dove l’AI fa il lavoro tecnico e l’umano resta sul piano in cui il valore si forma davvero, quello del confronto e della messa a fuoco. Mentre la parte tecnica della costruzione continuerà a costare meno e a essere più rapida, la capacità di capire cosa va costruito e perché diventerà la risorsa più scarsa del processo, e quella che ne determina la qualità.

Chi il problema di come il proprio software rappresenta il proprio business non se lo pone, sta meglio con soluzioni standard, e fa bene a usarle. La possibilità nuova si apre per chi ha già intuito che qualcosa non torna, e adesso ha gli strumenti per fare qualcosa con quell’intuizione: smettere di scegliere il software che modellerà il proprio business, e cominciare a costruire il software che si modella sul business che già esiste.