Introduction to the design, implementation and maintenance of electronic document management systems

Transcription

1 Lligall 21/ Introduction to the design, implementation and maintenance of electronic document management systems Montserrat Canela 1. Introduction In this day and age, it is difficult to imagine an organisation that has not incorporated electronic tools to help with administrative and technical tasks. This means that even those organisations that consider a signed paper document to be the only format with official value produce and store a huge and growing amount of information that is found only in electronic format. and record management applications are two of the many examples that illustrate this phenomenon: increasing numbers of decisions are documented only by messages. At the same time, record management databases contain a great deal of information and allow large numbers of management processes to take place without the need to consult the record. A management system for administrative documents and archives that only offers solutions for the management of records in paper format, ignoring documents and information in electronic format, is a system that is leaving a growing proportion of documents produced and received by the organisation out of the control of the archivist. In the last ten years, both archiving practice and information technologies have made important advances in creating solutions for processing electronic administrative documents 1. Following a first stage in which there were more questions and doubts than solutions and when it seemed that the management and the conservation of electronic documents was only of interest to archivists, a period has begun in which more and more public and private organisations are seeking solutions for the management of their electronic documents, for both legal and practical reasons. Pharmaceutical companies must store all of the information relating to medicines, even for medicines that are no longer on the market; organisations that are geographically scattered need to create virtual teams working with people who coincide in neither space nor time; public administrations, keen to facilitate user management, have incorporated procedures that can be completed electronically. These phenomena have spurred certain IT companies on to launch tools for managing electronic documents and information. Archivists and IT technicians have come together to carry out certain specific projects, which are leading to progress in the theoretical and practical corpora of both professions.

2 While the management of electronic documents is progressing in what seems to be the right direction, this is an area that is still in development and in which often the only way of learning is based on trial and error for the project in progress and previous projects. Archivists today, both those working in the area of historical archiving and those working in the area of administrative documentation management, must incorporate electronic documents into their field of responsibility. While in the field of electronic documentation management many aspects remain to be developed 2, there are already specific products on the market for the management of electronic documents within companies and there are also a range of experiences that can serve as models and examples for new projects. This article is an introductory text aimed at professionals and students of Archiving and Record Management who already have a broad-based knowledge of administrative document management systems and who are interested in or considering undertaking an electronic document management project. The text relates the management of electronic documents with the life cycle of the documents, beginning with the stage at which the archivist has more direct control, the record phase, and ending with the phase in which the archivist can only work as part of a team, the planning phase. The article continues by presenting the components of a system of electronic administrative document management and ends by examining the phases of a project of this type, from design to implementation and maintenance. It is a practical text, based on my experience as a member of a team that is putting a project of this type into practice and also on the exchange of information with colleagues who are immersed in similar projects. The aim is to present guidelines to help the archivist to ask the correct questions and to know what aspects are required to complete their information and training. 2. The life cycle of electronic documents and archivist intervention An electronic administrative document is an administrative document, that is, a document that has been created or received as a result of the activity of an organisation, that may be manipulated, transmitted or processed by a computer 3. Many administrative documents begin their life cycle in one format, which changes as they pass from one stage to the next. We can use a word processor to write a letter (electronic format) that we then print, sign and send by post (paper format); we can take this letter on paper that has already been signed and we can send it by fax (transmission in electronic format); at the point of arrival they may decide to keep our letter on paper, they may receive our fax directly on their computer, they may scan the paper document and reconvert it into an electronic document, and so on. messages are one of the cases where

