Il barbaro

In evidenza

Il barbaro

Barbaro è una parola onomatopeica di origine greca (βάρβαρος, balbuzienti), con cui i greci indicavano gli stranieri per via dei versi inintelligibili e addirittura animaleschi dovuti all’incertezza che manifestavano nell’uso del greco che, di conseguenza, impediva loro di condividere la cultura greca.

I greci, infatti, si consideravano un’unica entità culturale proprio in virtù della lingua condivisa.

Nella Roma repubblicana e imperiale, “barbarus” assunse un significato etnico e ideologico nei confronti degli stranieri col quale si manifestava anche il disprezzo per la mancanza di un sistema di scrittura e di leggi codificate, cui si accompagnava un fermo e testardo rifiuto dell’ordine romano, simboleggiato dal sistema legislativo.

Quando Augusto lo relegò nella lontana Tomi, oggi Costanza, nell’attuale Romania, allora un piccolo centro della Tracia sul mar Nero, Ovidio scrisse nei Tristia, “Barbarus hic ego sum quia non intelligor illis” (qui sono io il barbaro, perché loro non mi capiscono).

Le analisi, le valutazioni e le opinioni riportate in questo blog sono spesso controcorrente e hanno più volte guadagnato al suo autore l’appellativo di “barbaro”.

I libri del barbaro

La redazione dei documenti tecnici Taccuino barbaro A Contrarian's View on Translation Standards

* Facendone richiesta a info@s-quid.it, a coloro che acquisteranno una copia del “Taccuino barbaro” sarà inviata la password di apertura dell’ebook con i post pubblicati sul vecchio blog tra la fine del 2011 e l’inizio del 2012. § Anche in formato eBook.

L’occasione persa dei TMS

Gli operatori della traduzione, indipendentemente dalla loro posizione nel settore o in azienda, sono generalmente più reattivi che proattivi. Gli ultimi sviluppi sul fronte finanziario (Moravia, ULG, LIOX) sono un’ulteriore conferma di questo atteggiamento, sebbene la storia recente del settore non abbia bisogno di interpreti per chiunque avesse voglia di leggerla.

Il risultato di questa reattività è la proattività dei “non addetti ai lavori” costretti a introdurre innovazioni in un settore diverso dal proprio core business a causa dell’incapacità dei loro partner commerciali e, quindi, a trainare il settore che finisce così con l’essere governato dai clienti piuttosto che dagli operatori.

Mentre attività e processi produttivi sono pressoché gli stessi da secoli, ogni sviluppo tecnologico è il risultato di una richiesta, se non proprio di un’imposizione, dei clienti più facoltosi e tecnologicamente avanzati. Nella maggior parte dei casi, i progressi più significativi, e gli avanzamenti che ne sono seguiti, sono stati introdotti da questi clienti; i produttori dei vari strumenti hanno solo realizzato dei miglioramenti, raramente introducendo grandi novità. Per quasi trent’anni, l’idea di progresso nel settore della traduzione ha coinciso con il miglioramento di applicazioni basate su tecnologie consolidate e regolarmente spacciate per rivoluzionarie.

I sistemi di gestione per la traduzione (Translation Management System, TMS) sono emblematici in questo senso. I TMS dovrebbero essere l’equivalente dei sistemi per la gestione dei processi (Workflow Management System, WFMS), risalenti all’inizio degli anni novanta. Curiosamente, o forse no, i TMS mancano generalmente della maggior parte delle caratteristiche tipiche di un vero WFMS, di quelli che si possono trovare praticamente in tutte le aziende.

L’attuale CEO di Lionbridge Rory Cowan ha pensato di poter spiegare la quanto meno deludente esperienza borsistica dell’azienda di cui è alla guida da quasi vent’anni limitandosi a dire che “I mercati americani non amano proprio il settore della traduzione”.

Nessuna delle principali società di traduzione, però, si può definire campione d’innovazione, né è minimamente comparabile, da un punto di vista finanziario, tecnologico, organizzativo e operativo, ad altre aziende in altri settori, ancorché di dimensioni medio-piccole.

Un WFMS è di per sé una piattaforma per organizzare, gestire e automatizzare il più possibile una serie di attività che fanno parte di uno o più processi, alcune delle quali possono richiedere l’intervento umano, come lo sviluppo di un contenuto e/o la sua approvazione. Inoltre, il sistema deve permettere agli utenti di definire nuove attività e/o descrivere nuovi processi, e di solito prevede un modulo per modellare graficamente applicazioni di workflow.

