![[AIB]](/aib/wi/aiba10.gif)
|
AIB. Commissione nazionale biblioteche delle università e della ricerca |
EDI is the acronym of Electronic Data Interchange. There are several definitions of EDI; anyway it is a kind of electronic data exchange for direct transmission of commercial messages between information systems, through national and international telecommunication networks. EDI is a sort of lingua franca; for this reason it has been compared by some to Latin, for the function it had in medieval society. The request for standards for commercial transactions started in the 80's in industrial sectors such as transports, banking, pharmaceuticals, as an alternative to the use of proprietary solutions for orders and invoices. In these sectors, benefits of automated solutions were considered highly strategic, at such an extent that major organizations put a lot of pressure on their trading partners to oblige them to adopt EDI, in the goal to be still suppliers.
The first EDI formats to be released were X12 in the USA, created by ANSI, and TRADACOMS in the UK. Later, ONU [1] implemented its own format: EDIFACT. EDIFACT was created as an international and multisector standard, thought to overcome other formats; though the existence of national standards limited its diffusion, so its adoption is nowadays patchy.
EDIFACT was created as a generic format; so for each specific application to different sectors a specific subset has to be defined. EDItEUR is an organization to promote development of electronic book trade; EDItEUR's activities are sponsored by publishers, vendors, libraries and ILS producers. EDItEUR is also committed in creation and maintenance of EDI standards for book trade. In collaboration with EDILIBE and EAN International, EDItEUR has studied a subsect of EDIFACT for book trade. Guidelines for EDIFACT implementation in book trade were published by EDItEUR in 1995; first (and last) revision was in 1997. Since then, no new developments have been done, though EDItEUR still modifies the format with enhancements in response to users' needs.
EDI benefits are substantially of three kinds:
EDI improves quickness and correctness of commercial transactions, and lower costs of transmission and processing of information.
Message types defined by EDIFACT are: quotes, order, order response (and status report), modify (also cancellation) of order, claims, invoice.
An EDIFACT message is formatted as an only line, with several segments included between an header and a teaser. A single message can contain several orders, invoices, etc.; the message includes administrative and bibliographic information.
The following is an example of EDIFACT message. Signifying data are shown in red colour (price, author, title, publisher).
As we have seen, EDIFACT has had no new developments since 1997, but EDItEUR is working with BIC and BISAC to define the next EDI standard, based on XML: EDItX, that will offer the same range of messages supported by EDIFACT.
EDItEUR's aim is to define an EDI standard based on XML before several XML formats are established; it is therefore necessary to avoid the repetition of what happened with EDIFACT, and the growing success of XML in libraries improves the possibility that libraries develop local solutions.
An incentive towards the adoption of EDItX in libraries could be the diffusion of next generation ILS, likely to be XML compliant. One of the most successful library systems, ExLibris' Aleph 500, in ver. 16.02 already handles output with XML; the same EDIFACT incoming and outgoing messages are converted in an intermediate XML format. This means that ExLibris has already inserted in its software a conversion between EDIFACT and XML.
By now, anyway, EDItX seems to be more interesting for electronic book trade companies such as online book sellers, many of which already adopt ONIX, a bibliographic metadata standard based on XML.
A comparison between EDIFACT and EDItX can give us a scenario of the changes in companies' requirements and suppliers' responses in relation to commercial transactions.
EDIFACT messages are characterized by a unique kind of format, with multiple specific subsets for each sector (e.g. wholesale, banks, book trade). Messages are very brief and highly coded, to keep transmission costs low; level of compression of bibliographic and administrative informations is so high that human reading of messages is very difficult. Consequently, EDIFACT is a solution with very high implementation costs, specifically in terms of programming, data mapping, acquisition, implementation and maintenance of software, transmission costs. Obviously, organizations willing to implement EDIFACT must be sure to obtain consistent savings to justify these costs.
EDItX, differently from EDIFACT, was created as a specific standard for book trade, with different formats for each application: book trade, libraries, end users. XML tags adopted in different applications are, if possible, consistent. With the spread diffusion of the web, message size is no longer a problem, and this means also that XML files can be easily readable. In EDItX files, data will be closed in XML tags, but semantic contents (e.g. types of messages) will be the same of EDIFACT; so a new possibility will open for this format.
We can definitely assume that XML is the most promising system to move EDI technologies towards the Internet: it is platform independent, and low-cost XML tools could make EDI accessible even for smaller organizations. Furthermore, an XML-EDI message will be able to include not only text, but also image files such as book cover and author's portrait.
Flexibility is the key that makes XML the right tool to join EDI and the Internet. The goal is to move under a standard model a wide range of transactions made possible by the Internet. Selection of documents is nowadays more and more carried out through vendors' online databases; but each of the titles selected must be turned into an order and invoice record in vendors' and library's databases. As we have seen, exchange of these informations is EDI's prerogative. Next challenge will be to join traditional EDI, intended as a way to exchange informations, with the web's potentialities of access to information.
The moment in which it became possible for our library to adopt EDI is fixed in my memory: September 2002, after a successful migration from SBN to Aleph 500, that we had selected as our new ILS. We felt sure that we had chosen a software with necessary requirements of technological innovation, interoperability, perspectives for the future; these considerations were simultaneously due to efficiency and effectiveness reasons. Among all the technological solutions offered by Aleph, EDI represented to us a good compromise: though technologically not up-to-date, as we have heard in the first part of this speech, EDI implementation required a minimum effort in terms of configuration, and most of all with no need for ad hoc adjustments. Furthermore we hoped that EDI could be an opportunity and a first step towards a global redesign of acquisitions processes.
Timing for EDI adoption was very short: tests on the sending of orders started in may 2003; during the second half of the same year it became a standard procedure for many of the order units in which our library is organized.
But every software user knows that new versions are often released at short intervals; though the old version of Aleph 500 (14.1) had reached an acceptable level of stability, we decided to risk some uncertainties upgrading to ver. 16.02, because the new version announced many new features, some of which were specifically focused on EDI messages.
One year after EDI tests on ver. 14.1, new tests were undertaken on ver. 16.02; results of this activity were presented in ITALE (Associazione Italiana Utenti ALEPH) Milan Workshop "EDI e non solo", in June 2004.
In September 2004, after two years of implementation of Aleph 500, our site upgraded to ver. 16.02, featured to support a wider range of EDI messages, such as invoices and claims. During 2005 we plan to implement widely the standard.
As we have already seen, EDI offers several immediate benefits for vendors and libraries: first of all it gives a warranty of correctness and completeness of data, avoiding human errors in re-keying of data; moreover, the benefits of a standard solution should be self-evident: the mere interoperability is sufficient to justify the choice of standard vs proprietary solutions.
Over medium and long term period we think that we will obtain an improvement in suppliers' performance, due to reduction of human intervention, and also, on the library-side, a shortening of processing time. Another effect should be a global costs reduction, at least in terms of major discounts offered by the supplier. The final outcome should be a productivity improvement, an issue that has the maximum relevance among the goals of our library, that is characterised by being recently founded and consequently by the necessity of a fast growth of collections.
By now, we still have no elements to evaluate whether these medium-long term goals will be pursued: the wide adoption of EDI is too recent to allow a balance, but data from the first semester of this year seem to confirm a positive trend.
We are conscious that the use of EDI by itself does not imply new developments in traditional acquisitions workflow, and cannot be an exhaustive response to requests of innovation and efficiency, but the use of this standard has been a first sign of our will to redesign acquisitions workflow. For the same reason during 2004 other methodologies of acquisition have been tested: approval plan and MARC records supplied by vendors.
EDI orders: 864 (11% of orders recorded in Aleph)
Items ordered through approval plan: 701 (9% of monographs orders)
Bibliographic records supplied by vendors: 809 (10% of monographs orders)
We think that the use of these methodologies in conjunction will allow us to redirect human resources to value-added activities that require an higher level of specialization than the mere processing of orders.
We plan to reduce the number of acquisitions with the traditional model, that anyway presents some innovative features such as EDI and copy cataloging, with a model that will give us the opportunity to use innovative services that are increasingly offered by vendors, such as approval plan and bibliographic records supply.
In the traditional model of acquisitions, order creation is done in the library's database, usually one record at a time, and EDI is used to transfer order information to the supplier's database, and invoices data in the inverse way. Aleph ver. 16.02 allows us to use the part of EDIFACT regarding invoices loading, but does not support the full range of messages regarding claims and modifications of orders. Specifically, Aleph does not support order cancellation by the vendor and requires sending a claim to allow the loading of responses on orders. In this model, the whole process of order creation is assigned to the librarian; this implies that there will not be a significant saving of time: some data will have to be manually re-keyed and the librarian's activity will be limited to the role of order processing. The negative impact of this situation is maximum in a library that is mainly focused on the improvement of productivity in response to patrons' needs:
indeed our library is still living a start-up period in library collections development, and for some sectors collections have started only 5 years ago.
Approval plan and bibliographic records supply are meant to reduce human intervention in ordering and cataloging, but apparently they could seem to be in opposition to EDI that, as we have seen, in Aleph implementation does not allow the supplier to send to the library notifications of new titles.
This consideration makes us globally rethink the workflow of acquisitions, loading in the library's system packages of bibliographic records that are tied to the sending of books according to the profile established with approval plan. The file including all the bibliographic records will be made available by the vendor via FTP.
Manual processing, in this model, will consist in the selection of titles that the library is willing to buy among all the records supplied by the vendor in the approval plan. Loading of records into Aleph will be done automatically after ad hoc procedures that will deduplicate the records that are already in the database. Moreover, Aleph has a specific feature named "multiple orders" that reduces manual keying of data, allowing the creation of several order records starting from a file – in our case supplied by the vendor - containing bibliographic records. Such multiple orders will be the basis to start an EDI messaging exchange, according to the model we have just analysed.
This workflow would be free of troubles if approval plan were a perfect model, and the whole delivery of books turned into actual orders. As we all know, this does not necessarily happen; for this reason we are studying technical solutions to allow a correct workflow for rendered, without implying an additional intervention by the librarians.
This solution makes possible to use both acquisition of packages of records by vendors, not necessarily tied to approval plan, and EDI as it is nowadays implemented in Aleph 500 and in some vendors' systems. This solution can be immediately applied.
What are the reasons for the limited diffusion of EDI in Italy, at such an extent that the standard has grown old without reaching a wide diffusion? There are few library and vendors systems compliant with the standard, because of its high implementation costs. Moreover, libraries do not put a big pressure on vendors and ILS developers. We can argue that such indifference can be a consequence of a low concern regarding acquisitions workflow, thought to be less strategic than other aspects, in part because acquisitions are strictly tied to administrative procedures of organizations in which libraries are situated, and in part because in many cases fragmentation of Italian university libraries determines low sizes in acquisitions. In other terms, a limited number of transactions do not justify wide investments for systems that produce benefits only in presence of huge masses of data to transfer.
If we add to these considerations the usual "resistance to change" both by the libraries and by the vendors, that in some cases have already developed proprietary solutions, we can easily understand how difficult it can be the diffusion of this and other standards.
But maybe this moment could imply new opportunities of rebirth and adoption of EDI. As we have seen, EDIFACT is frozen, but EDI evolves towards solutions based on families of XML formats and Internet technologies.
Paradoxically, in Italy low investments on EDIFACT could make easier the shift of ILS and vendors to XML, that could represent the frame for a wide range of library applications of which EDI messages are just one part.
For those who have already implemented EDI, transition could be gradual, with EDIFACT/XML conversion; anyway, investments in EDI implementation would not be lost, because vendors could develop new systems maintaining compliance with EDIFACT, trying to gain new clients without losing old ones.
But to reach the critical mass to justify technological developments in this direction, it is necessary to activate a virtuous circle; otherwise the risk that each of the actors (libraries, vendors, ILS) stands still, waiting to see the others' moves, could turn into paralysis, with negative consequences first of all for libraries' efficiency, and also for patrons' expectations of having a good, fast and cost saving service.
[1] Under the auspices of UN/ECE.
N.B.: è disponibile anche la versione italiana.
Copyright AIB 2005-06-15,
ultimo aggiornamento 2024-02-09 a cura di
Serafina Spinelli
URL: http://www.aib.it/aib/commiss/cnur/boedigir.htm3