Architecture for Archiving - OCHA

1 > PURPOSE

As the number of documents that any organization deals with is continually increasing, the need for a document management, records management, and archiving solution [1] is also ever increasing. Therefore, the purpose of this architectural document is to describe how different systems and work procedures within OCHA can contribute to a solution for OCHA. This document will examine both existing systems and the general workflow within OCHA. Finally, recommendations for both recordkeeping system requirements and the modification of functions in the office’s workflow will be made.

2 > SCOPE

This document makes an attempt to incorporate the major systems in use within OCHA as well as the general workflow within the office. Although it is recognized that there are several smaller applications that are currently being used it is assumed that a vast majority of the items to be captured will originate in the major systems.

This document also attempts to give consideration to all elements of the office ranging from Headquarter to Field Office needs.

3 > CURRENT SYSTEMS

The systems currently used by OCHA that would be affected in some capacity by an Archiving system are:

System Name	System Function	System Platform	Comments
OCHA Email (HQ)	Email Exchange	Lotus Notes	Varity of email formats & attachments
OCHA Online (CDR)	ochaonline.un.org (OCHA Internet & Intranet)	Microsoft IIS Server, ASP, and SQL Server	Documents stored in variety of format and in one directory
Correspondence – Registry	Process incoming materials	Lotus Notes database application	Difficult to manage & modify. Documents stored in PDF format.
Field Guidelines	Information resource	CD-Rom – web interface	Variety of files – good resource for field office
Relief Web	Specialized Website	Lotus Notes	Variety of documents from a variety of sources (OCHA & non-OCHA)
Shared Directory (S: in NYC)	Active documents of staff	Microsoft Windows	Unstructured, variety of document types, sources, etc.
Quick Place	Project work space	Lotus Notes	Huge variety of documents and text stored in user defined structures
Field Office Email	Email Exchange	Lotus Notes	Larger office have dedicated server with communicates with HQ
FIS Databases (WWW, Mapping, Contacts, etc.)	Assist coordination of activities in the field	Various	In process of development
Shared Directory	Active documents of staff	Microsoft Windows	Unstructured, but FIS Filing System is under development and would give structure to these documents

* For simplicity, the Geneva office is considered part of the HQ inclusions

See Annex 1: OCHA Systems for a graphical representation of the systems by location.

4 > WORK PROCEDURES

4.1 > Work Groups and Related Document Types

Although definitely not all encompassing, a sample picture of the documents associated to some of OCHA work groups are:

Group Name	Document Type
Front Office (Office of the USG)	Final version of documents (for signature)
Admin Office (Geneva) & Executive Office (NYC)	Administrative documents
Desk Officers (and Field Offices)	Country related information, Situations Reports
Policy Branch	Policy, Policy research of Human Rights, IDPs, etc.
Advocacy Unit	Media / Public Relations related, Press Statements, Situation Reports
CAP Unit	CAP related document / materials

4.2 > Organizational Structure

The typical structure found in OCHA follows a very traditional arrangement. An example of the structure in OCHA is:

4.3 > Movement of Formal Outgoing Documents within OCHA

4.3.1 > Common Movement

Outgoing documents in OCHA tend follow a standard path of approval before being released. In this process, there can be three different locations for approval within the organization. Depending on the nature of the document, this approval level increases within the organizational structure.

1. Chief of Branch

2. Chief of Staff or Special Assistant, USG Office

3. Under Secretary General

Graphically represented as:

NOTE: In general, correspondence emanating from Geneva, that requires the

USG signature, will follow the same path with the exception that a

copy will be directed to the AERC/Director Geneva.

4.3.2 > OCHA Geneva

For OCHA Geneva, the AERC will normally be responsible for signing regular correspondence addressed to Permanent Representatives of UN Missions based in Geneva, members of the IASC Working Group and other NGOs based in Geneva.

> For simplicity, this document will consider the AERC equivalent to a Branch.

4.4 > Responding to Incoming Correspondence

The chief of each branch or office is responsible for designating the officer who will draft the response. This person is usually the desk officer for the area concerned.