3 the document is electronic throughout its life cycle: creation, transmission, reception, processing and archiving are all electronic, but even an message can be printed in the end and incorporated into a paper record. Because of the variety of formats in which documents appear throughout their life cycle, when we begin an electronic document management project, we cannot focus only on electronic documents, but instead we have to think about all administrative documents in every format throughout their life cycle. The life cycle of an electronic administrative document is comparable to the life cycle of traditional documents on paper. In the same way as for a paper document, an electronic document is drafted, passes through several drafts or different versions, the final version is reached, this is transmitted, filed and finally deleted or transferred for its permanent storage. In this list of stages, one essential step is missing, particularly with regard to electronic documents: this is the planning phase. By this phase, I mean the design of print-outs, the drawing up of models and also, often, the design of administrative circuits within which the diverse documents are generated, used and archived. I also include in the planning phase the design of record management databases, as these systems eventually produce documents (for example, the budget, reports, proceedings) and in many cases, they themselves can be considered as administrative documents that contain data of legal or fiscal value. In the archiving phase, the archivist has total control over all decisions and operations. As the process moves away from this strictly archival stage, the archivist begins working with other actors (database designers, those in charge of organisation and methods, management staff, etc). If the archivist is clear as to how archival requirements can be incorporated into each phase of the life cycle and knows how to work in a team with these other professionals, they can ensure that archival principles are taken into account from planning right up to storage. Now we will look at the archival requirements from the phase in which the archivist has most direct control, that is, the archiving phase, to the most remote phase, that is, the planning phase. It should be remembered that while the ideal electronic document management system incorporates archiving requirements throughout all the phases of the life cycle of documents, it is a real possibility that a specific project may only include one or some of the phases of the life cycle, leaving the others outside its limits Intervention by the archivist during the archiving phase During this phase, the archivist should collect those electronic administrative documents of permanent value that have been created and managed by different applications and process them, in order to ensure their long-term preservation as documents that are authentic, complete and accessible.

4 More extensive practice consists of extracting the documents from their original system, migrating them to a standard format and documenting their structure, the original system and the administrative context in which this was created. Finally, the archivist will ensure, usually by means of successive migrations, that the documents remain accessible as technology advances 4. The role of the archive and the archivist in this phase is clear, as one of the recognised functions of archivists is the custody of the annual reports of organisations. Obviously, the technical task must be carried out by personnel with knowledge of IT, but it is the archivist's task to decide what should be preserved and why, and it is also up to the archivist to document the administrative context and produce the archival description of all of the material. If the archivist does not intervene when electronic documents pass to the noncurrent phase, the decision concerning the preservation of the information is left in the hands of users and IT departments. In such cases, the most usual course of action is for information to remain on-line, until the system is wiped to free up memory, or it is lost when the computer systems are updated. When an organisation updates its computer systems without the intervention of an archivist, it usually takes one of two extreme decisions which are equally problematic: to erase the obsolete information with no archival criteria, or to keep it indiscriminately off-line on disks or CD-ROMs that no one will ever take the trouble to migrate as the systems evolve 5. In order to retain documents of permanent value, the archivist must have a clear mandate concerning the evaluation of computer systems. This mandate must ensure that the archivist's intervention is obligatory before migrating data from one system to another version of the program or to another system, before eliminating the information from the system in order to free up memory or before eliminating a specific system. When the archivist intervenes at the moment when the information or an entire system become obsolete, a series of problems can emerge that are difficult to solve, such as: Information tends to be dispersed among several different media and systems (paper, databases, , spreadsheets, etc). If the archivist has not intervened in the phase of collating the records to ensure that all the information and the documents are archived and structured following the same logic, it will be very difficult, if not impossible, to later find and evaluate the documentation in a relevant fashion. Together with the information and the original system, the archivist should receive all of the documentation that exists concerning the design, structure, objectives and context of the transferred system and also concerning the administrative context in which it is to operate. This information often does not exist or is not accurate and the archivist is forced to invest time and effort filling in

5 the gaps and correcting the mistakes. In contrast, if a system has been evaluated as permanent from the planning phase, it is possible to put mechanisms into place to document the evolution of the application in terms of both the technical aspect and its administrative use Intervention of the archivist in the phase of collation and control of records In general, computer systems, which have greatly facilitated the creation and distribution of documents, have not incorporated efficient mechanisms for the collation and management of records. Databases generate documents, but they do not have a device incorporated for archiving them; messages accumulate in personal inboxes, for which each individual decides on a unique, non-transferable archiving system. The same is the case for electronic documents that accumulate on different disks, with no order or archivist control. The aim of the archivist s intervention in the creation and control phase of records is to collect complete, reliable, authentic documents and keep them accessible and in context for the required time, until they can be deleted or transferred to an archiving system. In short, creating virtual records. Virtual records can be processed with the same techniques that years ago were successfully applied to the management of administrative documents on paper. That is: A corporate classification scheme. Corporate evaluation and selection tables that are integrated into the classification scheme. A system of management archives or a centralised archive to which all those people authorised to see or use the records have access. An index containing the localisation and metadata (title, date(s), author, unit, classification code, preservation rules, etc.) Certain regulations and procedures establishing the content of the records, the description and archiving standards and the division of responsibilities. Electronic administrative document control systems are usually systems that are controlled by the archivist but that are implemented on a decentralised basis. The archivist creates and maintains the classification schemes, draws up and applies the evaluation and selection tables, prepares the regulations and maintains and uses the index, but the responsibility for selecting the documents, archiving them in the records and recovering the information when necessary is in the hands of the users. In this phase, the archivist must work in collaboration with the administrative units for the collection of information and to design classification schemes that are intelligible and usable from the point of view of the archive and from the point of view of its users.

