Automazione con l’AI: come conservare le competenze che permettono all’azienda di controllare il lavoro

Quando un processo funziona, ma nessuno sa più spiegare perché

Immagina un’azienda che riceve ogni giorno ordini da clienti italiani ed esteri. Per anni un gruppo di persone ha controllato i documenti, verificato i codici articolo, consultato il magazzino e corretto le anomalie prima di registrare ogni ordine nel gestionale. Con il tempo i dipendenti hanno imparato a riconoscere i clienti che utilizzano descrizioni particolari, i prodotti che richiedono controlli aggiuntivi e le richieste che vanno confermate prima di proseguire.

L’azienda introduce un sistema di intelligenza artificiale che legge i messaggi, estrae i dati e prepara gli ordini. Durante i primi mesi il funzionamento è soddisfacente. Le persone devono intervenire più raramente e possono dedicarsi ad altre attività.

Dopo un paio d’anni, però, cambia una condizione commerciale importante e il sistema comincia a gestire male alcune eccezioni. Chi lavorava nel reparto non svolge più manualmente quei passaggi da molto tempo. Alcuni colleghi esperti hanno cambiato mansione e i nuovi arrivati hanno imparato a controllare la schermata finale, senza conoscere la procedura che produce il risultato.

A quel punto l’azienda affronta un problema che non compare quasi mai nelle presentazioni commerciali: il software continua a lavorare, ma la capacità interna di capire e correggere il processo si è ridotta. Se il fornitore tarda a intervenire, oppure se bisogna cambiare piattaforma, ricostruire le regole può diventare più difficile di quanto fosse automatizzare il lavoro all’inizio.

Questa situazione è un esempio illustrativo, costruito per rendere visibile un rischio organizzativo. Non significa che ogni automazione porti alla perdita di competenze. Significa che il rischio esiste quando l’impresa trasferisce attività a un sistema senza decidere quale conoscenza debba restare alle persone. La questione non riguarda soltanto l’intelligenza artificiale: ogni tecnologia può rendere meno frequente un’abilità manuale. Con l’AI, però, l’automazione può estendersi a compiti che prima richiedevano interpretazione, ricerca e giudizio, e questo rende più importante la progettazione delle responsabilità.

Le competenze sono più ampie delle singole operazioni

Quando si dice che un collaboratore sa fare una determinata attività, spesso si pensa alla sequenza visibile dei passaggi. Aprire un documento, leggere un importo, copiare un codice e compilare una schermata sono operazioni che si possono descrivere. In molte aziende, tuttavia, la competenza consiste anche nel sapere perché si segue quella sequenza e in quali circostanze bisogna cambiarla.

Un addetto amministrativo esperto riconosce una fattura che non corrisponde all’ordine anche quando i campi formalmente sembrano corretti. Un responsabile acquisti nota che un prezzo insolito richiede una verifica perché conosce le condizioni negoziate con il fornitore. Una persona dell’ufficio estero sa che una determinata destinazione richiede documenti aggiuntivi. Alcune di queste regole sono scritte, altre vengono apprese con l’esperienza e si tramandano tra colleghi.

È utile distinguere tre dimensioni della competenza. La prima riguarda l’esecuzione: saper svolgere i passaggi necessari per completare una pratica. La seconda riguarda la valutazione: riconoscere se ciò che è stato prodotto è corretto, completo e coerente con il contesto. La terza riguarda il governo del processo: capire perché l’organizzazione lavora in un certo modo e come modificarlo quando cambiano clienti, norme, prodotti o strumenti.

L’AI può ridurre molto il lavoro necessario nella prima dimensione. Può supportare anche la seconda, suggerendo controlli e segnalando anomalie. La terza, per un’azienda, rimane strategica: qualcuno deve decidere quali risultati sono accettabili, chi è autorizzato a modificarne le regole e quando un sistema deve essere sostituito. Se queste decisioni vengono completamente delegate a un fornitore esterno, l’impresa può perdere la capacità di cambiare autonomamente il proprio modo di lavorare.

Tre livelli in salita: esecuzione, cioè se l’AI sa fare il compito, dove lavorano quasi tutti; supervisione, cioè se qualcuno in azienda sa capire se lo sta facendo bene; capacità, cioè se l’azienda saprebbe modificare, sostituire o riprogettare il sistema domani, segnato come il problema vero

