Document Management System Workshop

by Karl Lawrence
I.	Introduction
A.	Classifying Information Management and Access Needs
The World Bank is a knowledge-based organisation whose competitive advantage lies in its vast economic development experience working in numerous countries and across a broad range of sectors over the last 50 years.  A key objective of the recently-approved Strategic Compact is to more effectively harness and exploit the knowledge and experience of the Bank’s staff to deliver more timely and effective products and services to its member governments.
As with most knowledge-based organisations the Bank's staff have a variety of knowledge and information management and access needs.  These needs fall into the following complementary categories:
•	Knowledge Management: generating new knowledge both through formal research and through learning via networks; capturing information and knowledge through the systematic assembling of existing information; project debriefing; commissioning contributions by Bank experts in subject areas; pulling, reviewing and analysing information from existing internal and external sources; and drawing on discussions from electronic discussion tools and on-line communities.
•	Information Access: access to formal and informal documents and expertise.
•	Workgroup Collaboration: collaborative authoring of documents, electronically-supported discussion, etc.
•	Document Management: creation, assembly, distribution, storage and management of documents.

B.	Knowledge Management
The various Web-based databases and the emergent Knowledge Management System (KMS) seek to address the Knowledge Management, Information Access and Workgroup Collaboration needs of the staff.  The KMS is a major pillar of the World Bank’s institutional renewal programme and addresses long-standing needs of the staff for improved access to internal sources of information and expertise.  The KMS seeks to address the requirements for improved information access and means of collaborating with colleagues in- and out-side the organisation.  This system is not a monolithic entity.  Rather, it is a collection of resources (networks of people, inter-connected systems and processes) designed to capture information at the individual level and disseminate it more broadly to Bank staff, clients and others working in collaboration with the Bank on behalf of its clients.  The knowledge resources that are thus accumulated will therefore need to be accessible, irrespective of one’s physical location—at headquarters, in field offices, at home, on mission.
C.	Imaging
As part of the evolution from a predominantly paper-based to digitally-based document management system, final-form documents produced or received by units in the Bank are currently scanned, indexed and stored in a document imaging system (IRIS/imageBank) that is being deployed in units across the organisation.  This document image store is also being made accessible via Lotus Notes and Web browser, business applications that are commonly available to members of the target audience.
D.	Records/Document Management
In order to support the institution’s knowledge and information management objectives, the traditional records management function has expanded its purview to encompass broader document management concerns.  Our work implementing the imaging system convinces us that the integrity and utility of this system, indeed any system that aspires to effective management of documents, would be enhanced by capturing the documents during their creation and revision stage.  This requires the authoring tools that staff use to create documents to be interfaced with a document management system to enable document content and metadata capture.  Capturing the document content and its metadata at creation will enhance life cycle management and ensure the document’s availability for reuse.
II.	Purpose of Workshop
A document management architecture has been defined and a document management system, developed internally and referred to as the Document Management Engine (DME), are already in place.  Since the DME was developed (it has been tested but not deployed), the Bank announced a new IT strategy that requires use of commercial off-the-shelf software for its business applications.  Consistent with this strategy, the purpose of this workshop is to begin a process that will lead to a determination of whether it’s technically and financially feasible to employ the Documentum software package or the available “toolkit” to address the Bank’s records and document management requirements.  The time-frame for deciding on the feasibility of employing the Documentum (or alternative software package) solution is the next 6-18 months.
The workshop will consider the requirement that the creators of documents in the Bank be able to continue using the common business applications they currently use to produce document content (e.g., MS Word, PowerPoint, Excel).  We also want, however, to be able to transparently integrate these front-end document authoring tools with the document management system so that:
•	document content and metadata can be captured at appropriate stages of the document creation and revision stages of the life cycle for storage in the document management system;
•	documents are in easily reusable format (i.e., can be readily repackaged and republished in forms suitable to a variety of audiences);
•	documents are retrievable via common business applications and delivery mechanisms such as Lotus Notes and Web browsers;
•	documents can be preserved independent of a specific hardware/software platform; and
•	the normal records management controls can be efficiently and cost-effectively applied at the back-end of the life cycle process.
III.	Desired Outcomes
At the conclusion of this workshop,
•	Documentum should have a broad understanding of the environment of the Bank and its document management requirements.
•	Bank participants should clearly understand whether and how Documentum could leverage the existing solutions–KMS, Document Management Engine (DME), Lotus Notes, the EFS-based Imaging service and RetrievalWare– to provide extended document management functionality (e.g., document checkout/checkin, version control, document-level security, etc.).
•	Specific, concrete “next steps” for continuing the workshop discussion, to expeditiously resolve open questions such as the product fit (e.g., technical compatibility of Documentum with pieces of the document management solution already in place) and the likely cost to implement, should be agreed.
IV.	Agenda
1.	Introduction (20 mins.) - Ana Flavia Fonseca:
•	Brief Introduction to the World Bank
•	Information & Technology Services Dept. (ITS) Document Management (DM) Strategy & Work Programme
•	Synopsis of Users’ Document Management Requirements
2.	Document Management & Knowledge Management
•	DM Programme as it Relates to Knowledge Management (10 mins.) - Ana Flavia Fonseca
•	Overview of Knowledge Management System Architecture (15 mins.) - Ramesh Siva
3.	Document Management System
•	Document Management Architecture (10 mins.) - Robert Patt-Corner
•	Technical Architecture of the Document Management Engine (DME) (15 mins.) - Robert Patt-Corner
4.	Presentation/Discussion - Documentum’s Document Management Business Solution vs. Bank Requirements (1 hour)
5.	Wrap-up: Agreed "Next Steps" (15 mins.)
V.	Issues from April 11, 1996 Teleconference Between ITSIE and Documentum

