![[AIB]](/aib/wi/aiba10.gif)
|
AIB. Commissione nazionale biblioteche delle università e della ricerca |
EDI è l'acronimo di Electronic Data Interchange. Esistono numerose definizioni di EDI; in sostanza si tratta di una modalità di scambio elettronico di dati finalizzata alla trasmissione diretta di messaggi commerciali tra sistemi informativi, attraverso reti di telecomunicazione nazionali ed internazionale. L'EDI è dunque una sorta di lingua franca, e per questo motivo è stato paragonato da alcuni [1] alla funzione che per la società medioevale aveva il latino.
L'esigenza di sviluppare standard per le transazioni commerciali è nata negli anni '80 in ambito industriale, in particolare nel settore farmaceutico, automobilistico, bancario, dei trasporti, come soluzione alternativa all'utilizzo di metodologie proprietarie per l'invio di ordini e fatture. In questi ambienti i benefici di soluzioni automatizzate erano percepiti come altamente strategici, tanto che le organizzazioni più grandi esercitavano una pressione tale sui loro partner commerciali da costringerli ad adottare l'EDI per mantenere il ruolo di fornitori.
I primi formati EDI ad essere rilasciati furono X12, messo a punto dall'American National Standards Institute (ANSI) e TRADACOMS nel Regno Unito; soltanto in un secondo momento l'ONU [2] decise di impegnarsi nell'implementazione di un proprio formato: EDIFACT (EDI for Administration, Commerce and Trade). EDIFACT è stato quindi creato come standard internazionale e intersettoriale destinato ad affermarsi sugli altri formati; tuttavia l'esistenza di standard nazionali ne ha limitato la diffusione, e di fatto la sua adozione è a tutt'oggi a macchia di leopardo.
Poiché EDIFACT è stato rilasciato come formato generico, per ogni specifica applicazione ai diversi settori deve essere definito un subset specifico. EDItEUR è un organismo che promuove lo sviluppo del commercio elettronico nel settore librario; le attività di EDItEUR sono sponsorizzate da editori, fornitori librari, biblioteche e produttori di ILS. Tra i compiti di EDItEUR rientra anche la creazione e manutenzione di standard EDI per il commercio librario. In collaborazione con EDILIBE [3] ed EAN International, EDItEUR ha messo a punto un subset di EDIFACT specifico per il commercio librario. Le linee guida per l'implementazione di EDIFACT nel settore librario furono pubblicate da EDItEUR nel 1995; la prima ed ultima revisione risale al 1997. Da allora non vi sono stati nuovi sviluppi, ma solo adeguamenti in risposta a richieste degli utenti.
I benefici dell'EDI possono essere riassunti in 3 punti fondamentali:
EDI aumenta quindi la velocità e l'accuratezza delle transazioni commerciali, ed abbatte i costi di trasmissione ed elaborazione delle informazioni.
Le tipologie di messaggi previste da EDIFACT sono:
Un messaggio EDIFACT si presenta come un'unica linea, caratterizzata da numerosi segmenti racchiusi tra un'intestazione ed una coda, all'interno dei quali possono essere incapsulati molteplici messaggi. Nel messaggio sono racchiuse informazioni amministrative, contabili e bibliografiche.
Es. di messaggio Edifact scomposto su più linee per facilitare la lettura. In rosso sono evidenziati i dati riconoscibili (prezzo, Autore, Titolo, Editore):
Come si è detto, EDIFACT è fermo alla revisione del 1997, ma EDItEUR sta lavorando insieme con BIC [4] e BISAC [5] alla messa a punto del prossimo standard EDI, basato su XML: EDItX, che rispecchierà tutta la varietà di messaggi attualmente supportati da EDIFACT.
L'obiettivo di EDItEUR è quello di giungere alla definizione di uno standard EDI basato su XML prima che si affermino molteplici dialetti XML; si vuole evitare, dunque, che si ripeta quanto si è verificato in precedenza con EDIFACT. Del resto il rischio di dispersione, se si pensa al successo crescente che XML sta ottenuto in questi anni nel mondo delle biblioteche, appare molto elevato.
Probabilmente uno stimolo all'adozione di EDItX nel mondo delle biblioteche potrà venire dall'adozione di ILS di nuova generazione, basati su XML. Non sembra casuale che uno dei software di gestione per biblioteche più diffusi nel mondo, Aleph 500 di ExLibris, sponsor di EDItEUR, dalla ver. 16.02 gestisca l'output con XML. Gli stessi messaggi EDIFACT in uscita ed in entrata vengono convertiti in un formato XML intermedio. ExLibris ha quindi già inserito nel suo prodotto una funzionalità che crea una conversione tra EDIFACT e l'output XML di Aleph.
Al momento, tuttavia, le possibilità più concrete di adozione di EditX sembrano provenire da aziende impegnate nell'e-commerce librario (es. librerie online), dove peraltro è già in uso ONIX, uno standard per i metadati bibliografici basato proprio su XML.
Un confronto tra EDIFACT ed EDItX fornisce un quadro abbastanza preciso di come siano mutate, rispetto a meno di dieci anni fa, le risposte dei produttori di standard alle esigenze del mercato.
I messaggi EDIFACT sono contrassegnati da un'unica tipologia di formato, al quale fanno capo sottoinsiemi specifici per le differenti applicazioni (es. grande distribuzione, sistema bancario, commercio librario). I messaggi si presentano molto brevi ed altamente codificati, al fine di contenere i costi di trasmissione; il livello di compressione delle informazioni è tale da rendere molto difficoltosa la decifrazione "ad occhio nudo" dei dati bibliografici ed amministrativi. E' appurato che EDIFACT si propone come una soluzione con alti costi di implementazione. Il dettaglio di questi costi è riassumibile in termini di scrittura di codice, mappatura dei dati, acquisizione, implementazione e manutenzione di software, costi di trasmissione. Ovviamente le organizzazioni che vogliano adottare EDIFACT devono avere ampi margini di ricavo sul medio e lungo periodo ed un volume di affari tale da giustificare questi costi.
EDItX, a differenza di EDIFACT, nasce come standard specifico per il settore librario, con formati specifici per le sue molteplici applicazioni: commercio librario, biblioteche, utenti finali. I tag XML adottati nelle diverse applicazioni sono, laddove possibile, coerenti. Con la diffusione del web le dimensioni dei messaggi non sono più un problema [6], e questo fa sì che i file XML si presentino come facilmente leggibili dall'uomo, oltre che dalla macchina. In un file EDItX l'informazione sarà quindi racchiusa tra tag XML, ma i contenuti semantici (es. tipologie di messaggi) saranno comunque mutuati da EDIFACT; si aprirà quindi una nuova opportunità per questo formato.
Si può ormai affermare che XML si propone come l'approccio più promettente per muovere le tecnologie EDI verso Internet; grazie al fatto di essere slegato da piattaforme specifiche, ed in virtù della sempre maggiore disponibilità di tool XML a basso costo, promette di abbassare sensibilmente i costi dell'EDI. Questo aprirà la possibilità anche per le organizzazioni più piccole di accedere a nuove quote di mercato e di essere compatibili con soluzioni standard. Un messaggio EDI in XML, a differenza di un messaggio EDIFACT tradizionale, potrà contenere, oltre a testo e informazioni bibliografiche, anche immagini e informazioni commerciali (ad esempio la copertina del libro, o note biografiche sull'autore).
La versatilità rende quindi XML lo strumento adatto a realizzare l'integrazione tra EDI ed Internet. Si potrebbe aprire così la possibilità di ricondurre ad un unico modello un'ampia casista di transazioni rese oggi possibili da Internet. Infatti la selezione di materiale bibliografico da parte di biblioteche ed utenti finali viene sempre più effettuata online, su database interrogabili via web. Tuttavia queste operazioni devono necessariamente concretizzarsi in record di ordini, fatture e solleciti nei gestionali del cliente e del fornitore, il cui colloquio è stato finora affidato all'EDI. Il nuovo standard XML-EDI riuscirà a rendere conto di questi ed altri modelli di transazione, ovvero ad integrare la modalità tradizionale dell'EDI di scambio dell'informazione con quella tipica del web di accesso alle informazioni?
E' molto facile individuare nella mia memoria il momento preciso in cui è stato possibile che la Biblioteca di Ateneo dell'Università di Milano Bicocca ipotizzasse di adottare l'EDI per gli acquisti: settembre 2002, in cui, conclusasi con successo la migrazione dei dati da SBN, Aleph 500 è divenuto il nostro sistema di automazione bibliotecario. La scelta di un sistema che fornisse le necessarie garanzie di innovazione tecnologica, di interoperabilità, di prospettive per il futuro era e continua ad essere dettata da ragioni di efficienza oltre che di efficacia. Fra le diverse opportunità offerte dal nuovo ILS, l'EDI si connotava in maniera specifica come una soluzione che, per quanto tecnologicamente ormai "vecchia" come evidenziato nella prima parte di questo intervento, a fronte di un relativo investimento da parte nostra, esclusivamente in termini di configurazione della nostra installazione dato che la versione di Aleph 500 da noi adottata la supportava e non erano necessari interventi ad hoc, avrebbe permesso in tempi brevi di incrementare la nostra produttività, ponendo le basi per un più globale ripensamento di tutto il processo delle acquisizioni.
E i tempi sono stati effettivamente brevi: la sperimentazione dell'invio degli ordini con la ver. 14.1 iniziata nel maggio del 2003 ha portato, nel corso della seconda parte di quell'anno e del primo semestre del 2004, all'adozione dell'EDI per alcune aree disciplinari in cui è articolata la nostra biblioteca.
Ma come gli utilizzatori dei software sanno bene, non si fa in tempo a considerare assestata una versione che viene rilasciata la successiva, che spesso presenta caratteristiche innovative tali per cui è auspicabile effettuare la migrazione. E' stato il nostro caso, con la versione 16.02 di Aleph che proprio per quanto riguarda EDI presenta delle importanti novità.
Ad un anno esatto dall'inizio della sperimentazione nella ver. 14.1 è stata quindi effettuato un test dell'EDI sulla ver. 16.02, i cui risultati sono stati presentati al seminario Itale del giugno 2004.
Il 1 settembre scorso, a soli due anni dall'implementazione di Aleph 500, il polo Bicocca Insubria è "entrato in produzione" con la versione 16.02 che per quanto riguarda EDI supporta i messaggi relativi a fatture, solleciti etc. Per il 2005 si prevede l'implementazione completa dello standard.
Come già detto, EDI presenta una serie di benefici immediati a chi sceglie di implementarlo (biblioteche e fornitori, dunque): innanzi tutto c'è la garanzia di dati completi e corretti, sempre che come tali siano stati immessi la prima volta in uno degli archivi gestionali, eliminando gli errori che potrebbero verificarsi nel passaggio di dati fra i due sistemi a causa dell'intervento umano, inoltre la garanzia che una soluzione standard può dare in termini di interoperabilità (e quindi di cooperazione fra sistemi diversi) dovrebbe di per se' giustificare una scelta di questo genere rispetto a soluzioni di tipo proprietario.
Sul medio-lungo periodo invece si possono ipotizzare la compressione dei tempi di fornitura e di trattamento, grazie alla riduzione al minimo dell'intervento umano sui record amministrativi sia da parte del fornitore sia da parte della biblioteca, il contenimento complessivo dei costi che, nel caso di riduzione dei costi per il fornitore può trasformarsi in un beneficio per la biblioteca sotto la forma di maggiore sconto, e, cosa particolarmente efficace nel caso della nostra biblioteca, caratterizzata da una forte tendenza allo sviluppo quantitativo delle collezioni a causa della sua giovane età e della necessità di proporre ai propri utenti un'offerta documentaria che non li penalizzi nei confronti di atenei dalla storia secolare, un consistente aumento della produttività.
Non siamo attualmente nelle condizioni di valutare se tali obiettivi di medio-lungo periodo sono da considerarsi veritieri, a causa della troppo recente applicazione di questa metodologia di acquisti, ma i primi dati del 2004 sembrano confermare questa ipotesi.
Siamo consapevoli che il semplice uso dell'EDI, che di per se' non comporta novità nel tradizionale flusso di lavoro degli acquisti, non possa rispondere in maniera adeguata alle esigenze di innovazione e sviluppo di una maggiore efficienza, ma il ricorso a questa modalità ha senza dubbio rappresentato un primo e tangibile segnale della volontà della nostra biblioteca di perseguire tale obiettivo. In quest'ottica nel corso del 2004 sono state sperimentate altre modalità di acquisto: l'approval plan e l'acquisto di record bibliografici in formato MARC dai fornitori librari.
Ordini con EDI: 864 (11% degli ordini gestiti in Aleph)
Volumi acquisiti con approval plan: 701 (9% degli ordini di libri)
Record bibliografici acquistati da fornitore: 809 (10% degli ordini di libri)
La coesistenza di tali modalità e il loro impiego in maniera coordinata potrà consentirci a partire da quest'anno di liberare le risorse umane in servizio in biblioteca, sempre più ridotte a causa della congiuntura economica che limita grandemente le nuove assunzioni, per attività che richiedono un maggiore grado di specializzazione e che attualmente non possono essere svolte in maniera soddisfacente.
In pratica pensiamo di sostituire progressivamente il modello "tradizionale", nel senso di quello attualmente in uso che pure già presenta delle innovazioni come l'EDI e la catalogazione derivata da fonti esterne, con un modello che permetta di sfruttare al meglio le possibilità offerte dai fornitori in termini di approval plan e di acquisizione dei record in formato MARC.
Nel modello tradizionale la generazione dell'ordine avviene nel sistema gestionale della biblioteca, di norma un record alla volta, e l'EDI viene utilizzato allo scopo di trasferire i dati relativi all'ordine dalla biblioteca al sistema del fornitore e i dati relativi alle fatture in senso inverso. La ver. 16.02 di Aleph permette di utilizzare la parte del protocollo relativa al caricamento nel nostro sistema dei dati di fattura, cosa non possibile nella versione precedente, ma ancora presenta delle criticità per quanto riguarda lo scambio di messaggi relativi ai solleciti e alla cancellazione degli ordini. In particolare Aleph attualmente non supporta la cancellazione dell'ordine da parte del fornitore e presuppone che sia stato effettuato un sollecito da parte della biblioteca per attivare un messaggio di risposta relativo allo status dell'ordine stesso. E' evidente come con tale modello il processo di generazione dell'ordine sia totalmente lasciato al singolo operatore di biblioteca con tutto ciò che ne consegue in termini di lentezza, di rischi di errore a causa dei molti interventi manuali nel sistema gestionale, e di frustrazione per il bibliotecario la cui unica attività pare essere quella di "produzione di ordini". Tale aspetto comporta tanto più impatti negativi sulla motivazione individuale e sulla qualità del proprio lavoro quanto più la biblioteca è in una situazione di "rincorsa alla produttività" sotto la pressione incalzante degli utenti che a buon diritto reclamano la disponibilità di una collezione che risponda alle loro esigenze di aggiornamento e di ricerca. Se pure a fronte di una tendenza alla stabilità dei finanziamenti, quando non ad un loro decremento, la nostra biblioteca si trova infatti ancora in una fase di start up per quanto riguarda la costruzione della sua collezione, se si pensa che per molte delle aree disciplinari che la costituiscono i primi libri e i primi abbonamenti risalgono solo a 5 anni orsono.
L'approval plan e l'acquisto dei record dagli stessi fornitori librari costituiscono senza dubbio due interventi che vanno nella direzione di ridurre l'intervento manuale dei bibliotecari nella fase di ordinazione e in quella di catalogazione, ma apparentemente possono confliggere con l'uso dell'EDI che, come abbiamo visto, nell'implementazione attuale dello standard in Aleph 500 non prevede l'invio di record da parte del fornitore sotto forma di proposta da sottoporre alla biblioteca per l'eventuale ordinazione (c.d. notificazione nuovi titoli).
Da questa semplice constatazione nasce l'ipotesi di rivedere globalmente il processo di acquisizione, facendo ricorso all'immissione nel gestionale della biblioteca di lotti di record bibliografici corrispondenti agli invii dei volumi in "carta e inchiostro" secondo i profili di approval plan. L'attività manuale in questo secondo modello consisterà "semplicemente" nella selezione dai file, inviati dai fornitori mediante FTP, di quei record per cui si sarà deciso di dar corso all'ordine. Il caricamento di tali record nel sistema gestionale sarà gestito in modo automatico dopo che apposite procedure effettueranno la deduplicazione dei record già presenti nell'archivio. L'opportunità offerta da Aleph di effettuare il cosiddetto "ordine multiplo" riduce ulteriormente gli interventi manuali dei bibliotecari, permettendo il trattamento di un numero superiore di transazioni. In sostanza si tratta di generare in un'unica soluzione ordini per più record bibliografici a partire da un qualunque file in formato MARC. Tali ordini multipli saranno poi alla base dell'avvio dello scambio di messaggi EDI, secondo il modello visto in precedenza.
Il processo qui rappresentato sarebbe privo di criticità se il modello di acquisti in approval plan fosse un "modello perfetto" e l'intera fornitura in approval plan si trasformasse in un acquisto effettivo da parte della biblioteca, cosa che come noto non accade di norma. Per questi motivi è necessario ipotizzare delle soluzioni tecniche che garantiscano una corretta gestione dei "resi" senza gravare sull'attività ordinaria dei bibliotecari.
Come si può vedere si tratta di un'ipotesi che sfrutta le potenzialità attuali sia dell'acquisto di record in lotti dai fornitori, non necessariamente collegato all'approval plan, sia dell'EDI per come è ad oggi implementato in Aleph 500 e nei sistemi gestionali di alcuni fornitori commerciali. E' quindi un'ipotesi di immediata applicabilità.
A cosa si deve quindi lo scarso successo dell'EDI in Italia, al punto che ormai lo standard può dirsi "superato" prima ancora di essere applicato? Sono pochi i sistemi di automazione delle biblioteche e i sistemi gestionali dei fornitori che implementano lo standard, a causa dei notevoli costi. A ciò si aggiunge, e forse in qualche modo ne può costituire la causa, la scarsa pressione esercitata dalle biblioteche nei confronti di progettisti del software e dei fornitori. Possiamo ipotizzare che tale "indifferenza" delle biblioteche sia conseguenza della tradizionalmente scarsa attenzione dei bibliotecari nei confronti delle procedure di acquisizione (a favore della catalogazione da un lato e dei servizi al pubblico dall'altro), ritenute meno strategiche in parte perchè strettamente connesse con le procedure amministrativo-contabili degli enti che in genere sovrintendono le biblioteche stesse (amministrazione universitaria, dipartimenti, aree amministrative degli enti locali etc.), in parte perchè in molti casi la frammentazione delle biblioteche italiane (le biblioteche delle università solo recentemente hanno dato l'avvio a processi di accorpamento e centralizzazione e in misura limitata ad alcuni servizi fra cui difficilmente si trovano gli acquisti), ne determina dimensioni tali da non richiedere grossi interventi di razionalizzazione e di snellimento delle procedure. In altre parole numeri ridotti in termini di transazioni di acquisto (e di vendita) non giustificano grossi investimenti per sistemi la cui ricaduta positiva e' visibile solo per grosse quantità di dati da trasferire.
Se a questo aggiungiamo la tradizionale resistenza al cambiamento sia da parte delle biblioteche sia da parte di fornitori che hanno già messo in atto soluzioni proprietarie, magari a fronte di grossi investimenti, possiamo facilmente comprendere come sia difficoltosa la diffusione di questo come di altri standard.
Ma forse il momento attuale potrebbe comportare delle nuove opportunità di rinascita e di adozione di EDI. Come abbiamo visto EDIFACT è "congelato", ma EDI si evolve verso soluzioni basate su famiglie di formati XML e tecnologie Internet.
Paradossalmente i relativamente scarsi investimenti su EDIFACT, almeno in Italia, potrebbero accelerare il passaggio di ILS e fornitori ad XML che potrebbe rappresentare la cornice per tutta una serie di applicazioni di tipo bibliotecario, di cui lo scambio di messaggi EDI rappresenta solo una porzione.
Per chi ha già implementato EDI, la transizione potrebbe essere graduale (conversione EDIFACT/XML) e in ogni caso gli investimento già fatti nello sviluppo dell'EDI nella sua forma attuale non andrebbero persi ne' per le biblioteche che lo hanno adottato ne' per i fornitori, che sarebbero stimolati a sviluppare nuovi sistemi che mantengano la compatibilità con i "vecchi" permettendo loro di acquisire nuovi clienti senza perdere i vecchi.
Ma per passare da pochi a molti e raggiungere la massa critica che giustifichi lo sviluppo tecnologico in questa direzione, è necessario attivare un circolo virtuoso altrimenti il rischio che ciascuno degli attori impegnati (biblioteche, produttori di software, fornitori commerciali) resti "alla finestra" in attesa delle mosse degli altri si può facilmente trasformare nella certezza di una stagnante immobilità con conseguenze negative innanzi tutto per l'efficienza delle biblioteche e frustrare irrimediabilmente le attese degli utenti finali di ottenere un buon servizio, rapido e a costi contenuti.
[1] Hardinge, Julian, EDI and web services for libraries, <http://home.imaginet.co.za/liasa/EDI%20and%20Web%20Services%20for%20Libraries.htm>.
[2] Sotto gli auspici dell'UN/ECE, United Nations Commission for Europe.
[3] Sul progetto EDILIBE (Electronic data interchange for libraries and boobksellers in Europe), si veda l'articolo di Michele Casalini EDI developments in the Italian book sector ad URL <http://dotsx.usc.edu/archive/WESS/EDIF96.html>.
[4] Book Industry Communication; gruppo fondato e sponsorizzato nel Regno Unito da editori, librai e biblioteche (inclusa la BL) per promuovere standard per il commercio elettronico nel settore librario.
[5] Book Industry Standards And Communications; gruppo statunitense che promuove l'utilizzo di standard nel commercio librario, sponsorizzato da editori, librari, biblioteche (anche LC).
[6] In termini di numero di caratteri trasmessi, un messaggio EDI XML potrebbe essere da 2 a 3 volte più lungo del suo corrispondente EDIFACT; fonte: XML/EDI European Pilot Project <http://www.psol.be/old/1/xmledi/>.
N.B.: an English version is also available.
Copyright AIB 2005-02-22,
ultimo aggiornamento 2024-02-09 a cura di
Serafina Spinelli
URL: http://www.aib.it/aib/commiss/cnur/boidigir.htm3