Il rischio aumenta nei settori in cui le eccezioni sono frequenti. Una procedura standard può essere documentata con relativa facilità. Molto più difficile è descrivere tutte le circostanze in cui la procedura deve essere adattata. Per questa ragione, prima di automatizzare, conviene chiedere alle persone esperte non soltanto che cosa fanno, ma che cosa guardano per capire quando qualcosa non va.

Primo livello: il sistema sa eseguire il compito?

La valutazione di un progetto comincia inevitabilmente dalla capacità di eseguire un’attività. Se vogliamo automatizzare la lettura delle fatture, il sistema deve individuare correttamente fornitore, numero del documento, data, imponibile e altri campi necessari. Se vogliamo preparare risposte ai clienti, deve utilizzare informazioni aggiornate e rispettare le condizioni effettive dell’azienda.

Per verificare questa capacità servono prove rappresentative del lavoro reale. Una dimostrazione costruita su tre documenti perfetti dice poco su ciò che accadrà quando arriveranno file scannerizzati male, email incomplete o richieste formulate in modo insolito. Conviene raccogliere esempi diversi e sapere in anticipo qual è il risultato corretto per ciascuno.

Prendiamo un ufficio acquisti che deve confrontare le conferme d’ordine con quanto era stato concordato. Un sistema può leggere i documenti e mettere in evidenza differenze di quantità, prezzo o data di consegna. Per capire se funziona bisogna provarlo su conferme normali e su casi problematici: un articolo sostituito con un equivalente, un prezzo in una valuta differente, un costo di trasporto aggiunto successivamente, una consegna divisa in più spedizioni.

La verifica deve includere anche ciò che il sistema fa quando non possiede abbastanza informazioni. Un buon programma può segnare una richiesta come incompleta e chiedere l’intervento di una persona. Un programma che inventa un valore per riempire un campo mancante rischia invece di creare errori difficili da identificare, soprattutto se la schermata finale appare ordinata.

Non esiste una percentuale universale che renda accettabile ogni automazione. Un errore nella classificazione di una comunicazione interna può essere recuperabile; un errore che modifica dati bancari o determina una decisione su una persona ha conseguenze molto diverse. La precisione richiesta deve essere definita in relazione al compito, al danno potenziale e alla possibilità di correggere ciò che è stato fatto.

Secondo livello: qualcuno sa controllare il risultato?

Una volta stabilito che il sistema è capace di eseguire il compito, bisogna progettare il controllo. Dire che una persona rimane nel processo è insufficiente se non si spiega cosa deve controllare e quali strumenti possiede per farlo.

Immaginiamo che un assistente AI prepari una dichiarazione di dati da inserire in una pratica fiscale. Il professionista che la esamina deve poter vedere i documenti utilizzati, i campi estratti e le eventuali incoerenze. Se riceve soltanto un testo finale dall’aspetto impeccabile, il controllo potrebbe trasformarsi in una firma formale. La responsabilità resta umana, ma mancano gli elementi necessari per esercitarla concretamente.

Per ogni automazione significativa conviene quindi definire una procedura di supervisione. La persona incaricata deve sapere da quali fonti proviene il risultato, quali controlli automatici sono già stati eseguiti e quali verifiche richiedono esperienza professionale. Deve poter correggere il sistema, respingere un risultato e bloccare l’operazione quando incontra un caso dubbio.

La capacità di contestare un risultato è importante soprattutto quando l’AI presenta risposte persuasive. Un modello linguistico può formulare una spiegazione credibile anche se non ha interpretato correttamente un documento. La scorrevolezza del linguaggio non dimostra che il contenuto sia esatto. Per questo, negli usi documentali, è utile riportare la fonte consultata e consentire a chi controlla di aprirla immediatamente.

Anche i controlli dovrebbero essere verificati periodicamente. Se un collaboratore approva automaticamente ogni proposta perché il sistema ha sbagliato poco nei primi mesi, la supervisione rischia di perdere efficacia. È opportuno esaminare campioni di casi, confrontare gli errori rilevati e ascoltare chi utilizza il programma. Quando un controllo non intercetta più le anomalie, va riprogettato prima che diventi una formalità.

Terzo livello: l’azienda può cambiare il sistema?

Questo è il livello che considero più trascurato. Un programma può funzionare bene ed essere controllato correttamente, ma l’azienda potrebbe trovarsi in difficoltà se volesse modificarlo, sostituire il fornitore o trasferire il processo su un’infrastruttura diversa.