6 2.3. Intervention of the archivist in the creation and processing phase of documents One of the problems that is most difficult to resolve in the collation and control phase of records and documents is the collection of the documents. Office automation has accustomed people to creating their own personal archiving systems and normally they limit themselves to storing electronic documents in a structure of shared records that follows a standard classification scheme. Users also have difficulty in identifying those documents that should be incorporated into a virtual record and at what point this should take place. To ensure that the system collects all of the relevant documents and that these documents are archived in the appropriate records, it is necessary to: Integrate office automation tools into document management systems so that, for the user, archiving a document in the standard folders and recovering documents is as similar as possible to doing this in their personal folders. Create simple structures for the records that are based on classification schemes that respond to the needs of each unit. Standardise the contents of the records and the formats in which documents are kept. Establish responsibilities: who archives what and where? who has the right to delete documents from the records or to move documents, and until when? etc. In general, the quality of records reflects the quality of the internal organisation of the unit. A well-organised unit, with a rational distribution of work, does not usually have problems incorporating a standardised electronic archiving system; in contrast, it is impossible to implement an electronic archive system amidst administrative chaos Intervention of the archivist in the planning phase All the measures for intervening in the phase of creation and processing of documents require the user to make a series of decisions concerning each document. Is it a document that should be incorporated into the record? Am I the person responsible for archiving it? Which is the correct record? These questions are not exclusive to electronic documents, they are exactly the same as those that must be asked by people working with records on paper. There are, however, certain aspects that make these questions more difficult to answer in the world of electronic documents than in the world of paper documents. In systems based on paper processing, it is easy to distinguish a draft from a final document that should be archived and, moreover, the task of creating and maintaining records is usually in the hands of the administrative staff, who always apply the same criteria. In the world of electronic documents, particularly when e- mail is included, the number of documents that are created and transmitted grows ceaselessly and it is therefore difficult to decide which documents are final

7 and should be incorporated into the record and which documents are "transitory" and therefore should be deleted from the system as soon as possible. Moreover, each person is expected to take responsibility for selecting and archiving their own documents, which increases the risk that different criteria are applied to similar documents. Intervention during the planning phase can solve many of these problems, by introducing archiving criteria during the planning and design of IT systems and administrative circuits. That is: Integrating record management databases into electronic administration document management systems so that documents generated by the databases are automatically archived in the corresponding records. Creating print-outs and models of documents that from the start incorporate the link with the corresponding record 6. Designing documentary circuits that incorporate archiving and implementing them with workflow tools. The circuits should not be confused with the workflows. A documentary circuit precedes the workflow, is designed manually, on paper or on a computer. The workflow is a system to implement this design on the computer system so that documents circulate from one person to another according to the decision made and the procedure to be carried out. The planning phase is beyond the strict areas of responsibility and knowledge of the archivist. It is not usually the archivist's task to design databases or create workflows, neither is it usually the archivist's task to design documentary circuits. However, it is important for the archivist to be on the team working to introduce the archival criteria that will make the later phases of record creation and control, and therefore the evaluation and selection and preservation of the record, easier. 3. IT tools for electronic document management. EDMS systems and ERMS systems In archiving literature on the subject of electronic documents, sometimes authors will talk about Electronic Records Management Systems (ERMS) and on other occasions they will refer to Electronic Documents Management Systems (EDMS). The difference between the two is somewhat blurred; in this article I have chosen the term ERMS to refer to ERMS systems themselves and to EDMS systems that integrate ERMS functions. It is, however, important to clarify the conceptual differences between ERMS and EDMS, as there are products on the market that only have ERMS functions, others that only have EDMS functions and others that integrate both functions Electronic Document Management Systems (EDMS) EDMS applications are tools intended to facilitate collaborative work and knowledge management for organisations in a virtual environment. The heart of