1.	The Documentum server can be enhanced, but its basic behaviour cannot be changed.
2.	It seems unlikely that Documentum can meet Bank security requirements.  There are several possibilities for integrating the Bank security requirements, as currently implemented in the Bank’s Document Management Engine (DME), with Documentum.
3.	Documentum cannot implement the Bank’s information gathering rules to describe documents (profile attributes), but may be able to store and search the information once it is gathered by the Bank Document Management Engine.
4.	Documentum/Notes integration may provide a large group of functions to Bank staff.  Much depends on whether the Notes functions that use Documentum  are available for modification.
5.	The use of Notes as the interface to Documentum instead of Documentum’s own workspace significantly limits the management functionality provided by Documentum.
6.	There is some concern that the current mode of Notes/Documentum integration will require prohibitively large storage in a very large installation like the Bank, due to duplicate storage of large sets of Bank documents.
7.	Bank documents must be available to other authorised applications.  Documentum manages the location where document content is stored, but appears able to surface enough location information to meet Bank requirements for institutional access to content from outside the Document Management System.
8.	The Bank Document Model provides support for multipart, multi-version documents, and Documentum has implemented a different model.
9.	Bank search requirements tend to go beyond the standard Documentum/Notes search capability provided by Verity.
10.	Scalability issues - current Documentum installations appear somewhat small by Bank requirement standards.

April 1997

I.	Background Information

A.	What is the World Bank?

The International Bank for Reconstruction and Development, frequently called the "World Bank" was established in July 1944 at the United Nations Monetary and Financial Conference in Bretton Woods, New Hampshire, USA. The World Bank opened for business on June 25, 1946. The World Bank’s goal is to reduce poverty and improve living standards by promoting sustainable growth and investments in people. The Bank provides loans, technical assistance and policy guidance to help its developing-country members achieve this objective. The World Bank group of institutions includes: 

• The International Bank for Reconstruction and Development (IBRD) 

• The International Development Association (IDA) 

• The International Finance Corporation (IFC) 

• The Multilateral Investment Guarantee Agency (MIGA) 

• The International Centre for the Settlement of Investment Disputes (ICSID)