5 > CURRENTLY CAPTURED

5.1 > Registry (Incoming Items)

> These include all items sent to OCHA by another agency or outside party;

> These items are currently catalogued, scanned and disbursed by the Registry group;

> The system is a Lotus Notes database;

> A new (empty) database is set-up each year;

> Paper items received are bundled and sent to off-site archives;

5.2 > Formal Documents (USG Signature Required)

> These include all documents signed by the Under Secretary General;

> Each document is copied after signing is completed;

> Each document copy is manually filed;

> Details of each document are recorded into a Microsoft Word document;

> Each document should be received with a routing slip (see OCHA Correspondence Manual, Section II D, Paragraph 12);

5.3 > Geneva Items

> Waiting for detailed feedback from Geneva about archiving of document – perhaps only Registry sending their files to archives? If so, then this section can be moved to Registry;

> The office archives paper only;

> Archiving is performed in a very traditional sense (collection, boxing, related forms, and then sent to archives);

> Electronic items are not captured unless there are printed;

> Items are only archived based if the individuals deems them to have importance;

6 > NOT CURRENTLY CAPTURED

6.1 > Email

> OCHA email is entirely based in Lotus Notes;

> Email to be placed in a recordkeeping system is a sub-set of all incoming and outgoing email that that is sent/received by OCHA staff or consultants;

6.2 > Other Formal Outgoing Items (Branch)

> These include documents or reports released by OCHA that do not require a signature;

> The items require the approval of the Chief of Branch before they can be released;

6.3 > Other Documents (Unit / Individual)

> Many documents are created in OCHA and are never sent outside the organization;

> Supporting materials to other OCHA documents may be deemed as retainable material;

> Each unit has a special assistant assigned whom is generally knowledgeable about what work is being performed inside the given unit;

6.4 > Field Office Documents

> There are no formal procedures in place to capture items created by a Field Office;

> There are essentially three things that happen to OCHA Field documents upon closure:

1. Stay in the Office of the Resident Coordinator;

2. The FO decides, in agreement with the desk, which documents to destroy and which to transfer to Geneva and/or New York;

3. Originals may be left with UNDP, or any other local service provider, for the purpose of an audit or other necessity;

> Consideration is given to transferring any financial reports received from NGOs/Agencies that received funding at local level through OCHA (NGOs funding mechanisms such as in Angola, DRC, Indonesia and DRPK) to Geneva.

6.5 > Facsimile

> Faxes are sent and received using traditional fax machines;

> Although the outgoing faxes may be captured at other points, the incoming faxes are not;

> Any given fax machine is not necessarily assigned to a specific unit or branch;

> OCHA does have access to an e-fax solution provided by the UN, but has not taken advantage of it;

7 > PROCESS AND CAPTURE RECOMMENDATIONS

7.1 > Purpose of Implementation

For OCHA, there are three purposes for the set-up of a recordkeeping system. Each purpose corresponds to one of the three specific aspects in a recordkeeping system. There are:

1. Document Storage ® Document Management (Individual Level)

2. Knowledge Sharing ® Records Management (Unit / Branch Level)

3. Institutional Memory ® Archiving System (Organization Level)

7.2 > Conceptual Functionality of the System

To best fulfil the purposes outlined above, the system should be envisioned as working at three different levels. Essentially, most items will be inserted into the system at the individual level and may eventually progress to the archive. Therefore the system should be able to perform both formal archiving as well as general document management functions.

The common denominator to each level is the OCHA Classification Scheme. This scheme is currently under development and has taken into consideration the OCHA Classification Scheme maintained by UNOG Archives Classification Scheme, the Registry System information, OCHA groups’ filing structures, and other UN Agencies’ Classification Schemes.

7.2.1 > Individual Level

> OCHA staff would be able to use the system to store any type of items, including personal files;

> Only the staff member will have access to view and edit these files;

> Only the staff member can open up the file for viewing and editing at the unit / branch level;

> Staff member will file items according to the OCHA Classification Scheme;

> True document management features should be available in order to in order to extend the system to groups such as the CAP Unit where such things as versioning, workflow, and approval are necessary;