Il problema appare spesso quando un’automazione è stata sviluppata da un soggetto esterno senza consegnare una documentazione completa. Il fornitore conosce le regole, le integrazioni, le eccezioni e le configurazioni. Il cliente sa che premendo un pulsante ottiene un risultato, ma non conosce più il percorso necessario per produrlo. Nel tempo quella dipendenza può diventare rilevante, anche in assenza di conflitti commerciali.

Per prevenirla, l’azienda dovrebbe conservare una descrizione comprensibile del processo, indipendente dal software utilizzato. Il documento dovrebbe indicare quali informazioni entrano, quali regole vengono applicate, quali sistemi vengono consultati, quali persone possono approvare e quali risultati vengono registrati. Non serve trasformare ogni imprenditore in un programmatore; serve rendere leggibile ciò che l’impresa ha deciso di automatizzare.

Poi occorre chiarire gli aspetti contrattuali. Chi possiede i dati e in quale formato possono essere esportati? Chi conserva le configurazioni? Quali documenti vengono consegnati al cliente? È possibile trasferire l’automazione a un altro fornitore? Quanto dipende da componenti proprietarie che non possono essere sostituite facilmente? Sono domande che hanno un impatto economico e organizzativo preciso.

Anche la continuità operativa fa parte del terzo livello. Se un servizio esterno è temporaneamente indisponibile, quali attività devono fermarsi e quali possono proseguire? Esiste una procedura manuale per i casi urgenti? Chi è capace di attivarla? Il piano non deve necessariamente replicare per intero il vecchio processo, ma deve permettere di gestire almeno le attività più importanti durante un’interruzione.

L’effetto dell’automazione sulla formazione dei nuovi colleghi

La perdita di competenze può essere lenta e poco visibile. Prima di introdurre un nuovo sistema, un collaboratore junior impara svolgendo operazioni semplici sotto la guida di una persona esperta. Con il tempo riconosce le eccezioni, capisce il significato delle informazioni e acquisisce un criterio professionale. Se le attività di base scompaiono completamente, bisogna trovare un altro modo per costruire quella comprensione.

Pensa a una persona appena assunta in un ufficio amministrativo. Se il suo compito consiste soltanto nel verificare che il programma abbia inserito la spunta verde, difficilmente imparerà a riconoscere una fattura incoerente. Per formarla occorre mostrare quali documenti vengono confrontati, perché alcuni errori contano più di altri e come si arriva alla decisione finale.

Una soluzione pratica consiste nel dedicare parte dell’inserimento iniziale al lavoro su casi reali già conclusi e corretti. Il nuovo collega può confrontare il documento di partenza con il risultato dell’automazione, identificare le anomalie e discutere con un tutor i motivi delle correzioni. In questo modo apprende il ragionamento senza dover ripetere ogni giorno tutte le operazioni manuali.

Si possono inoltre programmare esercitazioni sulle eccezioni. Per esempio, un ufficio ordini può conservare alcuni casi in cui un codice articolo era ambiguo, un cliente aveva richiesto una consegna particolare o un indirizzo non era valido. Il personale nuovo prova a capire come avrebbe gestito la situazione e confronta la propria decisione con quella presa dall’azienda. È un esercizio molto più educativo di una semplice presentazione delle funzionalità del software.

Il ruolo delle persone esperte cambia. Possono impiegare meno tempo nella produzione ripetitiva e più tempo nella formazione, nella revisione delle regole e nell’analisi dei casi difficili. Questo spostamento non avviene automaticamente: richiede che la direzione riconosca queste attività come parte del lavoro, assegnando tempo e responsabilità.

Documentare le eccezioni prima di automatizzarle

Nelle piccole e medie imprese gran parte del funzionamento reale è conservata nella memoria dei collaboratori. Una procedura ufficiale può spiegare come registrare un ordine, ma non menzionare che un certo cliente usa un codice interno diverso da quello del catalogo. Un manuale può indicare come rispondere a un reclamo, ma non riportare gli accordi particolari assunti con alcuni distributori.

Quando si analizza un processo conviene quindi osservare il lavoro insieme a chi lo svolge e chiedere che cosa succede quando un passaggio non va come previsto. Quali casi vengono fermati? A chi si telefona? Quali informazioni si devono cercare? Quali eccezioni sono state introdotte per evitare un errore già avvenuto? Ogni risposta può rivelare una regola che non compariva nel progetto iniziale.