As of February 28, 1997, IBRD and IDA combined employ an active headquarters-based workforce (including regular, fixed-term, long-term consultants and temporary staff) of about 7,259. IFC and MIGA combined employ about 1,105 for a total Bank Group headquarters-based workforce of about 8,364. Local staff in field offices number about 1,676; 71.4 percent of these are support staff. About 434 of the headquarters-based workforce are also assigned full-time to field offices. The Bank has 97 field offices.

As of March 15, 1997, IBRD had 180 members; IDA, 159; IFC, 171; MIGA, 141 and ICSID, 126. Bosnia and Herzegovina became the 180th member of IBRD.
B.	Knowledge Management Business Imperative
1.	Development Knowledge Management
“We need to rebuild our knowledge base and better manage it.  Being the global catalyst for the sharing of lessons and expertise on development is potentially our greatest comparative advantage—and it is a service greatly needed by our clients.  The Networks are the first step in this direction, but we must go further. We need a new culture in which we share experience within the Group, and we need a system which encourages the preservation and exchange of that experience.”  (Excerpted from January 31, 1997 letter from Mr. James Wolfensohn, World Bank Group President, to Bank Staff)
2.	The Vision—What is Knowledge Management?
“Managing knowledge involves: generating knowledge through research, the networks, the regions and outside sources; systematically assembling this knowledge; and disseminating it both internally and externally through the networks, the regions, EDI, as well as information databases.
“Initially, it is aimed at increasing individual effectiveness, transferring information and knowledge to the organizational level, and, ultimately, making it easily accessible to all.  It constitutes not only a corporate memory of information and best practices, but also incorporates the best development knowledge from outside organizations through connections with universities, foundations, and other world-class sources of knowledge.”
3.	How will the knowledge management system be developed?
“The (Network) councils will generally take the lead in developing the requisite knowledge bases.  Each knowledge area will be led by a full-time knowledge manager and supported by subject-specialists and other operational staff who will spend part of their time building and maintaining the knowledge base.  These staff members will constitute communities of practice in their fields of expertise.  Other information systems, including those managed by the Regions, OPR, and OED, will also be integrated to form a single institutional system.
“A small central knowledge management team dedicated to overseeing the knowledge management system will be created.  Its functions will include establishing an integrated knowledge management framework, developing an institutional classification system, organizing priorities among multiple knowledge management activities, dealing with issues concerning the quality of knowledge, managing external access to the knowledge management system and consolidating external knowledge partnerships, regulating the Bank’s knowledge economy, facilitating the organizational culture shift, and championing the Bank’s knowledge management effort.
“ITS will support the knowledge management system with the appropriate technology and ensure that the knowledge management system is fully integrated into other information systems.”
4.	How will the system be organized?
“Material will be organized within the overall framework of the Bankwide architecture (e.g. by sector, region, etc.).  Classification procedures will be established to enable easy retrieval and facilitate access to internal and external users.  Quality standards will be set.  The system will include processes not only to assimilate information, but also to synthesize and distill information into key findings.  Feedback mechanisms will be put in place so that the system can evolve to meet changing user requirements.
“The system will include: help-desks with capacity to answer queries and provide resource maps and information packets; databases including terms of reference, consultants, lessons learned, key articles and books, papers, reports, what’s new; knowledge bases including sector strategies, tool kits, model outputs, analytical tools, best practices, sources of information, and think-pieces.”
C.	Synopsis of User and Technical Requirements
The key document management requirements on which the existing DME is based are attached.  Figure 1 depicts the extent to which existing IT solutions satisfy the functional requirements.
Significant numbers of the headquarters-based staff involved with country operations work are tend to be on mission (traveling) at any given point in time.  Thus access by traveling staff as well as staff located in field offices to the contents of the document management system is of vital importance.
1.	Coverage of Current Solutions
Besides the KMS, Lotus Notes, numerous internal Web databases, other database applications and the Document Management System are used to provide solutions in the document management space diagrammed below.  These knowledgebases and repositories all contain documents, whether “think pieces” especially commissioned by the KMS or the products of normal routine business processes.