7.2.2 > Branch/Unit Level

> Items can originate from two sources:

1. Individuals who open up their items;

2. Unit / Branch activities that submit items as part of their functions (e.g. Registry);

> OCHA Classification Scheme is used for the folder structure

> When items are opened by individual users, the branch staff will simply find them in the same OCHA Classification Scheme location, but in the branch cabinet;

> Items can be viewed / updated only by those authorized to do so;

> Any changes are recorded as a new version of item;

7.2.3 > Organizational Level

> Items that are to be archived;

> Guidelines on which items “must” be archived should be provided to all staff (see 7.3 “Type of Documents / Items to Archive” for details);

> OCHA Classification Scheme is used for the folder structure

> When items are opened by individual users or a specific branch member, OCHA staff will find them in the same OCHA Classification Scheme location, but in overall OCHA cabinet;

> Viewable permission is still maintained;

> Item is not editable;

7.3 > Type of Documents / Items to Archive

The comparison in Annex 2 “What to Archive – A Comparison” makes it quite clear that the items that should be archived are OCHA Items and Working Items. These are items that have been created by OCHA, plus those items used as important reference materials to OCHA work (items that affect OCHA business).

For archival purposes, the “OCHA Items and Working Items” strikes a nice balance between not capturing enough and capturing too much. Although it may present questions from general users in terms of defining a working item, that will be a mater of training rather than of system function.

If the solution includes a document management type aspect, strong consideration should be given to allow the expansion of material that a regular user can store in this part of the system.

7.3.1 > What Should Be Archived

> All OCHA created document / items

> Other items used as important reference materials to OCHA’s work

> Items / Documents that affect OCHA’s business

7.3.2 > What Should Not Be Archived

> Items / Documents received from other organization that are not significant to OCHA’s business.

> Example: NGO project document we place on OCHA Online or Relief Web for others’ reference benefit

> Example: Vacancy announcement placed on Reliefweb for another agency

7.3.2 > Retention Period

> Archival retention should be automatically determined by the system where possible;

> The length of time should be based on the item’s content, context, and classification where possible;

> See the RecordKeeping Policy for additional details regarding retention and disposal.

7.4 > New or Modification of Office Functions

7.4.1 > Registry

> Re-engineer system to adhere to OCHA Metadata Standards;

> Re-engineer the work process to reduce scanning and data entry time

1. All data entry performed at one time (each entry assigned a barcode),

2. Documents are separated with the barcodes and placed on a scanner,

3. Scanning automatically submits the document to the recordkeeping system, in PDF format, and attaches it to the metadata already entered.

> Automatic addition to the recordkeeping system, either through modification of the system or re-engineering the process and system, would greatly improve the retrieval and archiving of these documents;

> See Annex 3 Registry Proposal for proposed workflow for the new registry.

7.4.2 > Formal Documents (USG Signature Required)

> Automate the currently manual process of copying and cataloguing all documents,

> Upon set-up of the registry system, the same solution could be used for the USG office,

1. Assistant enters metadata about the document,

2. Upon signature, the document is scanned (with barcode sheet),

3. The document is stored in PDF format and is attached to the metadata entered.

7.4.3 > Email

> Any recordkeeping system put in place should integrate with Lotus Notes and provide easy capture options;

> If an integrated system is not set-up or cannot be afforded on all desktops, then it is recommended that a special email address be created where anyone can send his or her emails for capture;

> See Annex 4 Email Capture for a detailed recommendation;

7.4.4 > Other Formal Outgoing Items (Branch)

> Each branch deals with a significant number of formal outgoing items that are currently not captured in other workflows described earlier;

> Should a document management (type) system be assigned to individual users, the staff could simply “open up” their documents to the branch level for sharing purposes;

> Should a system not be rolled-out to all users, a branch secretary could become a capture focal point for any general branch document. Using a process similar to the registry, the process would be streamlined and ensure consistent entry and classification while minimizing related costs (licensing, training, etc.).

7.4.5 > Other Documents (Unit / Individual)

> Each unit deals with a significant number of items that are currently not captured in other workflows described earlier;

