Qual è il primo pezzo nel puzzle dell’automazione? E l’ultimo?

Un altro abuso del linguaggio è l’affettazione dell’oscurità, ottenuta o applicando parole vecchie a significati nuovi e inconsueti o introducendo termini nuovi ed ambigui senza definirli oppure mettendoli assieme in tal modo da confondere il loro significato ordinario.
John Locke

I VAR

PuzzleGli LSP sono tipici intermediari la cui missione aziendale è quello che chiamano pomposamente “project management”, ma che ha poco o nulla in comune con il vera project management, trattandosi al più di coordinamento delle attività. Se fosse davvero project management, la maggior parte degli LSP si atterrebbe alla ISO 21500:2012, assumendo solo PMP per coprire le posizioni di project manager. Non ce ne sono? Ma dai!

In ogni caso, questa funzione di coordinamento dovrebbe aggiungere valore alla traduzione, pur aumentandone significativamente il costo. Dovrebbe anche agevolare i processi, mentre spesso crea colli di bottiglia e intasamenti, conflitti e controversie, soprattutto tra i membri del team, tipicamente freelancer.

In effetti, un’azienda esternalizza essenzialmente per non dover affrontare compiti e problemi che preferisce non affrontare direttamente in quanto non rientrano nel proprio core business. Per la maggior parte delle aziende, soprattutto PMI, la traduzione non fa parte del proprio core business, e la sua necessità si presenta solo in circostanze periodiche, ma isolate. Per queste aziende, l’outsourcing permette maggiore flessibilità di bilancio e maggiore controllo, consentendo loro di pagare i servizi e le funzioni aziendali di cui hanno bisogno, quando ne hanno bisogno, riducendo al contempo le spese in conto capitale e di esercizio e i rischi.

Per questo, affidando ad altri i progetti di traduzione, le aziende possono evitare di doversi far carico di ulteriore personale, del suo reclutamento, della sua produttività della formazione e del suo collocamento in un percorso di crescita. Hanno solo bisogno di qualcuno che controlli le milestone e prenda decisioni per gli incarichi in outsourcing. Questo vale soprattutto quando si ha a che fare con progetti multilingue e serve scalabilità, dal momento che la localizzazione segue un tipico percorso di crescita esponenziale, e l’introduzione di una nuova lingua raddoppia la complessità del progetto.

La gestione progetti a luci spente

Lights out manufacturingProprio come l’intero settore fa da tempo con il project management, aiutato da “consulenti” compiacenti, alcuni di questi adesso hanno avviato un processo di distorsione e manipolazione dell’espressione “lights-out” e farne qualcosa di completamente diverso dall’originale.

Con “lights-out” si intende infatti una metodologia di produzione che prevede la piena automazione, cioè l’assenza di personale in loco. Il concetto si applica alle fabbriche tra l’ingresso delle materie prime e l’uscita dei prodotti finiti non c’è praticamente alcun intervento umano, e sono così in grado di funzionare “a luci spente”. Le aziende che implementano la metodologia “lights-out” impiegano solo robot, e lasciano ai lavoratori compiti come l’assicurazione qualità. Assicurazione, non controllo. È ancora necessario sottolineare questa distinzione? Purtroppo sì, almeno nell’industria della traduzione.

Anche se oggi molte fabbriche sono in grado di produrre “a luci spente”, sono ancora poche quelle che funzionano esclusivamente così.

Usare i dati storici e il machine learning per analizzare i contenuti e assegnare automaticamente gli incarichi non significa gestire i progetti di traduzione (qualunque cosa si intenda) “a luci spente”. Piuttosto potrebbe essere un modo di migliorare la gestione fornitori, che è o dovrebbe essere preliminare alla gestione progetti, ma non tocca le altre attività.