Figure 1. Coverage of Functional Requirements by Existing Solutions
D.	Document Management Architecture
Gartner Group advises that “in the absence of generalizable Document Management solutions that span applications and work objects, IS must develop its own architecture to grow and protect the information assets of the company.”  Consistent with this commonsense guidance, the Bank has developed a document management architecture (DMA).  The DMA provides a standards-based framework for selecting products and applications, so that documents can be shared and application investments leveraged across applications and architectures.

The DMA is based on the following key design, architectural, and technical principles:

•	responsiveness to business needs as expressed through the user requirements;
•	document location independence;
•	adherence to open and de facto industry standards;
•	consistency with IMA and integration with key Bank repositories;
•	open, distributed, client/server computing architecture; 
•	object-oriented technology; and
•	scalability and modularity.
Figure 2
E.	Current Technical Environment
1.	Notes Environment

The World Bank is in the process of deploying Lotus Notes.  For purposes of the investigation we can assume a Notes client and certificate per desktop and traveling computer.  Current release is 4.5.1.
2.	Web Environment

 The World Bank has an IP intranet with internet connections and numerous Domino and non-Domino intranet servers as well as non-Domino internet servers.  Netscape 3.x is the standard browser, and Notes is configured to use it.
3.	Image Display Environment

 The World Bank has a fairly large collection of documents stored as CCITT G4 TIFF images, one image per page, with directories representing logical documents.  The images are stored on NFS file systems and  can be accessed by both Web and non-Web (e.g. EFS client) viewers.  The intention for now is to continue to store images in this manner.
Images can be displayed via URL, although there are security issues involved in mapping Notes ACLs to permissions on a Web server offering up the images.  This set of issues is to be part of the investigation,  either through probing Notes ACLs by the existing Web process or specifying a new Domino process.

Images are also displayed in hierarchical Room/Cabinet/Drawer... taxonomy by means of an Excalibur EFS server on UNIX servers and a dedicated EFS client on Windows workstations.  This hierarchical display is one key element to be replaced by the product.
4.	Capture Environment

Current image capture is by a dedicated scan station built in house.   Maintaining it is resource intensive, but the profiling flexibility is substantial.

Additional ad-hoc capture is done by various Bank Web sites and by a Knowledge Management System cataloging system built in Notes which feeds an X.500 database. 
5.	Profile and Metadata Environment

The current implementation using EFS works with an ad-hoc set of ORACLE tables to provide some rudimentary picklists and attribute storage on a per file cabinet basis, without normalization or standard design.

There is, in addition, a new document management database which captures attribute information in a fully normalized manner and makes use of a full set of metadata, synchronized with common data stores and other Bank processes. The universal capture mechanism relies upon this metadata and database for its operation.

The selected document management product must integrate with this data environment, or provide an alternate enterprise means of metadata and profile management.
6.	Search Environment
OCR-produced image text and electronically captured documents are currently searched via the Excalibur EFS search engine, which features a fuzzy bitmap pattern search.  Migration is planned to the Excalibur   RetrievalWare search engine, offering similar function with the addition of the former Conquest engine.

7.	Security Environment

Current security is implemented by UNIX file protection on the actual images.  This is acknowledged to be an unsatisfactory solution.

There are two in-house security possibilities.  The Notes environment with its certificates offers a rich ACL-based security and a standard user interface for definitions.  However it maps poorly to the Web in
terms of synchronization with HTTP passwords, and may be inaccessible from other system seeking to validate access.  In addition, there is an in-house security engine built in ORACLE PL*SQL which determines security by dynamic ACL, based on document properties, user properties and user membership in organizational hierarchies, and the action requested.  However this engine does not have the ubiquitous user interface that the Notes ACL environment provides.