> By extending a document management (type) system to each individual user, staff would be able to include any document, including personal items, that they desired;

> Given the item is already in the system, the user could open the document to a wider audience (branch and/or organization);

> With the item already in the system, the archiving requirement could simply become a function in the system, either manual or automatic;

> Should a system not be rolled-out to all users, a unit secretary could become a capture focal point for the group. Using a process similar to the registry, the process would be streamlined and ensure consistent entry and classification while minimizing related costs (licensing, training, etc.).

7.4.6 > Field Office Documents

> At the moment, the FIS group is considering the implementation of a Field Office filing application. The application should be one of two options, of which will be affected by the solution selected in Headquarters;

1. A remote (or offline) version of the system being used by OCHA HQ where:

> System allows a user to selectively publish subsets of the server-based repository to a portable database on the mobile computer;

> System allows users to capture items onto the mobile computer and upload the index and files to the central server at a later time;

> Synchronize with HQ a predefined times;

2. Custom-built software that integrates into any HQ system

> Upload of index and files to OCHA HQ system at predefined times would be considered the minimum;

> Download of index and files from the OCHA HQ system should be considered as it would extend item availability to the office;

> If a system is not purchased or developed, strong consideration should be given to setting up a special centralized email address that would allow field offices to submit any documents it considers should be captured and retained;

> Any system should adhere to appropriate standards which are required for integration into the Headquarters’ system;

> A searchable web-interface to the recordkeeping system will allow the field office to search the contents.

7.4.7 > Facsimile

> Set-up the UN e-fax solution such that it is received and processed by one central person/group, such as the registry;

> Depending on the UN solution, the e-fax service could be directly linked to another system, such as the registry;

> The one public OCHA fax number should be transferred to this solution. The other fax machines are seen to have low volume and mainly for outgoing faxes;

7.5 > Modification of Other Existing Information Systems (in order of action)

7.5.1 > OCHA Online

> Modify the document attachment aspect to pull documents from the recordkeeping system;

> Provide a facility to add a new document which actually puts the document directly into the recordkeeping system;

> Modify the system to adhere to the OCHA Metadata Standards;

> Investigate the ability to capture or integrate the web page into the system (capture the web page content – not just any attached documents);

7.5.2 > Field Guidelines

> Create from documents in the recordkeeping system rather than OCHA Online;

7.5.3 > Relief Web

> Recordkeeping system could act as a document source for all OCHA documents;

7.5.4 > Quick Place

> Investigate the real need to have any dynamic link to Quick Place;

> As Quick Place is essentially a working space, perhaps only the final versions of any document should be placed in the recordkeeping system;

> Investigate the ability to send documents from Quick Place into the recordkeeping system (choice of logged in user);

> Investigate the ability to have Quick Place link to documents in the recordkeeping system.

7.5.5 > Shared Directories

> Shared directories will continue to function as is;

> Assuming a solution is set-up with document management capabilities, these shared directories may be envisioned as becoming obsolete as they could be replaced in the document management system.

8 > TECHNICAL SCENARIOS

In order to accomplish the above recommendations, there are several different possible technical scenarios that can be considered. These are:

8.1 > Full Third-Party Installation

> An “off-the-shelf” package is purchased and customized to meet OCHA’s needs;

> Certain systems, such as the Registry, are re-engineered to leverage the power of the selected package;

> Use existing interfaces to perform general document and records management;

> Advantages include strong system design, strong security, modularity, and the flexibility to build custom systems;

> Disadvantages include cost and reliance on specific package;

> Possible packages included TRIM Context and Documentum;

8.2 > Limited Third-Party Installation

> An “off-the-shelf” package is purchased and customized to act as a central repository for OCHA’s needs;

> Systems would only be modified in order to use the API provided with the package;

> Advantages include strong system design, strong security, flexibility in system development, limited number of licenses required;

> Disadvantages include cost and reliance on specific package;

> Possible packages included TRIM Context and Documentum;

8.3 > Parallel Systems

> An “off-the-shelf” package is used for archival purposes and to run certain systems;

