Exploiting knowledge
Exploiting knowledge
Content management consultant Len Asprey has teamed up with academic Michael Middleton to redefine the way people approach specifying, requiring and installing records, document and content management systems in a new book.
Speaking about the book; Integrative Content Management: Strategies for Exploiting Enterprise Knowledge, Mr Asprey said he and Mr Middleton were aiming to educate the end users and to help people see the separate information disciplines as connected. ”The various information disciplines, records, document and content management need to talk together and work together. They are currently working in silos; and yet they are often the very people who remark on the deficiencies with which organisations manage their information, and that is in ‘silos’,” he said. Mr Asprey said the book aims to show how and why these areas are connected and as a result, prevent organisations making the costly mistakes that others have made.
”The essence of the book is that the whole topic of document, content and records management is quite complex. Unfortunately organisations tend to see it as simple. They identify content, document and records management with the traditional practices for managing physical documents and they ask the people that have dealt with managing physical documents to find a solution, often at an enterprise level,” he said. The problem with this, is that decisions are increasingly being made electronically through the Internet or via email; thus involving digital document functionality and architectural considerations that are much more complex than systems that manage physical documents.
An organisation needs an integrated information management solution, potentially comprising a range of technologies.
”Records management systems shouldn’t be called that, because they typically refer to systems for managing those business documents that are records. They don’t embrace other types of business records such as those captured by airline reservation, banking and clinical information systems,” he said.
A typical example, according to Mr Asprey, would be an organisation that wanted to manage contract administration, and tendered for a document management application, but in fact document management was just a component of what they needed. He said the entire process of managing the contracts needed to be considered, or otherwise the system would be under-utilised.
”There are organisations in this country that have bought document management systems and they have sat on the shelf because people within the organisation don’t align and associate the enabling technology with real business applications. Seeking tenders for a “document management system” is like seeking tenders for a “database management system” without identifying the required application. After all, digital documents are just data when all is said and done, and they just have specific file formats and requirements for management,” he said.
A key area of the book is specifying your requirements and selecting your supplier for a records and document management application. When considering the specification, the authors state that the strategic objectives of the organisation have to be considered and where the information management system fits into this.
”We shouldn’t be talking about what technology we require. We need to talk about the solutions and then the technology,” said Mr Asprey. Mr Asprey stated that, while businesses were responsible for aligning their needs with business processes, and providing adequate specifications, the vendor community must also share some of the blame. Sometimes vendors are too eager to make a “quick sale”. They should see their software systems within the wider context of a business management framework as a holistic approach for managing information assets, and help organisations to have a better understanding of the requirements process.
”Requirements get so much space in the chapters because we believe these are the things that people really need to do right,” he said.
Both Mr Asprey and Mr Middleton will be flying to London to present to AIIM Info@2002 conference to speak on the importance of, and contextual structure for, requirements specifications. Their presentation will cover many areas from the book. An abstract from the book and presentation is published here.
Integrative Content and Document Management: Strategies for Exploiting Enterprise KnowledgeDocument management systems and records management systems have been with us for many years, and despite differences of emphasis they have been growing closer together in functionality. The content management system is a more recent terminology that has been adopted to describe the creation, organisation and management of content availability via the Web. It is therefore increasingly associated with businesses publishing.
Each of these systems is an interpretation of information management from the viewpoint of specific disciplines. However they share principles to the extent that an enterprise that is involved in any of the three areas should now look integrating their records and content management systems. An integrative solution covers a range of facets that need to be addressed by professionals seeking to manage organisational information assets in documented form. The integrative solution needs to embrace a range of functionality including document and Web content management capabilities, document/content review, approval management, and the implementation of recordkeeping principles and requirements.
Successful solutions result from a number of facets; including an understanding by the business and project managers of the life cycle of information systems (IS) planning techniques when initiating and progressing document and records management projects. Two components of the software development life cycle process that are critical success factors for deploying successful solutions, are; the specification of requirements and selecting the correct supplier.
The purpose of analysing and defining requirements for integrated information systems for managing document, Web content and documentary records is to define the diverse business and technical requirements that are to be met by the target information solution. The key deliverable from analysis and definition of requirements is the Requirements Specification.
Information professionals tasked with specifying requirements for an integrative environment for managing documents and Web content are faced with a number of challenges. For example: specifying the role of documents within the context of relevant business processes; developing requirements that will enable the enterprise to deploy flexible and scalable solutions that are relevant to a diverse range of business processes within an enterprise; and specifying the functionality for capture, registration, storage, search/retrieval, security and audit requirements for a diverse range of document formats, and tools that will support the management of documents. These information management professionals would also need to address: defining recordkeeping requirements that will need to be satisfied for managing both physical documents and digital documents, including Web content; defining the architectural, performance and system administration requirements for the integrated solution required for managing documents including Web content within a recordkeeping framework; detailing the technology requirements for integration of potential solutions with enterprises’ technology infrastructure; and capturing implementation and change management issues and making clear the policy and procedural change imperatives. The process of specifying detailed requirements for selection of the system should follow IS life cycle planning methodology that features: definition of plans that stipulate aim and objectives, scope and define the nature of the requirement, define the project organisation and identify risk and associated mitigation issues; and development of change management strategy at project initiation and the implementation of the strategy throughout the project life cycle; definition and promotion of information policy and the development of document management policy as a key sub-set of information policy. The process should also include a feasibility study approach to determine operational, technical and financial feasibility of document and Web content solutions that sustain business processes and implement recordkeeping requirements. The approach processes for the requirements analysis and definition stage are defined by Shelly, Cashman & Rosenblatt in their book Systems Analysis and Design as: determination of requirements, which is primarily concerned with obtaining the facts about the process and systems models relating to the current business environment; analysis of requirements, which focuses on the various business and technology solution options for improving business process and delivering effective document, Web content and recordkeeping solutions; specification of requirements, which defines the requirements of integrative systems that will support the implementation of the preferred business/technology solution options; validation of requirements, which confirms the documented requirements, involving validation by stakeholders representing business and system responsibilities.
Requirements analysis and definition includes techniques such as interviewing, data collection and analysis, sampling, and analytical tools such as functional analysis, process modeling, data flow diagrams, data models, and detailed process descriptions. The outputs from the step processes involved in determination and analysis of requirements need to provide the inputs to the Requirements Specification. The Requirements Specification is the primary deliverable from the IS life cycle process of requirements analysis and definition. The specification is a vital key to successful supplier/package selection, contract management and a winning project implementation.
In order to address the diversity of requirements for an integrative document, Web content and recordkeeping solution, the Requirements Specification might be structured along the lines proposed for software projects by Ian Sommerville in his book Software Engineering (6th ed.), with both user requirements and system requirements.
User requirements would focus on the business requirements for the solution. Determination of the business requirements needs to address strategic, tactical and operational planning within an enterprise, and focuses primarily on process models and the role of documents, Web content and documentary records within the models. The list of system requirements include functional requirements, which focuses on the functionality of the software that is required to support the solution. These requirements might include coverage of functionality for digital office documents, email, physical office documents, drawings, workflow, document imaging and recognition technologies, and systems’ integration requirements.
System requirements also include: non-functional requirements, which includes architecture, inter-operability, reliability and performance measures; and domain requirements, which include attention to infrastructure, regulatory requirements and standards utilisation.
Other deliverables may include project and quality plans, problem definition statements, process maps, data dictionaries, and similar outputs from the application of analytical techniques and tools.
The diversity of issues that need to be addressed during the requirements analysis and definition stage of IS life cycle planning is such that enterprises may find it beneficial to adopt a collaborative approach to analysing, determining, validating and specifying requirements. The collaborative approach would involve the establishment of a team that represents the interests of various information disciplines, including an IS project manager, end-users systems analysts, recordkeeping professionals, archivists, and librarians. A collaborative requirements analysis and definition approach that embraces inputs from the diversity of business users and information professionals will reduce risk and help the development of a Requirements Specification that has merit.
The primary deliverable is the Requirements Specification that encompasses the user and system requirements for the information system(s) that will support the business solution.
The importance of specifying requirements cannot be understated. Also the level of effort involved should not be under-estimated. The Requirements Specification is likely to form part of the contract with the selected supplier, and will be the basis upon which the design work associated with the information systems component of the solution will be developed. Inadequacy of specifications may mean costly delays in development and implementation, and can result in negative outcomes such as litigation involving the contract for the solution.
The purpose of supplier selection is to obtain the necessary software (and perhaps hardware and communications equipment) and professional services to implement integrated information solutions for managing documents including Web content within a recordkeeping framework.
The supplier selection process may involve a range of inter-related steps: developing a procurement strategy that the enterprise will adopt to select a supplier and required information systems products to satisfy the business needs; developing an evaluation strategy for evaluating suppliers/products; selecting information systems product(s) that provide the capability to meet the diversity of requirements defined in the Requirements Specification; choosing a supplier that has the product and domain experience, combined with resources that have the project management experience, business acumen and technical knowledge to deliver successful solutions; and negotiating a contract with the supplier that is acceptable to all parties.
Supplier selection covers the procurement processes involved in acquiring a supplier and packaged software to support an integrative document, Web content and recordkeeping solution.
The specific approach will depend on the procurement policies of respective enterprises. However, a typical approach might include: preparation and publication of RFP (encompassing Requirements Specification); desktop evaluation of proposals; benchmark assessment of proposals from a shortlist of suppliers; reference site visits; and gap analysis of final shortlist.
The techniques used during supplier selection might include functionality checklists, which are designed to help organisations confirm the capabilities of products, and supplier checklists, which are used to validate supplier capabilities. Other tools at the selection committee’s disposal include: weighted scoring methodology, which can be useful as a means of helping to differentiate relevance during functional (and supplier) analysis; benchmark assessment, which is used to validate solutions offered by suppliers in terms of the functionality and also pre-system acceptance performance tests (where these can be simulated); gap analysis, which is a technique that might be useful for identifying functionality gaps that are either manageable or non-manageable, and may assist final product determination; and risk analysis, which can be used to help organisations determine the relative risks associated with proceeding with suppliers/products.
The selection committee would also need to have experience in contract negotiation, which involve techniques in developing contracts between purchasers and suppliers. The types of deliverables during this process include a procurement strategy, which defines the process for selecting a supplier and entering into a contract agreement, and an evaluation strategy/plan, which defines the strategy by which the evaluation will be managed, and the planning associated with the strategy. It will also include the selection criteria that are to be applied for selection of the supplier/product. During the process, committee members might also be expected to produce a weighted scoring plan, which might be useful for scoring specific requirements during the supplier/product assessment process, as well as reference site visit scripts, which define the approach and types of questions for conducting reference site visits (recommended) or checks. Also, the process might include some benchmarking activities, such as a benchmark plan, which defines how functional (and performance, where relevant) benchmark assessments will be conducted, and benchmark specifications, which are used to define benchmark test configuration requirements, business usage scenarios, functionality checklists, and logistical requirements relating to benchmark assessment.
During the selection process the capabilities of offered products and each supplier need to be examined from a number of perspectives. For example, the functionality of the solution would need to be validated against the functional component of the Requirements Specification.
Check a range of functional capabilities including items such as (to cite a few examples only): capabilities to manage complex relationships between documents, such as embedded or linked objects; capabilities to manage drawings, and maintain links between parent drawings that reference child drawings; management of e-mails and attachments; management of different renditions (formats) of the same document so that integrity is maintained between all versions); and management of hyperlinks within the document repository (and perhaps also hyperlinks from externally stored documents to documents managed by the solution).
Given that there are likely to be a number of products that comprise the solution, a range of integration checks needs to be examined to help validate the capabilities of the solution. For example, you would need to test the capabilities of all modules to integrate with desktop client operating systems and software, server operating and database management systems, browser and Web services, as well as the capabilities of modules to operate in a distributed computing environment (if that is a requirement) or to service highly mobile users. Other areas to gauge include the integration capabilities of the products to test the workability of the products as a complete solution, plus the system administration capabilities of the solution to determine usability for administering the diverse products within the overall solution. Performance of specific aspects of the solution might also be tested as part of the benchmark assessment. Finally, supplier capabilities would be tested, in terms of a supplier’s demonstrable capabilities to deliver the solution offered in the enterprise environment.
The exit criterion for the supplier/package selection stage of an IS life cycle is a signed contract, which is the entry criterion for initiating project implementation, commencing with the design phase of the IS life cycle.
Procurement processes for document and Web content solutions that implement recordkeeping are very similar to procurement activities for other IS projects. However, there are unique aspects to managing documents and Web content within enterprises that differentiate them from information solutions that write/read data to database systems. Documents form an integral part of virtually every business process, and there may be requirements to access/share large digital documents or linked digital documents across distributed computing networks, or provide highly mobile users with quick and easy access to managed digital document collections. Consequently, the architecture and performance capabilities of the software solution, in addition to its functionality, may have an impact on the final selection of a product and supplier. In addition, the enterprise needs not only to feel comfortable that a vendor has the requisite skills, methods and experience to deliver the solution, but also that the vendor has a proven track record in delivering solutions of a similar size and complexity, preferably with relevant domain experience.