La documentazione non deve essere un elenco infinito di casistiche scollegate. Può essere organizzata come una guida operativa con la procedura standard, i segnali che indicano un’eccezione e le persone autorizzate a decidere. Nei sistemi più complessi si possono aggiungere esempi commentati e riferimenti ai documenti da consultare.

Questo lavoro è utile anche se alla fine si decide di non impiegare l’intelligenza artificiale. Spesso basta rendere esplicite le regole per eliminare passaggi inutili e correggere incongruenze che erano state accettate per abitudine. Una buona analisi del processo produce quindi valore prima della scelta dello strumento.

Naturalmente le eccezioni cambiano nel tempo. Se un nuovo cliente impone una procedura particolare, qualcuno deve valutarla e decidere se inserirla nelle istruzioni dell’automazione. Senza un responsabile degli aggiornamenti, anche un sistema inizialmente ben progettato tende a restare ancorato alle regole del giorno in cui è stato installato.

Chi deve essere proprietario del processo

In un progetto di AI è utile distinguere il responsabile del software dal responsabile del processo. Il primo si occupa della disponibilità tecnica, degli accessi, degli aggiornamenti e delle integrazioni. Il secondo conosce l’obiettivo dell’attività, decide quali risultati sono corretti e stabilisce come gestire le eccezioni. Nelle imprese più piccole queste responsabilità possono essere affidate a poche persone, ma devono comunque essere chiare.

Un software che prepara solleciti di pagamento, per esempio, può essere amministrato da un fornitore informatico. La decisione su quando inviare un sollecito, quale tono utilizzare e quali clienti escludere dovrebbe però restare nelle mani di chi governa il credito e conosce gli accordi commerciali. Se cambia la politica aziendale, il responsabile deve poter aggiornare le regole senza dover ricostruire tutto da zero.

Allo stesso modo un sistema che supporta la gestione del personale non dovrebbe prendere decisioni importanti in assenza di regole e controlli adeguati. I processi che incidono sui diritti e sulle opportunità delle persone possono richiedere valutazioni normative specifiche. Il fatto che un algoritmo sia disponibile sul mercato non significa che possa essere utilizzato per qualsiasi scopo o che il suo impiego trasferisca la responsabilità al fornitore.

Per rendere effettiva la responsabilità, l’azienda può creare un registro sintetico delle automazioni. Per ogni processo si indica chi ne è responsabile, quale risultato deve produrre, quali dati utilizza, chi può approvare le azioni e come segnalare un errore. Un documento di poche righe, aggiornato realmente, è più utile di una procedura lunga che nessuno consulta.

È importante anche stabilire chi può fermare il sistema. Se un’automazione modifica dati aziendali, una persona deve avere la possibilità tecnica e organizzativa di sospenderla quando produce risultati inattesi. Il blocco dovrebbe essere provato, non soltanto promesso nella documentazione del fornitore.

Che cosa succede quando cambia il fornitore

Una buona domanda da fare durante la progettazione è questa: se tra due anni decidessimo di utilizzare un altro software, quali informazioni dovremmo consegnare al nuovo fornitore perché possa ricostruire il processo? Se la risposta è «dovrebbe parlare soltanto con chi ha sviluppato il programma attuale», esiste una dipendenza da affrontare.

Cosa consegnare a un nuovo fornitore per ricostruire il processo. Mappa del processo: Quali informazioni entrano, quali sistemi vengono consultati, chi può approvare. Regole approvate: Quelle che l’azienda ha deciso di far applicare al sistema. Dati e integrazioni: Dove sono i dati, in quale formato si esportano, con quali programmi comunicano. Autorizzazioni: Chi può correggere un risultato, aggiornare una regola o sospendere il sistema. Casi corretti: Esempi di risultati giusti, per ricostruire il processo e valutare alternative. Se la risposta è «deve parlare con chi ha sviluppato il programma»,. esiste una dipendenza da affrontare.

L’impresa dovrebbe essere in grado di consegnare almeno la mappa del processo, le regole approvate, la descrizione dei dati e delle integrazioni, le autorizzazioni e gli esempi di casi corretti. Le specifiche tecniche più dettagliate possono richiedere competenze specialistiche, ma i requisiti di business devono essere comprensibili a chi guida il reparto.