> OCHA custom systems are used for document management purposes;

> The parallel systems are synchronized at pre-defined intervals;

> Advantages include clearly defined archive (avoids confusion) and limited impact on existing systems;

> Disadvantages include complex synchronization and the cost of “off-the-shelf” package is still high;

8.4 > Third-Party Scanning Solution

> An “off-the-shelf” package is purchased to re-engineer capture points;

> OCHA builds its own back-end database and its own custom API for the database;

> Advantages include specialized package interface, highly customized for OCHA’s needs, and little reliance on outside expertise.

> Disadvantages include long development time, security concerns and possibly large development team;

> Possible packages include Kofax Ascent Capture and Captovation eCapture;

8.5 > OCHA Only Systems

> The entire database and all systems are developed and/or modified by OCHA;

> OCHA builds its own back-end database and its own custom API for the database;

> Advantages include customisability and flexibility.

> Disadvantages include long development time, security concerns and possibly large development team;

9 > TECHNICAL RECOMMENDATION

Since each of the technical scenarios listed above will require some form of investment, a decision must be made on how to minimize both the financial aspect and the implementation time while maximizing the solution quality.

The scenario described in 8.1 “Full Third-Party Installation” is highly recommended. This solution has the following advantages:

> Proven “back-end” storage system to house items and their metadata;

> High quality customisable user interfaces available including scanning, document management, and records management solutions;

> Web interface will provided with packages;

> Flexibility remains with the ability to build own solutions and connect to the package using a well-established API;

> Design and implementation time is reduced as the “back-end” is already set-up and customisable interfaces are already pre-defined;

> Strong security measures are already built in (do not have to rely on a single programmer);

> Software packages provided multiple integration points: scanning, email, automated desktop folder, and application interface (direct entry).

> Support from the software company;

> Upgrades periodically available from the software company;

> Licensing costs will only be related to the number of users using the solution directly (not through a system using the API);

> Selecting the packaged used by UN ARMS and several other UN Agencies would provide benefits such as future portability, automatic archival to UN ARMS, supports, and lessons learned;

Although outweighed by the benefits of this scenario, there are disadvantages with this choice. They are:

> Database is proprietary;

> Potentially significant initial investment cost;

> Cost of future upgrades and licensing will depend on the vendor – not on OCHA’s budget;

> Potentially purchasing software that has capabilities beyond OCHA’s current needs (may be able to leverage these capabilities in the future);

> Maintenance of such systems usually requires someone with knowledge of the package;

> OCHA would become reliant on one solution and thus lose some flexibility in terms of other future solutions;

10 > SOFTWARE / HARDWARE REQUIREMENTS

10.1 > Software

10.1.1 > Recordkeeping Software

It is recommended that OCHA implement a software solution that has the following features:

> One central repository;

> Common interface

> High bandwidth users can use an application interface;

> Web interface available for all users (especially for field office);

> Central search facility

> One central search facility for users of the system;

> One central web-based search facility for all OCHA staff (including the field offices);

> Inter-operability with other OCHA systems:

> Allow other systems to automatically deposit/retrieve documents;

> Communicate with other applications through electronic data exchange standards;

> Applications such as OCHA Online could use the system as its source for attached documents on the website – in this sense, it would be working as a document management facility;

> Other systems could be modified to automatically submit a document to the system when added by a user;

> Flexibility to allow OCHA to define its own metadata tags;

> Flexibility to allow OCHA to define how searches are performed and how their results are displayed;

> Strong security features;

> Document Management capabilities;

> E-signature availability for future usage;

> Workflow management/process capabilities – will help in Enterprise Content Management.

For additional information on what a recordkeeping system may have as functional requirements, it is recommended to read the United Nations Archives and Records Management Section’s “Functional Requirements for Recordkeeping Systems”.

10.1.2 > Intermediary Software for OCR & PDF Conversion

It is recommended that OCHA implement an intermediary software that has the following features:

> Ability to convert a given scan to Adobe PDF format

> Provides consistency in format;

> Reduces future refreshment cost;

> Reduces end users requirements in terms of opening archived items;