Qui entra in gioco la narrazione tipica dell’industria della traduzione, secondo cui il project management è l’essenza di un LSP, la fonte del valore aggiunto al servizio di base offerto dai freelancer che svolgono il lavoro. Essendo gli LSP fortemente dipendenti dai freelancer dato che esternalizzano tutti o gran parte degli incarichi che ricevono dai clienti, dovrebbero avere un nutrito archivio fornitori da cui attingere, se necessario. Questo archivio dovrebbero curarlo in modo quasi ossessivo, mantenendo sempre aggiornate tutte le informazioni relative a ciascun fornitore e verificandone costantemente l’affidabilità. Quest’attività, però, non è in capo a un project manager, peraltro di solito già sovraccarico. Questi, semmai, dovrebbe fornire ai vendor manager le informazioni raccolte post mortem per aggiornare l’archivio fornitori. Sono queste informazioni a costituire i dati storici con cui si dovrebbero alimentare le applicazioni di apprendimento automatico. Purtroppo, siamo ancora lontani dall’avere uno standard per questo tipo di dati. D’altronde, la serie di opportunità perse è lunghissima; la più recente ha prodotto uno spreco di tempo e risorse per lo sviluppo di un’“API universale” che sarà probabilmente dimenticata molto presto, mentre si sarebbe potuto definire un modello per i dati di progetto (vi dice niente TAPICC?). Ma questa è un’altra storia.

Come la gestione dei fornitori, anche i compiti amministrativi come la gestione della fatturazione e dei pagamenti non riguardano la gestione progetti, e l’automazione dei cosiddetti debiti commerciali, debiti verso fornitori, debiti a breve, riscontri o conti passivi che dir si voglia può essere di grande aiuto.

Per tutto questo, è necessario un TMS completo, che potrebbe gestire tutti i compiti attualmente assegnati agli essere umani e rendere il servizio disponibile automaticamente ai clienti.

Se la gestione progetti “a luci spente” fosse qualcosa di più di un’espressione ganza da usare agli eventi di settore, in articoli e rapporti fumosi e vacui, o nelle chiacchiere da bar con i colleghi per darsi un tono, e costituisse invece anche solo una vaga, remota, ma effettiva possibilità, saremmo già sulla strada della completa disintermediazione, mentre ne siamo ancora molto lontani.

Automazione della contabilità fornitori

Quentin Metsys, The MoneylendersLa fatturazione elettronica rientra a buon diritto nell’automazione dei processi, e praticamente qualsiasi TMS ha un modulo per essa, mentre apparentemente nessun TMS prevede un modulo di automazione della contabilità fornitori (Accounts Payable, AP).

La gestione dei debiti verso fornitori è importante quanto la gestione dei crediti commerciali. Pagamenti lenti o ritardati possono avere un impatto sul flusso di cassa e sulla credibilità di un’azienda. Inoltre, la lavorazione manuale delle fatture presenta costi significativi.

Rispetto alla gestione manuale, l’automazione della contabilità fornitori può aiutare a ridurre drasticamente i costi di lavorazione delle fatture (oltre il cinquanta per cento), eliminando al contempo gli errori, assicurando conformità e garantendo dati tempestivi e accurati per i bilanci.

Il software di automazione della contabilità fornitori estrae i dati delle fatture e li inserisce nel sistema, quindi elabora i dati della contabilità fornitori, il tutto in maniera centralizzata.

L’automazione della contabilità fornitori permette di elaborare le fatture dei fornitori senza alcun intervento umano fino ai bonifici, andando oltre il tipico “si paghi” una volta che le fatture ricevute sono state elaborate.

Ovviamente, un sistema di automazione della contabilità fornitori costa. Tuttavia, ora ci sono soluzioni SaaS che permettono di mantenere i costi di implementazione e di esercizio a livelli estremamente bassi, con prezzi di partenza a partire da 20 dollari al mese.

Eppure, nessun LSP sta di fatto adottando queste soluzioni, e la cattiva gestione della contabilità fornitori è alla base dei ritardi di pagamento, a meno che non siano parte di fantasiose strategie di finanziamento in cui i fornitori sono trattati al pari di un istituto di credito molto conveniente, e generano una percezione diffusa di inaffidabilità generale, non solo presso i fornitori.

L’illusione della blockchain

Just one more thingQuasi due anni dopo la pubblicazione in un white paper per TAUS, Bob Kuhns ha ripubblicato le sue riflessioni sulla blockchain nell’industria della traduzione nel blog di Kirti Vashee.

Premesso che il semplice reiterare un argomento non lo rende di per sé più valido, fin qui non c’è stato caso d’uso da cui emerga il potenziale della blockchain per la traduzione. I sostenitori insistono sulla capacità della blockchain di risolvere una lunga serie di problemi come la mancanza di trasparenza, di responsabilità, di verificabilità dell’identità e di controllo dei dati, ma non spiegano come. Forse perché non possono.

Per esempio, il modello che propone Bob Kuhns per garantire rapporti stabili, affidabili e sicuri tra clienti e traduttori e ridurre il ruolo degli intermediari è solo un abbozzo.

