Come i software modellano, e a volte sostituiscono, la strategia d’impresa
C’è una domanda che raramente irrompe nelle riunioni di direzione, ma permea ogni processo aziendale in modo silenzioso e inesorabile: chi prende davvero le decisioni operative all’interno di un’organizzazione?
In apparenza, la risposta è ovvia: l’imprenditore, il management, le persone al vertice della gerarchia. Eppure un’analisi attenta delle dinamiche operative di molte organizzazioni rivela una verità più scomoda. Una quota crescente di decisioni, tanto strategiche quanto quotidiane, è orientata, e spesso vincolata, dai sistemi software adottati. Non si tratta di una provocazione teorica: è una constatazione empirica, verificabile nella pratica di imprese di ogni settore e dimensione.
Questo articolo analizza il meccanismo attraverso cui i sistemi informativi esercitano un’influenza silenziosa sulla governance aziendale, propone uno strumento diagnostico per rendere visibile tale influenza, e delinea le condizioni affinché il software torni a essere un alleato della strategia, invece di sostituirla.
La visione implicita nel codice
Ogni software incorpora una visione del mondo. Un gestionale ERP, un CRM, una piattaforma di project management non si limitano a registrare dati: strutturano processi, definiscono priorità, delimitano l’insieme delle opzioni disponibili. Trasformano una strategia astratta in comportamenti operativi concreti — e lo fanno secondo regole che spesso restano invisibili agli stessi utilizzatori.
Per comprendere questo meccanismo è utile ricorrere al concetto di affordance, introdotto dallo psicologo James J. Gibson e successivamente applicato al design degli artefatti da Donald Norman in The Design of Everyday Things. Un’affordance è la proprietà di un oggetto, o di un sistema, di suggerire, facilitare o impedire determinati comportamenti. Una porta con una maniglia orizzontale invita alla spinta; con una verticale, alla trazione. Il software opera in modo analogo: un CRM che misura esclusivamente il numero di chiamate effettuate insegna implicitamente al reparto commerciale che la quantità conta più della qualità relazionale, indipendentemente da ciò che il direttore vendite dichiara nelle riunioni.
Il filosofo della tecnologia Langdon Winner ha radicalizzato questa intuizione nel celebre saggio Do Artifacts Have Politics? (1980), sostenendo che la tecnologia non è mai ideologicamente neutrale: incorpora sempre scelte di design che distribuiscono potere in modo asimmetrico. Applicato al software aziendale, questo significa che ogni ERP standard è scritto secondo una visione del mondo, spesso quella del vendor, non dell’imprenditore che lo adotta. Adottare un pacchetto preconfigurato significa, in ultima analisi, accettare un modello implicito di business: le sue regole di priorità, i suoi flussi approvati, i suoi KPI predefiniti.
Adottando un software, un’azienda non acquista uno strumento neutro: accetta un modello preconfigurato di business, con regole implicite che orientano — o impongono — le scelte quotidiane del team.
Il paradosso operativo: lo strumento che guida il padrone
Le conseguenze di questa dinamica sono osservabili con precisione nei processi operativi. Si considerino due casistiche frequenti nelle PMI italiane.
Nel caso dei flussi commerciali, un CRM mal allineato forza i venditori a registrare le opportunità secondo categorie che non corrispondono al ciclo di vendita reale dell’azienda, genera reportistica su metriche irrilevanti e, nel tempo, orienta le decisioni di forecasting su basi distorte. Nel caso dei processi HR, una piattaforma di formazione legacy penalizza la collaborazione remota, rende impraticabili percorsi di upskilling personalizzati e produce dati di engagement che non catturano le variabili significative per il management.
In entrambi i casi emerge un paradosso: il software, nato per liberare tempo e risorse, finisce per guidare l’organizzazione invece di servirla. Il management adatta i processi allo strumento, non il contrario. La strategia viene formulata, consapevolmente o no, nei limiti di ciò che il sistema è in grado di supportare.
In Italia, dove secondo i dati ISTAT il processo di trasformazione digitale delle PMI procede con ritmi disomogenei, questo fenomeno è amplificato dalla prevalenza di soluzioni standard non customizzate e dalla scarsa cultura di audit periodico dei sistemi informativi. I dati McKinsey Global Institute (2024) mostrano come le PMI italiane presentino un gap significativo rispetto alle omologhe tedesche e francesi proprio nella capacità di adattare i sistemi informativi all’evoluzione strategica, non nell’adozione iniziale, ma nella gestione del ciclo di vita del software.
Uno strumento diagnostico: la matrice Aderenza Strategica / Flessibilità Tecnica
Per rendere visibile il nesso tra sistemi informativi e strategia d’impresa, è utile disporre di uno strumento diagnostico semplice ma non semplicistico. La matrice che segue incrocia due dimensioni:
- l’Aderenza Strategica, ovvero la misura in cui il software riflette e supporta il modello di business effettivo dell’organizzazione;
- la Flessibilità Tecnica, ovvero la capacità del sistema di evolvere in risposta a nuove esigenze strategiche senza richiedere sostituzioni integrali.
| Matrice | Bassa Flessibilità | Alta Flessibilità |
|---|---|---|
| Alta Aderenza Strategica | Sistema efficiente ma fragile: Funziona oggi, ma le logiche rigide richiedono interventi costosi per ogni evoluzione. Rischio obsolescenza rapida in mercati dinamici. | Asset strategico: Coerente con la visione aziendale e adattabile, genera vantaggio competitivo duraturo. Evoluzione continua senza strappi. |
| Bassa Aderenza Strategica | Sistema obsoleto: Non riflette il modello di business attuale, genera inefficienze croniche e frustrazione operativa. | Sistema evolvibile: Flessibile ma non allineato; necessita di riprogettazione mirata, non di sostituzione totale. Opportunità di quick win. |
La matrice non va letta come una classificazione definitiva, ma come punto di partenza per una conversazione organizzativa. Due domande operative permettono di posizionarsi con relativa precisione:
- Quante volte nell’ultimo anno avete modificato un processo aziendale non perché fosse sbagliato, ma perché il software non supportava altro?
- Quante decisioni strategiche sono state rinviate o semplificate perché il sistema informatico non era pronto a supportarle?
Se le risposte sono frequenti, l’organizzazione si trova con tutta probabilità nei quadranti in basso a sinistra della matrice. L’obiettivo non è necessariamente raggiungere il quadrante in alto a destra, un sistema efficiente ma rigido può essere sufficiente per modelli di business stabili, ma comprendere consapevolmente in quale quadrante ci si trova e perché.
Una nota critica: il software come commodity o come leva competitiva?
Prima di procedere con un caso applicativo, è necessario confrontarsi con la tesi opposta a quella sin qui sostenuta. Nel 2003, Nicholas Carr pubblicò sulla Harvard Business Review l’articolo Does IT Matter?, poi ampliato in volume, in cui argomentava che la tecnologia informatica, diventando ubiqua e standardizzata, ha cessato di costituire una fonte di vantaggio competitivo differenziale. Se tutti i concorrenti usano SAP o Salesforce, nessuno ottiene un vantaggio relativo dalla tecnologia in sé.
L’argomento di Carr è corretto nella sua premessa, la tecnologia standardizzata non differenzia, ma parziale nella conclusione. Ciò che differenzia non è il software in sé, ma la qualità dell’allineamento tra software e strategia specifica dell’organizzazione. Un ERP identico può essere un asset strategico in mani di un’azienda che ha progettato i propri processi attorno a esso, e un sistema obsoleto per un’azienda che ha subito passivamente la sua adozione. La variabile rilevante non è lo strumento: è la governance dell’adozione.
Clayton Christensen ha descritto un fenomeno analogo in The Innovator’s Dilemma: le organizzazioni di successo tendono a ottimizzare i propri sistemi attorno al modello di business corrente, costruendo barriere involontarie all’innovazione. I sistemi legacy non sono necessariamente il risultato di scelte sbagliate: spesso sono la conseguenza naturale di successi passati. Riconoscerlo è il primo passo per gestirli consapevolmente.
Dalla teoria alla pratica: il caso Yuman+
Le categorie analitiche proposte nei paragrafi precedenti trovano riscontro concreto in un nostro caso applicativo sviluppato nel settore della formazione e coaching aziendale. La sua utilità non è autodimostrativa, ogni case study interno porta con sé un evidente conflitto di interessi, ma risiede nella possibilità di applicare la matrice diagnostica a una situazione reale, con i suoi vincoli, le sue resistenze e le sue misurazioni.
Il contesto e il problema
Nel lontano 2016, una startup (Yucan Srl) che si era rivolta al nostro team già nel 2013 operante nel settore della formazione professionale e della collaborazione aziendale voleva sviluppare una nuova piattaforma web che superasse i limiti di tante aziende che operano nello stesso segmento: i processi formativi erano distribuiti su piattaforme eterogenee e non comunicanti, il monitoraggio dell’engagement avveniva tramite fogli di calcolo aggiornati manualmente, e la gestione dei contenuti didattici richiedeva interventi tecnici non autonomi da parte del personale HR. Il risultato dell’analisi dei sistemi esistenti sul mercato in quel periodo collocava questi stessi strumenti nel quadrante in basso a sinistra della matrice: bassa aderenza alla strategia (il focus dichiarato era sulla formazione scalabile e sui team distribuiti, ma gli strumenti non supportavano né l’uno né l’altro) e bassa flessibilità tecnica (ogni modifica richiedeva l’intervento di fornitori esterni con tempi e costi imprevedibili).
Le resistenze iniziali erano di natura organizzativa prima che tecnica. Una parte del management considerava il problema come un deficit di utilizzo degli strumenti esistenti, non come un disallineamento strutturale. La decisione di procedere con una progettazione o riprogettazione integrata fu preceduta da un audit dei processi che rese visibile, dati alla mano, il costo nascosto della frammentazione: duplicazione del lavoro amministrativo, impossibilità di estrarre reportistica aggregata, latenza nelle comunicazioni tra formatori e partecipanti.
La soluzione e i vincoli di progetto
Il brief finale richiedeva un sistema integrato con funzionalità di gestione corsi, videoconferenza (mediante integrazione con Adobe Connect, allora standard di mercato per la formazione sincrona), strumenti di collaborazione asincrona, social wall, forum strutturato, directory documentale e profili personali con tracciamento delle attività formative. Il vincolo principale non era tecnico: era temporale. La finestra di adozione disponibile — determinata da un ciclo formativo in partenza — era di sei mesi dalla definizione dei requisiti al go-live.
Un secondo vincolo, meno visibile ma più vincolante nel lungo periodo, riguardava la scalabilità. Il sistema doveva poter evolvere autonomamente, senza dipendenza da fornitori per la gestione ordinaria, e doveva supportare un numero di utenti potenzialmente variabile senza richiedere migrazioni architetturali. Questo vincolo orientò le scelte di design verso un’architettura modulare, con interfacce ben definite tra componenti, una scelta che avrebbe mostrato il suo valore anni dopo.
Gli esiti e la loro misurazione
La piattaforma integrata, denominata Yuman+, fu consegnata nei tempi previsti e adottata progressivamente nel corso del primo anno. I dati di onboarding, il tempo medio necessario a un nuovo utente per completare il primo percorso formativo autonomamente e soprattutto il coinvolgimento degli utenti alla piattaforma mostrarono tutti dati positivi e incoraggianti rispetto a processi simili adottati dai concorrenti che invece continuavano ad utilizzare vecchi software e piattaforme frammentate.
Il dato più significativo è però di natura longitudinale. La piattaforma ha operato per oltre dieci anni senza migrazioni strutturali, attraversando due evoluzioni tecnologiche maggiori (la diffusione degli smartphone come dispositivo primario di accesso e la pandemia del 2020, che ha moltiplicato il carico di utenti in formazione remota) e numerose evoluzioni funzionali. L’architettura modulare adottata nel 2013, poi una nuova versione nel 2016 ha consentito di integrare nuovi componenti — analytics avanzati, notifiche push, gestione asincrona dei contenuti video — senza riscrivere il sistema di base. Nella terminologia della matrice, Yuman+ si è posizionata nel quadrante dell’asset strategico non al momento del lancio, ma nel corso della sua evoluzione: la flessibilità tecnica iniziale ha reso possibile l’adattamento alla flessibilità strategica richiesta dal contesto.
Ciò che questo caso illustra non è l’eccellenza di una singola implementazione, ma un principio generale: il valore di un sistema informativo non si misura al momento dell’adozione, ma lungo il suo ciclo di vita. Un sistema che risponde perfettamente ai requisiti del 2016 ma non evolve con l’organizzazione diventa un sistema obsoleto nel 2020. La longevità di Yuman+ è stata la conseguenza di scelte architetturali compiute in fase di progettazione, non di aggiornamenti reattivi.
Il valore di un sistema informativo non si misura al momento dell’adozione, ma lungo il suo ciclo di vita. La flessibilità tecnica iniziale è il prerequisito della resilienza strategica futura.
Il software come atto di governance
Se il software non è neutro, e se la sua adozione equivale all’accettazione di un modello implicito di business, allora la decisione di adottare, customizzare o sostituire un sistema informativo non è una decisione tecnologica: è una decisione di governance.
Questo cambiamento di prospettiva ha implicazioni precise. La prima riguarda il livello gerarchico al quale tali decisioni vengono prese: se il software struttura i processi decisionali dell’intera organizzazione, la scelta del sistema informativo appartiene al board o a chi prende decisioni aziendali strategiche, non al reparto IT. La seconda implicazione riguarda i criteri di valutazione: accanto al costo di implementazione e alle funzionalità disponibili, un’organizzazione consapevole dovrebbe valutare il grado di aderenza al proprio modello di business specifico e la flessibilità a lungo termine del sistema.
La terza implicazione, forse la più rilevante sul piano pratico, riguarda la logica di adozione. La distinzione fondamentale è tra adozione passiva e progettazione attiva. L’adozione passiva consiste nell’acquistare un pacchetto standard e adattare l’organizzazione alle sue logiche. La progettazione attiva consiste nel definire prima il modello di business e i processi che si vogliono supportare, e costruire o selezionare il sistema in funzione di questa definizione. La seconda via è più costosa nel breve periodo; è la sola che evita di diventare prigionieri del proprio gestionale.
La decisione di adottare, customizzare o sostituire un sistema informativo non è una decisione tecnologica: è una decisione di governance. Appartiene al board, non al reparto IT.
Conclusione: il software come architettura del pensiero organizzativo
La domanda con cui abbiamo aperto — chi guida davvero l’azienda? — non ammette una risposta binaria. L’imprenditore e il software non si escludono: si condizionano reciprocamente. Il software non rimpiazza l’imprenditore, ma ne amplifica il pensiero, ne delimita i confini operativi, ne struttura l’eredità organizzativa.
Comprendere questo equilibrio non è un esercizio teorico. È il prerequisito per costruire organizzazioni capaci di evolvere senza strappi, di adottare nuove tecnologie senza perdere la coerenza strategica, di fare della trasformazione digitale un processo governato e non subito.
La scelta di progettare sistemi informativi coerenti con la propria visione, invece di adattare la propria visione ai sistemi disponibili è, in ultima analisi, una scelta di libertà organizzativa. La questione non è quale software comprare: è quale modello d’impresa si vuole che il proprio software incarni.
Questa consapevolezza non appartiene all’IT manager. Appartiene al board o a chi prende decisioni aziendali strategiche.
Alcune letture di approfondimento
- N. Carr, Does IT Matter? Information Technology and the Corrosion of Competitive Advantage, Harvard Business School Press, 2004 (pagina Google Books ufficiale del libro e articolo correlato HBR);
- C. Christensen, The Innovator’s Dilemma. When New Technologies Cause Great Firms to Fail, Harvard Business Review Press, 1997 (pagina Harvard Business School e pagina Wikipedia);
- J. J. Gibson, The Ecological Approach to Visual Perception, Houghton Mifflin, 1979; D. A. Norman; The Design of Everyday Things, Basic Books, 2013 (ediz. rev.). Per Gibson, Norman (ed. rev. 2013) e Google Books;
- L. Winner, Do Artifacts Have Politics?, in Daedalus, vol. 109, n. 1, 1980, pp. 121–136. PDF diretto dell’articolo da Cornell e Scribd;
- G. Bracchi, C. Francalanci, G. Motta, Sistemi informativi d’impresa, McGraw-Hill Education, 2010. Pagina Google Books;
- R. Candiotto, S. Gandini, Il sistema integrato per la gestione delle informazioni aziendali, Giappichelli, 2022, Pagina ufficiale Università Piemonte Orientale;
- McKinsey Global Institute, The economic potential of generative AI — Productivity and digital adoption in European SMEs, McKinsey & Company, 2024 – Rapporto principale su genAI (2023, base per 2024);
- ISTAT, Rapporto sulla competitività dei settori produttivi, edizione 2024, Istituto Nazionale di Statistica, Roma. – Pagina ufficiale ISTAT con e-book e dati e PDF nota stampa.
Per avere maggiori informazioni su questo argomento vi invitiamo a contattarci.
Fisseremo un incontro per parlarne e approfondire il tema.
Contattaci via mail scrivendo a info@dev4u.it, non perdere altre opportunità!
Autore/i dell’articolo:
Maurizio Patitucci – BIO – Linkedin – Email
Business Analyst | Project Manager | Account Manager