> Ability to perform OCR on the scanned document

> Allows for searches to search through the content of an item rather than just its metadata.

10.2 > Hardware

In order to implement the software mentioned above as well as the system re-engineering suggested, the hardware listed would be recommended for OCHA NYC. These are items above and beyond the regular IT related items such as desktops and printers. (A similar set of hardware may be required in Geneva depending on requirements and connection speed to NYC)

Hardware Item	Quantity	Purpose	Special Technical Needs	*Estimated* Cost
Server	One	· Run central recordkeeping software · Act as the central	· Back-up facilities such as RAID · Multiple processors · Significant RAM & Hard Disk Space	$20,000
Server	One	· Intermediary server that automatically converts scan to PDF and performs OCR (for future searching)	· Fast processors & significant RAM to speed the intermediary process	$10,000
Scanners	Increases over time (one per floor/group)	· Scan document and automatically send to intermediary server · Handle large work load with acceptable speed	· Double sided scanning · B/W and Color · Speed · Software integration	$300/each

Note: Additional hardware may be required depending on the solution selected and the capacity in which the solution is implemented.
11 > MANAGEMENT REQUIREMENTS

11.1 > Finance

It is expected that management will provide adequate financial resources, both monetary and personnel, so that the recordkeeping system can be put in place effectively. Without sufficient financial support, any solution will be difficult to implement successfully.

11.2 > Training

Training will be a very important aspect of a successful implementation. As it would be recommended to implement the system in stages, the training would also follow suite. The envisioned training would be:

11.2.1 > Registry

> Subject: How to use the re-engineered registry system and the recordkeeping system;

> Performed By: ITS staff member responsible for designing and re-engineering the registry system;

11.2.2 > Office of the Secretary General – Special Assistant

> Subject: How to use the automated system to enter formal documents;

> Performed By: Registry staff (and ITS staff member responsible for system if needed);

10.2.3 > OCHA Staff (by Unit or Branch)

> Subject: What is the Recordkeeping System, how to use it, and what it should be used for;

> Performed By: Registry staff and ITS staff member responsible for the archiving system;

11.2.4 > Branch/Unit Archivist (capture of outgoing documents)

> Subject: How to use the Recordkeeping System for specific capture points;

> Performed By: Registry staff (and ITS staff member responsible for system if necessary);

11.3 > Personnel

When considering the personnel requirements of implementing a recordkeeping solution, OCHA must consider the industry movement towards Enterprise Content Management (ECM). A dedicated staff member would keep abreast of current trends/software and continually undertake related projects. On the other hand, using short-term consultants would provide expertise and flexibility.

A more detailed list of advantages and disadvantages of different personnel scenarios are listed below:

Scenario

Advantages

Disadvantages

Consultant for Set-up Only

· System is setup relatively quickly

· Dedication to project

· “Relatively” quick recruitment time

· Small costs – versus staff member

· May require additional resources in the future to perform fixes or enhancements

· Little in terms of future-vision for ECM and or Document Management

· Project may expand in requirements as work is undertaken

Consultants “As-needed”

· Flexibility to recruit as needed

· Recruit experts for the specific task

· Dedication to project

· Knowledge is lost each time a consultant leaves

· Cost + recruitment time may outweigh the cost of having a staff member

· Current staff member must still be assigned responsible (dealing with users, hiring consultant(s), industry understanding, working groups, etc.)

Part-time Staff Member Assigned

· Dedicated staff member for: investigating future options, dealing with users, retained knowledge (from consultants), and user help

· Duties can be added to current staff member OR other duties could be added to new staff member

· Time can be redirected if Arching related work is small at any given time

· Quick to respond to simple archiving needs (not necessary to recruit a consultant)

· Retained Knowledge

· Existing staff members would require additional training

· Diversion from archiving may result in lack of dedication/support given to ensuring the archiving system is successful

· Possibly a slow start – either becoming familiar with the archiving aspect or with the other assigned duties

· May still need to hire a consultant to perform specialized work

Full-time Staff Member (with strong archiving knowledge)

· Very quick to respond to any arching needs (not required to recruit a consultant)