Infatti, per passare da potenziale a fattibile, è necessario qualcosa di più di un elenco di quello che una blockchain permettere di fare, in una prospettiva puramente teorica. Per esempio, come si dovrebbe implementare una blockchain in un TMS? E per fare cosa esattamente? Come? Quali problemi risolverebbero gli smart contract? In che modo questi smart contract sono meglio delle attuali modalità di gestione di un’attività di traduzione e delle tecnologie a supporto?

Inoltre, esistono casi d’uso anche solo lontanamente legati alla traduzione? Tutte le attuali, rare implementazioni di blockchain al di fuori dell’ambito delle criptovalute sono piuttosto costose e sono riferibili quasi esclusivamente a società che possono permettersi di investire (anche al buio) in tecnologie complesse, magari con l’aiuto di qualche costosa società di consulenza. Vi sorprenderebbe sapere che IBM è la prima azienda nello sviluppo di blockchain?

Tracciare costantemente un container e il suo contenuto è molto più complicato e costoso che gestire un progetto di traduzione/localizzazione, per quanto grande sia, e comunque sporadico. Una blockchain non sarebbe un tantinello eccessiva, se non altro dal punto di vista finanziario? Non sarebbe come usare missili scud contro i passeri?

Nel suo post, Bob Kuhns non offre concreta dimostrazione dei benefici che una blockchain porterebbe ai traduttori, o di come possa ottimizzare il flusso di lavoro, tant’è che tutte le domande fondamentali poste in precedenza nello stesso spazio sulla blockchain nell’industria della traduzione sono rimaste senza risposta.

Inoltre, come ammette lo stesso Bob Kuhns, gli ostacoli tecnici sono enormi, e l’industria della traduzione è notoriamente a disagio con il cambiamento, specialmente se implica ostacoli tecnici, non necessariamente enormi. E se è vero che i costi di esercizio degli LSP pesano sui costi di prodotto finali, forse ci sono tecnologie meno costose e facilmente disponibili che potrebbero aiutare a risolvere questo problema. Vedi sopra.

Infine, citando sempre lo stesso Bob Kuhns, nonostante tutto il clamore e le previsioni, le blockchain sono ancora ai primordi e il loro futuro è incerto.

A questo punto, si sarebbe un’altra domanda oltre le dieci domande ricordate prima: qual è il costo dello sviluppo di un’applicazione a blockchain?

Ci sono diverse piattaforme per lo sviluppo di blockchain, quali Ethereum, HyperLedger Fabric o Hydrachain, ma la spesa più importante riguarda gli sviluppatori, poiché la natura altamente specializzata della blockchain richiede persone altamente qualificate.

Quindi, la costruzione di un’applicazione a blockchain richiede un investimento considerevole, sostanzialmente più grande dello sviluppo di applicazioni “normali”. In generale, il progetto di una blockchain può costare da 20.000 dollari per una blockchain pubblica a oltre 125.000 dollari per una blockchain privata. Il progetto di una blockchain pubblica potrebbe costare meno perché non è necessario costruire da zero la relativa piattaforma.

Quanti sono gli LSP che potrebbero permettersi un tale investimento? Magari, alcuni volenterosi LSP potrebbero costituire un consorzio, magari attraverso un organismo di categoria, a cui affidare lo sviluppo di una blockchain pubblica che poi potrebbe diventare una piattaforma comune. Tuttavia, visto l’esito del TAPICC, è realistica un’ipotesi del genere?

Quindi, la risposta alla domanda di Kirti Vashee se la blockchain nella traduzione è davvero possibile o se è solo una chimera che non si materializzerà mai non può che essere “no, sono solo chiacchiere”. E se ci si chiedesse quali potrebbero essere gli effetti di una blockchain, la risposta è che difficilmente risolverebbe anche solo uno dei problemi cronici del settore, per non parlare della possibilità di favorire lo sviluppo di nuove capacità.

Conclusioni

Non è sbagliato cercare di immaginare il futuro, né è sbagliato cercare di farlo con la tecnologia disponibile. Tuttavia, perché questo sforzo non sia un esercizio sterile e fine a sé stesso, è necessario entrare nello specifico e con onestà, senza manipolazioni linguistiche che servano per apparire brillanti pur avendo poche o nessuna idea. Quindi, è necessario presentare casi d’uso reali o almeno realistici e coerenti con una visione.