I.	User and Technical Requirements
A.	Summary of Key Document Authoring Requirements
1.	Identify and reuse related, relevant material
•	Determine if related documents exist; provide abstract so recipient can determine relevance
•	Create documents from different application components (e.g., Word, PowerPoint, Excel) and formats; convert to user’s format(s) of choice
2.	Streamline document preparation process
•	Reduce duration and number of steps
•	Streamline business processes (e.g., number of approval steps) before automating
•	Prompt creator for mandatory profile attributes
3.	Support collaborative work
•	Edit trace
•	Support preparation and review scheduling
•	Control routing, distribution by end-user or with bankwide directories
•	Provide automatic notification of undeliverable mail
•	Dynamic user control of work group definitions
•	Electronically collate comments from different sources
•	Support collaboration from all locations, including field
•	Support digital signatures
•	Support transfer of document ownership; identify owner of latest version
•	Automatically capture information about who creates/modifies documents
4.	Minimise redundant, non-value-added work
•	Create and use standard document templates and profiles
•	Perform quality control, consistency checks less often; improve accuracy
•	Automatically generate subsidiary documents from comment content
•	Automatically propagate changes among components for related comments
•	Reduce time spent on document format rather than on substance
•	Provide utilities to compare different versions of the same document

B.	Summary of Key Management Requirements
1.	Protect document integrity, prevent loss of documents
•	Version control of documents and document components
•	Standard file management, locking, protection
•	Document owner can define access privileges, revise on ad hoc basis
•	Document content, associated data stored and retrievable in portable format
2.	Manage document over its life cycle
•	Capture standard profile information (metadata) on all documents
•	Reuse existing profiles
•	Add profiles to imported (captured) external files
•	Track document
•	Define and maintain rules for retention and disposition
•	Apply retention and disposition rules automatically based on metadata
•	Allow deletion of unused versions
•	Provide support for documents that are stored off-line
3.	Capture borrower and external source documents in digitised, manageable format
4.	Provide automated support to assemble documents for publication
5.	Manage relationships between/among related documents
•	Maintain relationship of e-mail to relevant projects or case
•	Track status of responses to borrower correspondence
•	Manage workgroup comments as documents (e.g., editable)
•	Link workgroup comments to the document being referenced
•	Specify versions of document parts to be used to create document editions
•	Maintain profiles (metadata) for all documents, whether in paper or digitised format
•	Maintain profiled of documents stored on non-EDMS servers (e.g., image database)
6.	Reduce costs of document storage and retrieval
C.	Summary of Key Document and Information Access & Distribution Requirements
1.	Provide on-line access to all Bank information resources, formal and informal
•	Project documents (including graphics, tables, maps, etc.); bibliography of project files, analysis files, standard model TORs, bidding documents, “lessons learned,” etc.
•	Bank’s policies and procedures
•	Research material (e.g., Working Papers, Discussion Papers, etc.) and documents collected on missions
•	Procurement documents
•	Electronic mail
•	Identify Bank experts, consultants
2.	Coordinate and manage information access
•	Reduce paper by notifying users of document availability and providing access to copy in central database
•	Support simultaneous, “read-only” access by multiple users
•	Rules to govern user access privileges and authorisations
•	Selective access to document parts
•	Distribute electronic documents in traceable way among document stores and users during their period of active use
3.	Provide access to information regardless of user location
4.	Facilitate information sharing
•	Capture and provide access to borrower documents
•	Share analysis documents with borrowers
5.	Powerful full-text and profile data search and retrieval capabilities
•	Full complement of search tools
•	Context-based (sector, project, etc.) document retrieval
D.	Summary of Other Requirements
1.	Intuitive, easy-to-learn and use user interface
•	Common to document management and other information services
•	User view of business as context
2.	Gear training to different levels of expertise and needs (e.g., management vs. technical user needs)
3.	Integrated, intelligent (i.e., context-sensitive), on-line help and documentation
4.	Document management system seamlessly integrated with other information management and access applications (e.g., KMS)
5.	System performance
•	Scaleable to 10,000+ users
•	Usable across heterogeneous enterprise network
•	Quick system initialisation
6.	Support different levels of user technology sophistication
7.	Scale solutions and deployment to Bank’s ability to absorb technology