Questo non significa pretendere che tutti i software siano intercambiabili senza costi. Ogni migrazione richiede lavoro. Significa evitare che nessuno, al di fuori del fornitore originale, sappia più spiegare che cosa l’azienda sta pagando e perché. Una documentazione ben mantenuta può ridurre il tempo necessario per valutare alternative e negoziare condizioni.

La libertà di scelta dipende anche dai dati. Se lo storico delle operazioni è custodito in un formato proprietario difficile da esportare, sostituire il software può diventare oneroso. Per questo l’azienda dovrebbe chiedere come ottenere i propri dati, quali limiti esistono e che cosa accade alla fine del rapporto contrattuale. Sono aspetti da affrontare prima di affidare al sistema processi importanti.

In alcuni casi è sensato scegliere una soluzione proprietaria perché offre funzionalità particolarmente efficaci. L’importante è conoscere il costo di quella scelta e predisporre un piano ragionevole per i dati, la continuità operativa e la formazione interna. Una dipendenza consapevole e gestita è diversa da una dipendenza scoperta quando non esistono più alternative immediate.

Come misurare se l’automazione rende l’azienda più capace

Le ore recuperate sono un indicatore utile, ma non raccontano tutto. Se un sistema riduce i tempi di compilazione delle pratiche, l’azienda dovrebbe osservare anche quanti errori vengono intercettati, quante eccezioni sono gestite correttamente e quanto tempo serve per formare una persona nuova. Il risparmio apparente può diminuire se crescono le correzioni o se i casi difficili si accumulano senza un responsabile.

Si può cominciare da una fotografia iniziale. Prima dell’automazione si annotano le attività svolte, il tempo impiegato, i controlli e gli errori più frequenti. Durante la prova si registrano i risultati del sistema e il lavoro umano necessario per verificarli. Quando si confrontano le due situazioni bisogna includere il tempo di supervisione e di gestione delle anomalie, evitando di considerare ogni minuto non più dedicato all’esecuzione come un beneficio già acquisito.

Accanto ai numeri è utile verificare la competenza delle persone. Il responsabile sa spiegare come funziona il processo? I nuovi colleghi riconoscono gli errori più importanti? Esiste una guida aggiornata per i casi eccezionali? Se un programma è indisponibile, il reparto sa come continuare le attività essenziali? Queste verifiche richiedono tempo, ma mostrano se l’azienda rimane in grado di governare il proprio lavoro.

Non è necessario effettuare ogni mese una simulazione completa di guasto. Si possono organizzare controlli periodici proporzionati alla criticità del processo. Per un sistema che classifica messaggi interni può bastare una revisione dei risultati. Per un’automazione che interviene su ordini, pagamenti o informazioni riservate possono servire verifiche più rigorose e responsabilità formalizzate.

Il miglioramento si vede quando la tecnologia funziona e le persone acquisiscono capacità nuove: leggere le anomalie, valutare i risultati, aggiornare regole, progettare controlli e comprendere l’intero flusso. Il numero di passaggi manuali può diminuire, mentre la qualità del governo del processo aumenta.

Cinque decisioni da prendere prima dell’avvio

Prima di automatizzare un’attività importante, consiglierei di prendere alcune decisioni in una riunione che coinvolga il responsabile del processo, le persone esperte e chi seguirà la parte tecnica. La prima consiste nel descrivere il compito in modo preciso. «Automatizzare l’amministrazione» è un obiettivo troppo generico; «estrarre i dati delle fatture ricevute e prepararli per il controllo» consente invece di definire confini e verifiche.

La seconda decisione riguarda gli interventi umani. Bisogna stabilire quali risultati possono essere soltanto proposti dal sistema, quali richiedono un’approvazione e quali attività possono essere eseguite in autonomia entro limiti ben definiti. I limiti dovrebbero dipendere dalle conseguenze dell’azione, non soltanto da quanto il programma sembra capace durante una dimostrazione.

La terza riguarda chi può contestare il sistema. Occorre indicare le persone autorizzate a correggere un risultato, aggiornare una regola e sospendere l’automazione. Senza questo potere, il controllo umano rischia di restare una dichiarazione senza effetti pratici.