8 the system is a single repository for all the electronic documents of an organisation, centrally structured and controlled so that each user has specific rights in specific directories or sub-directories, according to the authorisation that they are given (for example, a user may read the documents in one part of the repository, add and edit documents in another part or delete documents and create sub-directories in another part). Some of the functionalities included in EDMS systems are: Tools for producing and revising documents as a team, with version control. Tools for working in virtual teams, for example, with spaces for discussion, project management, distribution of tasks. Tools for the publication of information among all users or specific user groups, depending on the associated authorisation for that area of the electronic repository. Tools for finding and recovering information. Workflow tools. Certain EDMS tools on the market also incorporate an ERMS module; others can be integrated into an external ERMS system Electronic Record Management Systems (ERMS) As I outlined above, ERMS tools can be used alone or integrated into an EDMS system 8. ERMS applications combine a record management application with an electronic document repository. The record management application is a database that carries out all the functions of management and control of administrative documents: classification, description, searching, access control and the application of evaluation and selection rules. These functions are exactly the same for all administrative documents, regardless of their format. By applying the same classification scheme, the same evaluation tables and the same description to all administrative documents and records, regardless of their format, we can apply the same rules of conservation to all documents with the same classification and recover all the information associated with a record or subject using a single search. The electronic document repository is also a database that contains documents and a reference to link each document with the corresponding metadata stored in the management database 9. As a result of the integration of the administrative document management database and the electronic document repository, an ERMS is used for: Archiving, classifying and describing all electronic documents and documents and records on paper or in other physical formats.

9 Automatically collecting metadata for electronic documents (for example author, type of document, creation date, key words for searches, record of which it forms part, format). Automatically applying the permits defined for records to documents. Searching using the database fields and accessing full records and documents from the same computer. Applying the conservation calendar to all the documents and records in the electronic and physical repositories. Eliminating obsolete documents from the electronic document repository or transferring them to the archived document repository if they are of permanent value. 4. The elements of an ERMS tool Exactly the same as for a paper record management system, an ERMS tool is based on a structured repository of records and documents. All of the operations relating to the documents and records are carried out in this repository: adding, indexing, describing, editing, recovering, according to the type of access defined for each user, and eliminating or transferring documents to a permanent archiving system The structure of the repository. The classification scheme. In a paper document repository, classification and archiving are two different activities and the physical ordering of records and the classification system are not required to be the same. In an ERMS system, classifying and archiving are the same process and the logical structure and the physical structure are the same thing. The structure that we create must therefore be conceptually correct, but it must also be practical and comprehensible for non-specialised users. If we create structures that are too complex, the archiving process will be more difficult; if we create structures that are too straightforward, the search for relevant documents will be unsatisfactory and it will also be impossible to apply the same table of document evaluation to all the documents archived in the same record. The structure of the repository will depend on each organisation and each project, but nonetheless certain general rules can be defined: Create the repository s structure based on a corporate classification scheme. Give the records titles that are clear and logical for all those using the repository, whether for archiving or consulting purposes. Complicated classification codes should be avoided, as should titles that are long, overly generic or too restrictive. Limit the number of levels that can be created. As a general rule, no more than five levels need to be created. For small organisations, create a single shared structure that is controlled based on authorisation.

10 For large, complex organisations, add the unit level, with its part in the classification scheme. Complement classification with the obligatory collection of certain metadata that allows the document to be recovered in a search (key words, basic data such as the author, the subject, the addressee, the start and end date of the record, etc.). Maintain the link between structure and evaluation and selection tables. All the documents in the same entry in the classification scheme should have the same rules of evaluation and selection. Authorise certain users to subdivide entries in the scheme in order to create records in the same series (for example, the archive creates the entry for Personal records with the associated classification code and evaluation and selection rule, while certain people with authorisation within the personnel unit have the right to start a record for each employee) The content of records ERMS systems are designed to collect electronic documents with no distinction between administrative and non-administrative documents, or between draft and final versions. When we design the system, it is imperative that we decide in which phase the document should be collected. Basically, there are three models: Records contain only final and official administrative documents that are to form part of the record. These are usually documents that have been signed and transmitted, with remittance documents or letters, minutes, etc. Records contain all documents related to the record from the first draft version. In this case, a mechanism is required to mark official documents and to delete, when the record has been closed, all those documents that do not need to form part of the record. The repository has two spaces: one for projects, which is used while the activity is going on, and another with definitive records, which will contain a selection of the documents when the project is closed. Whichever model is used, it will be necessary to give generic instructions on which documents should be included in the record folders, at what point and who should do this. Specific rules should then be defined for each type of record Evaluation and selection tables When the archivist draws up evaluation and selection tables, he or she should include paper and electronic format documents in the same table. A storage rule should be applied to each table that will be introduced into the ERMS system to ensure its automatic application to electronic documents. For example, "Store for 2 years on-line", "Store for 3 years off-line", "Destroy", etc.

