Electronic Recordkeeping
Implementation of Imaging Technology for Recordkeeping at the World Bank
by Clive D. Smith
Also, as many as 25 separate files may be used to generate a single complex bank document. Recent studies have shown that, even with improvements in technology, it is still easier to publish such complex documents from printouts generated from the various electronic files used to create them, than to try to combine those files. Consequently, paper has continued to be the medium for preservation, even for the documents created electronically. Furthermore, some members of the World Bank Group are engaged in litigation that can occur in almost any country in the world. Therefore, the bank's recordkeeping practices cannot be governed solely by U.S. rules of evidence, legislation or practice in the admissibility of records. For these reasons, the bank's official records are still primarily in paper.
As tools to support requirements have gradually become available (or promise to become available), the bank has moved to position itself to transition from paper-based recordkeeping systems to systems that would enable records to be created and maintained solely in electronic form. The implementation of a standard bank-wide network (the Enterprise Network) has solved the problem of a bank-wide delivery mechanism. It has greatly facilitated the sharing of documents and the standardization of applications and platforms. Document imaging technology has provided an additional means of implementing Tier 3 - capturing of final-form documents at an institutional level and making them accessible across the institution. The more recent development of reliable collaborative or work group tools promises to enable Tier 2.
The technology selected was Electronic Filing System (EFS) from Excalibur Technologies. This was chosen primarily because of its search engine, especially its "fuzzy" search logic, which eliminated the need for clean text for searching purposes. More than 13,000 documents have now been scanned and included in this collection, and they are now available to bank staff via the bank's Intranet, although this does not support searches on the text of the documents. Staff can search by a range of profile fields, including country, sector, date, author, title, report number, loan number and type of document. They can view either the image or the text of each page or can place a request for a paper copy. Copies are printed from the image files and have proven to be better quality than copies reproduced from the microfiche.
An early decision was not to store the images and text files within EFS; rather they are stored on separate servers and EFS merely contains pointers to their location. This was not only to reduce dependency on proprietary software, but also to facilitate simultaneous use of other access software that might become available. This has already enabled the documents to be made available via the bank's Intranet, and is also expected to permit access to the same document from a variety of access points utilizing whatever technology or software is most appropriate for the user. Similarly, the master copy of the profile data is also maintained outside EFS in a suite of Oracle tables which can be accessed via other software that might be more appropriate for particular users or in particular situations.
The studies of the recordkeeping systems had already resulted in a major initiative ("File Improvement Program") under which teams of records managers visited individual work units to establish a comprehensive filing system within each. The records managers analyzed the business processes, workflows and information needs of the work units in order to design relevant and useful filing plans, and this work has also provided a sound basis for the design of appropriate imaging systems for records.
EFS is built around the metaphor of a fileroom. Each EFS application is an electronic fileroom, containing electronic cabinets, which in turn contain electronic drawers, which hold electronic folders, which contain the documents themselves. To be filed in EFS, a document must fit into this hierarchy. With minor modifications, the filing plans that had been developed for paper records were easily adapted to fit this electronic hierarchy. This was an important factor in gaining user acceptance - the users were presented with a familiar environment. The fileroom structure for the bank's main operational vice presidencies is shown at Figure 1.
The profile attributes serve a number of purposes. While some are almost purely descriptive and are intended to facilitate retrieval, others are included specifically for records management or system management purposes. For example, Originating Unit tells us which organizational unit first received or created the document; Owner tells us which organizational unit is now responsible for the business process or transaction to which the document relates, as the bank is subject to frequent reorganization. Business Process will later facilitate appraisal and disposition, as will Document Type, although in practice over three-quarters of the documents are either memorandum or letter. Retrofit tells us whether the document was scanned in the normal course of business or was scanned as part of a backfile conversion; Action Flag is intended for use with the correspondence management system under development (see below) and will be used to trigger appropriate routing and tracking mechanisms depending upon whether a document requires action or is merely for information.
Different business processes require different combinations of profile attributes for document descriptions. For example, documents relating to general country information or the country portfolio performance are not related to lending projects, and so a number of profile attributes (Project Name, Loan #, etc.) are not required. Because these attributes are mandatory for describing project-related documents, it has been necessary to develop a number of customized data entry screens, so that the data entry operator has to select the screen appropriate to the relevant business process. A sample profile is at Figure 2.
In practice, the profile attribute that causes the most difficulty for the data entry operators is Document Name. The maximum length permitted for this attribute is 100 characters, and within this limit the operators have to construct a meaningful name for the document. The Document Date (in the format YYYY-MM-DD) is concatenated with Document Name to construct an EFS document label; the inclusion of the date enables EFS to display the list of documents within a folder in chronological order, the most rational order for a recordkeeping system. EFS assumes that within the same folder a document label is unique; the inclusion of the date within the label helps to achieve this, but operators need to bear this in mind also when constructing a document name.
Although the EFS system with its associated documents and Oracle databases is intended to be a recordkeeping system, it is important to note that records are not created within the electronic system itself; rather they are captured and stored within the electronic system after they have been created. Also, whereas EFS serves as a retrieval system for the images, the images and electronic texts themselves are separately stored, as are the profiles. The data, thus, is not actually attached to the document, as is envisaged in the Pittsburgh approach.
The Pittsburgh study recommended four tactics for meeting requirements: policies, design, implementation and standards. The bank concluded that all are necessary and also placed a high degree of stress on training.
Generally the study concluded that the electronic system met most of the requirements either wholly or partly. There was some uncertainty about the others. For example, the system came out well in the following areas:
However, the electronic system was less impressive in the area of Compliant Organization. It could only partly be said to comply with legal requirements. This latter conclusion is not particularly surprising considering the plethora of jurisdictions within which the bank operates. Given that the electronic system is not intended to include all records, these findings were sufficient encouragement to press forward.
Admittedly, some requirements are implemented somewhat awkwardly in the present system. For instance complete records requires that linkages between records be preserved. EFS has no way of linking related documents, such as a letter and an attachment, or a letter and a reply. Consequently, attachments and covering letters have to be treated as a single document, and the name needs to show that the document includes both, e.g., "Letter enclosing feasibility study for bridge on highway." This adds to the problem of creating a document name. Similarly, although a letter and a reply are treated as separate documents, it is often useful for the reply's Name to refer to the original letter, e.g., "Reply to Minister's letter of Apr 2 re cost overrun."
In units where the imaging system has been implemented, incoming documents, such as mail or faxes, are scanned before being forwarded to the relevant action officer. Because EFS does not now support document routing and tracking, the paper originals are still forwarded to the action officer. Action officers are then responsible for forwarding the original paper copy to the relevant paper files. The file copies of outgoing correspondence are forwarded to the scan station for scanning prior to filing. Electronic mail messages, of course, are received or sent directly by the action officers, who then must forward them electronically to the scan station for import into the system. At this stage, the paper files are, for the most part, still regarded as the records.
The implementation of an imaging system for correspondence and documents, however, has not resulted in a reduction of the workload in managing records. Instead of individual items being classified and filed, they are now scanned and described. In fact, database descriptions are now at the individual item level, rather than at the file level. If anything, the number of information professionals seems likely to increase. This, however, is offset by other savings. Documents no longer need to be copied and physically distributed. Only one paper copy is retained, eliminating a large volume of duplication in the archives. As many staff as need can have simultaneous access to the images, and their search times have been reduced significantly. Office space requirements for the storage of paper documents have also been reduced significantly. Further economies are expected when field offices are added to the system.
Figure 1
| CABINET | DRAWER | FOLDER |
|---|---|---|
| <Country or Area> | _Cofinancing & Aid Coordination | _General <Organization> |
| _Country Information | General | |
| _Country Program< | Country Assistance Strategy
Country Economic Memorandum Country Portfolio Performance Review Country Policy Framework Paper General | |
| _Grants & Trust Funds | <Project Name> | |
| _Sector Work | <Project Name> | |
| _Topical Information | <Sector or Program Objective> | |
| <Project Name> | Bank Reports
General Correspondence Legal Procurement |
Figure 2
| Project Name | MX-2nd Decentralization & Regional Development |
| Doc. Date | 1996-10-18 |
| Date Stored | 1996-10-25 |
| Loan # | 3790 |
| Credit # | |
| Country/Area | Mexico |
| Project ID | MXPA7702 |
| Doc. Type | memorandum |
| Task Mgr. | Sant'Anna, Anna--LAMXC |
| Sector | Public Sector Management |
| Category | General Correspondence |
| Bid # | |
| Ext. Fin. # | |
| Fund # | |
| Report # | |
| Security | Official Use Only |
| Author | |
| Bus. Process | A.2.a.5. Supervision - Accounting & Auditing |
| Accession # | |
| Box # | |
| Orig. Unit | LASLG |
| Organization | IBRD |
| Owner | LASLG |
| Doc. Version | |
| Label | 19961018 Memo fr Sant'Anna re audits & suggested measures |
| Folder | General Correspondence |
| Drawer | MX-2nd Decentralization & Regional Development |
| Cabinet | Mexico |
| Fileroom | 2 |
| Doc. Name | Memo fr Sant'Anna re audits & suggested measures |
| Volume # | |
| Entity ID | 00008124296102512474800 |
| Profile Type | 00 |
| Doc. Source | C |
| Division Tab | |
| Tab | |
| Sub Tab | |
| Alt Task Mgr | |
| Action Flag |