Un WFMS deve altresì permettere agli utenti di definire workflow diversi per attività o processi diversi, associare un utente o un gruppo a una specifica attività in ogni fase del processo e stabilire delle dipendenze per la sua gestione, dal livello più alto al più basso.

Un WFMS dovrebbe anche costituire una piattaforma middleware che permetta l’integrazione delle applicazioni.

Infine, un WFMS dovrebbe prevedere anche un modulo di project management per pianificare, organizzare e gestire stime e programmi, costi e risorse, oltre a uno per la collaborazione, la comunicazione, la gestione della qualità e l’amministrazione.

Analogamente, un TMS dovrebbe mettere in condizione una società di traduzione e i suoi clienti di controllare i progetti e monitorare ogni attività secondo un processo.

Un TMS dovrebbe quindi permettere di automatizzare il processo di traduzione, almeno per la maggior parte, massimizzandone l’efficienza, lasciando al software le attività non essenziali e ripetibili.

Tuttavia, anche i TMS più dichiaratamente all’avanguardia non forniscono che alcune funzioni gestionali di base.

Il fatto è che, nel settore della traduzione, non è possibile mettere d’accordo due persone su quale sia la parte creativa del processo, ovvero quella che non si può lasciare alle macchine, per non parlare delle caratteristiche qualificanti che dovrebbero nobilitare la professione.

Quindi, contrariamente a quanto accade in quasi ogni altro tipo di attività, non esiste ancora TMS un con tutte le caratteristiche descritte sopra. In particolare, mancano tutti di un’applicazione per modellare graficamente i processi. Solo uno o due offrono qualche funzione di base.

Quindi, scordatevi di Leibnitz*.

In effetti, gli operatori del settore sono molto raramente in grado di padroneggiare i linguaggi di modellazione e i diagrammi, anche semplici, come quelli di attività o di flusso, che servono a rappresentare graficamente i processi. Certo nascono per l’ingegneria del software, ma sono ormai da tempo di uso comune per descrivere visivamente processi e attività. Invece, gli operatori della cosiddetta industria della traduzione sono ancora, per la maggior parte, incapaci di concepire un processo appena più articolato del classico modello di intermediazione da agenzia.

Se questo non bastasse, il project management applicato alla traduzione non ha niente in comune con il vero project management e, infatti, i project manager di settore in possesso di una certificazione PMI si contano sulle dita di una mano.

La presunta, e a lungo vantata, peculiarità della traduzione, insieme al totale rifiuto di una visione autenticamente imprenditoriale, a dispetto dell’ossessione per le tariffe e le relative discussioni, è uno dei motivi per cui i TMS sono lontani dai WFMS e da qualunque altro sistema ERP.

Per consentire agli utenti di trovare sempre la soluzione migliore e le risorse più adatte nel minor tempo possibile, un TMS dovrebbe innanzitutto essere una piattaforma per la raccolta e la centralizzazione dei dati linguistici e operativi. Un TMS dovrebbe permettere agli utenti di fare a meno di intermediari, mettendo in condizione allo stesso tempo i project manager di selezionare le migliori risorse e pianificare e gestire al meglio le attività. Un TMS dovrebbe permettere anche di ottimizzare i processi e, di conseguenza, ridurre costi e tempi.

Ecco perché, il modello universale di processo adottato da tutti i TMS è quanto meno banale. I clienti, invece, dovrebbero essere in grado di modellare il loro workflow per poter controllare il livello di intervento umano necessario.

E pensare che l’impatto di un TMS potrebbe essere enorme se si potessero implementare processi più snelli e non seriali tali da consentire anche una vera collaborazione, ma, per le stesse ragioni per cui nessun TMS permette di modellare un processo, questa è ancora di là da venire.

Infine, quasi tutti i TMS hanno già migrato nel cloud; tuttavia, se anche permette di ridurre le spese in conto capitale e favorire la generale rapidità e facilità di gestione, il modello SaaS presenta alcuni gravi inconvenienti dovuti a minore flessibilità ed elevati costi di integrazione. Ovviamente, le caratteristiche offerte dai vari TMS dipendono dal livello di sofisticazione, ma la complessità tecnica dei più preclude l’adozione dei più avanzati dalla maggior parte degli LSPs e di molti clienti.

Insomma, i TMS potevano essere lo strumento giusto per modificare i rapporti di forza nel settore, ma alla fine sono solo l’ennesima occasione sprecata. Almeno fin qui.


* È indegno di uomini eccellenti perdere ore come schiavi faticando su calcoli che si potrebbero tranquillamente affidare a chicchessia se si usassero le macchine.