11 The same principle of simplicity behind the regulations to be applied to the classification scheme should be applied to the evaluation and selection tables. When preparing the tables, it is necessary to: Link evaluation and selection tables to the classification scheme, so that each entry in the scheme has a single storage rule. Simplify and limit the number of storage rules to as great an extent possible. While ERMS systems can apply the time frames automatically and without human intervention, archivists and users prefer to be able to revise the list of records to destroy or transfer before applying the rule Controlling access One of the strong points of ERMS systems is the ease of authorising different levels of access to the repository for different types of users. Depending on the place of work and the functions, access can be given to some records or to others, and it is also possible to define different levels of access: read-only access, content modification access, access to add and delete records, etc. The authorisation policy will depend to a great extent on the culture of the organisation: some organisations have a very open policy, which favours the maximum possible access to information for the maximum possible number of people, while others want to keep information in the hands of the few people who need it for their day-to-day work. The authorisation policy should be agreed with the organisation management from an early stage and disseminated in the form of an obligatory regulation. Maintaining an authorisation system may be a veritable labyrinth if the way permits are created and maintained is not well planned from the very beginning. Designing a system of permits requires: Basing permits on roles and groups, not on specific individuals. A role is a pattern on which authorisation is based; a group is a list of individuals who share the same rights. For example, our system could have four roles: Administrator (all authorisation), Coordinator (the right to create and modify subrecords, delete documents, move elements), Member (the right to add documents and to search) and Visitor (read-only). A group is a collection of individuals who have the same rights of access to a part of the repository. Each group has a role. For example, all staff in the HR department could be in group X, which has the associated role of Member, which would entitle them to add documents to Human Resources records. Within this department there could be another group, group Y, which has the associated role of Coordinator, and this group may consist only of those responsible for staff records and entitle them to add new records, delete or merge existing records, or to modify records. With this system, if a user changes unit or responsibilities, all that is required is to change the person s group to ensure that they have all rights of access appropriate to their new position within the organisation.

12 Making automatic and synchronising user management wherever possible with network user management, to avoid duplicating the workload and malfunctions between access to the network and access to the EDMS system. Standardising and documenting procedures for the creation of groups, roles and the assignment of individuals to specific groups and roles. For example, the names and codes for each group and role should be standardised Searching for information and document recovery The major advantage of electronic document systems over paper systems is the speed with which information can be recovered; searches that in a paper system can involve days of work can be reduced to minutes. Moreover, all those who have access to the system can carry out searches and find information for themselves, regardless of their physical location. A well-designed authorisation policy will also ensure that each person has access to all those documents and only those documents that they have a right to see. Good procedures for collecting relevant documents and for evaluation and selection ensure that the results of searches are relevant. Searches can be done by: Searching directly in the document repository, navigating through the repository s structure or using natural language search terms. Using the metadata collected automatically by the system or added manually, such as key words, author, date, addressee, title, etc. A combination of both procedures. 5. The integration of an ERMS tool with other information systems Whether the ERMS tool, or an EDMS system, is integrated or otherwise, they will need to be integrated with the office automation applications (word processors, spreadsheets, etc.), the system, the fax machines, the scanners (to be able to integrate paper and electronic documents into the same system) and record management systems in order to make the collection and reuse of documents easier. It will also be necessary to integrate the ERMS system into a permanent archive system. Theoretically, an ERMS system should be integrated with the maximum number of information systems possible; in practice, however, it is necessary to be aware that each system that is integrated increases the overall complexity of maintaining the final system. Each migration of one of the integrated systems to the ERMS system implies a reconstruction of the integration between the two systems Integration with office automation applications