· Specialized work could be performed by staff member

· Future considerations/concerns (document management, ECM, etc.) can be continually studied and applied to OCHA for best practices

· Retained Knowledge

· May require recruitment of new staff member

· Cost – in terms of future enhancements/projects that would be undertaken & staff member package

ANNEX 1 > OCHA SYSTEMS

ANNEX 2 > WHAT TO ARCHIVE – A COMPARISON

When considering items to archive within OCHA, we can break the scenario into three categories of which each has its advantages and disadvantages. These groups are: OHCA Only, OCHA & Working Items, and All Items. Below is a comparison of these three groups.

Document Category	Advantages	Disadvantages
OCHA Only	· Easy to define · Small number of items · Easy to manage · Expandable · Cheapest option · Small amount of intervention (may required little work from a regular user)	· Limited Scope · Miss a lot of critical/useful items · What are the benefits from the user’s point of view? (quality of information stored) · Hard to gain buy-in (hard to sell the benefits to users)
OCHA & Working Items	· Best definition of what may be retrieved · Captures the most used / most important documents · Beneficial for future retrieval · Balanced in terms of search benefits, number of stored items, and cost	· Hard to define (from user point-of-view) · Users may be confused if a given item should be included · Larger in project scope and cost
All Items	· Very easy to define · Covers everything (no missing)	· Heavy work load on the users · Most experience (all systems are affected and disk space requirement) · Search and retrieval is “heavy” · Number of items grows very quickly

ANNEX 3 > REGISTRY PROPOSAL

ANNEX 4 > EMAIL CAPTURE

There are four capture options available for OCHA’s email:

Personal Email Box and Lotus Notes Archiving
Central Email Address
Do-It-Yourself
Central Capture of All Email

By reviewing the advantages and disadvantages of each options (see below), it is recommended that staged approached be taken to capturing email. This approach would be:

Create a special email address to which staff can send any important emails/attachments for incorporation into the recordkeeping system (trial group will help determine work load).
Assign a specific unit to manage this new inbox.

> The Registry Unit would make a good candidate, as they are the most familiar in the organization with classifying documents.

Automate the processing of this inbox as much as possible

> Automatic importing into the system would save time and effort;

> Classification could be performed inside the system.

Over time, the system could be rolled out to all email clients

> Training of staff members would be required;

> Potential cost consideration (dependant on solution);

Maintain the central email address

> A central address will still allow staff/groups to archive in the case they do not have the archiving system installed either due to cost or due to low bandwidth (field offices).

Email Archiving Option

Advantages

Disadvantages

Personal Email Box and Lotus Notes Archiving

· Lotus Notes is already being used as Email application

· No additional software required (cost, set-up, etc.)

· Relies on individuals

· Not-centralized

· Cannot search through other’s email

· Loss of knowledge if user leaves OCHA

· Not structured & does not adhere to OCHA Archiving Policy (retention, metadata, etc.)

Central Email Address

· Easy implementation (little training)

· Central group is more knowledgeable and efficient (controlled & consistent classification)

· Users require little understanding of system or archiving (retention, structure, etc.)

· Low cost (licensing only for one group)

· Relies on individuals to send to send email (additional task)

· Only capturing what users deem as “important” material

Do-It-Yourself

· Puts full responsibility with staff

· Potentially better coverage if staff buy-in

· Training for all staff

· Potential to become a “mass dumping ground” for people’s email

· Misclassification of items

· Licensing Cost

Central Capture of All Email

· Easy logic

· Every important email would be captured

· No staff involvement required

· Can implement central capture rules (if certain words, then archive)

· Capture unnecessary items (e.g. junk & personal email)

· Classification would have to be automatic (large volume)

· Potential misclassification is quite high which may result in a useless archive

[1] Document management, records management, and archiving solution will be referred to as a Recordkeeping solution for the purpose of this document.

UN-CS-RAI-USAA-DB01-2004-00202

OFFICE FOR THE COORDINATION OF HUMANITARIAN AFFAIRS

ARCHITECTURE FOR RECORDKEEPING