La quarta decisione riguarda la conoscenza da conservare. È opportuno stabilire quali procedure, eccezioni e criteri debbano essere documentati e come verranno trasmessi ai nuovi colleghi. La formazione deve spiegare il processo, oltre alla schermata da utilizzare.

La quinta riguarda la possibilità di cambiare. Prima dell’avvio bisogna sapere dove rimangono i dati, chi custodisce la documentazione, come si esportano le informazioni e che cosa accade se il programma o il fornitore non sono più disponibili. Queste verifiche rendono l’automazione meno fragile.

Cinque decisioni prima di avviare un’automazione. Descrivere il compito: «Estrarre i dati delle fatture ricevute e prepararli per il controllo», non «automatizzare l’amministrazione». Stabilire gli interventi umani: Cosa il sistema può solo proporre, cosa richiede approvazione, cosa può fare da solo entro limiti definiti. Decidere chi può contestare il sistema: Chi può correggere un risultato, aggiornare una regola e sospendere l’automazione. Conservare la conoscenza: Quali procedure, eccezioni e criteri vanno documentati e trasmessi ai nuovi colleghi. Prevedere la possibilità di cambiare: Dove restano i dati, come si esportano e cosa succede se il fornitore non è più disponibile. Il controllo umano ha effetti pratici. solo se qualcuno ha il potere di fermare e correggere.

Un esercizio utile per una PMI

Se nella tua azienda esiste già un’automazione importante, puoi verificare oggi stesso il livello di dipendenza. Scegli un’attività precisa, per esempio la registrazione degli ordini o la preparazione delle offerte. Chiedi al responsabile di raccontare come funziona il lavoro dall’arrivo della richiesta fino al risultato finale, compresi i controlli che il software esegue.

Poi chiedi a una seconda persona, possibilmente non coinvolta nello sviluppo, di leggere la documentazione disponibile e spiegare quali passaggi sono automatici e quali richiedono un intervento umano. Se la descrizione è diversa da quella del responsabile, avete già individuato un’area su cui lavorare. Non serve aspettare un incidente per accorgersi che la conoscenza è concentrata in poche persone.

Un secondo esercizio consiste nel seguire un caso eccezionale. Prendete un ordine che ha richiesto una modifica manuale e ricostruite perché il sistema non poteva gestirlo automaticamente. Da quali informazioni dipendeva la decisione? Dove erano conservate? Chi conosceva la regola? Quello che emerge può diventare una scheda utile per i colleghi e, se appropriato, un miglioramento dell’automazione.

Infine immagina di dover cambiare fornitore. Non devi farlo davvero: prova a preparare l’elenco dei documenti e dei dati che dovresti consegnare. Se mancano le procedure, le specifiche o l’accesso allo storico, affronta il problema insieme al fornitore attuale. È quasi sempre più semplice farlo mentre il rapporto funziona che durante una situazione di urgenza.

L’automazione deve lasciare all’azienda la possibilità di decidere

L’intelligenza artificiale può ridurre attività ripetitive e rendere più efficace il lavoro di un reparto. Può aiutare persone esperte a concentrarsi sui casi difficili, migliorare l’accesso alle informazioni e offrire ai nuovi colleghi strumenti di supporto. Per ottenere questi benefici in modo duraturo serve però qualcosa di più di un programma che esegue correttamente una sequenza.

Le aziende devono conservare la capacità di comprendere il processo, giudicare i risultati e modificare le regole. Questa competenza non vive necessariamente nelle stesse attività manuali di prima. Può spostarsi verso la supervisione, la formazione, la gestione delle eccezioni e il disegno dei flussi di lavoro. È responsabilità della direzione creare le condizioni perché questo passaggio avvenga.

Un reparto che utilizza l’AI e sa spiegare come lavora rimane capace di migliorarsi. Un reparto che dipende interamente da risposte automatiche che nessuno sa verificare può sembrare efficiente fino al giorno in cui incontra una situazione diversa dal solito. La differenza si costruisce prima dell’avvio, attraverso la documentazione, la distribuzione delle responsabilità e la cura delle competenze interne.

Per questo, quando valuto un progetto di automazione, considero essenziale guardare a tre livelli: che il sistema sappia eseguire il compito, che le persone sappiano controllarlo e che l’azienda sia in grado di modificarlo o sostituirlo. L’obiettivo è fare in modo che la tecnologia aumenti la capacità dell’organizzazione di lavorare bene e di scegliere autonomamente come evolvere.