13 As I said above, the collection of documents is one of the critical points of any ERMS system. If possible, users must be able to work with their workplace tools (word processors, spreadsheets, presentations) and save and recover documents from the ERMS using the same office application. The collection of metadata about the document must also be as transparent as possible. If we want to force the user to enter data manually, the information that we ask of the user cannot require a special effort to find and must be useful to the user who enters it (for example, because it makes it easier for them to search for the same document and other relevant documents Integration with An message can be the equivalent of a remittance document, or can itself be a report, a letter, an official document, notice of a meeting or the minutes of a meeting. Many electronic administration documents will enter into the system as annexes to an message 10. What we have said of electronic office documents is also valid for the user must be able to work with the repository of electronic documents from the application itself and the archiving and recovering process must be as simple and similar as possible to the working environment to which the user is accustomed. The advantage of e- mail over other documents is that it is full of metadata (author, date, addressee, subject) that can be collected automatically and used to recover and validate the archived documents. The difficulty in this case concerns selecting the messages that should be archived in the system, as in general there are large numbers of messages that are irrelevant or incomprehensible when taken out of context. The problem stems from two very particular characteristics of the informal style of writing that is used and the exponential increase in the number of s circulating on the network. When electronic documents are collected, it is important to keep the relationship between the message and the annexes and avoid any potential fraudulent modification of any component of the message The integration of paper documents In paper document management systems, electronic documents are printed and incorporated into the record. In an electronic document management system, the process is the opposite: paper documents are scanned and incorporated into the record. If the documents are scanned only as images, it will be necessary to enter manually the metadata that will enable the document to be recognised and recovered. The minimum data that must be recorded for each document is the same as the data that would be collected by a registry system: author,

14 addressee, date of receipt or issue and content. If automatic character recognition tools are used, then it will be possible to index and recover the document using natural language, but it is important to ensure that the metadata is still entered in the necessary fields. If it is decided that paper documents should be incorporated, a decision must be made concerning which documents are scanned and which are not, who scans and who indexes, how the paper and images should circulate and what the final destination is of the original paper document Integration with other record management applications The majority of document management applications are relational databases that record parts of the information in different, interrelated tables. Many of these applications provide output in the form of documents that combine data from different tables. If we integrate these systems with the ERMS system, we must also make the archiving of these documents in the corresponding record within the electronic document repository automatic. It is also a common occurrence for data in applications to be related to documents that have come from outside or that have been created within the organisation (for example, a database for managing subsidies will be related to the application documents and the annexes, to the reports and to the receipts). If these documents are archived within the ERMS system, then it is also possible to integrate the reference of the electronic record into the record management system Integration with the electronic archive system In the same way as for paper documents, electronic documents proceed from the active phase to the semi-active and then inactive phase. Our system must incorporate solutions linked to the evaluation and selection tables for closing records, eliminating obsolete records, transferring those documents with permanent value to a permanent archiving system and maintain semi-active documents in another system, whether off-line or in the background. 6. Managing an electronic administrative document management project A project for the implementation of an electronic document management system is both an archiving project and an IT project and from the very first stages a team is required that includes archivists, IT technicians and wherever possible, end users. Functions must be well defined within the team: archivists should concentrate on the functionality of the system, users on usability and IT technicians on the technical elements and the infrastructure. It is however still important that all the members understand the needs and the points of view of other members of the team.

15 The project should be launched with the support of the organisation s directors and should be able to maintain this support until its completion. To do this, results should be presented periodically and it should be shown that the project is sticking to its deadlines, attaining its objectives and staying within budget. The team should have a project leader who is responsible for preparing a working plan that includes the objectives, all of the steps to be taken and the milestones to be passed, the budget with all expenses and investments that need to be made and the distribution of responsibilities. The project leader should keep the system within the objectives set, within the time frame and within the budget. A practice that is highly recommended is that of dividing the project into modules that, while they are interconnected, can be implemented separately. In this way, it is possible to keep the project to a manageable size, concrete results will be visible at a very early stage and it will be possible to learn from the experience gained during a sub-project so that it can be applied to subsequent sub-projects. Modules can be divided by functionalities, by procedures or by organic units Conception of the system and drawing up the technical specifications The unchecked increase in spending on the budget originally drawn up, the failure to meet deadlines and rejection by users are some of the dangers that can cause a project to fail. All of these problems usually originate with an insufficient analysis of the needs and the potential of the organisation and the design of a system that is vague and far removed from reality. In the process of designing and selecting the IT tool, the team should consider two basic questions: What model of electronic document management system does it want for the organisation? What electronic document management system can the organisation afford? It is clear that the same model cannot be put into place in a relatively small organisation, with a clear mission and a shared vision, with users with a good level of computer skills and with an up-to-date computer network, as in a large organisation that has been gradually computerised in stages, in which old and new computer systems co-exist, with users with different computer skill levels and with departments with different organisational cultures. Before even thinking about a system, the team must make an in-depth analysis of the organisation in which the electronic document management system is to be implemented, its organisational culture, its institutional, legal and organisational framework, and the role that administrative documents play for this organisation, the level of computer skills of the future users and the computer infrastructure available.

16 Once an in-depth knowledge has been gained of the needs and the possibilities of the organisation, the team should outline the objectives and the limits of the project in as much detail as possible, should decide on the processes to be included, the documents that are to be part of the project and which users will be affected. The maximum possible number of documented and accurate decisions must be taken during the design phase, given that as the project advances, changes will be more expensive, more difficult to implement and will have a more negative impact on the project's deadlines. Finally, the technical specifications that the IT tool or tools that will be used to implement the project should meet can be defined. Technical specifications must be specific and complete, clearly explaining what parts the system should have, the standards 11 it is to fulfil, the functionalities it is to have, on which platform it should operate and with which systems and into which versions of these systems it should integrate Choosing the software When choosing software, the functionalities of the program, the IT requirements and the capacity for integration with the organisation s IT platform should be evaluated, but it is also necessary to evaluate the quality-price relationship, compliance with international standards and the proximity and quality of customer service. It is worth contacting other organisations that use the software under evaluation in order to find out their opinion of both the program and the vendor, and to see how the software works once installed in a real environment. The majority of programs for electronic document management that exist on the market have certain basic functionalities and certain complementary modules. Many of these programs offer the option to adapt the program to the specific characteristics of each organisation or each specific project. While in theory the software should adapt to the needs and requirements of the organisation implementing it, experience shows that the software that offers the maximum possible number of functionalities that are required from the start should be selected, and the system in question can then be adapted to the peculiarities of the program. Adaptations should therefore be limited as much as possible, as they are expensive, increase the complexity of the system, increase the possibilities of error and need to be redone every time all or part of the system is updated Development, testing and installation of the software When the software has been selected and the functionalities and modules that we want to introduce, the modifications that we want to make and the integrations with other systems that we require have been studied in depth, we may find that we have to modify or complete the initial technical requirements. If this is the case, a written document should be drawn up that describes

17 requirements in detail and that requests the vendor to produce a study which includes requirements, the proposed solution and the evaluation in terms of days of work and budget. This study is essential if we are then to be able to accept or otherwise the software provided by the vendor. The vendor will then adapt, test and install the system. Before installing the program in production, it must be put through an intense and systematic session of tests to check that it fulfils requirements, to detect any possible errors that must be rectified and also to check whether there is any interference of the program with the other programs with which it is to be integrated. IT technicians, archivists and end users should participate in these tests and all of the results must be systematised and documented. The test period will consist of the following parts: Installation of the software in an experimental environment. Preparation of the set of tests, using the requirements that have been incorporated into the study. The series of tests must be complete and systematic and should include all types of variables (for example, if a series of tests is to be carried out concerning integration with the program, tests must be carried out with messages of different sizes, with and without attachments, internal and external, sent to a single addressee, to several, to mailing lists, etc.). Carrying out the tests, consolidating the results and communicating them to all the members of the project and to the provider so that any problems that have emerged can be resolved. Installation of the modifications and repetition of the complete series of tests. When the program operates correctly, its installation in the production environment and the repetition of the set of tests. When all the tests have been successfully completed, the system will be ready to go on to the next phase Standards and procedures When the system is fully defined and operates in a production environment, but before its implementation begins, the standards and procedures for its administration must be decided and documented in manuals. A minimum of two manuals will be required: one for the system operating administrators and another for the users of the units. These manuals will serve as a reference tool and also as material for training courses Pilot test The objective of the pilot test is to gain experience and to refine the system before proceeding to the implementation phase throughout the organisation. The pilot test is a trial of the program, the rules and procedures, the materials and the implementation process itself.

18 For the pilot test, a group should be selected that is small but representative of the organisation and that is interested in the project, as staff will be required to dedicate part of their working time to the test. The parts of the pilot test will be: Selection of the pilot group. Presentation of the project to the members of the group. Installation of the program. User training. Start of a test and monitoring period. Evaluation and conclusions. Modification of the elements of the project identified in the pilot test as unsatisfactory or with potential for improvement Implementation An ERMS project, however well designed it may be and however many functionalities it may have, will fail if we do not ensure that everyone in the organisation uses it directly or indirectly. At the implementation level, this means that we must achieve an acceptance level similar to that of and office automation tools. Implementing an ERMS system in a unit or working group will always involve changes in working processes. When the implementation begins in a unit, it will therefore be necessary to spend time demonstrating the new IT tool and ensuring that the unit or group incorporates this tool into their day-to-day work. If this is restricted to training users and installing the tool without prior groundwork and a later follow-up to this, implementation is bound to fail. It is essential to begin implementation with a realistic plan that balances the implementation of the system as quickly as possible with its more extensive implementation in each unit. Implementation must begin with the units, the procedures or the users where it is clear that the system is most likely to be successful with the minimum time and effort. The plan should also include indicators and tools to measure the progress of this implementation. For example, we can measure the number of users connected to the system each day, the number of documents consulted per user or the number of documents in the repository. For each unit, the following steps should be taken: Information. The project should be presented to unit heads or to team leaders first and then to all personnel involved. A study of the specific needs of the unit and the adaptation of the system. In this design, the responsibilities of each member of the unit should be clearly identified.

19 Staff training. Selection and migration of the documents scattered between disks and in-boxes to the ERMS system. Personalised monitoring of the implementation for a number of weeks until all users have incorporated the ERMS system into their day-to-day work and there is no longer any possibility of going back Maintenance One of the common errors in projects of this type is failure to anticipate the sustainability of the system once the project is completed and the budget has run out. When designing the system, an estimate of the economic and human resources required to maintain the system in operation and up-to-date and how responsibilities should be divided between IT technicians and archivists should be incorporated. To maintain the system in operation, the following at least will be required: An operating administrator who manages users and authorisation, who creates and modifies structures, who applies evaluation tables and who controls the use and abuse of the system. A database administrator who is responsible for the technical maintenance of the database, security copies, problem-solving and the installation of the system for new users. A training programme for new users and a revision programme for other users. A maintenance contract with the provider for resolving technical problems, answering doubts and that includes the migration of the program when new versions are launched. When the system is implemented, it will also be imperative to continue revising its use among the units, detecting and correcting malfunctions, listening to the new requirements that emerge and trying to adapt and refine the system to these new necessities. Finally, it is necessary to be constantly aware of the evolution of the organisation, to ensure that the program will continue to operate although there are changes in the platform, in the other systems into which this system is integrated and also in the organisational structure. 7. Conclusions At present, the conceptual elements and the IT tools necessary for the successful implementation of ERMS systems in organisations do exist. The management of electronic records uses the same conceptual tools as the management of paper documents, although it requires the incorporation of the phases of document planning and processing into the concept of document life

20 cycle, as it is at that point that decisions are made that will irreversibly affect the phases of record collation, evaluation and final disposal. An ERMS project, or an EDMS project that includes the components of an ERMS system, is a complex project that will affect all the staff of the organisation in which it is implemented and a project that may fail if the process from conception of the system to the project s completion is not dealt with carefully and methodically. Each organisation has different needs and means that must be analysed, the system that is designed must provide concrete solutions to concrete problems, and objectives such as "improving general management" or "sharing information" are of no practical use for the project. Objectives must be proposed that can be translated into requirements and that can be measured quantitatively and qualitatively. Whatever the system that we end up designing and whatever program may be used for this system, we must always try to keep things simple. The classification scheme should be as short as possible, the number of storage rules should be as low as possible and the control of users and authorisation should follow certain clear rules and an authorisation matrix that is as standardised as possible. There is no tool available on the market that will fully adapt to the specificities of our organisation and to our requirements, but we should try and avoid introducing changes and adaptations that are not imperative for the project. Designing, implementing and maintaining an ERMS system requires IT technicians and archivists to work as a team, each one working within their own field, but with a good understanding of the task required from each person. IT technicians must understand and respect the principles, the way of working and the interests of archivists, while archivists should also understand and respect the point of view of IT technicians, along with their requirements and their ways of working. An ERMS project must end one day. The project must leave behind a system that works and that is used, and the structure and resources necessary to keep this system active and evolving. Notes 1 For information on the state of electronic document management in Catalonia, see AGELET, F., et al. La gestió dels documents electrònics a Catalunya: un estat de la qüestió. Lligall, 2002, no To cite just one well-known example, the International Council on Archives has still not published a specific ISAD standard for the description of archived documents in electronic format. 3 International Council on Archives; International Records Management Trust. Managing Electronic Records. A Training Programme. International Records Management Trust. London, 1999 [see the website: 4 For information on permanent storage projects of electronic documents, see the project experiences at 5 It should be remembered that the security copies that IT technicians make systematically of all their systems and contents are not archive copies. The aim of these copies is not the long-term conservation of the information, but rather to recover as much information as possible in the event of a failure in the original system.