request for proposal - electronic information management (eim

A ALBERTA CORPORATE SERVICE CENTRE Supply Management Branch Contracted Services Section 2nd Floor, 12360 – 142 Street Edmonton, Alberta T5L 4X9

REQUEST FOR PROPOSAL (“RFP”) Number 279PA-42

Electronic Information Management (EIM) Software Selection Project

(Alberta Government Services)

RFP Issue Date: October 5, 2004 RFP Closing Time: 14:00:59 Alberta Time, November 5, 2004 Contracting Manager: Alec Chan Telephone: (780) 415-9735 Facsimile: (780) 422-9672 Email: [email protected]

Table of Contents

1.0 GENERAL......................................................................................................................... 1

1.1 Introduction .........................................................................................................................1

2.0 RFP PROCESS ................................................................................................................. 1

2.1 RFP Terminology................................................................................................................1

2.2 RFP Schedule of Events ......................................................................................................5

3.0 RFP ADMINISTRATION TERMS AND CONDITIONS............................................ 6

3.1 General ................................................................................................................................6 3.1.2 Vendor Questions ......................................................................................................................6 3.1.3 Current Technology ...................................................................................................................6 3.1.4 Confidentiality ...........................................................................................................................6 3.1.5 Freedom of Information.............................................................................................................7 3.1.6 Time...........................................................................................................................................7 3.1.7 Proposed Software .....................................................................................................................7 3.1.8 Agreement on Internal Trade.....................................................................................................8 3.1.9 Conflict of Interest .....................................................................................................................8 3.1.10 Vendor Expenses .......................................................................................................................8 3.1.11 Period of Commitment................................................................................................................8 3.1.12 Multiple Proposals ......................................................................................................................8 3.1.13 Pricing........................................................................................................................................8 3.1.14 Irrevocability of Proposals.........................................................................................................9 3.1.15 RFP Closing...............................................................................................................................9 3.1.16 Proposal Submissions .................................................................................................................9 3.1.17 Consent to Use of Information.................................................................................................10 3.1.18 Proposal Public Opening...........................................................................................................10 3.1.19 Recapitulation of Proposals .....................................................................................................10 3.1.20 Proposal Return ........................................................................................................................10 3.1.21 Proposal Rejection ...................................................................................................................10 3.1.22 Termination .............................................................................................................................10 3.1.23 Vendor Debriefing....................................................................................................................10 3.1.24 Tax ...........................................................................................................................................10 3.1.25 Sub-Contractual Terms and Conditions...................................................................................11 3.1.26 Product or Software Subsets or Supersets ...............................................................................11 3.1.27 Contract Duration ....................................................................................................................11 3.1.28 Proposal Alteration ..................................................................................................................11 3.1.29 Evaluation, Demonstration and Testing...................................................................................11 3.1.30 Modified RFP Process .............................................................................................................11

3.2 Proposal Evaluation...........................................................................................................12 3.2.1 Evaluation Sequence and Process............................................................................................12

3.3 Contract .............................................................................................................................14 3.3.1 Standing Offer Contract Finalization.........................................................................................14 3.3.2 Order of Precedence ................................................................................................................14 3.3.3 Contractual Warranties ............................................................................................................14

4.0 PROJECT INFORMATION ......................................................................................... 16

4.1 Project Overview...............................................................................................................16 4.1.1 Introduction .............................................................................................................................16 4.1.2 Objectives ................................................................................................................................17 4.1.3 Background..............................................................................................................................17 4.1.4 Project Scope ...........................................................................................................................18 4.1.5 Configuration of Product .........................................................................................................18 4.1.6 Anticipated Hardware Platform...............................................................................................18

4.2 EIM Software Requirements .............................................................................................19

5.0 EVALUATION CRITERIA ........................................................................................... 20

6.0 PROPOSAL CONTENT GUIDELINES...................................................................... 21

6.1 Proposal Format ................................................................................................................21

6.2 Proposal Content ...............................................................................................................21 6.2.1 Proposal Submission Letter .....................................................................................................21 6.2.2 Executive Summary.................................................................................................................21 6.2.3 Vendor Corporate Profile and Credentials...............................................................................22 6.2.4 Vendor Proposed EIM Products ..............................................................................................23 6.2.5 Pricing......................................................................................................................................23 6.2.6 RFP Administration and Conditions........................................................................................23 6.2.7 Contract Provisions..................................................................................................................23 6.2.8 Vendor References...................................................................................................................24 6.2.9 Appendices ..............................................................................................................................24

APPENDICES............................................................................................................................. 25

APPENDIX A – Contract Provisions .........................................................................................26

APPENDIX B – GoA EIM Overview .........................................................................................45

APPENDIX C – Related Project Documents .............................................................................53

APPENDIX D – Project Requirements ......................................................................................55

D1. Project Software Summary Form ..............................................................................56 D2. Mandatory Requirements.................................................................................................57 D3. Business and Technical Requirements.............................................................................62

APPENDIX E – Metadata Requirements ................................................................................193

APPENDIX F - Pricing Form....................................................................................................200

APPENDIX G – Vendor Recommendations ............................................................................205

APPENDIX H – Vendor References.........................................................................................206

APPENDIX I – Reporting Requirements.................................................................................209

APPENDIX J - Proposal Submission Letter............................................................................211

Alberta Government Services RFP # 279PA-42 Page September 28, 2004

1

1.0 GENERAL

1.1 Introduction

Vendors are invited to submit Proposals for the provision of an integrated suite of Electronic Information Management (EIM) Software products for the Government of Alberta as specified in this RFP. A single Manufacturer must support all core components of the integrated suite of EIM Software products including collaboration, document management, web content management and records management. Note that this RFP is intended to establish Standing Offer Contract(s) for qualified EIM Software products to a maximum of 3 with the preferred Vendor(s), however, there is no commitment to purchase at this time. This RFP will be conducted with the objective of maximizing the benefit to Her Majesty, while offering Vendors a fair and equitable opportunity to participate. Vendors are advised to pay careful attention to the wording used throughout this RFP. Failure to satisfy any term or condition of this RFP may result in an unacceptable Proposal. Facsimile or digital Proposals in any form (e.g. diskette files, disk files, tape files, e-mailed files) will not be accepted.

2.0 RFP PROCESS 2.1 RFP Terminology

Throughout this RFP, terminology is used as follows: “ACSC” means the Alberta Corporate Service Centre which is an organizational unit of Her Majesty the Queen in right of Alberta, as represented by the Minister of Government Services. “Alberta Government Services (AGS)” means Her Majesty the Queen in right of Alberta, as represented by the Minister of Government Services. “Alberta Time” means Mountain Standard Time or Daylight Saving Time as provided for in the Daylight Saving Time Act of Alberta. “Alberta Purchasing Connection (“APC”)” means the Government of Alberta’s electronic tendering system. “Approved Organizations” means organizations, including hospitals, as defined in the Hospitals Act, schools, post-secondary educational institutions, municipalities, Metis settlements and any organizations that carry out services or programs on behalf of the Government of Alberta, which are approved by the Minister to order the Software on the same terms and conditions as stated in the Contract. Approved Organizations will be posted on APC and updated from time to time. “Associated Software” is third-party software that is required to support the mandatory or desirable requirements in providing the required functionality such as reporting, imaging, searching or hardcopy records management. “Authorized Reseller” means an entity authorized by a Manufacturer or Canadian Distributor to act on its behalf, in Alberta, for the Software.


2

“Business Day” means 8:15 a.m. to 4:30 p.m., Alberta Time, Monday to Friday, excluding holidays observed by Her Majesty. “Business Hours” means 8:15 a.m. to 4:30 p.m. Alberta Time on Business Days. “Canadian Distributor” means an entity authorized by a Manufacturer to act on its behalf, in Alberta, for the Software. “Commercial Software” means Software of the Manufacturer and/or the Manufacturer’s subcontractors or agents (including their affiliates as specified in the Business Corporations Act of Alberta, as amended, revised or substituted form time to time) which was commercially available off the shelf prior to this RFP’s closing date. “Configuration” means any change, enhancement, etc. to the Software not requiring source code changes completed by the Vendor to provide the specified functionality. “Consortium” means two or more Vendors who together submit a Proposal. “Contract” see “Standing Offer Contract”. “Department” means Her Majesty the Queen in right of Alberta, as represented by the Minister of Government Services. “Electronic Information Management (EIM) Software”, “Software” means the proposed suite of Software products marketed by the Vendor in the Proposal that will meet or exceed the requirements and objectives described in this RFP.

“Evaluation Team” means individuals who will evaluate the Proposals on behalf of Her Majesty. “Evaluation Testing” means the tests the Evaluation Team will conduct on the proposed Software to determine whether the proposed Software performs according to the Manufacturer’s published specifications, industry standards, the RFP, and the Proposal. “Fixed Price” means a definite and predetermined price. “GAEA” means the Government of Alberta Enterprise Architecture and is the result of an initiative to analyze cross-government business, data, security, application and technology needs to create a set of ongoing investment/design guidance, blueprints and processes necessary to steer Information and Communications Technology (ICT) solutions towards support of corporate strategic goals, such as articulated in the Government of Alberta’s Corporate Information Management Technology Strategy “Connecting for the Future” (http://www3.gov.ab.ca/cio/itm/). See also the GAEA Glossary of Terms referred to in APPENDIX C – Related Project Documents, section of this RFP. “GAEA Band Definitions” – see below.

“GAEA Band One” is the category for an ICT asset that should be implemented once for the GoA and shared by all. It is a CORPORATE Asset. It is a STANDARDIZED (i.e. GAEA-Compliant) Asset. It is a CENTRALIZED Asset (i.e. located and managed centrally - e.g. by the ACSC).


3

“GAEA Band Two” is the category for an ICT asset that doesn’t necessarily have to be widely shared across government, but must still be implemented consistently across government, to deliver strategic value. It is a DEPARTMENTAL Asset. It is a STANDARDIZED (i.e. GAEA-Compliant) Asset. It may or may not be a CENTRALIZED Asset (i.e. located and managed centrally - e.g. by the ACSC). “GAEA Band Three” is the category for the rest of the ICT assets. Not all assets are placed in the above categories (Band 1 or Band 2), only the ones which make the most business sense to do so. A Band 3 asset is DEPARTMENTAL. It is UNIQUE (i.e. not GAEA-Compliant and doesn’t have to be; e.g. noncompliance is justified or due to legacy systems).

“Government of Alberta, (GoA)” means Ministries of Her Majesty. “Her Majesty” means Her Majesty the Queen in right of Alberta. “Hours of Operation” means Business Days, excluding between 12:00 and 13:00 hours when SMB is closed. “ICT” means information and communication technology. “ICT Asset” means any applicable information, knowledge, capability, skills, or thing that is valuable to the Information and Technology Management endeavor - typically because it supports service delivery. For example ICT Assets may include: architectures, methods, practices, skills, data, applications, infrastructure, products, or support staff. “ICT Solution” means the composition of ICT assets (application(s), data, technology, processes and procedures) necessary to deliver a total information solution to a defined business requirement. “Identified User” means the Ministry purchasing representative accessing a purchase under the resulting Standing Offer Contract. “ITM” means information and technology management. See “ICT”. “Manufacturer” means an entity that:

(a) uses components from one or more sources to assemble the Software that it sells under its brand or name.

(b) has a third party, on its behalf, use components from one or more sources to assemble the Software that it sells under its brand or name.

(c) develops the Software. “Materials” means all the working papers, surveys, notes, plans, designs, reports, records, studies, drawings, examinations, assessments, procedures, specifications, evaluations, results, conclusions, interpretations, calculations, analyses, systems, software, source code, documents, writings, programs, hardware, devices, data or any components of these, regardless of how they are represented, stored, produced, or acquired. “Ministries” means GoA departments, agencies, commissions, boards, councils, crown corporations. “Minister” means Her Majesty the Queen in right of Alberta, as represented by the Minister of Government Services.


4

“must”, “mandatory”, “required”, “shall” means a requirement that must be met in a substantially unaltered form in order for the Proposal to receive consideration. “optional” means a requirement not considered essential, but for which preference may be given.

“Order(s)” means the order placed by a Government of Alberta Identified User, and accompanied by the Ministry’s financial approval instrument, (such as: Purchase Order, Standing Offer Order, Direct Purchase Order, or any other form approved by the Minister). “Primary software” are products which comprise the mandatory core components of the EIM suite of products that must be supported by a single manufacturer. “Prime Vendor” means the Vendor, in a Consortium bid, that is responsible for the provision of the Software and Services and is accountable for all terms and conditions of the Standing Offer Contract. “Proposal” means the Vendor’s response to this RFP and includes all the Vendor’s attachments and presentation materials. “Purchaser” means:

(a) departments of Her Majesty; (b) boards, commissions and organizational units that form part of the public service of

Alberta but are not part of a department of Her Majesty; or (c) corporations that are an agent of Her Majesty, and (d) Approved Organizations.

“Request for Proposals (RFP)” means the solicitation for the Services and Materials including attached appendices. “Services” means the functions, duties, tasks and responsibilities to be provided by the Vendor as described in this RFP. “should”, “optional”, “desirable” means a requirement having a significant degree of importance to the objectives of this RFP. “SMB” see “Supply Management Branch”. “Software” means the proposed Software products and /or Services to be provided by the Vendor that meet or exceed all of the requirement specified in the RFP without customization. “Standing Offer Contract”, “Contract” means a written agreement between the Vendor and Her Majesty to provide the Software contemplated in this RFP, and under which there is no commitment to purchase the Software or any portion of the Software. “Supply Management Branch (SMB)” means the Contracted Services Section of ACSC. “Value-added Software” is software which is not included in the functional requirements but, in the opinion of the Vendor, may be of interest to the GoA in managing its information assets and supports the mandatory core components of the EIM suite (for example, digital rights management).


5

“Vendor” means an organization responding to this RFP with a Proposal. “Warranty Period” means the greater of the warranty stated in this RFP, the standard Manufacturer's, Canadian Distributor’s or Authorized Dealer's warranty, including any warranty extensions. References to “Alberta Government Services”, “Alberta Corporate Service Centre”, “ACSC”, “Department”, “Contracted Services Section”, “Government of Alberta”, “GoA”, “Her Majesty”, “AGS”, “Minister”, “SMB”, “Supply Management Branch”, mean “Her Majesty the Queen in right of Alberta” and are used only for administrative purposes. Headings are used for convenience only, and they do not affect the meaning or interpretation of the clauses. Words in the singular include the plural and vice versa.

2.2 RFP Schedule of Events

RFP Issue Date ...............................................................Oct. 5, 2004

RFP Closing Date...........................................................Nov. 5, 2004

Evaluation of Proposals .................................................Nov. 15, 2004

Notification of Shortlist Vendors ..................................Nov. 16, 2004

Shortlist Presentations/Software Demonstrations.........Nov. 29 – Dec. 17, 2004

Evaluation Testing Period..............................................Nov. 29 – Dec. 17, 2004

Selection of Preferred Vendor(s)...................................Dec. 22, 2004

Contract(s) Finalization..................................................mid-January, 2005

The above dates are subject to change at the sole discretion of Her Majesty.


6

3.0 RFP ADMINISTRATION TERMS AND CONDITIONS

All terms and conditions of this RFP are deemed to be accepted by the Vendor and incorporated by reference in its Proposal, except such terms and conditions as are expressly excluded in the Proposal.

3.1 General

3.1.1 Vendors must obtain this RFP directly from APC, or the Proposal will be rejected. SMB may, at any time and without notice, waive this requirement.

3.1.2 Vendor Questions All questions regarding this RFP must be directed to the Contracting Manager, in writing. Enquiries and responses will be recorded and may, in Her Majesty’s discretion, be distributed to all Vendors. The Vendor has a responsibility to notify the Contracting Manager in writing, of any ambiguity, divergence, error, omission, oversight, contradiction, or item subject to more than one interpretation in this RFP, as it is discovered, and to request any instruction, decision, or direction required to prepare the Proposal. In order for SMB to deal effectively with Vendor questions or concerns about any terms, conditions or requirements of this RFP including the Contract provisions, such questions or concerns must be communicated in writing to the Contracting Manager at least seven (7) Business Days prior to this RFP’s closing date. Questions received after this time will be answered if, in the opinion of SMB, time permits. Verbal responses to enquiries are not binding on any party.

3.1.3 Current Technology The Software must:

(a) be new;

(b) be the most current production and proven technology;

(c) conform to Canadian Federal and Alberta Provincial legislation; and

(d) comply with this RFP's requirements. Software that has not commenced full production or is not commercially available as of this RFP’s closing date and time, or has been or is scheduled to be, discontinued or replaced with new models or versions, may be rejected.

3.1.4 Confidentiality

The Vendor’s employees, subcontractors and agents shall:

i) keep strictly confidential all information concerning the Minister or third parties or any of the business or activities of the Minister or third parties acquired as a result of participation in this RFP; and

ii) only use, copy or disclose such information as necessary for the


7

performance of the Services or upon written authorization of the Minister.

The Vendor shall maintain security standards, including control of access to data and other information, consistent with the highest standards of business practice in the industry.

3.1.5 Freedom of Information

3.1.5.1 The Vendor acknowledges that:

(a) The Freedom of Information and Protection of Privacy Act of Alberta (FOIP) applies to all information and records relating to, or obtained, generated, created, collected or provided under, the RFP or the Contract and which are in the custody or control of Her Majesty;

(b) FOIP imposes an obligation on Her Majesty, and through the RFP and Contract on the Vendor, to protect the privacy of individuals to whom information relates. The Vendor shall protect the confidentiality and privacy of any individual’s personal information accessible to the Vendor or collected by the Vendor pursuant to the RFP or the Contract;

(c) For the records and information obtained or possessed by the Vendor in connection with or pursuant to the RFP or the Contract, and which are in the custody or control of Her Majesty, the Vendor must conduct itself to a standard consistent with FOIP when providing the services or carrying out the duties or other obligations of the Vendor under the RFP or the Contract.

3.1.5.2 The purpose for collecting personal information for the RFP is to enable

Her Majesty to ensure the accuracy and reliability of the information, to evaluate the Proposal, and for other related program purposes of Her Majesty. Authority for this collection is the Government Organization Act, as amended from time to time. The Vendor may contact the Contracting Manager identified in the RFP regarding any questions about collection of information pursuant to the RFP.

3.1.6 Time

Time is of the essence in this RFP and the Contract.

3.1.7 Proposed Software The Vendor, if other than the Manufacturer, must:

(a) be a Canadian Distributor or Authorized Reseller for the Software prior to the RFP closing date and time and, upon request, provide written confirmation to SMB of such authorization from the Manufacturer.

(b) upon request, provide written confirmation to SMB from the Manufacturer that all rights granted in relation to the Software are agreed to by the Manufacturer.


8

The Vendor must provide Manufacturers’ names and software version numbers for the proposed Software in the Proposal. The Vendor must provide the Manufacturer's published specification sheets and descriptive literature for the Software. If any specifications in this RFP are not identified in the specification sheets or literature, the Vendor must, upon request, provide written confirmation from the Manufacturer or Canadian Distributor validating the Software meets those specifications.

3.1.8 Agreement on Internal Trade This RFP is subject to Chapter 5 of the Agreement on Internal Trade.

3.1.9 Conflict of Interest

Vendors must fully disclose, in writing to the Contracting Manager on or before the closing date of this RFP, the circumstances of any possible conflict of interest or what could be perceived as a possible conflict of interest if the Vendor were to become a contracting party pursuant to this RFP. SMB shall review any submissions by Vendors under this provision and may reject any Proposals where, in the opinion of SMB, the Vendor could be in a conflict of interest or could be perceived to be in a possible conflict of interest position if the Vendor were to become a contracting party pursuant to this RFP.

3.1.10 Vendor Expenses

The Vendor is responsible for all costs of preparing and presenting its Proposal and for subsequent negotiations, if any, with Her Majesty.

3.1.11 Period of Commitment

Proposals shall be final and binding on the Vendor for 120 days from this RFP’s closing date and time and may not be altered by subsequent offerings, discussions, or commitments unless the Vendor is requested to do so by SMB.

3.1.12 Multiple Proposals

If multiple Proposals are offered, the Vendor must submit each Proposal separately in the same format as outlined in this RFP. Proposals must meet the fundamental intent of this RFP. The acceptability of each Proposal will be decided by the Evaluation Team.

3.1.13 Pricing

Vendors should propose in Canadian funds. Where applicable, Proposals in U.S. funds will be converted to Canadian funds by SMB and evaluated on the converted amount. This conversion will be based on the currency spot rate appearing on the Bank of Montreal’s web site http://www.bmo.com/economic/regular/fxrates.html on the RFP closing date. The Contract will be issued in Canadian funds in the amount converted from the amount proposed in U.S. funds. Payment will be made in Canadian funds. If all Proposals received are quoted in U.S. funds, the Contract will be issued and payments made in U.S. funds.


9

If an extension is incorrect, the net unit price will apply. Net unit prices shall include all costs to complete delivery of the Software to the Purchaser's site. All costs referred to in this clause shall include, but are not limited to, packaging, handling, freight, duty, customs, brokerage fees, insurance, and where applicable, traveling and living expenses.

3.1.14 Irrevocability of Proposals

Vendors may amend or rescind their Proposal prior to the RFP closing date and time by submitting a clear and detailed written notice to SMB. Subject to section 3.1.11, all Proposals become irrevocable after the RFP closing date and time.

In either of the following circumstances:

• the Vendor has rescinded a Proposal prior to the RFP closing date and time; or

• SMB has received the Proposal after the RFP closing date and time;

such Proposal will, at the Vendor’s choice, either be returned to the Vendor at the Vendor’s expense after the RFP closing date and time, or destroyed by SMB after the RFP closing date and time.

3.1.15 RFP Closing

This RFP will close at 14:00:59 Alberta Time on this RFP’s closing date. Proposals shall be received by SMB before 14:01:00 Alberta Time on this RFP’s closing date. For RFP closing purposes, the official time of receipt of Proposals shall be as determined by the time recorder clock used to time and date stamp Proposals upon submission to SMB.

3.1.16 Proposal Submissions

Facsimile or digital Proposals in any form (e.g. diskette files, tape files, e-mailed files) will not be accepted, unless requested by SMB or subject to sub-section e) below. Proposals may be delivered by hand, courier or mail during the Hours of Operations at SMB. In responding to this RFP, note to the following:

• The Proposal Submission Letter in APPENDIX J of this RFP, or a similar

representation of the same information as in that letter, must be completed, signed by an authorized representative of the Vendor and included in the Proposal.

• Proposals received unsigned or after this RFP’s closing date and time will

be rejected. • Ambiguous, unclear or unreadable Proposals may be cause for rejection.

• Proposals must be sealed and clearly marked with this RFP’s number and

RFP closing date and addressed as follows: Contracted Services Section Supply Management Branch


10

Alberta Corporate Service Centre 2nd Floor, 12360 - 142 Street Edmonton, Alberta T5L 4X9 Reference: Electronic Information Management Software Selection Project - RFP 279PA-42

• Submit twelve (12) bound copies (bound in such a manner that the pages

lie and remain flat when opened), one (1) unbound copy of the Proposal, and a CD(s) (compact disc) containing a softcopy of the Proposal (preferably in .pdf format).

3.1.17 Consent to Use of Information

The Vendor consents, and has obtained the written consent from any individuals identified in the Proposal, to the use of their personal information in the Proposal by Her Majesty, Her Majesty’s employees, subcontractors and agents, to enable Her Majesty to evaluate the Proposal and for other program purposes of Her Majesty.

3.1.18 Proposal Public Opening

Proposals will be opened publicly at SMB, 2nd Floor, 12360 - 142 Street, Edmonton, Alberta immediately following RFP closing.

3.1.19 Recapitulation of Proposals

SMB reserves the right to publish the names of responding Vendors and any summary cost information deemed appropriate by SMB.

3.1.20 Proposal Return

Proposals and accompanying documentation submitted by Vendors, upon receipt by SMB, will become the property of Her Majesty and will be retained by Her Majesty, subject to section 3.1.14. Proposed Software provided by unsuccessful Vendors will be destroyed by SMB after the award of the Contract or returned to the address as directed by the Vendor in the Proposal at the Vendor’s expense and risk.

3.1.21 Proposal Rejection SMB may reject the lowest cost Proposal, or any or all Proposals.

3.1.22 Termination This RFP may be canceled at any time and any and all Proposals may be rejected in whole or in part when the SMB determines such action to be in the best interest of the Government of Alberta.

3.1.23 Vendor Debriefing

SMB will, at the request of an unsuccessful Vendor who responded to this RFP, conduct a debriefing for the purpose of informing the Vendor as to why their Proposal was not selected.

3.1.24 Tax


11

Her Majesty may deduct from all payments to the Vendor such amounts as required by the Canadian Income Tax Act, as amended, revised or substituted from time to time.

3.1.25 Sub-Contractual Terms and Conditions

It is the responsibility of the Vendor to coordinate all activities relating to the Vendor’s subcontractors. Any intent to subcontract must be detailed in the Proposal, including the name of the subcontractor(s), address, field of activity, the extent of the work to be subcontracted, and references.

3.1.26 Product or Software Subsets or Supersets

Her Majesty reserves the right to accept any functional subset or superset of the proposed Software or Services.

3.1.27 Contract Duration The Contract shall be for three years, with the Minister having the option to extend for two additional two-year terms on the same terms and conditions, including pricing.

3.1.28 Proposal Alteration Proposals may not be changed by the Vendor after the RFP Closing Date and Time, unless the Vendor is requested to do so by the SMB.

3.1.29 Evaluation, Demonstration and Testing

The Vendor must provide a full production copy of all proposed Software and an electronic copy of the technical proposed software documentation to the Minister at the Vendor’s expense with their Proposal (See M6) to allow testing and evaluation of the proposed Software. This copy of the Software should be web-enabled using Oracle as the DBMS. Vendors may be short-listed and selected to present their Proposals and to demonstrate their proposed Software. Through this shortlist presentation/ demonstration, the Vendor must demonstrate to the satisfaction of the Evaluation Team that the proposed Software is compliant with the mandatory requirements described in this RFP. The Vendor should also demonstrate that the proposed Software provides the functionality to meet the desirable and other requirements laid out in the Proposal. If the Vendor has been short-listed to demonstrate its proposed Software, the Minister will commence Evaluation Testing of the proposed Software. The period of Evaluation Testing shall not exceed 60 Business Days. Vendors should provide a copy of any license agreement that GoA is expected to review in the event of finalizing the Standing Offer Contract.

3.1.30 Modified RFP Process In the event non-compliant Proposals are submitted in response to the RFP, SMB and the Department reserve the right to undertake a Modified RFP Process in order to facilitate the selection of a preferred Vendor. The Modified RFP Process, if employed, will be conducted as follows:


12

• All Vendors submitting non-compliant Proposals will be requested to prepare a “Modified RFP Process Proposal”. The necessity, scope and the timing of such a Modified RFP Process will be at SMB’s and the Department’s discretion;

• Details regarding the manner and form of the Modified RFP Process

and the expected deliverables to be included therein will be provided in advance to all Vendors who submitted a non-compliant Proposal;

• Modified RFP Process Proposals and accompanying documentation,

upon receipt by SMB, will become the property of and be retained by Her Majesty;

• Vendors submitting Modified RFP Process Proposals must, in the

opinion of Her Majesty, meet the fundamental intent of the requirements identified in the Modified RFP Process;

• At the conclusion of the Modified RFP Process, following the

Vendors’ submission of the Modified RFP Process Proposals, the Evaluation Team will evaluate in accordance with an evaluation plan developed for the Modified RFP Process Proposal and will select the preferred Vendor(s), if any.

3.2 Proposal Evaluation

3.2.1 Evaluation Sequence and Process

The Vendor’s written submission in response to this RFP will be the basis of evaluation of the Proposals. Therefore, it is important that Vendors accurately and completely address all requirements of this RFP in their submissions. 3.2.1.1 Evaluation Process The Evaluation Team will evaluate Proposals in the sequence identified below. During the evaluation process, Vendors may be required to provide additional information to clarify statements made in their Proposals. Each Proposal shall be evaluated separately against this RFP’s requirement. 3.2.1.2 Evaluation Sequence

a) Mandatory RFP Requirements Vendors must provide sufficient detail in their Proposal to substantiate compliance with the RFP’s mandatory requirements. In addition, Vendors must provide cross references to any parts of the Proposal that contain information that they wish to be considered in the evaluation of any given requirement.


13

b) Rated Criteria The Evaluation Team will further evaluate Proposals against the evaluation criteria in the RFP.

Subject to the requirements of FOIP, such ratings shall be confidential, and no totals or scores of such ratings shall be released to any party. The evaluation results of the successful Vendor(s), including the Evaluation Team's comments about the strengths and weaknesses of the proposed Software, may be provided to those individuals within the Government of Alberta and Approved Organizations who are responsible for, and to make decisions regarding, the selection of the appropriate Software for a Ministry's and Approved Organization’s business environment.

c) Shortlisting

A shortlist of Vendors may be established. Shortlisted Vendors may be requested to make formal presentations regarding their Proposal and Software demonstration to the Evaluation Team. Key Vendor management and technical personnel will be expected to participate in presentations, demonstrations and evaluation testing. These presentations and demonstration will be made at no cost to Her Majesty.

The Vendor will be given ten (10) Business Days, from the time of notification by the Evaluation Team, to prepare for the presentation and demonstration. The Evaluation Team will provide the Vendor with a detailed description of the demonstration requirements (test scripts, if any) and schedule. The Vendor is responsible for supplying all software necessary to meet the requirements of this demonstration and must have the proposed EIM Software installed at the designated ACSC site, prior to the demonstration. The Vendor is responsible for all costs related to this presentation and demonstration. The Software used for this demonstration must be identical in its name and version to the one in the Proposal. It is important to note that any claims of compliance for mandatory and desirable features in future releases of the proposed Software will not be considered. The Vendor, prior to the demonstration, must highlight any additional scripting, configuration, coding, hardware and software configurations not included in the Proposal in writing to the Contracting Manager. The demonstration and evaluation of the proposed Software shall not exceed 2 Business Days. If the demonstration cannot be completed due to Evaluation Team requests for further information/clarification, Her Majesty reserves the right to extend the demonstration for an additional period of time. During this process, the Evaluation Team will clarify and enhance their understanding of the Proposal and the functionalities of the proposed Software to confirm whether the mandatory and desirable


14

requirements are consistent with the representations made in the Vendor’s Proposal, and if necessary, re-examine and adjust the initial score accordingly. If at any time during the presentation and demonstration, the Evaluation Team determines that the proposed Software does not meet any mandatory requirement(s) of this RFP, the Vendor’s Proposal will not be given any further consideration.

d) Evaluation Testing

Should the Vendor be shortlisted by the Evaluation Team to present its Proposal and demonstrate the proposed Software, the Minister will also initiate detailed Evaluation Testing, subject to section 3.1.29.

Evaluation Testing will allow the Evaluation Team to confirm and qualify that the proposed Software is compliant with the mandatory requirements and provides the functionality to meet the desirable requirements consistent with the Vendor’s Proposal. This testing shall not exceed 60 Business Days once the Vendor presentation has been completed. During this process, the Evaluation Team will re-examine the scores and if necessary, adjust the score accordingly. If at any time during the Evaluation Testing process, the Evaluation Team determines that the Software proposed by the Vendor does not meet any mandatory requirement of this RFP, the Vendor’s Proposal will not be given any further consideration.

3.3 Contract

3.3.1 Standing Offer Contract Finalization Following the final evaluation, the preferred Vendor(s) shall be required to finalize a Standing Offer Contract with SMB and the Department, which may not include an initial purchase of the proposed Software but will contain the terms and conditions of APPENDIX A, in this RFP. Her Majesty will have the option to incorporate the Vendor’s proposed licensing and/or maintenance agreement.

If, in the opinion of SMB and the Department, it appears that Contract finalization will not occur with the preferred Vendor within thirty (30) days, Contract finalization with other Vendors submitting responsive Proposals may be undertaken.

3.3.2 Order of Precedence

This RFP and the Proposal shall form part of the Contract. In the case of conflicts, discrepancies, errors or omissions among this RFP, the Proposal, and the main body of the Contract, the documents and amendments to them shall take precedence and govern in the following order: (a) Main body of the Contract (b) RFP (c) Proposal

3.3.3 Contractual Warranties


15

Subject to Clause 11 Warranty in APPENDIX A, Standing Offer Contract, the Vendor shall indicate the warranty for the proposed Software products and warrant that the Purchaser shall receive the warranty, and any other benefits, for the Software. Claims made in the Proposal shall constitute contractual warranties. Any provisions in the Proposal may be included in the main body of the Contract.

3.3.4 Consortium Proposals In the case of Consortium Proposals the Prime Vendor is responsible for all acts, omissions, errors and performance under the Contract.

3.3.5 ICT Services Coordinator

The Government of Alberta is considering a cross-government initiative that would introduce a new structure for the delivery of government ICT services. This initiative would establish a relationship with an ICT Service Coordinator who would assume responsibility for overall coordination of ICT infrastructure and application maintenance services for the Government of Alberta. Clause 24 of the Contract contains a provision that allows the Minister to assign any part or the entire Contract to a third party.


16

4.0 PROJECT INFORMATION

4.1 Project Overview

4.1.1 Introduction This project shall be referred to as the Electronic Information Management (EIM) Software Selection Project. The EIM project is a government-wide initiative that addresses the need for a consistent and comprehensive approach to managing information as a corporate asset similar to human, financial and technology resources. More and more, delivering on the government’s commitment to Albertans depends on collaboration among Ministries. However, ad hoc and weak management of information assets may hinder collaboration across the government. There are 23 Ministries within the GoA at present. To date, each Ministry has been responsible for procuring, implementing and operating their own EIM Software products, within their own information technology environments. The main goal of this project is to establish a standardized and qualified list of EIM software product(s) that would allow each Ministry to migrate to the preferred Vendor(s)’ Software over the term of this Standing Offer Contract and beyond potentially. Currently, Ministries lack the information management tools such as EIM software that will enable them to:

• ensure that information resources are accessible by staff, clients and business partners, not only within individual programs and Ministries, but across Ministries;

• apply systematic rights of access to:

o enable the fullest use of individual resources where appropriate,

o restrict access to personal and other sensitive information where required by the Freedom of Information and Protection of Privacy Act, and

o protect the evidentiary integrity of official records;

• reduce the escalating costs associated with access to, management, storage, and lifecycle management of these resources; and

• support legislative requirements such as the Records Management Regulation, the Historical Resources Act and the Government Emergency Planning Regulation.


17

A corporate approach to EIM1 will position the GoA to manage information resources in a consistent manner to support service delivery and enable Ministries to implement EIM at a lower cost. EIM introduces the required consistent and systematic approach to managing all information assets, regardless of the medium in which they are held, throughout their entire life cycle. As a result, it will be easier:

• for people to do their work;

• for the general public, contractors and governance groups to gain access, when authorized, to government information; and

• for Ministries to meet their accountability requirements.

4.1.2 Objectives

The objective of this project is for Her Majesty to enter into a Standing Offer Contract(s) with the preferred Vendor(s) that have demonstrated the ability to successfully supply large-scale, enterprise-wide, integrated Electronic Information Management (EIM) Software products. Depending on the evaluation results and the number of qualified product(s), Contracts with up to three preferred Vendors may be established. This project will facilitate the GoA in procuring the required server and workstation licenses to reflect the GoA’s current and future EIM needs and technology direction as GoA Ministries begin to move towards adopting this new standard. As a result, Ministries will be able to reduce the time and effort to (a) develop their business cases (b) decide among competing products, and (c) implement EIM Software products to meet service commitments.

4.1.3 Background A corporate approach to EIM was identified by the GoA’s Information Management Advisory Committee (IMAC) as a priority to improve the discipline and coordination of information asset management within the government. This EIM strategy supports the Information and Communication Technology (ICT) strategy which was adopted by the Deputy Ministers Committee. AGS has undertaken the task of developing and managing this RFP for an integrated suite of EIM Software products to meet GoA’s identified needs. The selected product(s) will have to address current cross-government requirements as the transition occurs towards a shared GoA environment, resulting in Contract(s) for Software products that are available to Ministries as required.

1 Electronic information management (EIM) is used here to emphasize the breadth of information to be managed. In other contexts, and within some Ministries, this is referred to as Electronic Records and Electronic Document Management (ER/EDM) and in the industry is also known as Smart Enterprise Suites (SES) and/or enterprise content management (ECM). EIM is intended to emphasize the need to manage all digital assets of the government and to integrate information in digital format and information in hard media formats (e.g. paper).


18

4.1.4 Project Scope

The project scope includes the evaluation and selection of integrated suites of EIM Software products for the GoA. For the purposes of this project, EIM Technology includes both the common and unique functionality of these component technologies:

• Document Management (D); • Electronic Team Collaboration (C); • Web Content Management (W); • Records Management (R); and

NOTE: Workflow must be fully integrated with the above four components.

• Seamless integration with industry leading imaging, scanning, and OCR/ICR systems.

The project will assess capabilities of commercially available EIM Software products needed to effectively manage electronic documents, web content, paper files and other information in government. A maximum of 3 products that meet the government’s requirements will be selected and Standing Offer Contracts may be established with Vendors of the selected integrated suites. This project does NOT include the implementation of EIM products across Ministries. It is anticipated that individual Ministries will move forward as business requirements demand and resources are allocated. Vendors may be invited to respond to subsequent RFPs to implement EIM for the requesting Ministry. Further details about the EIM concepts are available in APPENDIX B.

4.1.5 Configuration of Product The Vendor’s Proposal for integrated EIM Software products must include tools that will enable the GoA to independently configure the proposed suite of EIM Software products. Vendors must clearly state in their Proposals and provide supporting documentation showing the extent to which the GoA will be able to configure the proposed Software products. Further information can be found in M16 in APPENDIX D – Project Requirements.

4.1.6 Anticipated Hardware Platform The GoA has primarily Compaq or HP Servers running either Windows 2000 or Windows 2003 participating in Windows 2003 Active Directory domains. A Raritan KVM switch environment allows for local console access to the servers. Large disk storage requirements are accommodated through a storage area network for SAN and NAS storage. There are a smaller number of SUN Solaris and IBM AIX servers as well.

The above information is subject to change based on Vendor’s response to M12 in APPENDIX D – Mandatory Requirements.


19

The GoA also anticipates on setting up the following environments in conjunction with the production environment: • User Acceptance Training (UAT)/Training

o This environment would allow for the testing of new functionalities, pre-production testing and training for new users. This environment would be separate from the production environment.

o The GoA anticipates that only 15% of desktop users from Ministries that have acquired EIM Software products from the Standing Offer would access this environment at one time.

• Upgrade/Development/Software Release testing environment

o This environment would allow for the testing of major/minor upgrades and new software releases. This environment would be separate from the production environment.

o The GoA anticipates that only 5% of desktop users from Ministries that have acquired EIM Software products from the Standing Offer would access this environment at the same time.

4.2 EIM Software Requirements

Vendors must respond to the mandatory requirements and should respond to the desirable requirements identified in APPENDIX D Project Requirements of this RFP. The functional and technical requirements for the EIM Software have been defined, according to the current and envisioned EIM needs for the GoA, as well as the GAEA architectural requirements. Refer to section 6.0 Proposal Content Guidelines when responding to this RFP.


20

5.0 EVALUATION CRITERIA

The RFP evaluation criteria will be distributed within the following categories and their sub-level components:

Evaluation Criteria Rating Category Weighting

Approach/Understanding 10% Technical Merit 60% Vendor Credentials and Suitability 10% Maintenance/Support as per APPENDIX D – Mandatory Requirements – M8

5%

Cost 15%

Acceptance of RFP terms and conditions will also be evaluated, but not scored. Proposals will be evaluated and scored based on the degree to which the Vendor’s Proposal meets the requirements of this RFP. Selection of the preferred Vendor(s) will be based on compliance to the mandatory requirements of this RFP and the highest overall score, subject to satisfactory qualification of the Software by the Evaluation Team during Acceptance Testing.


21

6.0 PROPOSAL CONTENT GUIDELINES

6.1 Proposal Format To facilitate ease of evaluation by the Evaluation Team, and to ensure each Proposal receives full consideration, Proposals should be organized in the following format using the section titles and sequence listed below:

a) Proposal Submission Letter as per APPENDIX J;

b) Table of Contents;

c) Vendor Executive Summary;

d) Vendor Corporate Profile and Credentials, as per 6.2.3;

e) Proposed Software Products Summary Form (APPENDIX D);

f) Mandatory Requirements – Vendor Responses (APPENDIX D);

g) Business and Technical Requirements – Vendor Responses (APPENDIX D);

h) Financial (Pricing) as per APPENDIX F;

i) RFP Administration Terms And Conditions, as per section 3.0;

h) Contract Provisions, APPENDIX A;

i) Vendor References as per APPENDIX H; and

j) Appendices (include APPENDIX G, I and any other information as required). Forms as required above are provided in the Appendices of this RFP or a similar representation of the same information must be used. The “Vendor Response” column in APPENDIX D should provide details and where necessary clearly cross-reference supporting sections of the Proposal.

6.2 Proposal Content The requirements described with a “must” in this section are required to be provided in the Proposal. It is highly desirable that Proposals also respond to “should” requirements in this section. The Proposal response to all mandatory and desirable requirements in this section will be utilized in evaluating each Proposal. Vendors proposing an alternative to any RFP requirement must clearly substantiate the merit of the alternative. Proposed alternatives must substantially meet the fundamental intent of the requirement. The acceptability of the alternative will be determined by the Evaluation Team. 6.2.1 Proposal Submission Letter

The Proposal Submission Letter in APPENDIX J must be completed, signed by an authorized representative of the Vendor, and included in the Proposal.

6.2.2 Executive Summary An executive summary of the key features of the proposal must:

• Clearly reflect an understanding of the scope, objectives and requirements presented in this RFP;


22

• Indicate why the Vendor considers itself to be the “right” Vendor and what key strengths it will provide in the immediate and long term;

• Identify what the Vendor sees as the critical success factors and impediments for providing the best products, services and maintenance; and

• Clearly identify the Vendor’s approach and understanding of this RFP and the subsequent Standing Offer Agreement Terms and Conditions.

6.2.3 Vendor Corporate Profile and Credentials

6.2.3.1 The Proposal must include:

a) a brief introduction of the Vendor, identifying the Vendor’s contact with the Department;

b) the full legal name of the Vendor;

c) the location of the Vendor’s head office and service centres;

d) a Vendor contact for all questions and clarifications arising from the Proposal. The contact information should include the person’s title, address including email, telephone and facsimile number;

6.2.3.2 The Proposal should include:

a) a Vendor contact authorized to participate in Contract negotiations. The contact information should include the person’s title, address including email, telephone and facsimile number;

b) financial information of Vendor’s corporation to demonstrate a solid financial history and background:

• Size of the firm

• Financial growth over the last 3 years

• Revenue (preferably attach audited financial statement or annual report); and

c) details of any and all subcontracting arrangements proposed by the Vendor.

6.2.3.3 In the case of Consortium Proposals, the Proposal should also:

a) include a statement that the Prime Vendor is responsible for all acts, omissions, errors, and performance under the Contract;

b) describe the role of the Prime Vendor and each Consortium member;

c) identify management, ownership, financial and legal relationships between Consortium members;

d) demonstrate a Consortium management approach that will ensure, for the duration of the Contract, clear lines of communication and delivery of Services; and


23

e) demonstrate that Consortium members are qualified to perform the tasks they have been proposed to perform.

6.2.4 Vendor Proposed EIM Products

The Vendor must provide a detailed description of how the proposed suite of EIM Software products will meet the needs described in this RFP. The description must include but is not restricted to a response to APPENDIX D – Project Requirements where it states a response is required. Vendors are asked to systematically address each section. If a Vendor wishes to propose more than one suite of EIM Software products, a separate proposal must be submitted, as defined in 3.1.12 Multiple Proposals. During the evaluation process, consideration will be given when the Vendor’s proposed Software products includes functionality that exceeds the requirements of any of the above components.

6.2.5 Pricing Vendors must use the Pricing Form in APPENDIX F – Pricing Form to submit pricing, for the Software products to meet the requirements in this RFP. The Vendor must:

a) provide clear, concise pricing details; and

b) include both regular pricing and, if applicable, discount pricing.

6.2.6 RFP Administration and Conditions

The Proposal must indicate that the Vendor accepts the RFP Administration Terms and Conditions specified in section 3.0 in this RFP.

6.2.7 Contract Provisions Her Majesty considers each of the provisions in APPENDIX A- Standing Offer Contract as highly desirable, excluding clause 13. Source Code which is a mandatory requirement, and will consider Vendor's explicit response to each of the Contract provisions in the evaluation of the Proposal. All clauses of the Contract, excluding clause 13, will be finalized between the preferred Vendor and SMB. The Proposal must include an explicit response to each of the provisions listed in APPENDIX A by indicating either: “Met” - means that the Vendor accepts the provision exactly as drafted. “Not Met”- means that the Vendor does not accept the provision exactly as

drafted, without qualification. If the Vendor does not accept a Contract provision exactly as drafted, without qualification, the appropriate response is “Not Met” and the Vendor must provide in their Proposal the Vendor’s final position on the provision, i.e., the wording that the Vendor requires for the Vendor to enter into a Contract. Her Majesty will deem any alternative wording,


24

including suggested, recommended, or proposed wording, as reflecting the Vendor’s final position on the provision.

If the Vendor responds “Not Met” to any of the Contract provisions in APPENDIX A, the Vendor should explain how the proposed alternative wording is balanced in terms of the rights and obligations of the parties. Any questions about these provisions must be addressed to the Contract Manager prior to this RFP Closing date.

6.2.8 Vendor References

The Proposal must include corporate references for at least three (3) clients of the Vendor, for whom similar EIM Software has been supplied, as per the detailed requirements found in APPENDIX H. References must include the name of the organization and official contact person and should include a street address, email address and telephone number. Her Majesty may contact these or other references without prior notice to the Vendor. Vendors who, in the opinion of Her Majesty, receive unsatisfactory references may have their Proposal rejected.

6.2.9 Appendices

If the Vendor wishes to include any other material not specifically requested by this RFP, it may do so by including additional appendices in the Proposal.


25

APPENDICES

Appendix A – Contract Provisions


26

APPENDIX A – Contract Provisions CONTRACT NUMBER: . THIS STANDING OFFER CONTRACT MADE IN TRIPLICATE THIS DAY OF , 2005. BETWEEN: HER MAJESTY THE QUEEN in right of Alberta, as represented by the Minister of Government Services ("Minister") - and - (Name of Company) ("Vendor") 1. Background

The Minister issued a Request for Proposals dated October 5, 2004 (“RFP”), which forms part of this Contract, for the supply of the Electronic Information Management Software products.

The Vendor’s response dated __________, 2004 ("Proposal"), which forms part of this Contract, was accepted to supply the Electronic Information Management Software products, specified in the attached Schedule “A” (“Software”), which forms part of this Contract.

2. Contract The parties agree as follows:

2.1 The Background is part of this Contract. 3. Definitions

In this Contract: “Acceptance” means that when the Purchaser is of the opinion after a visual inspection, the Software appears to be undamaged and the same as ordered; and has the same components as the Software proposed or, as supplied for Validation Testing. “Acceptance Testing” means the Acceptance and/or testing performed by the Purchaser to determine whether the Software performs according to the Manufacturer’s published specifications, industry standards, the RFP, and the Proposal.

“Alberta Purchasing Connection (“APC”)” means the Government of Alberta’s electronic

tendering system.

“Approved Organizations” means organizations, including hospitals, as defined in the Hospitals Act, schools, post-secondary educational institutions, municipalities, Metis settlements and any organizations that carry out services or programs on behalf of the



27

Government of Alberta, which are approved by the Minister to order the Software on the same terms and conditions as stated in this Contract. Approved Organizations will be posted on APC and updated from time to time.

“Authorized Dealer” means any individual, partnership, corporation, association or other legal relationship that is duly authorized, permitted or licensed by the Manufacturer to sell, license, lease or otherwise distribute the Software.

“Business Day” means 8:15 am to 4:30 pm in Alberta from Monday through Friday excluding holidays observed by Her Majesty the Queen in right of Alberta.

“Canadian Distributor” means an individual, partnership, corporation, association or other legal relationship that is duly authorized, permitted or licensed by the Manufacturer to sell, license, lease, or otherwise distribute any or all of the Software in Canada. “Change Request” is a written request from the Vendor to the Minister to consider whether certain Services or Materials are or are about to be outside the scope of this Contract. “Confidential Information" means Minister Confidential Information and Vendor Confidential Information.

“Confidentiality Legislation” means the Freedom of Information and Protection of Privacy Act and the Health Information Act and any other similar or related legislation currently in force or enacted in the future. “Contract” means the written agreement between the Vendor and the Minister to allow Purchasers to obtain the Software and consists of the RFP, the Proposal and this document. “Freedom of Information and Protection of Privacy Act” means the Freedom of Information and Protection of Privacy Act, R.S.A. 2000, c.F-25, and any regulations made thereunder, as may be amended from time to time. “Health Information” means “health information” as defined in the Health Information Act. “Health Information Act” means the Health Information Act, R.S.A. 2000, c.H-5, and any regulations made thereunder, as may be amended from time to time.

“Her Majesty” means Her Majesty the Queen in right of Alberta.

“Identified User” means the Ministry’s purchasing representative accessing a purchase under the Contract.

“Manufacturer” means any individual, partnership, corporation, association or other legal relationship that manufactures, assembles, or produces any or all of the Software. “Minister” means Her Majesty the Queen in right of Alberta, as represented by the Minister of Government Services.



28

“Minister Confidential Information” means Personal Information, Health Information and any other information concerning the Minister and/or third parties or any of the business or activities of the Minister and/or third parties acquired by the Vendor as a result of participation in this Contract, including information that is contained in data management systems of the Minister, financial or business information and plans of or relating to the Minister or third parties. “Orders” means the order, which is deemed to include all the terms and conditions of the Contract, placed by an Identified User, and accompanied by the Ministry’s financial approval instrument, such as: Purchase Order, Standing Offer Order, Direct Purchase Order, or any other form approved by the Minister or a similar document from an Approved Organization. “Procurement Section” means the Procurement Section of the Supply Management Branch, Alberta Corporate Service Centre, Department of Government Services of Her Majesty.

“Purchaser” means:

(a) departments of Her Majesty; (b) boards, commissions and organizational units that form part of the public service of

Alberta but are not part of a department of Her Majesty; (c) corporations that are an agent of Her Majesty, or (d) Approved Organizations

“Services” means the maintenance and support functions, duties, tasks and responsibilities to be provided by the Vendor as described in this RFP.

“Software” means the proposed Software and technical documentation to be provided that meets or exceeds the requirements under the Contract. “Vendor Confidential Information” means information, supplied in confidence, concerning the Vendor and/or third parties or any of the business or activities of the Vendor and/or third parties and which is acquired by the Minister as a result of participation in this Contract. “Warranty” means, after receipt of the Software at the Purchaser's site, the greater of the warranty stated in the RFP, the standard Manufacturer's, Canadian Distributor's or Authorized Dealer's warranty, including any warranty extensions.

“Warranty Period” means after receipt of the Software at the Purchaser’s site, the greater of the warranty stated in this RFP, the standard Manufacturer's, Canadian Distributor’s or Authorized Dealer's warranty, including any warranty extensions.

4. General 4.1 Headings in this document are used for convenience only and will not affect the meaning or

interpretation of the clauses. 4.2 In this Contract:

a) words in the singular include the plural and vice versa; and



29

b) references to “Alberta Corporate Service Centre”, "Government of Alberta", “Government Services”, “Innovation and Science”, "Her Majesty” "Minister", “Ministry”, “Procurement Section” and "Purchaser excluding Approved Organizations" mean “Her Majesty the Queen in Right of Alberta” and are used only for administrative purposes.

4.3 The Vendor, for the consideration of one dollar ($1.00), receipt of which is acknowledged,

agrees to supply the Software and be paid in accordance with the provisions of this Contract.

4.4 Despite anything in this Contract, the Purchasers:

a) may purchase more Software than the Contract amount in Clause 8, provided this Contract has been amended, increasing this Contract’s financial upper limit.

b) may purchase less Software than the Contract amount in Clause 8, or

c) is not obligated to purchase any Software.

4.5 The Minister may terminate all or any part of this Contract, without cause, upon written

notice to the Vendor. The Minister shall only have to pay the Vendor for the Software received to the effective date pf the termination.

4.6 Notices or reports to be provided under this Contract will be deemed to be given to the

other party if in writing, and:

a) personally delivered;

b) sent by prepaid registered mail; or

c) sent by facsimile transmission.

Notices or reports must be addressed to: the Minister, in care of: the Vendor, in care of: Government Services (Vendor Name) Alberta Corporate Service Centre (Address) 2nd Floor, 12360 - 142 Street (Address) Edmonton, Alberta T5L 4X9 Attention: (position/title) Attention: Purchasing Officer Fax Number: Fax Number: (780) 422-9672 The address of either party may be changed by written notice to the other party. Notices or reports personally delivered or sent by facsimile transmission will be deemed received when actually delivered or transmitted, if delivery or transmission is between 8:15 a.m. and 4:30 p.m. Alberta time ("Business Hours") on any day except a Saturday, Sunday or holiday observed by the Government of Alberta ("Business Day"). Notices or reports sent by prepaid registered mail will be deemed to be received on the fourth Business Day after mailing in any post office in Canada. In the case of postal disruption, notices or reports will be personally delivered or sent by facsimile transmission.

4.7 With the exception of Approved Organizations, this is to certify that the Purchaser of the

Software is the Government of Alberta or a listed tax-free Government of Alberta Agency, therefore the Purchaser is not subject to the Goods and Services Tax (GST) or the



30

Harmonized Sales Tax (HST). The Government of Alberta’s GST registration number is 124072513. The Vendor is responsible to determine whether or not each Purchaser is subject to the GST or the HST.

4.8 The Vendor must submit, within five (5) Business Days of the first day of each month

during the Contract, a written usage report, in the form attached as APPENDIX I – Reporting Requirements in the RFP, to the Purchasing Officer.

The Vendor must immediately submit a written report to the Procurement Section, if the total orders, received by the Vendor, will expend or exceed 75% of the Contract's value.

4.9 The Vendor agrees to perform the services and deliver the Software in accordance with the

provisions of this Contract. 4.10 The Vendor shall

(a) ensure that its employees comply with the provisions of this Contract, and

(b) contract with its subcontractors and agents to comply with the provisions of this Contract.

4.11 Each party shall perform the acts, execute and deliver the writings, and give the assurances

necessary to give full effect to this Contract. 4.12 This Contract contains the entire agreement of the parties concerning the subject matter of

this Contract and no other understandings or agreements, verbal or otherwise, exist between the parties.

4.13 The parties shall not change this Contract except by written agreement. 4.14 This Contract shall be for the benefit of and binds the successors and assigns of the parties. 4.15 This Contract may be executed in any number of counterparts or by facsimile, each of

which shall be deemed an original and all of which together shall constitute one and the same contract

5. Term This Contract shall be for three years commencing upon signing by both parties unless

terminated earlier. The Minister retains the right to extend this Contract twice for up to two-year durations each on the same terms and conditions including pricing.

6. Supply/Delivery 6.1 The Vendor shall deliver, upon receipt of an Order or any other form approved by the

Minister; the Software to the Purchaser in accordance with this Contract.

6.2 The Vendor must deliver the Software identified in the Order to the Purchaser within ten (10) Business Days after the Vendor receives an Order.

If the Vendor fails to deliver the Software within this time period, the Purchaser may cancel the Order.



31

6.3 An electronic version of the Software will be acceptable if a hard copy of the Software cannot be delivered. Payment will not be made until the hard copy of the Software is delivered to the Minister. If complete delivery of the Software is not made within the specified time period, the Purchaser may:

• extend the delivery period,

• accept partial shipment, or

• cancel the Order.

6.4 The Vendor must pay all costs to complete delivery and Acceptance of the Software to the

Alberta address identified in the Order. All costs referred to in this clause must include, but are not limited to, packaging, handling, shipping, unloading, duty, customs, brokerage fees and insurance charges.

6.5 If manufacturer-designated resellers are supplying the Software, the following clause will

be added to the Contract: The Vendor must supply and deliver the Software through its authorized re-sellers as identified in a schedule (which will be attached in the final Contract). The Vendor may add or delete authorized re-sellers upon written notice to the Minister. All references to the Vendor will, as applicable, include the Vendor's authorized resellers. All Orders issued under this Contract will have a unique Contract number for each authorized re-seller as identified in a schedule (which will be attached in the final Contract) or subsequently allocated by the Minister.

6.6 Despite any other provision of this Contract, the Minister may inspect the services and the

Software at any time and may order the re-execution of any services or Software which are not performed in accordance with the provisions of this Contract, and at the Vendor’s expense, the Vendor shall re-execute the services and Software in accordance with this Contract.

7. Pricing 7.1 Subject to clause 8., the Vendor must supply the Software to the Purchaser at the prices in

Schedule "A". 7.2 If, from the RFP closing date until Acceptance of the Software, the Vendor offers to any

third party the same Software in similar quantities, at a lower price than the price stated in Schedule "A", the price to the Purchaser for these Software must then be lowered by the Vendor to this lower price for all Software ordered after the offer to the third party.

7.3 If the Manufacturer or Vendor decreases the price of the Software or if the Manufacturer or

Vendor offers promotional prices including rebates for the Software, the Manufacturer or Vendor must:

a) send the Minister written notification of all price decreases, including: promotional prices and their effective and expiry dates, within five (5) Business Days of the Manufacturer's or Vendor's announcement date. If the Manufacturer decreases the prices to the Vendor, the Vendor's decreased prices must be consistent with the intent of the Manufacturer's announced price decreases; this notification will amend the prices of the Software in Schedule “A” and



32

b) supply the Software to the Purchaser, at the decreased prices, beginning on the effective date of the Manufacturer's or Vendor's announcement.

If promotional prices are lower than the decreased prices, the promotional prices will prevail.

7.4 During the Contract, if the Manufacturer discontinues any Software, the Manufacturer or

Vendor must notify the Procurement Section in writing:

a) of the discontinued Software; and

b) the replacement software, including the unit price and effective dates.

7.5 The Minister may add related software to this Contract if such software, in the opinion of

the Minister, is required by the Minister and is within the existing pricing structure as determined by the Manufacturer.

8. Payment 8.1 The Purchaser may pay the Vendor a sum not to exceed ($__________) for the Software.

The Vendor must not process Orders from the Purchaser, if:

a) the financial upper limit stated in this clause has been expended;

b) the Contract has expired; or

c) the Contract has been terminated.

8.2.1 Despite any other provision in this Contract, the Purchaser will, upon receiving an invoice

referencing this Contract and the Order number, pay the Vendor the price in effect on the date the Software was ordered or received, whichever is lower, within thirty (30) days after Acceptance of the Software.

9. Acceptance Testing 9.1 Upon Acceptance by the Purchaser, the Purchaser will conduct Acceptance Testing of the

Software subsequent to delivery of all components of the Software. The period of Acceptance Testing shall not exceed sixty (60) Business Days.

9.2 The Vendor will have a remedy period of ten (10) Business Days from the end of Acceptance Testing to correct any and all defects identified during Acceptance Testing. At the end of Acceptance Testing or the remedy period, whichever is later, the Purchaser reserves the right to reject the Software if the Software does not operate in accordance with the Contract.

9.3 If the Software is rejected by the Purchaser:

a) The Purchaser will, at the Vendor’s expense and risk, either hold the Software for disposition by the Vendor or return the Software to the Vendor; and

b) The Vendor shall immediately, at the Purchaser’s option, either replace the

Software or, if applicable, refund to the Purchaser all monies paid.

10. Rights in Relation to the Software



33

10.1 If the Vendor is not the Manufacturer of components of the Software, then the Vendor shall

provide the Minister, within 30 days of a request by the Minister, with written authorization from the Manufacturer confirming that all rights specified in this Contract in relation to those components of the Software are agreed to by the Manufacturer.

11. Warranty 11.1 The Vendor warrants that the Software will be free of defects in workmanship and

materials for a period of time consistent with industry standards and the nature of the Software (“Warranty Period”).

11.2 The Vendor warrants that the Software will perform in accordance with the representations given by the Vendor in the Contract.

11.3 The Warranty Period will commence when the Vendor has, to the Purchaser’s satisfaction, placed its Software in production (subsequent to completion of Acceptance Testing) at the Purchaser’s site.

11.4 If the Software does not perform in accordance with the Contract during the Warranty Period, then the Vendor shall take such steps as necessary to repair or replace the Software. Such warranty service shall be provided at the Vendor’s expense and shall include all media, parts, labour, freight and insurance to and from the Purchaser’s site.

11.5 Warranty service may be provided by a third party, provided these parties are authorized

to perform warranty service by the Vendor or, if the Vendor is not the Manufacturer, the Manufacturer prior to the RFP closing date and time.

11.6 If any defect in the Software is not rectified by the Vendor before the end of the Warranty Period, the Warranty Period shall be extended until, in the opinion of the Purchaser: a) the defect has been corrected; and b) the Software functions in accordance with the Contract for a reasonable period of time.

11.7 Despite any other provision, the Purchaser, at the Purchaser’s option, may return defective

Software to the Vendor within 10 days of delivery of the Software and the Vendor shall immediately provide full exchange, credit or refund. For the purpose of this section, ”defective Software” includes, but is not limited to:

a) broken seals;

b) missing items;

c) Software that is not the most current version at the time of shipping;

11.8 The Vendor shall provide, after warranty commences for all Software components,

telephone support to the Purchaser during Business Days for assistance with the operation of the Software.

11.9 If the Vendor is not the Manufacturer of components of the Software, then the Vendor shall

disclose the Manufacturer’s warranty for such components to the Purchaser and, in the event such warranty exceeds the Vendor’s warranty under this Contract in any respect, shall ensure that the Purchaser will receive the benefit of the Manufacturer’s warranty.



34

12. Title and License 12.1 Title to the Software shall remain with the Vendor or to the party that is authorized to

provide the rights in relation to the Software as stated in this Contract. Upon payment for the Software by the Purchaser, and subject to the terms and conditions of any license agreement between the parties (the terms of which shall reflect standard commercial norms), the Vendor grants a license to the Purchaser to use execute, reproduce, display, and perform Software upgrades and any user documentation provided for the Software.

13 Source Code 13.1 The Vendor must, within ten (10) Business Days of receiving an Order and within ten (10)

Business Days of all updates, enhancements and new releases to the Software released by the Vendor thereafter, maintain a current copy of the source code, proprietary tools, if any, used to maintain and make modifications to the Software, and user documentation of the Software in escrow with an escrow agent, to be mutually agreed upon. Within ten (10) Business Days from the date of any new release of the Software, the Vendor must place an updated copy of the source code, proprietary tools, if any, and user documentation with the designated escrow agent if this Contract provides for maintenance or the right of the Minister to obtain new releases. All costs of escrow shall be at the Vendor’s expense.

13.2 The Contract with the escrow agent must name the Minister as a beneficiary under that

Contract and provide that a copy of the source code, proprietary tools, if any, and user documentation in escrow shall be released to the Minister by the escrow agent not later than five (5) Business Days after the occurrence of any one or more of the following events:

a) the Vendor making an assignment for the benefit of its creditors generally;

b) the Vendor filing a petition or making a proposal under the Bankruptcy and Insolvency Act, Canada, or similar equivalent legislation of an applicable jurisdiction;

c) the Vendor is the subject of a receiving order or a petition filed under the Bankruptcy and Insolvency Act, Canada, or such other applicable legislation and where the Vendor does not contest such receiving order or petition in good faith;

d) the Vendor making an application under the Companies’ Creditors Arrangement Act or similar or equivalent legislation of any applicable jurisdiction;

e) the Vendor is subject to any distress or execution levied on its rights under the Contract;

f) the Vendor is subject to appointment of any receiver, manager, receiver-manager, liquidator or trustee of the property, assets or undertaking of the Vendor pursuant to the terms of a court order or security contract or similar instrument and such appointment is not revoked or withdrawn within thirty (30) days of the appointment, provided that such period of thirty (30) days shall be extended to one hundred and twenty (120) days after such appointment where the Vendor demonstrates to the reasonable satisfaction of the Minister that it is contesting such appointment in good faith; or



35

g) the Vendor discontinues performing maintenance on the Software.

14. Governing Laws 14.1 The Contract shall be interpreted and applied in the courts, and according to the laws in

force, in the Province of Alberta.

15. Third Party Claims 15.1 The Minister and the Vendor agree that if one of them is sued by a third party, the party

sued may:

a) join the other into the action; or

b) commence a separate action for recovery of that portion of the damages awarded against the party and for which that other party is legally responsible.

15.2 Despite clause 7.1, where loss or damage is directly related to the Software provided by or

through the Vendor, the Vendor’s liability shall not extend to loss or damage arising out of:

a) modifications made to the Software by the Minister;

b) the use by the Minister of the Software with programs, hardware or software supplied by other parties, unless the Vendor has represented to the Minister that the Software are designated for use with such other programs, hardware or software;

c) use of the Software by the Minister in a manner contrary to the Vendor’s specifications and/or documentation provided by or through the Vendor and accepted by the Minister;

d) use of the Software by the Minister on any hardware for which the software was not designed; or

e) the Minister not using corrections to the Software made known and available by the Vendor. This exception only applies if the corrections made known and available by the Vendor do not diminish the Software’s performance or functions as required by this Contract.

15.3 Despite clause 7.1, where loss or damage is directly related to the Software provided by or through the Minister under this Contract, the Minister’s liability shall not extend to loss or damage arising out of:

a) modifications made to the Software by the Vendor;

b) the use by the Vendor of the Software with programs, hardware or software supplied by other parties, unless the Minister has represented to the Vendor that the Software are designated for use with such other programs, hardware or software;

c) use of the Software by the Vendor in a manner contrary to the Minister’s specifications and/or documentation provided by or through the Minister and accepted by the Vendor;

d) use of the Software by the Vendor on any hardware for which the software was not designed; or

e) the Vendor not using corrections to the Software made known and available by the Minister. This exception only applies if the corrections made known and available by the Minister do not diminish the Software’s performance or functions as required by this Contract.



36

15.4 The party claimed against or sued by a third party must notify the other in writing of a

claim or suit promptly and provide reasonable cooperation, at the responsible party’s expense. Neither party shall have any obligation under any settlement made without its written consent.

16. Intellectual Property

(a) If a third party claims that any Software delivered to the Minister by the Vendor, the Vendor’s subcontractors or agents under this Contract infringes any copyright, patent, trade secret, industrial design, trade mark or any other proprietary right enforceable in Canada, the Vendor will defend the Minister against that claim at the Vendor’s expense. In this regard, the Vendor will pay all costs, damages and legal fees that a court finally awards or are included in a settlement agreed to by the Vendor, provided that the Minister:

(i) promptly notifies the Vendor in writing of the claim; and

(ii) cooperates with the Vendor, and allows the Vendor to control, with the Minister’s participation, the defense and any related settlement negotiations.

(b) If such a claim is made or appears likely to be made under clause 16(a), the Minister

agrees to permit the Vendor to enable the Minister, at the Vendor’s cost and with the Minister’s agreement, to continue to use the Software or to provide the Minister with a non-infringing replacement or modification which meets the specifications and functionality required for the Software in this Contract. If the Vendor determines that none of these alternatives is reasonably available, the Minister shall return the Software to the Vendor on the Vendor’s written request and the Vendor shall pay the Minister, upon the Minister’s return of the Software, the remaining unamortized amount based on a seven year straight line amortization schedule.

(c) The Vendor has no obligation regarding any claim based upon any of the following:

(i) the Minister’s modification of the Software or use of Software in other than the operating environment specified for the Software;

(ii) the combination, operation or use of the Software with any programs, hardware or software that the Vendor did not provide, unless the Vendor has specifically approved of the other programs, hardware or software for such combination, operation or use;

(iii) compliance with the Minister’s written requirements for the Software and which the Vendor has advised the Minister in writing with reasons that clause 16(a) will not apply with the Minister’s written requirement; or

(iv) infringement by anything provided first by the Minister for use in creating the Software.

(d) If a third party claims that the Software delivered by the Vendor, the Vendor’s

subcontractors or agents infringes any copyright, patent, trade secret, industrial design, trade mark or any other proprietary right enforceable in Canada and the alleged infringement is based upon:



37

(i) compliance with the Minister’s written requirements for such Software and which the Vendor has advised the Minister in writing with reasons that clause 16(a) will not apply with the Minister’s written requirement; or

(ii) anything provided first by the Minister for use in creating such Software

then the Minister will defend the Vendor against the claim at the Minister’s expense. In this regard, the Minister will pay all costs, damages and legal fees that a court finally awards or are included in a settlement agreed to by the Minister, provided that the Vendor promptly notifies the Minister in writing of the claim and cooperates with the Minister in, and allows the Minister to control, with the Vendor’s participation, the defense and any related settlement negotiations.

(e) If a claim described in clause 16(d) is made or appears likely to be made, the Vendor

agrees to permit the Minister, at the Minister’s cost, to continue to use such Software or to modify or replace it. If the Minister determines that none of these options are reasonably available, the Vendor agrees to return such Software to the Minister on the Minister’s written request.

(f) The Minister has no obligation regarding any claim based on any of the following:

(i) the Vendor’s modification of the Software or use of Software in other than the operating environment specified for the Software;

(ii) the combination, operation or use of the Software with any programs, hardware or software that the Minister did not provide, unless the Minister has specifically approved of the other programs, hardware, or software for such combination, operation or use; compliance with the Vendor’s written requirements for the Software; or

(iii) infringement by anything provided first by the Vendor for use in creating the Software, except to the extent such infringement arises from compliance with the Minister’s requirements for the Software and which the Vendor has advised the Minister in writing with reasons that clause 8(a) will not apply with the Minister’s written requirement.

(g) The party claimed against or sued by a third party must notify the other in writing of a

claim or suit promptly and provide reasonable cooperation, at the responsible party’s expense. Neither party shall have any obligation under any settlement made without its written consent.

17. Responsibility and Liability 17.1 The Vendor shall be responsible for loss or damage to the real or tangible personal

property of the Minister where the Vendor is legally responsible, including negligence, or willful harm of the Vendor, its employees, subcontractors or agents.

18. Confidentiality (a) The Vendor and the Vendor’s employees, subcontractors and agents shall, subject to

any Confidentiality Legislation requirement:



38

(i) not use, copy or disclose, except as necessary for the performance of the Services or upon written authorization of the Minister, any Minister Confidential Information;

(ii) adhere to security standards for Minister Confidential Information, including control of access to data and other information, using the same care and discretion the Minister follows for its own Confidential Information, as specified in this Contract. The Minister shall provide the Vendor with notice of any changes to these standards. If changing the security standards for Minister Confidential Information increases the Vendor’s costs the Vendor may submit a Change Request.

(b) Prior to allowing any third party, other than Vendor’s subcontractors or agents, access

to hardware, including loaner or replacement hardware, used by the Minister, the Minister’s employees, subcontractors or agents, the Vendor shall:

(i) determine whether the hardware contains any information or software because of such use; and

(ii) contact and follow the instructions of the Minister if such information or software is present.

(c) Confidential Information must be kept confidential the longer of six (6) years, the

Confidentiality Legislation requirement, if any, to keep Confidential Information confidential, or so long as the party retains Confidential Information of the other party.

(d) The Vendor shall return to the Minister or destroy any Minister Confidential

Information within thirty (30) days of this Contract being completed or terminated. Further, if such information is in electronic format in hardware of the Vendor or of its employees, subcontractors or agents, that information shall be dealt with in accordance with this Contract.

(e) The Vendor may disclose Minister Confidential Information to:

(i) employees of the Vendor and any corporation, company or other entity that it controls or controls it who have a need to know;

(ii) the Vendor’s subcontractors and agents who have a need to know provided that the Vendor has a similar confidentiality agreement with them as required of the parties by this clause 10; and

(iii) anyone else with the Minister’s prior written consent.

(f) The Minister and the Minister’s employees, subcontractors and agents shall, subject

to any Confidentiality Legislation requirement:

(i) not use, copy or disclose, except as necessary for the performance of the Services or upon written authorization of the Vendor, any Vendor Confidential Information; and

(ii) maintain security standards for Vendor Confidential Information, including control of access to data and other information, using the same care and discretion it follows for its own Confidential Information, as of the date of



39

execution of this Contract. The Minister shall provide the Vendor with notice of any material changes to these standards.

(g) Subject to any Confidentiality Legislation requirement, the Minister may disclose

Vendor Confidential Information to:

(i) employees of the Minister who have a need to know;

(ii) the Minister's subcontractors and agents who have a need to know provided that the Minister has a similar confidentiality agreement with them as required of the parties by this clause 18; and

(iii) anyone else with the Vendor’s, the Vendor’s subcontractor’s or agent’s prior written consent for their own Confidential Information.

(h) A party has no obligation with respect to Confidential Information of the other party:

(i) that the first mentioned party already possesses without obligation of confidentiality; develops independently; or rightfully receives without obligation of confidentiality from another; or

(ii) that is or becomes publicly available without breach of this clause 18.

(i) A party has no obligation under this clause 18 with respect to any ideas, concepts,

know-how or techniques contained in the Confidential Information of the other party that are related to the first mentioned party's business activities (“Knowledge”). This, does not however, give such party the right to disclose, unless described elsewhere in this Contract:

(i) the source of the Knowledge;

(ii) any financial, statistical, or personal data; or

(iii) the other party's business plans.

(j) Each party may disclose Confidential Information of the other party to their legal

counsel who has an obligation to keep that information confidential.

(k) The disclosure of a party’s Confidential Information does not grant to the other party any license under any patents or copyrights.

(l) Except for timely disclosure required to be made by any lawful government authority

or regulatory body, by any stock exchange or operation of law, including but not limited to any Confidentiality Legislation, and except for public disclosure made by any Minister of Her Majesty the Queen in right of Alberta, mindfully taking into consideration the sensitivity of specific confidentiality in this Contract, no press release or other public announcement relating to this Contract shall be issued without the prior written consent of each party to the specific content and form of such press release or announcement. Each party shall use reasonable efforts to disclose such release or announcement proposed by it to the other party as soon as reasonably possible and the other party will use reasonable efforts to approve or otherwise comment on such release or announcement without delay.

19. Safety and Security



40

19.1 The Vendor, its employees, subcontractors, and agents when using any Alberta

Government buildings, premises, hardware and software shall comply with all safety and security policies, regulations and directives relating to those buildings, premises, hardware and software.

20. Insurance 20.1 The Vendor shall, at its own expense, in accordance with the Insurance Act of Alberta and

without limiting its liabilities under this Contract:

(i) insure its operations under a contract of General Liability Insurance in an amount not less than $2,000,000.00 inclusive per occurrence, insuring against bodily injury, personal injury, and property damage including loss of use thereof.

20.2 The Vendor shall provide the Minister with acceptable evidence of insurance, in the form of a detailed certificate of insurance, prior to commencing the Services.

21. Outsourcing

21.1 Despite any other term or condition in the Contract, the Minister may transfer

to a third party who is under contract to the Minister, a copy of and the right to use the Software acquired as part of the Contract including, if applicable, the source code and all related documentation, for the third party’s use in performing duties and tasks on behalf of the Minister. If the Software is transferred from the Minister to a third party in accordance with the terms and conditions of the Contract:

a) the Vendor shall not require the third party to pay any additional monies to the

Vendor for the provision of and the right to use the Software during the period the Minister has the right to use the Software, provided the Minister has paid all applicable fees as of the date of the transfer;

b) the Vendor shall provide to the third party all Software to be provided to the

Minister under the Contract, including service, maintenance, support and upgrades on the same terms and conditions as stated in the Contract;

c) the Minister shall not be responsible to the Vendor for any fees from the date the

Software is transferred to the third party; and

d) the Minister shall contract with the third party to:

(i) restrict use of the Software in accordance with the terms and conditions of the Contract,

(ii) require that the third party, its employees, subcontractors and agents comply with the confidentiality terms and conditions of the Contract, and

(iii) make payments to the Vendor for all fees, in accordance with the terms and conditions of the Contract, including maintenance and upgrades, if applicable, that relate to the Software from the date the Software is transferred to the third party.



41

In the event that the contractual relationship between the Minister and the third party expires or is terminated, the third party’s rights to the Software are terminated and all rights provided in the Contract in relation to the Software are transferred back to the Minister.

22. Statutory Compliance 22.1 The Vendor shall:

(a) Comply with the provisions of all laws, now in force or in force after the signing of this Contract, that expressly or by implication apply to the Vendor in performing the Services.

(b) Pay, when due, all taxes, rates, duties, assessments and license fees that may be levied, rated, charged or assessed upon the Vendor in performing the Services

22.2 In the case of conflicts, discrepancies, errors or omissions among the RFP, Proposal, any

license or maintenance agreement, this document and any amendments; the documents and amendments to them shall take precedence and govern in the following order:

(a) this document

(b) Request for Proposals

(c) Proposal

23. Survival of Terms 23.1 Despite any other term or condition of the Contract, those clauses which by their nature

continue after the conclusion or termination of the Contract shall continue after such conclusion or termination including:

(a) Clause 12 Title And License;

(b) Clause 13 Source Code;

(c) Clause 15 Third Party Claims;

(d) Clause 16 Intellectual Property;

(e) Clause 17 Responsibility and Liability;

(f) Clause 18 Confidentiality; and

(g) Clause 21 Outsourcing.

24. Assignment 24.1

(a) The Vendor shall not assign, subcontract (other than as identified in the Proposal) or otherwise dispose of any of its rights, obligations, or interests in this Contract, without first getting the written approval of the Minister, which approval shall not be unreasonably withheld.

(b) The Minister may assign any part or this entire Contract upon 60 days notice to the Vendor.



42

(c) Subject to clause 24(h), the Vendor consents and has obtained, and will continue to

obtain during this Contract, the consent, in the form specified in clause 24(g), of all legal entities identified in this Contract (Note: this Contract includes the Vendor's Proposal). The consent is to allow the use of their information in this Contract by third parties that are considering taking an assignment from the Minister of any part or this entire Contract and for the purposes of this Contract if a third party takes an assignment from the Minister of any part or this entire Contract.

(d) Any such third party that is provided the information in this Contract may only use

such information for the purposes of:

(i) evaluating whether to take an assignment from the Minister of any part or this entire Contract; and

(ii) this Contract if the third party takes an assignment from the Minister of any part or this entire Contract.

(e) The Vendor shall, on request of the Minister, provide the Minister with a copy of

the written consent, as specified above, of all legal entities identified in this Contract.

(f) The Minister shall require such third parties to sign a confidentiality agreement

prior to obtaining information in this Contract. The confidentiality agreement shall require the third party to keep such information confidential other than for the purposes of:

(i) evaluating whether to take an assignment from the Minister of any part or this entire Contract; and

(ii) this Contract if the third party takes an assignment from the Minister of any part or this entire Contract.

(g) The consent required under clause 24(c) shall be in the following form:

(i) (name legal entity) consents to the use of our information contained in the agreement between (name of Vendor) and Her Majesty the Queen in right of Alberta, as represented by the Minister of (department name) ("Minister") (“Agreement”)by third parties which are considering taking an assignment from the Minister of any part or all of that Agreement.

(ii) It is understood that such third parties may only use our information for the

purposes of:

(aa) evaluating whether to take an assignment from the Minister of any part or all of that Agreement; and

(bb) the Agreement if the third party take an assignment from the Minister of any part or all of that Agreement.

(iii) (name of Vendor) shall provide this consent to the Minister upon request of the

Minister.



43

(name of legal entity)

Signature

Title

Date (h) The requirement of obtaining consent under clause 24(c) does not apply in relation

to an individual whose resume/resource skill summary sheet is contained in this Contract. However the name, business phone number and business addresses (email and street) of such individuals may be provided as contemplated by clause 24(c).

(i) Subject to the requirements of any Confidentiality Legislation, the Minister shall not

provide the resumes/resource skill summary sheets contained in this Contract to a third party which is considering taking, or who takes, an assignment of any part or this entire Contract

25. Time is of the Essence The parties have made this Contract. HER MAJESTY THE QUEEN in right of Alberta, as represented by (Minister) (Name of Vendor) Signature Signature Title Title Date Date

Approved by: Contracted Services Section Supply Management Branch Alberta Corporate Service Centre Government Services _ Signature _ Title _ Date



44

NOTE: As part of the Vendor’s response to this section of the RFP, any proposed license, maintenance or lease agreement that the Vendor will require, should be included in the Proposal or must be provided to SMB within 3 Business Days of request. In the case of conflicts, discrepancies, errors or omissions among the proposed license, maintenance or support agreements and the Contract Provisions listed under APPENDIX A of the RFP and listed as “Met” by the Vendor in the Proposal, the Contract Provisions listed under APPENDIX A of the RFP and listed as “Met” by the Vendor in the Proposal shall take precedence and govern.

Appendix B – GoA EIM Overview


45

APPENDIX B – GoA EIM Overview

1. Introduction to the IM Context

1.1 Government Information

The business goals of the Government of Alberta (GoA) rely heavily on collaboration among Ministries and the ability to make timely, informed decisions, develop useful plans and resolve urgent problems. The government not only needs quality information to deliver services and meet commitments, but also produces vast amounts of information both for internal use and for the citizens of Alberta.

Government information exists in many forms in many places: for example, in electronic mail; in databases and data warehouses; as electronic, paper and microfilm records; as intellectual property; as publications in print and on web sites; in transaction-based and document-based systems. Regardless of form or location, this information has value, and thus forms a critical strategic asset for the GoA — as important an asset as people, capital and technology. Information needs to be managed to ensure it is accurate, available, and useful to the people who need it. If ignored and left unmanaged, information assets become unusable, just like any other asset that gets neglected. However, “managing information”, is easier said than done.

It is ironic that the technology available to help information management (or “IM”) has advanced significantly in the last decade, but it is much more difficult to manage information today than it was in the past. Several realities now characterize our electronic work environment:

• a massively increasing volume of information;

• a growing mix and complexity of information forms (eg. instant messages);

• a demand for more and better information from clients and stakeholders, both internal and external;

• stricter legal and regulatory requirements around how organizations manage and use information; and

• decentralized management of information as a result of powerful technology tools at the desktop.

As with most organizations when it comes to managing information, the government’s business practices and systems have not kept up with these realities. Until recently, the focus has been on technology and transaction processes rather than on information assets themselves, i.e. an emphasis on personal and system productivity rather than overall information quality and value, and organizational performance. All of this has resulted in a number of significant information management issues in the GoA. Government employees have identified the most serious and urgent problems:



46

• Cannot Access Information. Finding and gaining access to the right information at the right time is becoming increasingly difficult in almost all Ministries. This impacts the ability to make timely decisions and is also a significant drain on productivity as information gets duplicated and re-created.

• Information is in silos and is very difficult to share across Ministries or with external agencies, stakeholders, and customers. This is a significant issue given the Government’s direction towards cross-ministry collaboration and private-sector partnership models for service delivery to Albertans.

• The government is in danger of not meeting legal and regulatory requirements around access and protection of information because there are very few processes, tools, or other mechanisms in place to efficiently manage information according to those rules.

• Information duplication exists throughout the government because of issues such as improper version management of documents and the inability to find information, causing it to be recreated.

• Official business records are not properly managed or protected. Confidence in the government’s ability to properly manage official business records according to legislation and for demonstrating accountability was questioned often throughout the workshops.

These increasingly difficult issues impact the GoA’s ability to make decisions, manage its business, and deliver effective and efficient services to Albertans. Virtually all workshop participants agreed that the situation is worsening and that action needs to be taken to help Ministries better manage the Government’s information assets.

1.2 The Information Management Framework

Fortunately, the need for a coherent electronic information management context to start addressing these problems has been recognized. In April 2003, the Deputy Ministers Committee adopted an asset management framework – the Information Management Framework (IMF) – to work towards a planned, disciplined, consistent approach to better manage information assets across the government. The IMF is based on six fundamental principles, two of which have contributed significantly to the direction and scope of the “Functional Requirements” in this document. The first principle deals with the accessibility of government information: Accessibility: Information is easily accessible to those who need to use it and are authorized to access it.

Three directives aimed at helping Ministries implement good information management practices support each principle. The following directive supports the principle of Accessibility:

1.1 Ministries must ensure that information systems are designed and implemented to easily locate and retrieve information, and to facilitate sharing the information within Ministries,



47

across government, with other levels of government and with Albertans, subject to legal constraints.

In addition to ensuring that information is accessible for government and stakeholder use, the IMF also emphasizes that information should be managed in a consistent and integrated manner. Principle 4, states that:

Integrated Approach: Information assets are managed throughout their entire life cycle regardless of the medium in which they are held. Two directives under this principle support the concept that IM must take the entire lifecycle of information assets into account:

4.1 Ministries must implement plans and practices related to the life-cycle of information — creation, capture or collection; organization; storage; access and use; and disposition, i.e. destruction or permanent retention.

4.2 Ministries must ensure that information, regardless of type or the medium in which it is stored, is managed under the same principles and is captured in appropriate systems so that information can be organized and described to facilitate access and ongoing management of the asset.

Using the IMF as the basis for implementing good information management practices will, at a high level, make it easier:

• for people to do their work;

• for the public, contractors and governance groups to gain access, when authorized, to government information; and

• for Ministries to meet their accountability requirements.

More specifically, doing a good job of managing information from an “asset” perspective will help Ministries to:

• improve accessibility to their information by staff, clients and business partners, not only within individual programs and Ministries, but across Ministries;

• improve accountability and transparency through better management of government records in all media;

• enhance the design and delivery of policy and program benefits, both for integrated service delivery and at the individual program level;

• reduce risk to government, partners and stakeholders;

• enhance the security of information;

• enable consistent adherence to legislative and policy requirements, such as protecting privacy, protecting the evidentiary integrity of official records, and preserving the heritage of the province2;

2 Freedom of Information and Protection of Privacy Act (FOIP Act), Records Management Regulation (RMR) and Historical Resources Act respectively.



48

• allow the government to achieve the efficiencies enabled under both the Electronic Transactions Act and the Evidence Act.

• apply systematic, appropriate rights of access to enable the fullest use of content where appropriate, and

• reduce the escalating costs associated with access to, management, and storage of information.

1.3 The International Records Management Standard

The Government of Alberta has endorsed the ISO 15489 Standard as a code of best practice. It was recognized that this standard would support the objectives of the IMF and that ministries should work towards its achievement. To do so, however, requires the deployment of EIM technology.

1.4 The Electronic Information Management Project

To help Ministries build the capabilities necessary to ensure that their information is accessible and managed in an integrated fashion, a project under the umbrella of the Information Management Framework called the Electronic Information Management (EIM) Project was established to guide the selection of technology for the GoA and to take a corporate approach to its deployment. The term EIM was selected for use in the GoA however, the industry has been using the term enterprise content management (ECM) or Smart Enterprise Suite (SES) and, has recently evolved from the more specific concepts of Electronic Records Management, Electronic Document Management (ER/EDM). The technology is expected to manage information assets or content, also known as “unstructured data” or “document-based” information, and is most easily explained as all the information that is not stored in rows and columns in corporate and ministry databases. Industry estimates indicate that approximately 85% of all business information now exists as “content”, but the overwhelming majority of technology resources and discipline to date have been directed towards management of “structured” data in operational systems and databases. Items of content come in various formats, are produced by different authors, are single and multiple items, arrive through different communication channels at variable rates and volumes. Examples of “content items” include:

• office documents, such as reports, letters, presentations, spreadsheets, e-mail messages and attachments; notes and discussions threads;

• graphical objects and images, often combined with or embedded in documents;

• multimedia items, e.g. sound and video, and

• web content, both publications and other forms of content.



49

To help the GoA better manage its information assets the EIM Project is developing a number of tools with a government-wide focus, using a process that involves knowledgeable staff from every ministry. These deliverables include:

1. Standing Offer Agreements for integrated suites of EIM Software products based on a common set of functional requirements for EIM technology that are required for the capture and life cycle management of GoA information.

2. Guidance to Ministries on the strengths of each selected suite of EIM Software products.

3. Metadata Standards.

4. Standard business rules, practices and guidelines that need to be established for staff to better manage information in work groups, programs and across the government.

5. Implementation planning guidance for how Ministries can proceed with EIM projects.

6. An accountability model for the management of information assets at a ministry and individual employee level.

7. A digital preservation strategy.

This document addresses the first deliverable. For the purposes of this project, “EIM Technology” includes both the common and unique functionality of these component technologies:

• Document Management (D);

• Electronic Team Collaboration (C);

• Web Content Management (W);

• Records Management (R); and

NOTE: Workflow must be fully integrated with the above four components.

• Seamless integration with industry leading Imaging, OCR and ICR systems.



50

2. Integrated EIM Technology

2.1 The Vision

From business plans, project reports, and meeting agendas to committee presentations, engineering drawings, and communication materials, information assets or, content is critical to the success of virtually every business process. The GoA increasingly relies on accurate and up-to-date information that is easily created, accessed, and shared among staff and stakeholders. Every organization would like to have a single, totally-integrated, fully-functional, completely-flexible technology solution to manage both its structured and unstructured information assets, ensuring their integrity through time, regardless of their format, location, security, purpose, size, etc.

The IMF clearly promotes the management of information using a suite of the core components of document management, team collaboration, web content management, and records management, encompassing the entire life cycle of the content, and all core components fully integrated with workflow capability. This EIM Project emphasizes that solutions should be as integrated as possible, no matter which particular component or combination a ministry uses to start implementing their EIM environment for content management.

2.2 Important Concepts

To fully understand the vision for EIM for the GoA, it is important to understand several concepts and their interrelationships.

Understanding Life Cycle

“Life cycle” is a well-established business concept, for example in financial management, product development and facilities management. It is also a foundation of the records management and archives professions. Records in all media have always moved through phases of Creation – Capture – Organization – Use – Retention – Destruction or Preservation, with associated requirements for managing both the records and their related metadata. The concept of “life cycle” encompasses all types of information content in an EIM environment and their common and unique functional and management requirements.

Understanding “Record”

How do pieces of content – content items – and records relate? Records are the containers of content, i.e. of “information.” By adding “structure” and “context” to the content, records become the mechanism through which people understand and use information, from which they then make decisions, develop plans, process transactions and solve problems.



51

Within the GoA environment, several related business perspectives impact the understanding of what a “record” is and what it does:

• Legal perspective – The official, legal definition of “record” is contained in the FOIP Act, 1(q), and the RM Regulation, 10(2)(d) as “a record of information in any form …recorded or stored in any manner...” This definition means that the provisions of this legislation apply to content in any medium at all stages of its life cycle, from first draft through destruction or preservation.

• Business perspective – The international ISO standard 15489 on records management describes records as “information created, received and maintained as evidence and information by an organization, or person, in pursuance of legal obligations or in the transaction of business.

• Technology perspective – For the purposes of defining, applying and managing records in electronic repositories, a record is “a logical entity that is constituted of both content and metadata. It may be a single item, or a set of closely-bound items which are meaningfully treated as one. Record contents cannot be changed, but some of their metadata can be changed….”

• Records management perspective - Most government records begin life as a “transitory” record, that is, it has short term value and can be disposed of by the individual who created it. However, at some stage staff must decide whether the record has value as evidence of the conduct of government business, and needs to be captured as an “official record”. This can be an automatic process, such as when an e-mail message is sent. Or it can be a deliberate decision, for example when a writer decides to retain and store the various versions of a draft act, report or letter. (See Official and Transitory Records Guide.)

Understanding EIM Technology Environments

All content items, or pieces of content, or records, move through a “dynamic” phase of preparation to some degree. In this environment, content can be revised and changed many times in many ways. At any point in this process, staff can decide (declare) that the content item is an “official record” and capture it into a “static” environment, in which the content, its structure and its context are fixed. New versions can be created and move back into the dynamic environment, but the original item remains unaltered, thus providing evidence of the conduct of business that will have integrity through time.

2.3 What does Integration Mean?

Complete integration among EIM component technologies is only achieved when systems share common functionality and common metadata. In this context, “integration” means moving toward a shared repository approach and breaking down some of the traditional differences in functionality between the products.

The EIM Project emphasizes the need for managing all electronic content assets of the government through their life cycles, integrating the management of information in electronic formats and in hard copy media such as paper, photographs, and microfilm.



52

When electronic content needs to move as an official record from its “dynamic environment”, to the “static” or records management environment staff must be able to move it easily within the context of the work he or she is doing, regardless of which technology tool is being used to create or work with the content. It is useful to picture these requirements in a “Management Model”:

Dynamic Content Environment Static Content Environment

Document Management →

Team Collaboration →

Imaging, Scanning, OCR →

Web Content Management →

Declare O

fficial R

ecords

Records Management

Preservation Management∗

Manage Content by Managing Common and Unique Functionality:

Capture Content

Manage Collabo-

ration

Manage Content

Organize Content

Publish Content

Manage Official Records

Preserve Records∗

Manage Repositories by Managing Common Functionality:

Manage Metadata

Manage Content Access

Manage Workflow

Manage Search and Browse

Manage Reporting

Administer EIM Repositories

While the Functional Requirements relating to these management phases have both common and unique aspects, the vision of the GoA is an Electronic Information Management environment that encompasses and cuts seamlessly across all technology components. The marketplace realization of this EIM vision is a work in progress, with ongoing consolidation and integration of functionality across the EIM spectrum. Integrated suites of EIM technology components for the Government of Alberta must include a significant commitment to a long-term, fully integrated EIM strategy. There could be additional capabilities or components in the EIM suites, for example, digital rights management, that the Government of Alberta is not requiring or evaluating at this stage; however, these may be desirable features of a suite in the near future and might become mandatory or desirable requirements for ministries as they proceed to acquire and implement EIM. Vendors should take the opportunity to include such features as Value-Added Software for consideration.

∗ To be developed in the future. Not included in these requirements.

Appendix C – Related Project Documents


53

APPENDIX C – Related Project Documents

C1. Government of Alberta Enterprise Architecture (GAEA) Documents A cornerstone of Alberta’s innovative approach to creating the ICT Model (Common Standards, Shared Common Infrastructure, Information Sharing, Common e-Business Processes, Existing Application Support (legacy systems), and New Application Development) is the use of “Enterprise Architecture”, a powerful managerial tool for helping organizations bridge between strategy and the successful implementation of that strategy. It employs a proven, methodical approach that has evolved, in ICT, over the past 10 years. It relies on the same type of discipline and common sense that has long been used to ensure correct high-level design and implementation in construction (e.g. buildings), manufacturing (e.g. airplanes), and individual ICT solutions. “And it applies it on a corporate, or enterprise-wide, basis". The GAEA program, administered by the Office of the Corporate Chief Information Officer, is executing its defined processes to work with corporate and departmental IT projects to ensure compliance through the GAEA-defined governance (a.k.a. “Architecture Management”) processes. The benefits such as the cultivation of common approaches and reuse, elimination of unnecessary duplication and diversity, progressive elimination of vertical “silos” and the making of faster, better IT decisions (we call it “decision velocity”) are already beginning to materialize as a result of the use of the Enterprise Architecture, to-date. The following GAEA materials or documents can be accessed electronically via the Government of Alberta’s shared repository (SHARP) at

http://www.sharp.gov.ab.ca/. The user ID is: RFPRespondent.V21 The password is: Future654

(note: the password is case sensitive) • 1. GAEA Glossary of Terms (GAEA V2.1) • 2. Scope and Strategic Alignment of GAEA Architecture Domains (GAEA V2.1) • G&H. GAEA Business Drivers and Architecture Requirements (GAEA V2.1) • I1. GAEA Architecture Principles (GAEA V2.1) • I2. GAEA One Page Summary of the GAEA Architecture Requirements and Principles

(GAEA V2.1) • K1. GAEA EA Toolset (GAEA V2.1) • M1. GAEA Business Architecture (GAEA V2.1) • N1. GAEA Data Architecture (GAEA V2.1) • O1. GAEA Application Architecture (GAEA V2.1) • P1. GAEA Technology Architecture - Main (GAEA V2.1) • P2. GAEA Technology Architecture - Components (GAEA V2.1) • P3. GAEA Technology Architecture - Nodes (GAEA V2.1) • Q1. GAEA Security Architecture (GAEA V2.1) • R1. GAEA Privacy Architecture (GAEA V2.1) • R2. GAEA Privacy Architecture - Overview Report (GAEA V2.1) • R3. GAEA Privacy Architecture - Privacy Glossary (GAEA V2.1) • S1. GAEA Architecture Management Processes - Alignment and Compliance (GAEA V2.1) • S2. GAEA Architecture Management Processes - Vitality (GAEA V2.1)

Appendix C – Related Project Documents


54

C2. Other Project Related Documents

The following IM materials or documents can be accessed electronically via the Government of Alberta’s shared repository (SHARP) at

http://www.sharp.gov.ab.ca/. The user ID is: RFPRespondent.IMF The password is: ManageInfo789

(note: the password is case sensitive)

• Business Case for a Corporate Approach to Electronic Records and Electronic Document Management – Project Description

• Information Management Framework Executive Summary

Appendix D – Project Requirements


55

APPENDIX D – Project Requirements

Instructions: This Appendix includes Mandatory (M) and Desirable (D) functional and technical requirements of the project.

• Each requirement is identified by an item number. Use this number to identify the response to the requirement in your Proposal

• For each mandatory requirement, the Vendor must indicate with either Yes or No as to

whether each individual criterion is met in the proposed Software products. The Vendor’s Proposal must provide information in sufficient scope and depth to demonstrate the ability of the proposed Software products to meet the mandatory requirements stated in this RFP and permit a complete analysis and assessment by the Evaluation Team. Proposals must comply with every mandatory requirement.

• For each desirable requirement, the Vendor should respond to the requirements. To

receive scoring on the desirable requirements, the documentation provided in the Vendor’s Proposal must be complete and address the criteria in sufficient depth to allow a complete analysis and assessment by the Evaluation Team.

The Vendor should also indicate if the primary Software products, associated software or value-added software would meet the mandatory and/or desirable requirement.

• Primary Software are products which comprise the mandatory core components of the EIM suite of Software products that must be supported by a single manufacturer.

• Associated Software is third-party software that is required to support the mandatory or desirable requirements in providing the required functionality such as reporting, imaging, searching or hardcopy records management.

• Value-added Software is software which is not included in the functional requirements but, in the opinion of the Vendor, may be of interest to the GoA in managing its information assets and supports the mandatory core components of the EIM suite (for example, digital rights management).

Weightings will be assigned to the requirements according to the evaluation criteria outlined in this RFP.



56

D1. Project Software Summary Form

Primary Software

Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer

Associated Software Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer

Value-Added Software Name of Product Version and Release date Name of Manufacturer Name of Product Version and Release date Name of Manufacturer



57

D2. Mandatory Requirements The following requirements must be provided by the Vendor in order for their proposal to remain compliant. Vendor Compliance must be Yes.

REQUIREMENT Value Vendor Response GoA Evaluation

M1. Support: A single Manufacturer must support all primary Software comprised of all core components of the integrated EIM suite of software including document management, collaboration, web content management and records management. NOTE: Workflow must be fully integrated with the above four components. (See RFP “Project Scope”, section 4.1.4)

M

M2 Authorization: The Vendor must be authorized by the Manufacturer to sell and service all components of the proposed Software products as of the closing date of this RFP.

M

M3. RFP Administration Terms and Conditions/ Contract:: The Vendor accepts the RFP Administration Terms and Conditions specified in section 3.0 and Contract Provision clause 13 Source Code in Appendix A. The Vendor, if successful, shall enter into a Contract with Her Majesty.

M

M4. Licenses: The proposed licenses must be available for three (3) years with two additional two-year options.

M

M5. Availability of the Most Current Version/Release of Product: The Vendor must make available and provide the GoA with the most current production version/edition release of the proposed Software products for the term of the

M



58


Contract.

M6. Evaluation Copy of Proposed Software Products: The Vendor must provide with its Proposal, at no additional cost or charge to the Her Majesty, production copy of all proposed Software products and an electronic copy of the technical documentation to allow testing and evaluation of the proposed Software products for 60-days subject to extension if required by Her Majesty. The Vendor by submitting a Proposal grants Her Majesty the rights to use such software and documentation for testing and evaluation purposes only. Her Majesty must destroy such software and documentation after the testing and evaluation period unless Her Majesty enters into a Contract with the Vendor. If the Vendor enters into a Contract with Her Majesty, the Vendor must, subject to section 3.2.1.2(b) of this RFP, grant Her Majesty the right to provide individual Ministries and Approved Organizations with a copy of the Software and an electronic copy of the technical documentation to test and evaluate such Software during the Contract. The individual Ministries and Approved Organizations may test and evaluate such Software for a period of 60 days each.

M

M7. Account Representative: The Vendor must provide the name of an account contact for the Contract, including phone/fax number, email address, and company URL.

M

M8. Software Maintenance and Technical Support: M



59


• Maintenance for the proposed Software products must be made available and include, at minimum, all minor upgrades/updates, major upgrades/updates, fixes and patches.

• The Vendor must provide support and include, at a minimum, weekly (i.e. Monday to Friday) availability from 8:00am until 4:30pm Alberta Time, a two-hour response time, phone and email support.

• The Vendor must provide further details on the support program proposed (e.g., phone hotline support, internet support, expected response times).

• Current methods of Product Maintenance and Technical Support must be provided as well.

• Security and maintenance updates to the EIM Software products must be issued on a regular basis.

• The EIM Software products must be updated to operate using the most recent security patches provided by the manufacturers of the prerequisite software (e.g. operating system, java runtime environment, database server etc.) within 30 days of patch release in order to keep the GoA’s implementation secure.

• Details must be provided of the Vendor’s response time to security threats.

M9. Technical Documentation: The Vendor must provide technical reference documentation/ manuals and media, including any updates. One set of materials must be in electronic format for unlimited use in the GoA environment.

M



60


M10. Proven Products: The proposed Software products must have been installed and in production use and/or in general availability release for a minimum of thirty (30) days prior to the closing date of this RFP. Vendor must provide release date for the Products.

M

M11. Hardware/Software Requirements: The Vendor must provide a detailed summary of the hardware and software requirements for the proposed Software products in APPENDIX F. The Proposal should include configurations for desktop computers, production and development servers at the 500, 1,000, 2,000 and 5,000 concurrent user levels.

M

M12. Warranty: For a period of 90 days following the date of Acceptance by a Ministry of one or more of the proposed Software products, the Products must operate according to the relevant Acceptance criteria, and must be free from problems. The Vendor must provide warranty documentation as part of their Proposal.

M

M13. Solution Configuration: The proposed Software products must include tools that will enable the GoA to independently configure the products. The Vendor must clearly state the extent to which the GoA will be able to configure the Software products and the tools available that support this.

M

M14. Imaging Requirements: The proposed Software products must accept content generated from industry-leading scanning, OCR and ICR Vendors. The Vendor must clearly state how this

M



61


will be accomplished.

M15. Database Integration: The proposed suite of EIM Software products must be able to operate on a minimum of one of the GoA’s chosen database products (MS SQL Server 2000 or above, Oracle 9 or higher, and/or DB2).

M

M16. Application Integration: Open application program interfaces (APIs) in all EIM components must be available to accommodate integration with other corporate applications. Mandatory integration is required with: • RedDot’s Web Content Management product

which is being deployed by several ministries. • PeopleSoft’s financial and human resources as

implemented by the GoA’s IMAGIS application.

M

M17. Industry Standards:: The proposed Software products must demonstrate either current certification or an application to be certified plus a continuing commitment to certification by the U.S. Department of Defence that its product meets the DOD standard 5015.2, which is recognized as a defacto industry standard.

M

Appendix D - Project Requirements


62

D3. Business and Technical Requirements The following six pages are a high-level summary of the business and technical capabilities required in the proposed integrated EIM solution suites, organized according to the sections of functionality in the Management Model in APPENDIX B. The number that follows each summary requirement below (e.g. /3) is the number of detailed requirements related to that item. The Detailed Requirements for all fourteen sections follow. All Detailed Requirements are Desirable. Vendor responses must be one of the following:

• No – No further description is required, however Vendors may wish to include additional information in the response. • Blank – A blank response is the same as No. • Yes – The response must describe:

o How the product(s) meets or exceeds the requirement. Mere affirmation of the requirement is not sufficient as a response. To “meet” a requirement means that it is fully functional in the software product being proposed. (See Mandatory Requirement M10 – Proven Products).

o Any limitations to the functionality requested in the requirement, e.g. If the requirement is “Establish and maintain an extensive number of….”, the response should be like “Can accommodate up to 25,000 instances of….”

o Any Associated Software needed to implement the requirement. Ensure that the Vendor Response also refers to the correct Associated Software listed on the “Project Requirements Software Summary Form” at the beginning of APPENDIX D, and ensure that any additional costs are included on the “Pricing Form” in APPENDIX F.

Summary of Business and Technical Requirements The ABILITY to:

1.0 CAPTURE CONTENT:

1.1 Define Content - Establish formats for electronic content in repositories. /3

1.2 Define and Maintain Templates - Design and revise forms and patterns that assist the creation and formatting of content. /13

1.3 Capture Content - Compose electronic content items and metadata within an EIM repository or import them in from another source./9

1.4 Receive Imaged Content - Capture content items from scanning, OCR and ICR technology, ensuring that these processes result in authentic, evidential-quality records. /2

1.5 Capture E-mail - Import or save e-mail messages and attachments. /4



63

The ABILITY to:

1.6 Register Content - On its entry into a repository, give a content item an unambiguous identifier, i.e. that is not duplicated. /10

1.7 Capture Official Records – Take official records into an environment that applies Records Management business rules. /2

2.0 MANAGE COLLABORATION: 2.1 Manage Workspaces and Tasks - Have individuals and work groups in different locations use interactive tools to aid in the creation,

discussion and flow of content. /25 2.2 Support Synchronous Collaboration - Have two or more participants in an interaction that relies on the use of common information

and requires interaction at the same time. /1

3.0 MANAGE CONTENT: 3.1 Transform Content – Duplicate or edit content, change its appearance or the arrangement of its components, or render it into a

different electronic form. /12 3.2 Version Content – Manage all iterations of content that has been altered sufficiently to capture it as a different version. /2 3.3 Manage Watermarks - Mark content items with electronic images containing provenance or ownership information. /4

3.4 Redact Content - Remove or permanently mask some material from a record when the full item cannot be released or published. /6

3.5 Delete Content - Remove content from a repository, update all directory and register information, update related metadata to record the action, and ensure before deletion that Final Disposition conditions are met. /12

3.6 Export and Transfer Content - Copy or move content from one EIM component or repository to another, maintaining authenticity, integrity, reliability and usability. /11

4.0 ORGANIZE CONTENT: 4.1 Manage Folders and Volumes – Create and maintain folders, with volumes as required, and link them to classes in content

structure(s). /13 4.2 Categorize Content – Assign content items to folders or volumes, and associate them with related content items and folders. /7 4.3 Name Content – Implement business-defined naming mechanism(s) and practices for titling classes, folders, volumes and content

items. /3 4.4 Assign Indexing Values – Select values from controlled terminologies to establish access points for retrieval of content. /1

5.0 PUBLISH CONTENT:

5.1 Change Content Format - Reformat or redesign original content for use by a different audience. /4



64

The ABILITY to:

5.2 Aggregate Content – Combine two or more content items or components to form another content item. /4

5.3 Publish Content - Extract folders, content items and metadata from EIM content repositories and send to distribution centres such as web sites and print centres. /11

5.4 Disseminate Content - Deliver content to specific groups and users, including discovering and matching content automatically to various criteria. /4

6.0 MANAGE OFFICIAL RECORDS: 6.1 Capture Records Schedule Information - Accommodate corporate business rules that manage the retention and disposition of

official records. /6

6.2 Link Schedules with Content Structure(s) - Create and maintain links between records schedule items and classes in records content structures to enable life cycle management of folders, volumes and records. /7

6.3 Manage Vital Records - Identify and restore those records that are necessary to continue government services and operations during a disaster and resume operations afterwards. /3

6.4 Review Records - Examine related folders, volumes and records to decide whether scheduled retention and disposition actions can take place. /6

6.5 Export and Transfer Records – Copy or move official records and their metadata from one recordkeeping system or repository to another, maintaining authenticity, integrity, reliability and usability. /3

6.6 Implement Final Disposition – After records reviews, destroy, preserve official records or alienate according to the criteria documented in records schedules. /8

6.7 Manage Hard Copy Records - Manage access and life cycle processes for repositories of hard-copy records stored on media such as paper, microfilm, photographs, videos, etc. at the box/container, folder, volume and record levels. /10

6.8 Manage Hybrid Records - Manage integrated access and life cycle processes for “hybrid” folders and volumes that consist of records in both electronic and hard copy media. /8

7.0 MANAGE METADATA: 7.1 Define Metadata Elements - Specify set(s) of metadata elements and their attributes. /3 7.2 Define Metadata Schemas - Define allowable structures and values for metadata elements. /4 7.3 Manage Metadata Repositories - Create and maintain storage mechanisms for retaining metadata, built around metadata models

and schemas. /5



65

The ABILITY to:

7.4 Manage Content Structures - Create and revise multi-level, hierarchical structures composed of groups (classes) of metadata at various levels of aggregation, and link to folders, to maintain the relative context of content, and facilitate information retrieval and life cycle management. /12

7.5 Manage Indexing Values - Develop and maintain controlled terminologies to establish access points for retrieval of information from classes, folders and content items. /4

7.6 Capture Metadata - Enter metadata about content into profiles in metadata repositories using both automated and manual processes. /10

7.7 Import Metadata – Transform metadata to fit consistent schemas and load it into metadata repositories using both automated and manual processes. /5

7.8 Export and Transfer Metadata – Copy or move metadata from one EIM component or repository to another, maintaining authenticity, integrity, reliability and usability. /2

8.0 MANAGE CONTENT ACCESS: 8.1 Implement Security for Content - Implement a system of security categories for content according to government-wide standards.

/10 8.2 Establish Access Profiles - Define types of access rights to content, whether in electronic repositories or in physical locations. /11 8.3 Define User Groups - Define the roles that determine the extent of users’ access rights to content. /3 8.4 Create Individual Profiles - Associate individuals with user groups to authorize their access rights to content and features in EIM

components. /3 8.5 Check-out/ Check-in - Allow only one individual to alter or otherwise use a content item or item component at one time. /8 8.6 Apply Digital Signatures – Append a data block or cryptographic mark to content to authenticate it and verify that it could only have

originated with the purported sender. /13 8.7 Apply Encryption – Translate a content item into an encoded item, usually accomplished using a secret key and a cryptographic

cipher. /6

9.0 MANAGE WORKFLOW: 9.1 Define Workflow - Define and maintain the properties of workflow process maps. /3 9.2 Define Tasks - Define and maintain the steps within a workflow and the associated properties of the steps. /6 9.3 Define Routes and Content Assembly - Define and maintain the sequence of tasks in a workflow based on a set of logical rules. /9



66

The ABILITY to:

9.4 Define Participants - Define and maintain the participants for a particular task in a workflow, including processing deadlines and notifications. /15

9.5 Save and Modify Workflow - Store and recall process maps and associated workflow tasks for subsequent retrieval, revision and output. /12

10.0 MANAGE SEARCH and BROWSE: 10.1 Manage Search Architecture - Define the EIM components, repositories and content that the search system will search. /8

10.2 Define Search Fields - Establish the metadata and content that will be indexed for search and retrieval in various indexes. /5

10.3 Manage Indexing - Define how fields will be indexed and control the indexing process. /12

10.4 Manage Search Interface - Provide a variety of interfaces by which users can search EIM content repositories. /11

10.5 Manage Query Processing - Provide a variety of techniques to match queries against indexes to retrieve search results. /9

10.6 Display Search Results - Define the fields of metadata to be displayed about the items retrieved in searches, and multiple formats of displays. /10

10.7 Capture Search Results - Define how search results can be used. /5

10.8 Manage Browse Structures - Define and maintain navigation paths in EIM components /6.

11.0 MANAGE REPORTING: 11.1 Manage Reporting Capabilities - Manage the processes that enable the presentation of content in a variety of ways to meet general

and specific business requirements. /9 11.2 Track Content and Transactions - Specify the types of content, metadata and transactions that EIM components will count. /2 11.3 Define Displays and Reports - Provide flexible ways of displaying and printing content items and their metadata. /9 11.4 Manage Hard Copy Reporting - Print content to paper or output it to another physical medium from EIM components. /6

12.0 ADMINISTER EIM REPOSITORIES: 12.1 Establish Content Repositories - Establish and identify electronic repositories for storing content and metadata, and configure

fields, business logic and processes. /5

12.2 Administer Content Repositories - Add, delete, and update repository fields, values and processes, control access, monitor and assure the integrity of EIM components in all phases of the content life cycle. /6

12.3 Administer Storage Devices – Implement processes to allocate physical storage devices for online, nearline and offline retention of content and metadata, identify processing errors, monitor capacity and reallocate storage resources. /5



67

The ABILITY to:

12.4 Administer Backup and Recovery - Implement processes to regularly copy repositories or specific sets of content to media which can be used to restore content, metadata and systems at the same or another location. /9

12.5 Administer Global Change - Implement processes that enable changes to a range of content and/or metadata at one time in one or more repositories. /3

12.6 Administer Help - Implement multiple levels of online assistance within EIM components for various processes and groups of users. /16

12.7 Administer Processing – Set up and manage multiple input queues according to user-specified requirements. /3

12.8 Administer Audit Logs - Create electronic means of tracking interactions with content, and monitor transactions that affect them. /11

12.9 Capture Audit Information - Store information in audit logs about transactions that affect or change content or metadata. /5

12.10 Perform Audits and Assessments – Determine whether breaches of security have occurred and whether actions upon content and metadata adhere to established business rules and are carried out by those authorized to do so. /13

13. IMPLEMENT TECHNICAL SPECIFICATIONS:

13.1 Ensure EIM Core Capabilities - Implement functionality and parameters for EIM technologies, in accordance with GoA and ministry-specific technology and information management requirements. /11

13.2 Integrate with Other Technologies - Capture content from, access content in, carry out transactions in, and output content to, repositories in other non-EIM technology components. /10

13.3 Remote Access Requirements – Allow users to interact with content and metadata in EIM technology components at locations other that their desktops/ 5

14. GAEA ARCHITECTURAL REQUIREMENTS:

14.1 GAEA Business Architecture. /3

14.2 GAEA Data Architecture. /4

14.3 GAEA Application Architecture. /4

14.3 GAEA Technology and Security Architecture. /4

14.5 GAEA Privacy Architecture. /1

Business and Technical Requirements – Capture Content


68

1.0 CAPTURE CONTENT Description

To “Capture Content” is to establish the processes and controls that provide for the:

• authoring of content within a dynamic electronic repository environment; • intake of content into an electronic repository from external sources, and • movement of content from one repository into another for various business purposes. Examples would be from a

desktop suite into a web content management or a records management repository, or from an imaging application into a document management system.

Sometimes the physical location of content items actually changes, and sometimes only their links, pointers and business rules are revised. Capture content includes activities such as:

• Defining the types of content in a repository. • Establishing forms and templates to format and transform content. • Authoring and editing content within a repository. • Capturing content from other sources, either through individual or batch transactions, such as receiving imaged paper

content, capturing e-mail, capturing other office documents, generating content automatically from other systems, and bulk importing.

• Registering content items in repositories, i.e. assigning a unique identifier to each content item providing evidence that it was created or captured.

• Declaring content items to be “official records.” Capture Content must be closely integrated with Manage Collaboration.



69

The ABILITY to: Value Vendor Response GoA Evaluation 1.0 CAPTURE CONTENT: 1.1 Define Content - Establish formats for electronic content in repositories.

1.1.1

Support the registration, storage, indexing, retrieval, reporting and distribution of all content formats including: • Hypertext Markup Language (HTML). • Extensible Markup Language (XML). • Office productivity tools such as word

processing, spreadsheet, presentation, graphics and text items.

• E-mail messages, attachments and links. • Structured content extracted from within a

database. • PDF items • Multimedia, e.g. audio, video, Flash files.

D

1.1.2

Extend to accommodate other formats as emerging technologies are adopted, for example: • instant messaging; • digital photographs, digital video, digital X-rays

and MRIs; • recorded conversations; • collaboration content.

D

1.1.3

Handle content of various sizes, from small word processing items to multiple page images to large video items. Please state any limitations.

D



70

The ABILITY to: Value Vendor Response GoA Evaluation SEE ALSO Implement Technical Requirements – Storage Devices Requirements

1.2 Define and Maintain Templates - Design and revise forms and patterns that assist the creation and formatting of content.

1.2.1 Use templates for all types of processes, such as content creation and capture, metadata entry and capture, managing content, workflow, user and life cycle management, publishing and reporting.

D

1.2.2

Use default templates for creating all types of content.

D

1.2.3

Pre-define form-based templates to manage style separately from content.

D

1.2.4 Apply styles correctly according to output devices.

D

1.2.5

Manage folders that control style, e.g. cascading style sheets, electronic forms.

D

1.2.6 Allow an unlimited number of templates.

D

1.2.7 Produce global and site-specific templates.

D

1.2.8 Allow nested templates.

D



71

The ABILITY to: Value Vendor Response GoA Evaluation 1.2.9 Store templates in content repositories.

D

1.2.10 Download templates and forms in their native formats from other repositories.

D

1.2.11 Generate templates that will create “printer friendly” web pages.

D

1.2.12 Create, modify and update templates using a Graphical User Interface (GUI)-based, wizard-based, or standard design tools.

D

1.2.13 Apply version control to stored templates

D

1.3 Capture Content – Compose electronic content items and metadata within an EIM repository or import them from another source.

1.3.1

Create content items within an EIM repository. D

1.3.2 Support the capture of content items from office productivity tools such as word processing, spreadsheet, and presentation tools into EIM components using: • cut/copy and paste and save features, • fax transmission, • direct scanning,

D



72

The ABILITY to: Value Vendor Response GoA Evaluation • direct loading, copying and print to file, • drag and drop filing., • other methods.

1.3.3 Take content items into an EIM repository and retain their structural integrity, e.g. all the components of an e-mail message with attachment(s), or of a web page, with links.

D

1.3.4

Allow a content item with more than one component to be captured in at least two ways: • as a single content item; • as a set of linked items, one item per

component.

D

1.3.5

Maintain links among the components of content items when storing content items in other EIM locations or repositories, e.g. capturing web pages into records management environments.

D

1.3.6

Capture the metadata elements for content as specified by GoA metadata requirements. (SEE Manage Metadata, and APPENDIX F.)

D

1.3.7

Capture content items prepared using templates that allow automated identification of metadata elements.

D



73

The ABILITY to: Value Vendor Response GoA Evaluation 1.3.8

Provide utilities for bulk import of content in various repositories and formats into an EIM component, i.e. in groups, not one item at a time.

D

1.3.9

Capture transactional documents (content items) from other systems: • support predefined batch file transaction

imports; • provide edit rules to customize automatic

registration of content; • maintain data integrity validation.

D

SEE ALSO Manage Metadata – Import Metadata.

1.4 Receive Imaged Content – Capture content items from scanning, OCR and ICR technology, ensuring that these processes result in authentic, evidential-quality records.

1.4.1 Support the capture of imaged content through integrated methods.

D

1.4.2

Support Optical Character Recognition (OCR) and Intelligent Character Recognition (ICR) through integrated methods.

D

SEE ALSO Mandatory Requirements (M14), and Implement Technical Specifications – Integrate with Other Technologies

1.5 Capture E-mail - Import or save e-mail messages and attachments.

1.5.1

Operate in at least the following modes, allowing initial choice and subsequent change from one

D



74

The ABILITY to: Value Vendor Response GoA Evaluation mode to another: • the system allows users to choose which e-mails

to capture and register; • the system automatically captures and registers

all e-mails.

1.5.2

Allow users to capture e-mail messages into the EIM environment from within the e-mail system, e.g. using drag-and-drop filing capabilities.

D

1.5.3

Ensure the capture of a human-readable version of an e-mail message address, where one is associated with the original message; for example, ‘Jan Schmidt’ rather than ‘[email protected]’.

D

1.5.4

Auto-populate the address with all the individual names of the recipients when a message was sent to a distribution list.

D

1.6 Register Content - On its entry into a repository, give a content item an unambiguous identifier, i.e. that is not duplicated. 1.6.1

Have EIM components generate unique identifiers automatically.

D

1.6.2

Associate a unique identifier with every occurrence of a class, folder, volume, content item, extract.

D

1.6.3

Ensure that every registered content item has a viewable registry entry including specified metadata.

D



75


Register content items to any other EIM component from within the current component.

D

1.6.5 Where a content item has more than one version, allow users to choose one of the following: • register all versions as one content item; • register one version of the content item; • register each version of the content item.

D

1.6.6

Store the unique identifiers as metadata of the content items to which they refer.

D

1.6.7

Reference the unique identifiers outside of the EIM components, e.g. to fulfill evidentiary requirements.

D

1.6.8

Prevent users from inputting a unique identifier manually, and from subsequently modifying it.

D

1.6.9

Allow an authorized individual to specify the starting point for unique identifiers (e.g. 0, 00, 100) and increments (e.g. 1, 10) to be used in all cases

D

1.6.10

Allow an authorized individual to specify the format of the unique identifier and permit subsequent revisions to the format.

D

1.7 Capture Official Records – Take official records into an environment that applies Records Management business rules.

1.7.1 D



76

The ABILITY to: Value Vendor Response GoA Evaluation Identify as official records those content items and their metadata that users have declared as official records to be retained as evidence of the conduct of business.

1.7.2

Retain official records in a Records Management environment which ensures that they cannot be altered, nor removed from the repository except through an authorized process by authorized individuals.

D

SEE ALSO Manage Official Records.

Business and Technical Requirements – Manage Collaboration


77

2.0 MANAGE COLLABORATION Description

To “Manage Collaboration” is to manage processes that allow people who are located in many different places to work together interactively on the creation and basic management of electronic content, over distributed computer networks and content repositories. Collaboration processes involve both Asynchronous and Synchronous activities.

Manage Collaboration includes activities such as: • Creating personal and group workspaces. • Establishing business rules and processes for content development. • Creating content items collaboratively in real-time and in sequential steps such as application sharing and

threaded discussions. • Scheduling individual and group events. • Developing projects, routing tasks and content, tracking progress and initiating adjustments. • Conducting interactive communications through a variety of methods, for example, electronic white boarding,

instant messaging, virtual conferencing. Manage Collaboration must be closely integrated with Create and Capture Content, Manage Content and Manage Workflow.



78

The ABILITY to: Value Vendor Response GoA Evaluation 2.0 MANAGE COLLABORATION 2.1 Manage Workspaces and Tasks - Have individuals and work groups in different locations use interactive tools to aid in

the creation, discussion and flow of content.

2.1.1

Provide secure capabilities according to GoA standards for extended partners and stakeholders to participate in collaboration workspaces. (See Section 14 GAEA Technology and Security Requirements)

D

2.1.2

Allow users to create personal workspaces with access to all their projects and content.

D

2.1.3 Allow users to belong to different project workspaces.

D

2.1.4 Allow collaboration activities to be captured as content items with related metadata.

D

2.1.5 A common, preferably web-based or portal-based interface should be used for the collaboration components.

D

2.1.6 Support synchronization collaboration activities across multiple client devices

D



79


Establish priorities for personal and corporate tasks, and output prioritized task lists.

D

2.1.8 Support alarms and reminders.

D

2.1.9 Support assignment and re-assignment of tasks to others.

D

2.1.10 Support international holidays and time zones.

D

2.1.11 Allow concurrent access to the repository for exchange of content items via multiple clients.

D

2.1.12 Support free time searching for calendaring.

D

2.1.13 Support group calendaring (calendar sharing) and scheduling of events/meetings.

D

2.1.14 Allow users to schedule interactions among team members in personal and group calendars.

D

2.1.15 Support vacation scheduling.

D

2.1.16 Interface with any workflow services that are outside the collaboration toolset.

D



80

The ABILITY to: Value Vendor Response GoA Evaluation 2.1.17 Support workflow automation for content-intensive processes.

D

2.1.18

Allow ad-hoc routing and approval of content items.

D

2.1.19

Integrate with other calendaring tools such as desktop calendaring

D

2.1.20

Detect participant presence and support instant messaging.

D

2.1.21

Support online polling/voting. D

2.1.22

Construct online surveys within the collaboration environment without the need for technical expertise.

D

2.1.23

Have basic task management facilities including: • creating tasks and milestones; • assigning resources, deadlines, and other details

to tasks; • viewing task relationships and

interdependencies preferably through graphical means;

• enabling team members to update their own

D



81

The ABILITY to: Value Vendor Response GoA Evaluation progress and report on the status of task groupings and projects.

2.1.24

Allow users to contribute to threaded discussion boards/news groups.

D

2.1.25

Integrate with project management tools. D

2.2 Support Synchronous Collaboration - Have two or more participants in an interaction that relies on the use of common information and requires interaction at the same time.

2.2.1

Support real-time meeting features including: • Instant messaging (chat); • E-whiteboard; • Application sharing; • Instant task creation; • Audio/Video conferencing with online meeting

tools; • Electronic classroom and virtual presentation.

D

Business and Technical Requirements – Manage Content


82

3.0 MANAGE CONTENT

Description

To “Manage Content” means to control the ways in which electronic information management systems manipulate, copy, track and move content items and folders within and between repositories.

Manage Content includes activities such as: • Creating and tracking versions of content items. • Editing content and new content items from different sources. • Using electronic watermarks, • Removing content from repositories under approved business conditions. • Moving content to different technological platforms by export or transfer. • Making extracts of content items (redaction) to meet specific requirements (from MCA) • Formatting content and transforming it into different renditions.

Manage Content must be closely integrated with Manage Records.

Functional Requirements for EIM Technology – Manage Content


83

The ABILITY to: Value Vendor Response GoA Evaluation 3.0 MANAGE CONTENT 3.1 Transform Content – Duplicate or edit content, change its appearance or the arrangement of its components, or render it

into a different electronic form.

3.1.1

Make an exact reproduction of content, leaving the source unchanged, and write the same content elsewhere on the same or a different medium.

D

3.1.2

Invoke the editing tool from within the EIM component.

D

3.1.3

Add to, delete from, or otherwise modify content. D

3.1.4

Add comments, highlights, stamps, and other annotations to content and maintain the association with the items.

D

3.1.5

View comments, annotations, etc. separately from their related content.

D

3.1.6

Combine into a single content item, content that was originally created in more than one format.

D

3.1.7

Automatically convert content items from and to multiple formats, both single items and large groups of items at a time.

D



84


Preview the rendered format of content. D

3.1.9

Allow ad-hoc viewing of rendered content through the rendering tools, as well as through viewers.

D

3.1.10

Support: • automatically storing renditions in the same

location as their source content items. • automatically linking renditions and their

source content items.

D

3.1.11

Change the look of individual content items in a page through the use of templates.

D

3.1.12

Allow external content and internal content sources to be integrated in one template, so that the new content item has one new presentation standard applied.

D

3.2 Version Content – Manage all iterations of content that has been altered sufficiently to capture it as a different version.

3.2.1

Support version control for templates and content at all levels of aggregation, providing access to both current and previous versions.

D



85


When required, support self-modifying content, such as: • content items that contain a field or code which

automatically displays the current date. • a spreadsheet with a macro which changes the

spreadsheet by means of the application software used to view it and then automatically saves it.

D

3.3 Manage Watermarks - Mark content items with electronic images containing provenance or ownership information.

3.3.1

Manage content items that have electronic watermarks or some comparable technological control, for example, to protect intellectual property.

D

3.3.2

Superimpose on an image bitmap, a complex visible or invisible pattern that can only be removed by use of an algorithm and a secure key.

D

3.3.3

Store content items that have electronic watermarks, including metadata about the watermarks.

D

3.3.4

Retrieve information stored in electronic watermarks.

D

3.4 Redact Content – Remove or permanently mask some material from a record when the full item cannot be released or published.



86


Allow an authorized individual to copy a record for the purpose of redaction, i.e. to create an “extract” of a record.

D

3.4.2

Remove or hide sensitive information, without affecting the source record.

D

3.4.3

Store both the original record and the redacted copy.

D

3.4.4

Remove sensitive information in the extract and show that something was removed.

D

3.4.5

Ensure that none of the removed information can ever be seen/heard in the extract, whether on screen or when printed or played back, regardless of the use of any technical features.

D

3.4.6

Store a cross-reference to an extract in the same folder and volume as the original record, even if that folder or volume has a status of Closed.

D

3.5 Delete Content – Remove content from a repository, update all directory and register information, update related metadata to record the action, and ensure before deletion that Final Disposition conditions are met.

3.5.1

Identify obsolete content based on retention and disposition rules.

D



87


Notify authorized individuals on expiration of content items.

D

3.5.3

Delete content items that have met retention requirements.

D

3.5.4

Allow authorized individuals to delete content items to correct user errors or to meet legal requirements.

D

3.5.5

Allow authorized individuals to delete classes, folders, volumes and content items.

D

3.5.6

Delete all the content items associated with a folder or volume when it is deleted, while ensuring that: • no content items are deleted if their deletion

would result in a change to another content item;

• links are identified from other folders, volumes or content items to a folder, volume or content item that is about to be deleted, requesting confirmation from authorized individuals before deletion is carried out.

D



88


Retain user-specified metadata about content and metadata that are deleted from repositories.

D

3.5.8

Report details of any failure during deletion, identifying items that generated processing errors and items that were not successfully deleted.

D

3.5.9

Destroy content stored on re-writable media by complete obliteration, so that it cannot be restored by use of specialist recovery facilities.

D

3.5.10

Destroy content stored on write-once media by preventing access to it, so that it cannot be restored by normal use of the system or by standard operating system utilities.

D

3.5.11

Prevent the deletion of a folder or any part of its contents at all times, with the exceptions of: • destruction or transfer according to an

approved retention and disposition schedule; • destruction or transfer by an authorized

individual as part of an authorized and auditable procedure.

D



89


Identify the folders, volumes and content items associated with content structures and classes to be deleted, and require: • confirmation before deletion; or • reallocation to another content structure

and/or appropriate classes.

D

SEE ALSO Manage Content – Export and Transfer Content; Manage Official Records – Implement Final Disposition, – Manage Hard Copy Records and – Manage Hybrid Records; Manage Metadata – Export and Transfer Metadata.

3.6 Export and Transfer Content - Copy or move content from one EIM component or repository to another, maintaining authenticity, integrity, reliability and usability.

3.6.1

Export content and metadata, i.e. copy the content and metadata, with or without reformatting or transforming it, and retain the original version in the source location.

D

3.6.2

Transfer content and metadata, i.e. move the content and metadata and delete the original version after confirmation of successful receipt, ensuring that retention and disposition conditions are met where appropriate.

D

3.6.3

Provide utilities for the bulk export and transfer of content and metadata that allow customization to accommodate requirements of destination repositories.

D



90


Maintain the integrity of the relationships among classes at all levels of content structures, folders, volumes, content items, records retention and disposition schedules, and all other metadata during export and transfer.

D

3.6.5

Include a copy of all audit data associated with the content and metadata being exported or transferred.

D

3.6.6

Report details of any failure during an export or transfer, identifying items that generated processing errors, and items that were not successfully exported or transferred.

D

3.6.7

Ensure that all exported or transferred content and metadata is retained in its original location, at least until successful receipt in the destination location is confirmed.

D

3.6.8

Ensure that the source content and metadata is identified as having been successfully exported or transferred.

D

3.6.9

Retain user-specified metadata about content and metadata that are exported, transferred, and moved to nearline and offline repositories.

D



91


When exporting or transferring hybrid folders, require an authorized individual to confirm that the paper parts of the same folders have been copied (exported) or transferred before exporting or transferring the electronic part.

D

3.6.11 Delete the source version of the transferred content and metadata after confirmation of successful receipt.

D

SEE ALSO Manage Content – Delete Content; Manage Official Records – Export and Transfer Records; Manage Metadata – Export and Transfer Metadata.

Business and Technical Requirements – Organize Content


92

4.0 ORGANIZE CONTENT

Description

To “Organize Content” is to set up logical containers for content, i.e. folders and volumes, to relate the folders to categories, or classes, in hierarchical content structures, and to organize content items by assigning them to the folders and volumes. Folders group related content items, and volumes typically subdivide folders that might otherwise be unmanageably large.

Organize Content includes activities such as: • Establishing folder structures. • Linking folders to classes in content structures • Categorizing content items by assigning them to folders. • Naming content according to specific practices. • Assigning indexing values and terms to content to assist retrieval.

Organize Content must be closely integrated with Manage Metadata and Manage Content Access.

Functional Requirements for EIM Technology – Organize Content


93

The ABILITY to: Value Vendor Response GoA Evaluation

4.0 ORGANIZE CONTENT 4.1 Manage Folders and Volumes – Create and maintain folders, with volumes as required, and link them to classes in

content structure(s).

4.1.1 Support physical folders, electronic folders, and a combination of both.

D

4.1.2

Link folders with related classes in hierarchical content structure(s).

D

4.1.3

Allow authorized individuals to reallocate folders and their volumes to different classes of a content structure.

D

4.1.4

Ensure that all folders, volumes and content items retain their association when reallocated.

D

4.1.5

Allow an authorized individual to record the reason for reallocating folders and volumes.

D

4.1.6 Allow authorized individuals to add (open) folders only at the lowest level of any class in a content structure.

D

4.1.7 When a volume is opened, automatically capture as metadata those attributes of its parent folder’s metadata that are common.

D



94

The ABILITY to: Value Vendor Response GoA Evaluation 4.1.8 Ensure that folders and volumes have a status of Open, Closed, or any others that are required.

D

4.1.9 Allow authorized individuals to subdivide any folder that is not closed into more than one volume.

D

4.1.10 Allow only authorized individuals to assign and change folder and volume status.

D

4.1.11 Allow only authorized individuals to assign content items to and delete content items from Closed folders and volumes.

D

4.1.12 Allow only authorized individuals to assign retention values and disposition dates to folders and volumes to identify when retention and disposition actions should occur.

D

4.1.13 Close folders and volumes automatically on fulfillment of specified criteria, including at least: • a periodic cut-off date such as the end of a

calendar year, fiscal year or other defined cycle; • the passage of time since a specified event, such

as, the most recent assignment of a content item;

• the number of content items assigned to a

D



95

The ABILITY to: Value Vendor Response GoA Evaluation folder or volume;

• the occurrence of a specific condition, e.g. a loan is re-paid,

• the capacity of a storage medium is reached.

SEE ALSO Manage Metadata – Manage Content Structures

4.2 Categorize Content – Assign content items to folders or volumes, and associate them with related content items and folders.

4.2.1 Store a large number of content items in a repository.

D

4.2.2 Assign a large number of content items to a folder.

D

4.2.3 Ensure that content items are associated with one or more folders.

D

4.2.4

Allow the same content item to be associated with more than one folder without storing the item more than once.

D

4.2.5 Allow users to create cross-references, i.e. “see also” links between related folders and content items.

D

4.2.6 Allow only authorized individuals to reassign content items to different folders or volumes.

D



96

The ABILITY to: Value Vendor Response GoA Evaluation 4.2.7 Provide automated support for decisions on assigning content items to folders one or more of the following: • making only a subset of a content structure

accessible to a user or role; • storing for each user or role a list of that user’s

most recently used folders; • suggesting the most recently used folders by

that user; • suggesting folders which contain related

content items; suggesting folders by inferences drawn from

content metadata elements, for example, significant words used in the item’s title; and

automatically assign content items to folder which users can confirm or change.

D

4.3 Name Content – Implement business-defined naming mechanism(s) and practices for titling classes, folders, volumes and content items.

4.3.1 Support naming mechanisms for classes and folders based on thesaurus terms and relationships compliant with ISO standards 2788 and 5964.

D

4.3.2 Provide at least two naming mechanisms for classes and folders in the content structure: • a mechanism to allocate a structured numeric

or alphanumeric code, including dates and persons’ names;

D



97

The ABILITY to: Value Vendor Response GoA Evaluation • a mechanism to allocate a textual title for each

class and folder.

4.3.3 Support the validation of names against controlled values lists.

D

4.4 Assign Indexing Values – Select values from controlled terminologies to establish access points for retrieval of content.

4.4.1

Allocate controlled vocabulary terms compliant to ISO 2788 and ISO 5964 as metadata elements.

D

SEE ALSO Manage Metadata

Business and Technical Requirements – Publish Content


98

5.0 PUBLISH CONTENT

Description

To “Publish Content” is to deliver a copy of content in its original form or another form to a separate repository for use by different audiences. Generally, original content needs to be presented in a publishable form by reformatting it and/or combining content components in different ways to form new content items for various communication purposes. Content can be published on an as-needed basis, or as part of a scheduled process, using one or more electronic information management technologies. The publishing process can provide generic content for a broad audience, or include features that allow publishers and users to match content distribution with specific requirements.

Publish Content includes activities such as: • Reformatting content to deliver information effectively • Combining content components to meet other publishing needs. • Disseminating different content items for general publishing, current awareness or other customer requirements • Creating subscription lists so that specific content is automatically distributed to specific users. • Permitting users to personalize subscription functions.

Publish Content should be closely integrated with Manage Content and Manage Workflow.

Functional Requirements for EIM Technology – Publish Content


99

The ABILITY to: Value Vendor Response GoA Evaluation 5.0 PUBLISH CONTENT 5.1 Change Content Format - Reformat or redesign original content for use by a different audience.

5.1.1 Convert content from and to multiple controlled formats, e.g. from office productivity tools to static documents, dynamic web pages, or coded structures.

D

5.1.2 Support the use of ministry-standard or system-controlled templates such as style sheets for formatting content.

D

5.1.3 Reuse content in multiple locations without storage duplication.

D

5.1.4 Provide a preview environment where content can be viewed in the same way as presented in the published version on a website or other distribution centre.

D

5.2 Aggregate Content - Combine two or more content items or components to form another content item.

5.2.1

Ensure that aggregated content can be identified as a separate content item.

D

5.2.2 Manage the new item as a static total object.

D

5.2.3 Identify the components of an original content

D



100

The ABILITY to: Value Vendor Response GoA Evaluation item, or identify original components of a new content item for the purpose of providing access to the component in all stages of its life cycle.

5.2.4 Ensure that all source attributes and information security categories are followed e.g. an aggregated content item would have the more restrictive security category if composed of two components that originally had different security categories.

D

5.3 Publish Content - Extract folders, content items and metadata from EIM content repositories and send to distribution centres such as web sites and print centres.

5.3.1 Publish in real-time without affecting the availability of the EIM or the publishing servers.

D

5.3.2 Publish static (fixed) content.

D

5.3.3 Publish dynamic content, i.e. support program code that builds content as requested so that the final product changes when sources change.

D

5.3.4

Publish a single content item to multiple repositories and distribution centres based on predefined rules.

D

5.3.5 Establish and revise workflows to create, approve and publish content.

D



101


Support automatic publishing. D

5.3.7 Choose content for automatic publishing based on sets of business criteria such as time, audience, or topic.

D

5.3.8

Add and remove content from automatic publishing routines.

D

5.3.9 Support ad-hoc publishing, i.e. without using pre-defined workflow.

D

5.3.10 Rollback publication to a previous state if unsuccessful.

D

5.3.11 Set up schedules and automatic processes for review and revision of published content.

D

5.4 Disseminate Content - Deliver content to specific groups and users, including discovering and matching content automatically to various criteria.

5.4.1 Establish subscription profiles based on roles and responsibilities, authorization or any other user criteria.

D

5.4.2 Notify subscribers when relevant content changes.

D

5.4.3 D



102

The ABILITY to: Value Vendor Response GoA Evaluation Allow subscribers to customize their subscription profiles to receive relevant content.

5.4.4 Push content to users who are not subscribers based on interests identified from their activity on publishing sites.

D

SEE ALSO Implement Technical Specifications – Integrate with Other Technologies.

Business and Technical Requirements – Manage Official Records


103

6.0 MANAGE OFFICIAL RECORDS

Description

To “Manage Official Records” is to control and carry out the processes that deal with systematic management of content items that have been declared “official records”, within a static technology environment so that their content, structure and context relative to each other are fixed, and their integrity can be demonstrated through time. Managing official records could mean moving content from its existing repository to a separate recordkeeping system or other content repository, or invoking a different set of rules within the original repository to meet records access and life cycle management requirements. EIM technologies that manage official records should accommodate both hard copy and electronic records regardless of media.

Manage Official Records includes activities such as: • Capturing or associating required information from records retention and disposition schedules, which define

how long records have to be kept and how they are be disposed of at the end of their life. • Linking retention and disposition schedule items with appropriate classes in records content structures. • Identifying and assigning priorities to vital records. • Reviewing records before disposition to ensure that legal and business requirements have been met. • Transferring records to other locations due to government program changes, storage requirements, or software,

media or technology changes. • Implementing Final Disposition of records, either by Destruction (Deletion) or transfer to the Provincial

Archives of Alberta. • Managing hard copy and hybrid folders, volumes and records under conditions and practices consistent with the

management of electronic content. Manage Official Records must be closely integrated with Create and Capture Content, Manage Content, Organize Content, Manage Metadata.



104

The ABILITY to: Value Vendor Response GoA Evaluation 6.0 MANAGE OFFICIAL RECORDS

Capture Official Records - SEE Capture Content – Capture Official Records, and Manage Metadata.

Manage Records Content Structures - SEE Manage Metadata – Manage Content Structures, and Organize Content – Manage Folders and Volumes.

6.1 Capture Records Schedule Information - Accommodate corporate business rules that manage the retention and disposition of official records.

6.1.1 Interface with, or import and export Records Retention and Disposition Schedule data from and to the GoA application RSS (Records Scheduling System), which is a central repository of all GOA schedules.

D

6.1.2 Allow only authorized individuals to set up and change retention schedule and item information.

D

6.1.3 Allow authorized individuals to define additional fields for information related to retention schedules and items.

D

6.1.4 Have no limit on the length of retention periods.

D

6.1.5 Allow retention periods to be calculated in at least the following ways: • a defined time period after a folder is opened; • a defined time period after a folder is closed; • a defined time period since the most recent

D



105

The ABILITY to: Value Vendor Response GoA Evaluation record was assigned to the folder;

• a defined time period since a record was retrieved from a folder;

• a defined time period after a specific event, defined in a schedule item and entered manually by an authorized individual.

• as ‘permanent’ to indicate long-term retention within an organization.

6.1.6 Allow at least the following Final Dispositions conditions for each schedule item: • review at a future date; • destroy; • transfer to the Provincial Archives for

preservation; • alienate to a non-GoA organization.

D

6.2 Link Schedules with Content Structure(s) - Create and maintain links between records schedule items and classes in records content structures to enable life cycle management of folders, volumes and records.

6.2.1 Associate each schedule item with at least one class at any level of a records content structure.

D

6.2.2 Ensure that a folder allocated to a class in a records content structure inherits as a default, the retention and disposition conditions from the schedule item associated with that class.

D



106

The ABILITY to: Value Vendor Response GoA Evaluation 6.2.3 Allow an authorized individual to override the default retention and disposition, i.e. to allocate a folder to a different class in a records content structure.

D

6.2.4 If any class is not associated with a schedule item, the disposition conditions for its related folders remain blank, i.e. disposition cannot take place.

D

6.2.5

Allow changes made to a schedule item to be automatically applied in the classes and folders linked with that item.

D

6.2.6 Allow override of the automatic application of changes in schedule items to linked classes and folders

D

6.2.7 When a folder is reallocated to a different class in a records content structure, allow the option of having the folder inherit the retention and disposition conditions linked to the new class.

D

SEE ALSO Manage Content – Delete Content; Manage Metadata – Manage Content Structures.

6.3 Manage Vital Records – Identify and restore those records that are necessary to continue government services and operations during a disaster and resume operations afterwards.



107

The ABILITY to: Value Vendor Response GoA Evaluation 6.3.1 Identify Vital Records according to the business categories in the GoA Business Continuity Planning process, or other categories as appropriate. The current business categories are: critical services, vital services, necessary services and desired services. For further details, see Business Resumption Guide.

D

6.3.2 Assign priority values to Vital Records, i.e. identify which records should be restored in which order.

D

6.3.3 Restore vital records and other records in distinct operations.

D

6.4 Review Records - Examine related folders, volumes and records to decide whether scheduled retention and disposition actions can take place.

6.4.1

For any specified time period, calculate retention periods and dates to identify which folders, volumes and records are eligible for retention and disposition actions.

D

6.4.2

Support rules-based alerting, i.e. before initiating retention and disposition processes, notify authorized individuals, that folders, volumes or records: • require review by a specific individual; • have a specified security category;

D



108

The ABILITY to: Value Vendor Response GoA Evaluation • are linked to other folders, volumes or records

(references to and from).

6.4.3 Identify records for which retention and disposition actions can take place automatically, without a records review.

D

6.4.4 Ensure that all records eligible for Final Disposition are reviewed by an authorized individual, who confirms before disposition that: • concurrence conditions in records schedules

have been met. • records are no longer required for business

purposes.

D

6.4.5

Allow the reviewer to take the following actions: • confirm that final disposition should continue; • mark the folder, volume or record on hold

from final disposition; • allocate the folder to a different class in the

records content structure, i.e. to a different set of retention and disposition conditions.

D

6.4.6 Ensure that an authorized individual confirms that a disposition process on hold should be completed.

D

SEE ALSO Manage Workflow.

6.5 Export and Transfer Records – Copy or move official records and their metadata from one recordkeeping system or repository to another, maintaining authenticity, integrity, reliability and usability.



109

The ABILITY to: Value Vendor Response GoA Evaluation 6.5.1 Automatically track retention periods associated with folders and volumes and calculate dates when transfer actions can take place, for example to near or off-line storage.

D

6.5.2 Provide automated processes to obtain and record required approvals for transfer actions.

D

6.5.3 Delete the source version of the transferred records after confirmation of successful receipt, ensuring that appropriate retention and disposition conditions are met.

D

SEE ALSO Manage Official Records – Manage Hard Copy Records; Manage Content – Export and Transfer Content; Manage Metadata – Export and Transfer Metadata.

6.6 Implement Final Disposition – After records reviews, preserve, or alienate official records according to the criteria documented in records schedules.

6.6.1 Destroy official records, i.e. delete records and metadata, according to GoA policy and practices.

D

6.6.2 Preserve official records, i.e. transfer official records and metadata of enduring value to the Provincial Archives of Alberta (PAA) for permanent retention.

D



110

The ABILITY to: Value Vendor Response GoA Evaluation 6.6.3 Alienate official records, i.e. transfer records and metadata outside the Government of Alberta to a non-GoA repository.

D

6.6.4 Have an authorized individual confirm final disposition of official records before Destruction, Preservation, or Alienation.

D

6.6.5

Add user-defined metadata elements to metadata of official records to be transferred to PAA.

D

6.6.6 Interface with, or import/export data from/to, applications used by the Alberta Records Centre (ARC) to support the Final Disposition of hard copy records from the ARC.

D

6.6.7

Accommodate the same or different procedures for managing retention and Final Disposition of Master Sets and Copy Sets of hard copy records.

D

6.6.8

When deleting hybrid folders, require an authorized individual to confirm that the hard copy parts of the same folders have been destroyed before deleting the electronic parts.

D

SEE ALSO Manage Hard Copy Records and Manage Hybrid Records; Manage Content – Delete Content.

6.7 Manage Hard Copy Records - Manage access and life cycle processes for repositories of physical records stored on media such as paper, microfilm, photographs, videos, etc. at the box/container, folder, volume and record levels.



111

The ABILITY to: Value Vendor Response GoA Evaluation 6.7.1 Link physical folders, volumes and records to the same or different classes in the same records content structures as electronic content.

D

6.7.2 Maintain boxes of hard copy folders and volumes according to a predetermined plan. Boxes may be virtual aggregations, physical containers, or a combination of both.

D

6.7.3 Display and recommend shelf locations available for storing physical boxes in multiple locations, based on number of boxes to be stored as well as storage facility location.

D

6.7.4 Support the recognition, processing and printing of a variety of bar codes, or other tracking mechanisms to automate the data entry for tracking physical box, folder and volume movements.

D

6.7.5 Print colour labels for physical items.

D

6.7.6 Apply the same metadata elements to both physical and electronic boxes, folders, volumes and records.

D

6.7.7 Track physical boxes, folders, volumes and records using check-out, check-in and bring forward facilities.

D



112

The ABILITY to: Value Vendor Response GoA Evaluation 6.7.8 Record a specific user and/or location to which a physical item is checked-out, and display this information if an authorized individual requests the item.

D

6.7.9 Notify an authorized individual of review decisions and necessary actions to be taken on the physical boxes, folders, volumes, and records.

D

6.7.10 Export and transfer metadata of physical boxes, folders, volumes and records.

D

SEE ALSO Manage Content Access – Check-out and Check-in

6.8 Manage Hybrid Records - Manage integrated access and life cycle processes for “hybrid” folders and volumes that consist of records in both electronic and hard copy media.

6.8.1

Define folders and volumes that logically contain both electronic and physical records, and ensure that both types of records are managed in an integrated manner.

D

6.8.2 Assign the same security category to the physical and electronic components of a hybrid folder or volume.

D

6.8.3 Ensure that retrieval of a hybrid folder or volume retrieves the metadata for both its electronic and hard copy records.

D



113

The ABILITY to: Value Vendor Response GoA Evaluation 6.8.4 Allow the electronic and physical components of a hybrid folder or volume to use the same title and identifier(s).

D

6.8.5 Alert an authorized individual to the existence and location of any physical components when hybrid folders, volumes or records will be transferred.

D

6.8.6 Apply any review decision made about the electronic component of a hybrid file to its physical component.

D

6.8.7 Accommodate the same or different procedures for managing Final Disposition of the physical and electronic components of hybrid folders.

D

6.8.8

Automatically identify both electronic and hard copy parts of hybrid folders that have met retention requirements and notify authorized individuals.

D

SEE ALSO Manage Official Records – Export and Transfer Records and – Implement Final Disposition; Manage Content – Delete Content and – Export and Transfer Content.

Business and Technical Requirements – Manage Metadata


114

7.0 MANAGE METADATA

Description To “Manage Metadata” is to define the set of metadata elements and attributes that are required to support information access and life cycle management activities, to identify controlled values for those elements and to capture them into encoding schemes. In addition, it comprises the development and maintenance of hierarchical content structures, or classification schemes, to organize content items, processes to establish and maintain metadata repositories, as well as the creation and capture of metadata for all types of content, using both automated and manual processes.

Manage Metadata includes activities such as: • Defining sets of metadata attributes required to manage content. • Implementing standard sources and controlled values for achieving quality control of metadata, such as

GoA data standards and metadata requirements, or program-specific terminology. • Developing hierarchical structures to organize content, for example by business functions and activities, by

topic, by geographic areas. • Establishing and maintaining metadata repositories. • Capturing metadata into profiles for all levels of aggregation, from content structures to content items, and

working towards consistent metadata across multiple repositories. • Managing metadata repositories and maintaining the quality of metadata. • Importing/exporting metadata to/from repositories (See also Capture Content (Import), and Manage

Content (Export)).

Manage Metadata must be closely integrated with Organize Content.



115

The ABILITY to: Value Vendor Response GoA Evaluation 7.0 MANAGE METADATA

7.1 Define Metadata Elements - Specify set(s) of metadata elements and their attributes.

7.1.1 Accommodate user-specified metadata elements, including at least those that: • identify and describe content, • relate content to business functions, • record life cycle management actions required

and performed on content, • record who is responsible for actions and who

performed them.

D

7.1.2

Accommodate at a minimum the Dublin Core metadata elements. (ISO Standard # 15836.)

D

7.1.3

Allow authorized individuals to specify and revise mandatory, recommended and optional metadata elements, and controlled and uncontrolled values.

D

SEE ALSO GOA Metadata Requirements (APPENDIX E)

7.2 Define Metadata Schemas - Define allowable structures and values for metadata elements.

7.2.1

Allow authorized individuals to create, revise and delete metadata schemas at any time.

D

7.2.2

Specify values for metadata schemas. D



116


Develop specific values for user metadata requirements such as ministry business functions and activities, subjects, organization units.

D

7.2.4

Harmonize common metadata values across EIM components and repositories.

D

SEE ALSO GoA Metadata Requirements (APPENDIX E)

7.3 Manage Metadata Repositories - Create and maintain storage mechanisms for retaining metadata, built around metadata models and schemas.

7.3.1

Provide non-proprietary storage for metadata. D

7.3.2

Support both auto-populating and manually entering metadata.

D

7.3.3

Allow authorized individuals to change any user-entered metadata, for example to correct errors and maintain user and group access.

D

7.3.4

Support quality assessment processes to enable metadata to meet quality requirements.

D

7.3.5

Manage multiple metadata repositories to facilitate effective searching and life cycle management. Please explain.

D



117

The ABILITY to: Value Vendor Response GoA Evaluation SEE ALSO Administer EIM Repositories Section 12.

7.4 Manage Content Structures - Create and revise multi-level, hierarchical structures composed of groups (classes) of metadata at various levels of aggregation, and link to folders, to maintain the relative context of content, and facilitate information retrieval and life cycle management.

7.4.1

Allow an unlimited number of content structures. D

7.4.2

Support the initial construction of content structures prior to the capture of specific content.

D

7.4.3

Enable logical content structures that are separate from the physical arrangements of folders.

D

7.4.4

Allow a single content structure to be implemented and maintained across: • multiple content repositories within the same

EIM component, and • multiple EIM components such as DM, WCM

and RM components.

D

7.4.5

Map metadata elements from one EIM component or repository with those from others.

D

7.4.6 Have integrated functionality for maintaining content structures.

D



118


Allow an extensive number of levels of aggregation in content structure hierarchies.

D

7.4.8

Allow an extensive number of classes at any level of aggregation in a content structure.

D

7.4.9

Allow authorized individuals to create, revise and delete content structures.

D

7.4.10

When a class of a content structure is reallocated to a different position in the hierarchy, ensure that all relationships among related folders, volumes and content items are maintained.

D

7.4.11

Accommodate content structures based on at least: • business functions, activities and transactions, • organizational structure, • topics or subjects, • records life cycle management requirements, • privacy protection requirements, • security requirements, and • other user-defined requirements.

D



119


Have records content structures accommodate different retention and Final Disposition conditions for Master Sets and Copy Sets of hard copy records, as defined in records schedules.

D

7.5 Manage Indexing Values - Develop and maintain controlled terminologies to establish access points for retrieval of information from classes, folders and content items.

7.5.1

Create and maintain thesaurus structures that comply with ISO standards 2788 and 5964.

D

7.5.2

Establish controlled vocabulary terms compliant to ISO 2788 and ISO 5964 as metadata values.

D

7.5.3

Allow authorized individuals to update the thesaurus structures and controlled vocabularies.

D

7.5.4

Validate contents of metadata fields against controlled values.

D

7.6 Capture Metadata - Enter metadata about content into profiles in metadata repositories using both automated and manual processes.

7.6.1

Automatically extract user-specified metadata for all forms of content during capture.

D



120


Automatically capture metadata elements: • for content items in the formats specified in

1.1.1. • from source applications, e.g. from office

productivity tools, and • other EIM components.

D

7.6.3

Accommodate automatic metadata capture from other formats as emerging technologies are adopted.

D

7.6.4

Automatically capture metadata from content items created with templates.

D

7.6.5

Support system validation of metadata values, e.g. confirming as entered that user-generated identifiers are unique or within a certain range.

D

7.6.6

Allow entry of metadata at the time of content creation as well as other stages of the life cycle.

D

7.6.7

Capture user-specified metadata about content and content structures according to GoA standards and requirements, including at least: • title, • agent,

D



121

The ABILITY to: Value Vendor Response GoA Evaluation • subject, • description, • date created, • dates modified, • security classification, • aggregation level, • record identifier, • location, • disposition, • keywords, • originator or author, and • application program which generated the

object, including program version.

7.6.8

Have classes in a content structure inherit user-specified metadata that derive from their positions in the hierarchy.

D

7.6.9

Have folders and volumes inherit user-specified metadata from the classes to which they are related.

D

7.6.10

Have content items inherit user-specified metadata from the volumes and folders to which they are related.

D

SEE GoA Metadata Requirements (APPENDIX E).

7.7 Import Metadata - Transform metadata to fit consistent schemas and load it into metadata repositories using both automated and manual processes.



122


Support batch processing for bulk import of metadata.

D

7.7.2

Import metadata from another metadata repository.

D

7.7.3

Automatically extract metadata from imported content and add to existing repositories.

D

7.7.4

Automatically create additional metadata values from imported content.

D

7.7.5

Support automated and manual validation of imported metadata.

D

SEE ALSO Capture Content – Capture Content

7.8 Export and Transfer Metadata – Copy or move metadata from one EIM component or repository to another, maintaining authenticity, integrity, reliability and usability.

7.8.1

Use a combination of automated and manual techniques that allow authorized individuals to format or otherwise transform metadata prior to export or transfer.

D



123

The ABILITY to: Value Vendor Response GoA Evaluation 7.8.2 Maintain a central repository of metadata (i.e. destruction and disposition certificates) about folders, volumes and content items that: • have been destroyed, • transferred to the Provincial Archives of

Alberta; and • transferred outside the control of government

(“alienated”).

D

SEE ALSO Manage Content – Export and Transfer Content; Manage Official Records – Export and Transfer Records, - Manage Hard Copy Records and Manage Hybrid Records.

Business and Technical Requirements – Manage Content Access


124

8.0 MANAGE CONTENT ACCESS

Description

To “Manage Content Access is to control the conditions that permit access to content in both electronic and hard copy form according to an organization’s legal, policy and business requirements. Managing content access helps to ensure that an organization’s information is protected against unauthorized disclosure, manipulation, modification, unavailability and destruction, and provides direction for demonstrating the authenticity and integrity of its records.

Manage Content Access includes activities such as: • Implementing an information security classification for content; • Setting up profiles that define types and conditions of access permitted; • Creating user role profiles, and linking them with access rights; • Establishing and maintaining profiles for authorized individuals and groups; • Setting up methods for checking-out and checking-in content, folders and boxes; • Using digital signatures and encryption techniques where appropriate.

Manage Content Access must be closely integrated with Administer EIM Repositories.



125

The ABILITY to: Value Vendor Response GoA Evaluation 8.0 MANAGE CONTENT ACCESS 8.1 Implement Security for Content - Implement a system of security categories for content according to government-wide

standards.

8.1.1 Assign security categories to classes, folders and/or volumes, and content items.

D

8.1.2 Have draft GoA standard security categories (unrestricted, protected, confidential and restricted) with sub-categories.

D

8.1.3

Implement default levels of security (e.g., group, business unit, folder, role based, etc.) for all content.

D

8.1.4 Implement complex or unique security rules for specific situations. i.e fiscal year budget is very confidential until it is announced in the legislature.

D

8.1.5 Allow a default security value to be assigned for content not allocated to any other security category.

D

8.1.6 Specify a security category for an individual content item that is different from the volume, folder or class to which it is related.

D



126

The ABILITY to: Value Vendor Response GoA Evaluation 8.1.7 Allow authorized individuals to change the security category of folders, volumes and content items.

D

8.1.8

Establish automatic routines to review content for declassification.

D

8.1.9 When changing the security category of folders, choose whether all assigned volumes and content items will automatically inherit the changes.

D

8.1.10 Provide a warning if the security category of any class, folder, volume or content item is to be lowered, and await confirmation from an authorized individual before completing the transaction.

D

SEE “Information Security Classification” Guide.

8.2 Establish Access Profiles - Define types of access rights to content, whether in electronic repositories or in physical locations.

8.2.1 Differentiate access to content based on pre-defined criteria, at least: • roles and responsibilities; • any level in a content structure or folder

arrangement • specified user groups and

D



127

The ABILITY to: Value Vendor Response GoA Evaluation 8.2.2 Define actions that can be performed on content and metadata in a repository.

D

8.2.3 Allow access to specific content items, folders, classes and other metadata.

D

8.2.4 Limit access to specific actions, i.e. to create, read, up-date and or delete specific content and metadata.

D

8.2.5 Allow read-only access regardless of whether a folder or volume is Open or Closed, or has another status.

D

8.2.6 Limit access before and after a specified date and within a range of dates. i.e. access to draft budget content; access by temporary staff.

D

8.2.7 Allow only authorized individuals to define and change access rights, and track all such transactions.

D

8.2.8 Allow access to specified content and specific actions by users from multiple ministries and business units, and external stakeholders.

D



128

The ABILITY to: Value Vendor Response GoA Evaluation 8.2.9 Allow authorized individuals to delegate access rights to others, e.g. to complete assignments in their absence.

D

8.2.10 Allow authorized individuals to specify which individuals and groups can access content that the user is responsible for, and what actions they can take.

D

8.2.11 Provide alternatives to respond if an individual requests access to, or searches for, a content item, volume, folder, class or other metadata to which he or she does not have access rights: • display title and metadata; or • display the item identifier but not its title or

other metadata; or • do not display any information or indicate its

existence in any way, nor include such records in any count of search results.

D

SEE ALSO Administer EIM Repositories Sections 12.

8.3 Define User Groups - Define the roles that determine the extent of users’ access rights to content.

8.3.1

Establish groups of users based on business roles, including at least: • level of authority, e.g. Executive Director,

Regular User; and • task-specific roles, e.g. Web Content Reviewer,

D



129

The ABILITY to: Value Vendor Response GoA Evaluation Records Disposition Coordinator.

8.3.2 Associate defined access rights with each user group.

D

8.3.3 Allow only authorized individuals to establish and change user groups and track all such transactions.

D

8.4 Create Individual Profiles - Associate individuals with user groups to authorize their access rights to content and features in EIM components.

8.4.1 Allow individuals to be associated with multiple user groups.

D

8.4.2 Allow only authorized individuals to establish, change and delete individuals’ profiles, view user lists and administer security procedures.

D

8.4.3 Prohibit access to content and metadata in EIM repositories without authentication using GoA authentication standards.

D

SEE ALSO GAEA Requirements (Section 14).

8.5 Check-out/ Check-in - Allow only one individual to alter or otherwise use a content item or item component at one time.

8.5.1 Permit folder, volume and content item check-out and check-in.

D



130

The ABILITY to: Value Vendor Response GoA Evaluation 8.5.2 Enable read-only access rights when an item is checked out, i.e. implement record locking.

D

8.5.3

Update the repository when the item is checked-out and checked in.

D

8.5.4 Log transactions in the audit log of the repository or separate “circulation” function as appropriate.

D

8.5.5 Record at least the following information about electronic and hard copy check-out: • unique identifier; • current location as well as user-defined number

of previous locations and check-out transactions;

• user who is checking-out; • date checked-out from location; • date received at location (for export and

transfers); and • user responsible for the move (where

appropriate).

D

8.5.6 Set a default location for content and allow an authorized individual to over-ride it with a user-defined location.

D

8.5.7

Allow authorized individuals to electronically D



131

The ABILITY to: Value Vendor Response GoA Evaluation request both electronic and hard copy content that is checked-out.

8.5.8 Enable notification to the individual who has it, whenever a request is made for a box, folder, volume or content item that is checked-out.

D

SEE Also Manage Official Records – Manage Hard Copy Records, Manage Hybrid Records.

8.6 Apply Digital Signatures - Append a data block or cryptographic mark to content to authenticate it and verify that it could only have originated with the purported sender.

8.6.1

Apply only where a requirement exists to manage content bearing digital signatures.

D

8.6.2

Ensure that encrypting content items with the signers’ Private Encryption Keys forms digital signatures. The private keys should be accessible only by the signer.

D

8.6.3

Ensure that the signers’ Public Keys will successfully decrypt the signature and reproduce the cryptographic mark for the active period of he record.

D

8.6.4

Ensure that a subscriber can be strongly linked to a particular transaction so that the signature captures the entire transaction.

D



132


Ensure that it can be demonstrated that a subscriber intended to sign a content item.

D

8.6.6

Ensure that it can be demonstrated that a subscriber knew exactly what he or she was doing when the digital signature was made.

D

8.6.7

Ensure that a notary can attest to the validity of the signature and date/time stamp i.e. certificate authority.

D

8.6.8

Ensure that a digitally-signed receipt is sent after a transaction, ideally reciting the relying party’s view of exactly what was signed and the intent of the signature.

D

8.6.9

Ensure that other techniques are used in addition to passwords to establish non-repudiation.

D

8.6.10

Ensure that a process is implemented to support secure long-term storage of the required keys to be able to validate a digital signature at any point in the future when required. Please explain.

D

8.6.11

Ensure that keys exist for as long as storage of the content is required.

D



133


Ensure that digitally signed content and metadata tags are separate so that they are not signed and not subject to change.

D

8.6.13

Ensure that digital signatures comply with the Digital Signature Standard (DSS) http://www.itl.nist.gov/fipspubs/fip186.htm

D

8.7 Apply Encryption - Translate a content item into an encoded item, usually accomplished using a secret key and a cryptographic cipher.

8.7.1

Apply only where there is a requirement to manage content that is encrypted

D

8.7.2

Restrict access to encrypted content to users holding the relevant decryption key, in addition to any other access controls applied to that content item, when the item is sent or received by an application that interfaces with the content management system.

D

8.7.3

Retain as metadata about an encrypted content item: • the fact of encrypted transmission; • the type of algorithm; • the level of encryption used; • time;

D



134

The ABILITY to: Value Vendor Response GoA Evaluation • certificate authority; • validity and strength; • other user-specified fields.

8.7.4

Ensure the capture of encrypted content directly from an application that has an encrypting capability.

D

8.7.5

Permit different encryption technologies to be introduced easily.

D

8.7.6

Capture encrypted content directly from an application that has an encrypting capability.

D

Business and Technical Requirements – Manage Workflow


135

9.0 MANAGE WORKFLOW

Description

To “Manage Workflow” is to manage and monitor prescribed, rules-based, automated business processes, by controlling the tasks, procedures, organizations, people, and input and output content items needed to perform work. Workflow can be focused designed around content and its movement, or around processes and the people who perform them, but all workflow processes typically integrate these components in some way.

Manage Workflow includes activities such as: • Defining, building, and controlling business processes; • Routing information via an electronic messaging backbone; • Setting up decision points so that the information "knows" what to do next; • Accommodating ad hoc or unique processing not reused in other prescribed workflow; • Encapsulating business processes in workflow process maps with associated properties; • Saving, modifying and deleting workflow process maps and work items.

Manage Workflow is integral to all EIM core component technologies, and must be totally integrated with all components of the Management Model.



136

The ABILITY to: Value Vendor Response GoA Evaluation 9.0 MANAGE WORKFLOW 9.1 Define Workflow - Define and maintain the properties of workflow process maps.

9.1.1 Allow for a large number of workflows that can be defined. Please explain any limitations.

D

9.1.2 Create workflow paths without requiring programming skills.

D

9.1.3 Define workflow using GUI, table-driven, and programming script language methods.

D

9.2 Define Tasks - Define and maintain the steps within a workflow and the associated properties of the steps.

9.2.1 Allow for a large number of steps in each workflow.

D

9.2.2 Automatically initiate user-defined processes.

D

9.2.3 Add instructions, and define tasks via instructions and attachments.

D

9.2.4 Rendezvous, i.e. pause the workflow to await the arrival of related content and resume automatically on receipt.

D

9.2.5

Allow the receipt of electronic content to trigger D



137

The ABILITY to: Value Vendor Response GoA Evaluation workflows automatically: • content received from within the EIM

component; • content from another EIM component; and • content from non-EIM technologies.

9.2.6

Allow the receipt of data from applications to trigger workflows in EIM components automatically.

D .

9.2.7 Balance team members’ workloads by assigning incoming items: • to group members in rotation; • on a member’s completion of a current task,

and • other methods.

D


9.3 Define Routes and Content Assembly - Define and maintain the sequence of tasks in a workflow based on a set of logical rules.

9.3.1 Set up routes based on the following conditions: • always true (no condition), • participant response, • logical expression built from defined data

fields, or • conditional flows depending on user input or

D



138

The ABILITY to: Value Vendor Response GoA Evaluation system data.

9.3.2 Route content items and folders in a controlled way from user to user for specific actions, e.g. check an item, approve a new version.

D

9.3.3 Manage parallel routing, when more than one person is involved in the same action.

D

9.3.4 Manage concurrent processes, i.e. different processes happening at the same time.

D

9.3.5 Create custom workflow paths for specific, user-defined business processes.

D

9.3.6 Route multiple content items as one set, e.g., case files.

D

9.3.7

Move content items through the workflow together and upload them from a staging area in bulk or piece-by-piece.

D

9.3.8 Support the ability to track and audit changes to content items through the workflow.

D

9.3.9 Support rollback of changes to content items.

D

9.4 Define Participants - Define and maintain the participants for a particular task in a workflow, including processing



139

The ABILITY to: Value Vendor Response GoA Evaluation deadlines and notifications.

9.4.1

Recognize both individuals and work groups as “participants”.

D

9.4.2 Assign multiple roles to a single user.

D

9.4.3

Notify a participant that content has been sent to their electronic “in box” for attention and specify the action required.

D

9.4.4 Let participants view queues of work addressed to them and select items to work on.

D

9.4.5 Display status of content progress through the workflow.

D

9.4.6 Design strategies in which workflow routing can be visually tracked by other users, i.e. allow participants to see the status of content and tasks of others, according to organization practices.

D

9.4.7 Reassign work from one user to a different user or group.

D

9.4.8 Assign time limits to tasks in each workflow, and report tasks that are overdue.

D



140

The ABILITY to: Value Vendor Response GoA Evaluation 9.4.9 Bring-forward folders and content items and tasks when they are due to expire.

D

9.4.10

Automatically notify participants of deadline expirations or tasks overdue, according to user-specified criteria.

D

9.4.11 Allow a participant to notify others of tasks requiring their attention.

D

9.4.12 Define who is alerted at which steps in the workflow.

D

9.4.13 Define how users will receive workflow notifications.

D

9.4.14

Support notification both within and outside of the workflow environment.

D

9.4.15

Push notifications from the workflow process to an e-mail or other messaging function.

D

9.5 Save and Modify Workflow - Store and recall process maps and associated workflow tasks for subsequent retrieval, revision and output.

9.5.1 Save and select workflow templates or “process maps”.

D



141

The ABILITY to: Value Vendor Response GoA Evaluation 9.5.2 Save workflow instances separately from their process maps.

D

9.5.3 Delete a previously-saved process map if it has no associated content items.

D

9.5.4 Detect and report bottlenecks and support the ability to redirect content and tasks.

D

9.5.5

Forward content and tasks to others when participants are not available to do them, e.g. vacation or illness.

D

9.5.6

Allow only authorized individuals to override or change pre-defined workflows, and track these instances of exceptions.

D

9.5.7 Allow participants to stop a workflow item temporarily, i.e. to change the due date, and restart it from the point at which it was stopped.

D

9.5.8 Content or tasks to flow backwards for rerouting on disapproval or other conditions.

D

9.5.9

Customize workflow in order to meet changing business needs. Explain how changes with be

D



142

The ABILITY to: Value Vendor Response GoA Evaluation implemented for content that is already in progress.

9.5.10

Copy and modify workflows to create new ones. D

9.5.11 Retain process maps, but make them inaccessible for future use.

D

9.5.12 Remove process maps as long as there are no workflows that have used it.

D

Business and Technical Requirements – Manage Search and Browse


143

10. MANAGE SEARCH AND BROWSE

Description

To “Manage Search and Browse” is to establish and maintain functions that enable the ability to find, order, and retrieve content at all levels of aggregation, so that users can take action with it. EIM technologies must employ techniques to identify relevant content both when precise details about it are known, and when they are not. They must provide navigation facilities, as well as comprehensive, flexible search capabilities. All of this functionality must be subject to access and security provisions, so that users are never presented with content that they are not entitled to access.

Manage Search and Browse includes activities such as: • Configuring the search system architecture. • Defining search fields and search index parameters. • Setting up search system interfaces and search results presentation. • Defining search systems techniques and approaches (query processing algorithms). • Establishing options for using results of searches. • Providing options for configuring browse structures to enable navigation through predefined groups of content.

Manage Search and Retrieval must be closely integrated with Manage Metadata, Manage Content Use and Manage Users.



144

The ABILITY to: Value Vendor Response GoA Evaluation 10.0 MANAGE SEARCH AND BROWSE 10.1 Manage Search Architecture – Define the EIM components, repositories and content that the search system will search.

10.1.1

Search across one or more EIM components and repositories at one time, without users having to know where content is stored in order to retrieve it, i.e. a logically transparent interface. Please identify the search engine and version used and how this is integrated within the core EIM components.

D

10.1.2 Search all folders within an EIM component, i.e. within Document Management, Team Collaboration, Web Content Management, and Records Management repositories.

D

10.1.3 Search all types of content seamlessly within each EIM component, for example: • content items, lists, calendar items, tasks, etc. in

a Collaboration component; • electronic folders, hybrid folders and physical

folders in a Records Management component. • publications, templates, annotations and “sticky

notes” in a Web Content Management or Document Management component.

D

10.1.4 Search using full-text, metadata and controlled terminology approaches in an integrated and consistent manner.

D



145

The ABILITY to: Value Vendor Response GoA Evaluation 10.1.5 Search across content and metadata in online, nearline and offline repositories at one time.

D

10.1.6 Search the metadata of both electronic and hard copy content together.

D

10.1.7 Search dates using: • calendar dates; • numbers of days, months, etc.; and • other techniques.

D

10.1.8

Allow remote crawling of content by knowledge management tools such as automated taxonomy generators

10.2 Define Search Fields – Establish the metadata and content that will be indexed for search and retrieval in various indexes.

10.2.1 Specify any element of class, folder, volume and content item metadata as searchable.

D

10.2.2 Specify the full text of content items as searchable.

D



146

The ABILITY to: Value Vendor Response GoA Evaluation 10.2.3 Search for templates using pre-defined metadata assigned to the template, e.g. templates for a specific group or type of content, keyword, title, phrase, etc.

D

10.2.4 Search, retrieve and display folders by all implemented naming principles, including: • folder name (title); • folder identifier; and • associated category (classification) code.

D

10.2.5 Allow users to retrieve folders and content items directly by their unique identifiers.

D

10.3 Manage Indexing – Define how fields will be indexed and control the indexing process.

10.3.1 Support multiple indexes.

D

10.3.2 Browse and view indexes.

D

10.3.3

Allow the individual words in a field to be indexed as well as the entire value in a field as a unit or phrase.

D



147

The ABILITY to: Value Vendor Response GoA Evaluation 10.3.4 Maintain a viewable count of word and phrase occurrences

D

10.3.5 Support proximity searches.

D

10.3.6 Index the full text of content items.

D

10.3.7 Support recognition, indexing and retrieval of bar codes.

D

10.3.8 Require specified fields to be indexed.

D

10.3.9 Implement validity checking and/or table lookups during indexing.

D

10.3.10 Allow user control of the indexing process, including process reports, routing or assignment of batches, controlling indexing priority, etc.

D

10.3.11 Maintain the relationship between a source content item and its redacted version so that both are retrieved, but retain separate metadata and access controls over these items.

D



148

The ABILITY to: Value Vendor Response GoA Evaluation 10.3.12 Support indexing using sources of controlled terminology, for example a thesaurus database.

D

SEE ALSO Manage Content – Redact Content.

10.4 Manage Search Interface – Provide a variety of interfaces by which users can search EIM content repositories.

10.4.1 Support a range of search techniques users such as quick search and advanced search for experienced users, occasional users and novice.

D

10.4.2 Design customized search interfaces for specific types of content, business processes, etc.

D

10.4.3 Present the same interface, features and options whether searching classes, folders, volumes or content items.

D

10.4.4 Provide a command-line search interface as well as graphical screens.

D

10.4.5 Allow users to select query-processing algorithms, e.g. search exact phrases, all words, any words, etc.

D

10.4.6 Create sets of results with counts of terms retrieved.

D

10.4.7 D



149

The ABILITY to: Value Vendor Response GoA Evaluation Narrow or expand searches by modifying a current search statement without re-entering information.

10.4.8 Save, reuse and edit frequently-used and user-defined search queries.

D

10.4.9 Support user-controlled options for sorting and presenting search results.

D

10.4.10 Exclude from the list of search results any metadata or content for classes, folders, volumes and content items that the access restrictions are intended to prevent, such as access to intellectual property or personal information.

D

10.4.11 Calculate resource usage for various types of searches, or access to certain types of content, e.g. to restricted intellectual property, by certain users or groups, etc.

D

SEE ALSO Manage Content Access; Implement Technical Specifications – Integrate with Other Technologies.

10.5 Manage Query Processing – Provide a variety of techniques to match queries against indexes to retrieve search results.

10.5.1 Search across all indexes or only user-specified indexes in the course of a search.

D

10.5.2 Provide the following search techniques for both metadata and the full-text of content:

D



150

The ABILITY to: Value Vendor Response GoA Evaluation • individual words; • exact phrases; • full Boolean operators; • fuzzy matching; • truncation, both left and right; • wild card for one or more characters; and • proximity within a specified number of words,

within the same sentence, within the same paragraph.

10.5.3 Perform complex queries within user-acceptable response times.

D

10.5.4 Limit searches to specific fields or types of metadata.

D

10.5.5 Limit searches to specific groups of content items.

D

10.5.6 Define searches as content-specific or metadata-specific searches, or both together, i.e. search the full-text of content items and the other indexed values at the same time or separately.

D

10.5.7 Limit metadata searches to specific levels of aggregation, i.e. to classes, folders, volumes, and combinations.

D

10.5.8 D



151

The ABILITY to: Value Vendor Response GoA Evaluation Allow searches across all folders associated with a hierarchical content structure, or limit searches to one or more folders.

10.5.9

Thread together series of stored search actions, and series of stored browse (navigation) actions, to illustrate consecutive action steps and produce logs for review.

D

10.6 Display Search Results – Define the fields of metadata to be displayed about the items retrieved in searches, and multiple formats of displays.

10.6.1 Provide a design process for multiple displays and sort options.

D

10.6.2 Display the number of hits from a search and allow the user to display the search results, or refine the search criteria and do another search.

D

10.6.3 Choose full, partial or minimal metadata to be displayed with search results.

D

10.6.4 Select and display related content items from the set of search results.

D

10.6.5 If related content items cannot be displayed, provide contact information and an electronic contact method to request access to those items. E.g. for content items in hard copy, be able to send

D



152

The ABILITY to: Value Vendor Response GoA Evaluation a message to retrieve them.

10.6.6 Specify the number of results to be displayed on the screen per view from the search results.

D

10.6.7

Set the maximum number of hits for a search. D

10.6.8 Allow users to configure formats for display of search results, including: • selection of which metadata elements to

display; and • selection of the order in which the search

results are presented.

D

10.6.9 Support multiple levels of sorting for search results.

D

10.6.10 Rank search results by relevance.

D

10.7 Capture Search Results – Define how search results can be used.

10.7.1 Save the search results list as a content item within the EIM component.

D

10.7.2 Save the search results list as a content item in common office productivity formats.

D

10.7.3 Send the search results list in an electronic message.

D



153

The ABILITY to: Value Vendor Response GoA Evaluation 10.7.4 Print search results in user-specified formats.

D

10.7.5 Select specific results from the total results to output (save, send or print).

D

10.8 Manage Browse Structures – Define and maintain navigation paths in EIM components.

10.8.1

Ensure that graphical user interfaces support browsing and navigation of the content structures and folders, and the selection, retrieval and display of folders, volumes and their contents items.

D

10.8.2 Allow users to navigate forward, back, within and between folders, and to/from the metadata for folders and content items.

D

10.8.3 Ensure that graphical user interfaces provide browsing mechanisms and displays at both the class and folder level, capable of being used with the search techniques described above to view metadata for groups of folders and content items retrieved in search results.

D

10.8.4

Browse and display within an EIM component to find information about the next-higher level of aggregation when viewing or taking other actions on content without leaving or closing the item, for

D



154

The ABILITY to: Value Vendor Response GoA Evaluation example: • when reading a content item, the user must be

able to find its folder and volume; and • if viewing folder metadata, the user must be

able to find information about its related class.

10.8.5 Derive browse structures automatically from metadata and established content structures.

D

10.8.6 Develop and revise browse structures for specific business needs and map to content structures.

D


Business and Technical Requirements – Manage Reporting


155

11. MANAGE REPORTING

Description

To “Manage Reporting” is to control those activities that support the presentation of content and metadata in multiple, pre-defined and ad-hoc formats for various business purposes, such as in-depth user queries, management oversight, publishing activities, life cycle management activities, security validation or EIM system maintenance. Reports include output in both electronic and physical media, and displays as well as printed or other hard copy items.

Manage Reporting includes activities such as: • Defining standard, custom reporting and ad hoc reporting, for both online and hard copy output formats. • Selecting the content and metadata that are to be presented in reports for different business purposes. • Determining the order and structure of content items, their components and metadata in any display or other

report. • Establishing capabilities to save, modify and re-use reports. • Managing the processes of printing reports to paper or outputting them to any other physical medium. • Specifying the transactions that will be counted or tracked to produce statistics about a wide range of EIM

activities. Manage Reporting must be closely integrated with Publish Content and Manage Search and Browse.

Business and Technical Requirements – Administer EIM Repositories


156

The ABILITY to: Value Vendor Response GoA Evaluation 11.0 MANAGE REPORTING 11.1 Manage Reporting Capabilities - Manage the processes that enable the presentation of content in a variety of ways to

meet general and specific business requirements.

11.1.1 Display all components of content items in their original form, including their structure, i.e. their physical features and logical internal arrangement.

D

11.1.2 Display content items that a search has retrieved without loading the associated application software.

D

11.1.3 Display content in an external application if the EIM technology stores content in a proprietary format.

D

11.1.4 Provide viewing capabilities for content regardless of its native format.

D

11.1.5 View content items concurrently in multiple locations, regardless where those locations may be.

D

11.1.6 Integrate with third-party reporting tools such as Crystal Reports.

D

11.1.7 Schedule automatic periodic reports.

D



157

The ABILITY to: Value Vendor Response GoA Evaluation 11.1.8 Request ad-hoc reports at any time.

D

11.1.9 Restrict access to selected reports.

D

11.2 Track Content and Transactions - Specify the types of content, metadata and transactions that EIM components will count.

11.2.1 At any time, dynamically generate counts of user-specified metadata elements and content items, singly or in any combination, for example: • numbers of classes, folders, volumes and

content items; • numbers of content items with particular

statuses and dates; • numbers of transactions related to specific

folders, volumes and content items within a specific period of time; and

• numbers and types of actions by specific users.

D

11.2.2 Allow authorized individuals to define statistics to be tracked and reported from counts and maintained over specified time periods.

D

SEE ALSO Administer EIM Repositories – Capture Audit Information.

11.3 Define Displays and Reports - Provide flexible ways of displaying and printing content items and their metadata.



158

The ABILITY to: Value Vendor Response GoA Evaluation 11.3.1 Select, display and print metadata for any class, folder, volume or content item.

D

11.3.2 Select, display and print a list of content items consisting of user-specified metadata elements.

D

11.3.3 Display and print a content item with user-specified metadata.

D

11.3.4 Select, display and print some or all of the content items in a folder in one operation, in the sequence specified by the user.

D

11.3.5 Allow authorized individuals to define, modify and delete displays and reports.

D

11.3.6 Sort the order of retrieved items to be displayed or reported.

D

11.3.7 Sort the order of metadata elements to be displayed or reported.

D

11.3.8 Select and append metadata elements to displays or printed reports.

D



159

The ABILITY to: Value Vendor Response GoA Evaluation 11.3.9 Overlay headers, footers, watermarks, or special pagination across a group of displayed or printed content items.

D

SEE ALSO Manage Search and Browse; Administer EIM Repositories – Capture Audit Information.

11.4 Manage Hard Copy Reporting - Print content to paper or output it to another physical medium from EIM components.

11.4.1

Output at the application level, not simply using screen image dumps.

D

11.4.2 Output all components of content items ensuring the presentation of the layout produced by generating applications, including structure and all printable features.

D

11.4.3 Use any suitably-configured printer to produce all features.

D

11.4.4 Output content that cannot be “printed” to appropriate media, for example, to audio or video forms, web sites.

D

11.4.5 Output content to removable media and other offline storage devices.

D

11.4.6 Support high-volume printing; i.e. high-speed printing of text and images.

D



160

12.0 ADMINISTER EIM REPOSITORIES

Description

To “Administer EIM Repositories” is to establish, control and carry out activities that support the set up of content repositories, their overall performance and continuity of operations. It includes both initial configuration activities, as well ongoing revisions to repository parameters, monitoring and maintenance activities. EIM systems must be able to provide evidence of compliance to standards for integrity of their content. A key factor in meeting these requirements is monitoring system errors by maintaining a complete record of all the actions on content items and their metadata.

Administer EIM Repositories includes activities such as: • Establishing content repositories and identifying values, formats and business logic for content and processes; • Administering content repositories to assure access to information, integrity of content and optimal

performance of systems; • Maintaining storage media to meet access and volume demands; • Managing backup facilities to enable recovery from system failure; • Administering global change, processing and help capabilities; • Establishing reliable audit logs to consistently capture information about transactions; • Using audit log information to verify various types of transactions.

Administer EIM Repositories must be closely integrated with all other components in the Management Model.

Functional Requirements for EIM Technology – Administer EIM Repositories


161

The ABILITY to: Value Vendor Response GoA Evaluation 12.0 ADMINISTER EIM REPOSITORIES 12.1 Establish Content Repositories - Establish and identify electronic repositories for storing content and metadata, and

configure fields, business logic and processes.

12.1.1 Allow for user-defined repository names. Explain any restrictions.

D

12.1.2 Implement and maintain user-defined data elements (fields) that are clearly defined by data type and size.

D

12.1.3 Implement and maintain government and ministry default values for Vendor-supplied data fields. e.g. vital records categories

D

12.1.4 Accommodate all types of date fields, formats and associated business logic.

D

12.1.5 Design and revise interface screens for interaction with a repository, application, or selected set of content items and metadata.

D

SEE ALSO Manage Content Access; Manage Search and Browse – Search Interface

12.2 Administer Content Repositories - Add, delete, and update repository fields, values and processes, control access, monitor and assure the integrity of EIM components in all phases of the content life cycle.

12.2.1 Centrally administer repository management and user-related tasks.

D



162

The ABILITY to: Value Vendor Response GoA Evaluation 12.2.2 Centrally administer content access, with secondary security functions administered in a distributed way (e.g. business unit managers may assign supervisor roles to authorized individuals in their unit).

D

12.2.3 Demonstrate compliance with legal admissibility and security requirements.

D

12.2.4 Restrict management of repositories to authorized individuals.

D

12.2.5 Allow authorized individuals to change metadata, and delete content and metadata from repositories, for approved reasons following approved processes.

D

12.2.6 Track and automatically and/or manually update links and cross-references among content items in a repository” so that the accuracy of the links can be maintained.

D

SEE ALSO Manage Content; Manage Metadata.

12.3 Administer Storage Devices – Implement processes to allocate physical storage devices for online, nearline and offline retention of content and metadata, identify processing errors, monitor capacity and reallocate storage resources.

12.3.1 Monitor error rates occurring on storage media, and notify authorized individuals about any media or devices on which error rates exceed specified

D



163

The ABILITY to: Value Vendor Response GoA Evaluation parameters.

12.3.2 Automatically monitor available storage space, and notify authorized individuals when action is needed because available space is at a low level or because it needs other administrative attention.

D

12.3.3 Implement automatic and manual rules to identify and transfer folders and volumes as part of retention life cycle management.

D

12.3.4 Transfer to nearline and offline storage, selected groups of content items based on specified criteria.

D

12.3.5 Maintain an audit log of storage activities according to GoA policy, standards and requirements.

D

SEE ALSO Manage Content – Remove Content, Export and Transfer Content; Manage Official Records – Export and Transfer Records; Manage Metadata – Export and Transfer Metadata.

12.4 Administer Backup and Recovery - Implement processes to regularly copy repositories or specific sets of content to media which can be used to restore content, metadata and systems at the same or another location.

12.4.1 Implement automated procedures for scheduled backup of all or selected content, including classes, folders and volumes, content items, metadata and administrative attributes of any content and/or metadata repository.

D

12.4.2 Allow authorized individuals to schedule backup

D



164

The ABILITY to: Value Vendor Response GoA Evaluation routines by: • specifying the frequency of backup; • selecting classes, folders and volumes, or

content items to back up; and • allocating storage media, system or location for

the backup, such as off line storage, separate system, or remote site.

12.4.3 Allow the authorized individuals to restore from system backups.

D

12.4.4 Allow authorized individuals to recreate content and metadata using restored back-ups and audit logs.

D

12.4.5 Retain integrity of the EIM system, the content and the metadata during backup and recovery procedures.

D

12.4.6 Demonstrate that integrity is maintained during backup and recovery.

D

12.4.7 Notify users whose content and metadata may have been incompletely recovered, when they next use the system, that a potentially incomplete recovery has been executed.

D

12.4.8 Provide recovery and rollback facilities in the case

D



165

The ABILITY to: Value Vendor Response GoA Evaluation of system failure or update error, and notify authorized individuals of the results.

12.4.9 Select content and metadata to be restored. (SEE Vital Records)

D

12.5 Administer Global Change - Implement processes that enable changes to a range of content items and/or metadata at one time in one or more repositories.

12.5.1

Allow authorized individuals to make bulk changes to content structures and related metadata. i.e. changes to affected classes, folders, volumes and content items can be processed with a limited number of common transactions.

D

12.5.2

Enable the transfer or reallocation of content structures and/or classes to accommodate changes to services and organization units such as: • a new program / function; • movement or re-naming of a program,

organization unit or organization; • division of a program, an organization unit or

organization into two or more components; and

• combination of two or more programs, organization units or organizations into one.

D

12.5.3

When bulk changes are made to content structures, manage related content items such that:

D



166

The ABILITY to: Value Vendor Response GoA Evaluation • closed folders and volumes remain closed; • closed folders and volumes continue to be

allocated to classes in the content structure prior to the change;

• open folders and volumes can be closed and continue their allocation to classes in the content structure prior to the change;

• newly-closed folders and volumes are cross-referenced to appropriate classes in the revised content structure;

• open folders and volumes can be reallocated to classes in the revised content structure;

• folders and volumes that continue as open are cross-referenced to classes in the content structure prior to the change.

12.6 Administer Help - Implement multiple levels of online assistance within EIM components for various processes and groups of users.

12.6.1

Provide online Help for non-technical users. D

12.6.2

Provide online, context-sensitive Help for all system processes in all EIM components.

D

12.6.3

Provide multiple levels of Help such as content, field, window, application and system levels.

D

12.6.4

Allow authorized individuals to construct and revise customized Help for specific groups, content, metadata or actions using office

D



167

The ABILITY to: Value Vendor Response GoA Evaluation productivity tools. 12.6.5 Search Help text and metadata as well as navigate by browsing.

D

12.6.6

Re-use Help components. D

12.6.7 Implement traditional Help techniques, as well as error messages, wizards, cue cards, guided tours, mouse-over tool tips.

D

12.6.8 Support hypermedia such as hyperlinks and image maps.

D

12.6.9 Invoke Help through a common API.

D

12.6.10 Support internationalization.

D

12.6.11 Dynamically access business data, e.g. code tables.

D

12.6.12 Tightly integrate Help with the application distribution process and mechanism.

D

12.6.13 Support version control.

D

12.6.14 Support hyperlinks to documents external to the native Help system.

D

12.6.15 Support full multi-media capabilities, e.g. sound and video.

D

12.6.16 D



168

The ABILITY to: Value Vendor Response GoA Evaluation Configure auto-help settings.

12.7 Administer Processing - Set up and manage multiple input queues according to user-specified requirements.

12.7.1 Establish processing queues according to content type.

D

12.7.2

Establish and revise priorities for transactions in queues.

D

12.7.3

Allow authorized individuals to examine and control the folders and content items in queues.

D

12.8 Administer Audit Logs - Create electronic means of tracking interactions with content, and monitor transactions that affect them.

12.8.1

Create audit logs that are both human-readable and machine-readable.

D

12.8.2

Track changes to content, logging user and activity.D

12.8.3

Track transactions without manual intervention, and store specified information about them in the audit logs.

D

12.8.4

Allow authorized individuals to specify the transactions for which information is automatically stored in audit logs.

D



169


Maintain audit logs for as long as required, which will be at least for the life of the content items or folders to which they are linked.

D

12.8.6

Maintain audit logs that are unalterable, i.e. so that audit trail data cannot be modified in any way or deleted by any user.

D

12.8.7

Allow audit log data to be re-organized and exported without affecting the stored audit logs.

D

12.8.8

Ensure that audit log data is available for inspection on request.

D

12.8.9

Ensure that authorized individuals who have who have little or no familiarity with the EIM system can interpret the audit logs.

D

12.8.10

Ensure that a specific event can be identified and all related information made accessible.

D

12.8.11

Ensure that all metadata and audit trail data are handled correctly and completely at all times when bulk (global) changes are made.

D

12.9 Capture Audit Information - Store information in audit logs about transactions that affect or change content or metadata.

12.9.1 D



170

The ABILITY to: Value Vendor Response GoA Evaluation Store changes as transactions in sufficient detail to allow the reconstruction of a previous action.

12.9.2

Capture all changes made to administrative parameters, such as an authorized individual changing a user’s access rights, or specifying which transactions should be captured in audit logs.

D

12.9.3

Log events that affect all content structures, classes, folders, volumes and content items, and associated metadata.

D

12.9.4

Automatically capture at least the following information about specified events: • date and time of event; • type of event (see 12.9.5 for list of events) • subject and user identity • success or failure of the event; • system processes that caused the event.

D

12.9.5 Log at least the following specified events: • capture (registration) of all content items; • creation, amendment and deletion of metadata; • changes to metadata elements, attributes,

schemas and values; • creation, amendment and deletion of templates; • rendition of a content item; • redaction of a content item;

D



171

The ABILITY to: Value Vendor Response GoA Evaluation • all collaboration activities; • opening of new classes, folders and volumes,

and closure of existing ones; • reassignment of a content item to a different

volume; • reallocation of a folder within a content

structure; • the prior location and status of all classes,

folders, volumes or content items that are reallocated or reassigned;

• changes to linkages between classes and retention and disposition schedules and items;

• changes to the access privileges affecting folders, content items and users;

• export or transfer actions of content structures and folders;

• deletion/destruction actions on folders, volumes and content items;

• access violations, i.e. a user’s attempts to access a content item, volume or folder to which he or she is denied access, both successful and unsuccessful;

• the progress of a folder and/or content item through a workflow;

• changes to predetermined workflows; • changes to the metadata of physical or hybrid

boxes, folders, volumes and content items; • actions and decisions made during records

reviews; • all export, transfer and disposition actions; • all check-out and check-in transactions (in an



172

The ABILITY to: Value Vendor Response GoA Evaluation audit log or separate “circulation” function as appropriate);

• changes in location and movement of content, both electronic and physical;

• all search and search save transactions; • all browse (navigation) transactions; and • all display and other reporting transactions. SEE ALSO Manage EIM Repositories – Perform Audits and Assessments; Manage Reporting – Track Content and Transactions.

12.10 Perform Audits and Assessments – Determine whether breaches of security have occurred, and whether actions upon content adhere to established business rules and are carried out by those authorized to do so.

12.10.1

Allow authorized individuals to set up and revise automatic processes to collect information required for security audits and other evaluations, e.g. sampling mechanisms.

D

12.10.2

Allow authorized individuals to specify which content security categories and types of transactions generate automatic warnings and notifications.

D

12.10.3

Send automatic warnings and notifications to authorized individuals in real-time.

D

12.10.4

Analyze unauthorized attempts to access classes, folders, volumes or content items.

D

12.10.5

Analyze access to physical folders and volumes, D



173

The ABILITY to: Value Vendor Response GoA Evaluation including controls based on content security categories comparable to those for electronic content.

12.10.6

Analyze all disposition actions, i.e. removing content from a repository.

D

12.10.7

Analyze the assignment of security categories to content items.

D

12.10.8

Analyze: • the assignment of content items to folders; • the allocation of folder to classes in content

structures; and • actions performed on content structures.

D

12.10.9

Analyze the association of schedule items with classes in content structures.

D

12.10.10

Analyze unauthorized attempts to define, change and delete content structures, classes, folders, volumes and content items.

D

12.10.11

Verify that access, review, export, transfer, and disposition transactions follow established rules and requirements.

D



174


Analyze information about the workflow and content items.

D

12.10.13

Analyze routed content for business process engineering purposes.

D

Business and Technical Requirements – Implement Technical Specifications


175

13. IMPLEMENT TECHNICAL SPECIFICATIONS

Description The following requirements must be closely integrated with the Mandatory Requirements, with Administer EIM Repositories (section 12) and with GAEA Architectural Requirements (section 14).

The ABILITY to: Value Vendor Response GoA Evaluation 13.0 IMPLEMENT TECHNICAL SPECIFICATIONS 13.1 Ensure EIM Core Capabilities - Implement functionality and parameters for EIM technologies, in accordance with GoA

and ministry-specific technology and information management requirements.

13.1.1

Manage all electronic content regardless of the method of encoding or other technological characteristics. SEE ALSO Capture Content – Define Content.

D

13.1.2

Ensure access to the electronic content, including the ability to render it, and including maintenance of its structure and format, over time and through generations of office productivity software. SEE ALSO Manage Content – Transform Content.

D

13.1.3

Ensure backward compatibility, that EIM components can correctly accept and process content from earlier versions without loss of integrity.

D



176


Maintain internal integrity of an EIM component and its repositories at all times, regardless of: • maintenance activities; • user actions; and • failure of software or other system

components.

D

13.1.5

Handle content items that are constructed of more than one component so that: • content items remain as single indivisible items,

retaining the relationships between the components;

• the structural integrity of content items is retained;

• integrated retrieval, display, and management is supported; and

• disposition of all components of the content item can be managed as a whole unit , i.e. in one operation.

D

13.1.6

From any EIM component, provide full access to content allocated to folders in other EIM components and office productivity tools, in addition to content unique to a particular EIM component.

D



177


Store large volumes of content and handle a large number of concurrent users, allowing for: • content growth rates of 10% or more per year;

and • growth in number of users.

D

13.1.8

Access all EIM components via the GoA standard web browser interface.

D

13.1.9

Support government-supported browsers such as Netscape.

D

13.1.10

Provide authorized individuals with secured 24/7 access to the content repositories. SEE ALSO Manage Content Access; Implement Technical Specifications – Remote Access Requirements.

D

13.1.11

Demonstrate current leadership in the EIM technology environment and a commitment to ongoing leadership, through relevant recent product evaluation citations by key industry associations and/or by major IT industry research experts such as Gartner, Forrester, Metagroup or the equivalent

D

13.2 Integrate with Other Technologies - Capture content from, access content in, carry out transactions in, and output content to, repositories in non-EIM technology components.



178


Use custom API’s and other methods to integrate with other GoA business applications that generate content, including: • other document management, web content

management, and records management systems and repositories;

• groupware publishing systems; • workflow systems, such as correspondence and

Action Request tracking systems; • enterprise project management tools; • case management systems; • e-mail systems, to allow notification and

receipt of reports without having to login to the EIM components and; and

• corporate and ministry databases. SEE ALSO Mandatory Requirements (M16); Capture Content - Define Content; Manage Workflow – Define Tasks.

D

13.2.2

Integrate with industry-leading scanning, optical character recognition (OCR) and intelligent character recognition (ICR) systems to enable: • the import of imaged content into EIM

repositories, and • the access to and use of imaged content stored

in other non-EIM systems and repositories. SEE ALSO Mandatory Requirements (M14) and Capture Content – Received Imaged Content.

D



179


At the desktop, switch easily between the EIM components and non-EIM applications.

D

13.2.4

Integrate business applications with the EIM components to carry out transactions, including, but not limited to: • EIM workflows can be triggered by receipt of

data from applications; • EIM components can send instructions to

application databases, e.g. to update specific data when an approval is received in the EIM component;

• folders, volumes and content items can be added to a content repository based on activity in the application; and

• metadata in a content repository can be changed, e.g. status and date, based on activity in an application.

SEE ALSO Manage Workflow.

D

13.2.5

Have EIM components process transactions generated by other business applications in real time.

D

13.2.6

Integrate with industry-leading web portal products to provide access to EIM components from a portal level, so that a user can launch any EIM

D



180

The ABILITY to: Value Vendor Response GoA Evaluation functionality from within a portal environment.

13.2.7

Publish content from EIM components to portals. SEE ALSO Publish Content

D

13.2.8

Demonstrate commitment to adoption of industry portal standards and a long-term portal strategy.

D

13.2.9

Implement end-user interfaces for EIM components that are convenient to navigate, and consistent in appearance to the Microsoft Windows and Web browser desktops. SEE ALSO Manage Search and Browse – Manage Search Interface, and – Manage Browse Structures.

D

13.2.10

Allow different end-user interfaces based on roles of different types of users, e.g. program support, senior executive, service delivery, system administrator, etc. SEE ALSO Manage Search and Browse – Manage Search Interface, and – Manage Browse Structures.

D

13.3 Remote Access Requirements – Allow users to interact with content and metadata in EIM technology components at locations other that their desktops. SEE ALSO Manage Content Access, and GAEA Requirements (Section 14)



181


Download a collection of content items from an EIM component to a portable computer for review and printing at a remote location not connected to the network.

D

13.3.2

Work on content both locally and remotely then synchronize modified content to the content repository.

D

13.3.3

Work on common content types directly across the web without having to download a local copy.

D

13.3.4

Search across multiple repositories located both locally and remotely.

D

13.3.5 The proposed Software must be remotely accessible through the GoA’s CITRIX access node.

D

Business and Technical Requirements – GAEA Architectural Requirements


182

14. GAEA ARCHITECTURAL REQUIREMENTS

Description The EIM RFP will provide the GoA with the ability to create ICT assets or ICT solutions. (See section 2.1 of the RFP for definitions of these terms, and Appendix C for an overview of GAEA.) These assets and solutions will result from the follow-on projects that ministries will launch, making use of the integrated EIM Software selected for standing offer by this RFP. These future ICT assets and solutions should be aligned as closely as possible with GAEA principles and architectural requirements when initially created. The EIM Software should allow the GoA to evolve these ICT assets and solutions towards increasing levels of GAEA-compliance, as they are developed and enhanced over time. The GoA will evaluate Vendor responses to section 14 to determine the extent to which each proposal makes this possible. The following table highlights two important GAEA concepts:

• Band 1, Band 2 and Band 3 ICT Assets and Solutions • GAEA Principles and Architecture Requirements

NOTE: See Appendix C, section C1, for instructions to access the GoA SHARP web site for items marked *.

“BAND 1”, “BAND 2”, “BAND 3” ICT ASSETS AND SOLUTIONS: What is it? These are the three fundamental ways to design / deploy an ICT asset.

A quick look: Band 1 is “do it corporately”. Band 2 is “do it departmentally, but consistently”. Band 3 is “do it in several differing ways”

Details: See the definitions in the RFP section 2.1.

Relevance to the EIM Project

When ministries physically create and manage content-related ICT assets, they will have to decide whether the assets are Band 1, 2 or 3 assets in each of several decision-making domains: Business Architecture, Data Architecture, Application Architecture, Technology and Security Architecture, Privacy Architecture. Regardless of domain, general principles apply: • Band 1 is more desirable than Band 2. • Band 2 is more desirable than Band 3. • Ability to migrate from a Band 3 or 2 deployment toward a Band 2 or 1 deployment, if the GoA chooses to



183

do so, is very desirable.

ARCHITECTURE REQUIREMENTS AND PRINCIPLES: What is it? Based on an exhaustive analysis of the corporate ICT Strategy, 18 GAEA Architecture Requirements and 43

GAEA Principles were defined and approved. These establish fundamental rules to guide IT designs and decisions. They convey the “spirit” of the strategy and what enterprise architecture must do to be successful.

A quick look: See Appendix C, section C1, document number: • I2. GAEA One Page Summary of the GAEA Architecture Requirements and Principles (GAEA V2.1)*

Details: See Appendix C, section C1, document numbers: • G&H. GAEA Business Drivers and Architecture Requirements (GAEA V2.1)* • I1. GAEA Architecture Principles (GAEA V2.1)*

Relevance to the EIM Project

The GAEA principles of Accessibility and Integration are particularly important, as described in Appendix B. The other GAEA Principles and Requirements are also relevant and desirable.

The following tables address the specific domains for which ministries must make decisions about alignment of their ICT assets and solutions that will support their Electronic Information Management (EIM) activities. These domains are:

• Business Architecture • Data Architecture • Application Architecture • Technology and Security Architecture, and • Privacy Architecture.



184

14.1 GAEA BUSINESS ARCHITECTURE - BACKGROUND

What is it? The GAEA Business Architecture defined 106 common, stable, business activities that are performed by most or all departments. These are potential target areas both for consistency of cross-government business process, and for sharing the supporting technology assets.

A quick look: Business Activities * (i.e. what is done) User Groups * (i.e. who does it) Locations *(i.e. where it is done)

Details: See Appendix C, section C1, document:: • M1. GAEA Business Architecture (GAEA V2.1) *

Relevance to the EIM Project:

From the GAEA perspective, the EIM Software Selection Project aims to provide comprehensive, integrated ICT software that ministries can use to support the business activity called: “MANAGE INFORMATION”

For the purpose of responding to this RFP, assume that in the Business Architecture in document M1, “the activity, MANAGE INFORMATION has the following sub-activities that are described in the “Management Model” of Appendix B and in the Business and Technical Requirements in Appendix D:

1. Capture Content 2. Manage Collaboration 3. Manage Content 4. Organize Content 5. Publish Content 6. Manage Official Records 7. Manage Metadata 8. Manage Content Access 9. Manage Workflow 10. Manage Search And Browse 11. Manage Reporting 12. Administer EIM Repositories 13. Implement Technical Specifications



185

Architecturally, it has not yet been determined which sub-activities need to be performed by which User Groups and at which Locations. For now, assume that all User Groups, with the exception of “Customer”, and all Locations may apply. When sub-activities are selected and put together in sequences, as illustrated in Section 8, the Business Scenarios section, of document number M1, and assigned to staff to perform as a business process, then the Band 1, Band 2, Band 3 decisions must be made:

• If Band 1, then a single organizational unit will do the work for that sub activity, regardless of the department(s) for which the work is being done.

• If Band 2, then departmentally – but in a consistent, reusable, defined way. If Band 3, then departments will use different business processes, but all based to some extent on the GAEA-defined activities and sub-activities, thereby achieving some limited degree of commonality.

14.1 GAEA Business Architecture Value Vendor Response GoA Evaluation

Explain how the proposed Software supports the following aspects of the GAEA Business Architecture:

14.1.1 – Aspect: Business Model

How, and to what extent, will the proposed Software enables the “MANAGE INFORMATION” activity and its sub-activities to be performed by all the GAEA User Groups, according to their roles, at all of the GAEA locations?

D

14.1.2 – Aspect: Toward Corporate Process

How, and to what extent, will the proposed Software enable the GoA to move business processes from Band 3 towards Band 2 and from Band 2 towards Band 1 as described under “Relevance to the EIM Project”?

D

14.1.3 – Aspect: Toward Corporate Process

If your proposed Software was one of the integrated EIM suites selected to deploy, what could the GoA do as indicated in 14.1.2 in the future, if it chose to do so?

D



186

14.2 GAEA DATA ARCHITECTURE - BACKGROUND

What is it? The GAEA Data Architecture defined 73 areas where establishing consistency and share-ability in the Alberta government’s data would make the most business sense, from both a logical and physical perspective. It also determined which data should best reside in departmental databases and which data should reside in centralized shared databases.

A quick look: Data Subject Areas * Physical Data Stores *

Details: See Appendix C, section C1, document:: • N1. GAEA Data Architecture (GAEA V2.1)*


For the purpose of responding to this RFP, “CONTENT”, is the “information that is not stored in rows and columns in corporate and ministry databases” as described in Appendix B, section 1.3. Assume that “CONTENT” has been thus defined architecturally in document N1 under the high level GAEA subject area “ADMINISTRATIVE RESOURCE”. It is, in fact, already reflected to some extent in the existing GAEA sub-headings “INFORMATION” and/or “KNOWLEDGE”. Similarly, assume that the repositories in which content will be housed have also been defined as GAEA physical data stores in document N1.

14.2 GAEA Data Architecture Value Vendor Response GoA Evaluation

Explain how the proposed Software supports the following aspects of the GAEA Data Architecture:

14.2.1 – Aspect: Logical Data Model

Will some aspects of the CONTENT, e.g. the associated metadata, be stored in rows and columns in a database? If so, confirm that the proposed solution has a Logical Data Model (LDM).

D

14.2.2 – Aspect: Logical Data Model

Indicate whether, upon purchase of the software, the GoA will receive a copy of the LDM.

D



187

14.2.3 – Aspect: Toward Corporate Model

Will the GoA be able to add the LDM to the GAEA LDM to help evolve toward a corporate LDM that supports the 18 GAEA Architecture Requirements?

D

14.2.4 – Aspect: Toward Corporate Data

How, and to what extent, will the proposed Software enable the GoA to move CONTENT repositories that ministries will create in their EIM projects towards Band 2 and ultimately Band 1, if and it chooses to do so?

D



188

14.3 GAEA APPLICATION ARCHITECTURE - BACKGROUND

What is it? The GAEA Application Architecture defined 69 areas where common, shared assets would make the most business sense, either entire applications or at least certain application components. Many standards and recommendations were defined about how applications should be constructed in the future to reap the most cost-effectiveness and service-delivery benefits. Examples are: application structure, tiers, application design model, component model, programming model, object-oriented paradigm, methodology, development tools and standards, organization roles, and skills.

A quick look: Application Groups *

Details: See Appendix C, section C1, document:: • O1. GAEA Application Architecture (GAEA V2.1)*


If the proposed Software meets the general need to perform the activities described in section 14.1 for all the types of content described in section 14.2, then from the architecture perspective the software would be expected to provide application building blocks for creating the GAEA Application Group:

“MANAGE INFORMATION”, includes Metadata Management, Records Management, plus likely others, not yet identified and defined in GAEA.

These application building blocks might also be used with others, perhaps custom applications built by the GoA or off-the-shelf software, to implement other GAEA Application Groups, such as: “MANAGE COLLABORATION”, GOVERNANCE MANAGEMENT”, etc. Thus, the proposed software should, if possible, adhere to the GAEA standards and recommendations about how applications should be constructed. The proposed software might be a “black box”, for which the GoA is only provided with the ability to invoke and interface to it. In this case, the GoA would essentially be acquiring technology architecture building blocks, with a view to leveraging them as application solutions.



189

14.3 GAEA Application Architecture Value Vendor Response GoA Evaluation

Explain how the proposed Software supports the following aspects of the GAEA Application Architecture:

14.3.1 – Aspect: Building Blocks

How, and to what extent, will the proposed Software enable a “building block”-based implementation of: • the application components of the GAEA

“MANAGE INFORMATION” Application Group;

• other GAEA Application Groups?

D

14.3.2 – Aspect: Building Blocks How, and to what extent, will the proposed solution enable the GoA to move future instances of the application building blocks that will be created towards Band 2 and ultimately Band 1, if and when it chooses to do so?

D

14.3.3 – Aspect: Black Box Indicate to what extent the proposed solution is a “black box”.

D

14.3.4 – Aspect: Black Box Please describe the process by which the GoA can submit requests for desired features for consideration in future releases to increase the level of software compliance with GAEA Application Architecture requirements, such as application structure, tiers, design model, component model, programming model and object-oriented paradigm.

D



190

14.4 GAEA TECHNOLOGY AND SECURITY ARCHITECTURES - BACKGROUND What is it? In the GAEA Technology Architecture, detailed designs were defined for these high level patterns of electronic service

delivery: 1. Government to Public (G2P) 2. Government to External (G2X) – person 3. Government to External (G2X) – machine 4. Government to Internal (G2I) 5. Business Intelligence (BI).

The designs in these patterns are created from building blocks, i.e. the GAEA-defined nodes. The nodes are created from even smaller components. The Technology Architecture is built on the design guidance in the GAEA Security Architecture, which enhances support for GoA security strategies, policies and objectives such as the use of Security Zones, Enterprise Threat and Risk Assessment, and leverage of published industry standards and models including Security Structure.

A quick look: Nodes* Components* Patterns*

Details: See Appendix C, section C1, documents: • P1. GAEA Technology Architecture - Main (GAEA V2.1) * • P2. GAEA Technology Architecture - Components (GAEA V2.1) * • P3. GAEA Technology Architecture - Nodes (GAEA V2.1) * • Q1. GAEA Security Architecture (GAEA V2.1) *


For each GAEA Component, the proposed Software will either: • be able to IMPLEMENT the component; • not implement, but nonetheless be able to USE this component; • have NO DIRECT DEPENDENCY.



191

14.4 GAEA Technology and Security

Architecture Value Vendor Response GoA Evaluation

Explain how the proposed Software supports the following aspects of the GAEA Technology and Security Architecture:

14.4.1 – Aspect: Building Blocks How, and to what extent, will the proposed Software enable a “building block” basis for creation of the GAEA components: Collaboration Services, (Web) Content Management Services, Document Management Services, Workflow Management Services, and Internationalization Services, and do so in a way that supports the 18 GAEA Architecture Requirements?.

D

14.4.2 – Aspect: Building Blocks

Indicate if there are any other GAEA components that are part of the proposed Software.

D

14.4.3 – Aspect: Toward Corporate Infrastructure The follow-on projects that will be launched by the Ministries will make use of the integrated EIM Software selected by this RFP. How and to what extent will the proposed Software enable the GoA to move these technology building blocks towards Band 2 and ultimately Band 1,if and when it chooses to do so?

D

14.4.4 – Aspect: Toward Corporate Infrastructure How and to what extent will the proposed Software be able to use or interoperate with other GAEA components when they are implemented at a GoA corporate level, such as: • Security Services (Note: a corporate

authentication solution is being implemented); • Base Platform Services, Infrastructure Services,

Relational Database Services, etc.; and • Presentation Services (Note: alternative access

D



192

mechanisms beyond CITRIX are desirable.).

14.5 GAEA PRIVACY ARCHITECTURE - BACKGROUND What is it? The GAEA Privacy Architecture includes a Privacy Glossary, Privacy Taxonomy; and an Identity Key Scheme, which

provides a simple way for personal information to be decomposed into separately accessible pieces that align with the minimum personal information needs of various users. Some of these keys are used to define “islands” where personal information is normally shared (e.g. within a Program) and others define “bridges” to selectively allow islands to exchange or share personal information without revealing their own keys to each other.

A quick look: None. Details: See Appendix C, section C1, documents:

• R1. GAEA Privacy Architecture (GAEA V2.1) * • R2. GAEA Privacy Architecture - Overview Report (GAEA V2.1) * • R3. GAEA Privacy Architecture - Privacy Glossary (GAEA V2.1) *


The privacy taxonomy is relevant for the proposed Software, because it defines the general structure of metadata describing personal information in the Government of Alberta. Other features of the privacy architecture may be less applicable to the proposed solution, because they are primarily intended for use with structured information stored in database formats, which is out of scope. However, where it is possible to separately manage personal information data elements in otherwise unstructured data files, the privacy architecture will be relevant.

14.5 GAEA Privacy Architecture Value Vendor Response GoA Evaluation

Explain how the proposed solution supports the GAEA Privacy Architecture:

14.5.1 The ability to separately identify, store and manipulate personal information data elements, such as through the use of metadata elements.

D

Appendix E – Metadata Requirements


193

APPENDIX E – Metadata Requirements The GoA Recordkeeping Metadata Elements and the GoA Web Content Metadata Elements are draft sets of requirements that should apply to content and transactions conducted in EIM environments that manage Official Records and Web Content respectively. These requirements are still under development, and are subject to change. They are not yet approved government standards; however, they are being developed based upon best practices in other jurisdictions. These requirements are mapped to the Dublin Core (DC) Basic Elements as defined in the ISO standard, ISO 15836:2003(E), “Information and documentation – The Dublin Core metadata element set”, as well as to each other. For example, the web content metadata element “Title” is equivalent to the recordkeeping metadata sub-element “Official Title” (#1.01), and both map to the Dublin Core element, “Title” (#1.) Mandatory recordkeeping and web content metadata elements and sub-elements are bolded. With respect to the recordkeeping requirements, where an element has sub-elements, the metadata would be captured and managed at a sub-element level. Also, if an element is “Optional”, but an organization chooses to implement it, then some of its related sub-elements are “Mandatory.” /M = Mandatory element or sub-element /R = Highly recommended element or sub-element /O = Optional element or sub-element NOTE: Many of these metadata elements and sub-elements would also apply to the retrieval and management of content in EIM document management and collaboration components.

DC Basic Elements

GOA Recordkeeping Metadata Elements and Sub-elements (DRAFT) GOA Web Content Metadata Elements (DRAFT)

1 Title /M: Name of a record or group of records.

1.01 Official Title /M: Name by which a record or record group is officially known. Title /M: A name given to the resource.

1. Title

1.02 Other Title /O: An additional name for a record or group

2 Agent /M: The person/s, organization unit/s, or organization/s, responsible for creating the content of a record or group of records, or with responsibility for actions related to it.

2.01 Agent Type /M: Category that defines the role and responsibilities of individual Agents.

2. Creator

2.02 Organization Name /M: Name of an Agent’s organization Creator /M: Identifies the person, work group or organization with responsibility for a resource.



194

DC Basic Elements


2.03 Organization ID /O: Identifier assigned to an Agent’s organization agency.

2.04 Person Name /O: Name of an individual Agent who performs some action.

Creator /M: Identifies the person, work group or organization with responsibility for a resource.

2.05 Person ID /O: Identifier assigned to an individual Agent who performs some action.

2.06

Organization Unit /O: Name of the business section responsible for an action on a record or group of records; the name of the business section within which an individual Agent responsible for records actions works.


2.07 Position Name /O: Title of a position responsible for records actions.


2.08 Contact Details /O: Information on how to contact an individual Agent.

2.09 Digital Signature /O: An encrypted, tamper-proof piece of data that creates a unique and un-forgeable identifier for an Agent.

2.10 Jurisdiction Type /O: The type of jurisdiction in which an Agent operates, i.e. the legislated or administrative jurisdiction, not a geographical area.

3 Subject /M: The topic of the content of a record or group of records.

3.01 First Subject /M: The first topic of a record. Subject /M: Identifies the subject or topic of a resource.

3. Subject

3.02 Other Subject /O: A topic of a record that adds refinement or enhancement to the first subject term.

4. Description

4 Description /M: An account of the content and/or purpose of a record or group of records.

Description /M: An account of the content or purpose of the resource.

5. Publisher

See 2.01

See Agent Type: The entity responsible for making a record available.

Publisher /O: An entity responsible for making the resource available.



195

DC Basic Elements


6. Contributor

See 2.01

See Agent Type: An entity responsible for making a contribution to the content of a record. Contributor /O:

5 Date: The date and time when records or created or are involved in transactions.

Date /M: A date associated with an event in the life cycle of the resource.

5.01 • Date Created /M: The date and time that a record or group

of records is created by an organizational unit in the course of its business.

Date Created /M: Date resource published on the web.

5.02 Other Date /O: The date and time at which other significant events take place that are not captured under Management History, Use History or Preservation History.

Date Last Revised /M: Date last changed on the web.

7. Date

5.03 Other Date Description /O: Descriptive information about the event whose date/time of occurrence is captured under 5.02, Other Date.

8. Type

13 Type /O: The recognized form or genre of a record or group of records which governs its internal structure. Type /R: The nature or genre of the document or resource.

15 Format /R: The logical form and physical form of a record.

15.01 Content Medium /M: The generic format of the information comprising the record. (Logical)

Format /O: The physical or digital manifestation of the resource.

15.02 Data Format /M: The format of the data that comprises a record, usually denoted by its file extension, often proprietary. (Logical)

Format /O: The physical or digital manifestation of the resource

15.03 Storage Medium /M: The type of device on which a record is physically stored. (Physical)

Format /O: The physical or digital manifestation of the resource

9. Format

15.04 Extent /O: Physical size of a record. (Physical) Format /O: The physical or digital manifestation of the resource

10. Identifier

16 Record Identifier /M: An unambiguous reference to record or group of records.

Identifier /O: An unambiguous reference to the document or resource.

11. Source

NA Source /O: A reference to a resource from which the present resource is derived.

12. 6 Language /O: The language of the content of a record. Language /M: The language of the intellectual content of the



196

DC Basic Elements


Language resource.

10 Relation /O: A link between records, between aggregations of records, or between a record and another information resource.

10.01 • Related Item ID /M: A unique identifier for a related record or information resource.

Relation /O

10.02

• Relation Type /M: A category of relationship between records or groups of records at the same or different levels of aggregation, or between records and other information resources.

13. Relation

10.03 • Relation Description /O: Information about the relationship

not explicit or obvious in Relation Type. Further explanatory notes or details about the relationship.

11 Coverage /O: The jurisdictional, spatial, and/or temporal characteristics of the content of a record.

11.01 • Coverage Type /M: The type of place or period, including

jurisdiction, covered by and/or discussed in the content of a record.

14. Coverage

11.02 • Coverage Name /O: Names of locations, regions,

geographical areas and/or time periods covered by and/or discussed in the content of a record.

Coverage /O

15. Rights

Rights /O: Information about rights held in and over the resource.

No DC Element 7

Management History /M: The dates and descriptions of all records management actions performed on a record or group of records from its registration until its disposal.

7.01 • Event Date/Time /M: The date and time at which a defined management event occurs.

7.02 • Event Type /M: An event that relates to the management or control of a record or group of records.



197

DC Basic Elements


7.03

• Event Description /M: The specific details of an event, including information about the original status, the changes made to it, the reasons for the changes, and authorization for the changes.

No DC Element 8

Use History /O: The dates and descriptions of both legal and illegal attempts to access and use a record, from the time of its registration until its disposal.

8.01 • Use Date/Time /M: The date and time at which a defined use of or access to a record occurs.

8.02 • Use Type / M: An event that relates to the access or use made of a record.

8.03

• Use Description /O: Details of an event, such as information about where a record was downloaded to, the name and location of the record to which the contents were downloaded, and the specific nature of any illegal action or security breach.

No DC Element 9 Access Management /M: Legislation and policies that govern or

restrict access to or use of records.

9.01 • Security Classification /M: A means of classifying records based on their content.

9.02 • Other Access Condition /M: An access condition in addition to, or in exception to FOIP.

9.03

• Usage Condition /O: An indication that some kind of limitation or restriction has been placed on how a record or group of records may be used by individual Agents or by the public.

9.04 • Encryption Details /O: Information or pointers to information about how a record has been encrypted.

No DC Element 12 Function /O: The general or organization-specific business

function(s) and activities that are documented by a record.

No DC Element 14

Aggregation Level /M: The level at which a record or group of records is described and controlled. The level of aggregation of the unit of description.



198

DC Basic Elements


No DC Element

17

Preservation History /O: The dates and descriptions of all actions performed on a record after its registration into a recordkeeping system that ensure the record remains readable (renderable) and accessible for as long as it has value to the agency and to the community at large.

17.01 • Action Date/Time /M: The date and time at which a defined preservation action on a record takes place.

17.02 • Action Type /M: A preservation action carried out on a record.

17.03 • Action Description /M: The specific details of an action.

17.04 • Next Action /O: The next preservation action that a record needs to undergo

17.05 • Next Action Due Date /O: The date that the next preservation action is due.

18 Location /M: The current physical or system location of a record. Details about the location where the record usually resides.

18.01

• Primary Location Details /M: The name and address of the organization, organization unit, or individual Agent where a record is normally stored. (DIRECTORY??)

18.02

• Primary Location Details /M: Information about a record’s specific storage location and any special conditions under which it is stored.

18.03 • Current Location /M: The current physical or system location of a record.

18.04

• Recordkeeping System /O: Identification of the organization recordkeeping system of which a record is a part or in which a record is stored.

No DC Element 19

Disposition /M: Information about policies and conditions that pertain to or control the authorized disposition of records. Information about the current retention schedule and dispition actions to which the record is subject.



199

DC Basic Elements


19.01

• Retention Schedule/Item Number /M: Legal documentation issued that authorizes the disposition of records.

19.02 • Retention Period /M: The length of time the record needs to be kept.

19.03 • Disposition Action /M: The action taken on a record once the end of its retention period is reached.

19.04 • Disposition Due Date /M: The date that a record is due for a disposition action.

No DC Element

20

Mandate /O: A source of recordkeeping requirements. For example, a piece of legislation, formal directive, policy, standard, guideline, set of procedures, or community expectation which (explicitly or implicitly) imposes a requirement to create, keep, dispose of, or control access to and use of a record.

20.01 • Mandate Type /M: The type of resource that explicitly or implicitly contains the requirement or mandate.

20.02 • Refers To /M: The type of recordkeeping activity to which the mandate, explicitly or implicitly, refers.

20.03

• Mandate Name /M: The name of the resource that contains the requirement or mandate relating to a record, or a link to the resource.

20.04

• Mandate Reference /O: The actual reference (numeric, paragraph, etc) within the resource or link which details the requirement or mandate.

20.05

• Requirement /O: Either a direct quote or a link to a quote of any explicit or implicit requirement or mandate contained in the source, or a description of the requirement itself.

Appendix F – Pricing Form


200

APPENDIX F - Pricing Form The Vendor must provide a total price for the proposed suite of EIM Software products and the associated pricing components for the entire period of the Contract as stipulated in M5 of APPENDIX D – Project Software Summary Form. The price of the proposed Software will be evaluated in Canadian dollars, excluding Goods and Services Tax (GST) and Harmonized Sales Tax (HST). All charges related to delivery to destination, customs duties and excise taxes, freight and packaging charges, living and traveling expenses, if applicable, are to be included in the price of the proposed Software. The costs must be for all components of the integrated suite of EIM Software products from a single Manufacturer, which meets GoA’s needs (target environments, mandatory requirements, and desirable requirements), as outlined in this RFP. Although it is not possible to accurately estimate the total users of a particular suite of EIM Software product or complete package of Software products at this time, Vendors are encouraged to price their proposed Software based on the potential of implementing the Software within multiple GoA departments of various sizes through the period of the Contract. As a point of reference, currently there are approximately 25,000 employees in the GoA.

Proposed Pricing Model GoA recognizes that there are currently a variety of different pricing models and approaches that many Vendors have adopted in order to provide competitive pricing to potential customers. Some examples of these pricing strategies may include:

• Enterprise Licencing;

• CPU tier or MIPS;

• Site or CPU-specific by model or serial number;

• Per user;

• Per server;

• Per Number of concurrent Users;

• Combination of any of the above; or

• Tiered by number of Users.

Because the scope of this RFP focuses on developing cross-government standards for Electronic Information Management software, it is the GoA’s intent to enter into enterprise-wide Standing Offer Licencing agreements with the preferred Vendors.

As stated in 4.1.7 Anticipated Hardware Platform, the GoA will also be implementing two other non-production support environments that will allow for Upgrade Preparation along with training and testing functions. The GoA requires that the Vendor’s proposed licensing and pricing structure incorporate these separate, but important environments as well.

The Vendor must also list in the Pricing Form, if applicable, any other pricing model options that are available to the GoA.



201

1. Pricing Form

Using the Pricing Form below as a framework, list all Software included in the proposal, provide a description for the proposed Software, and the proposed cost

The GoA also requires pricing costs for maintenance and systems support included in the Proposal. All of the listed Software in this Proposal must be included. Further details can be found in APPENDIX D – Mandatory Requirements in item M9.

Pricing Form Section 1: Detailed pricing for the primary Software on an individual basis. These products

comprise the mandatory core components of the EIM suite of Software products that must be supported by a single manufacturer.

Section 2: Detailed pricing for Associated Software required. This may include third-party software that is required to support the mandatory or desirable requirements in providing the required functionality such as reporting, imaging, searching or hardcopy records management.

Section 3: Complete package pricing for all products in Section 1 and 2 if licenced or purchased as one product.

Section 4: Value-added Software which is not included in the functional requirements but, in the opinion of the Vendor, may be of interest to the GoA in managing its information assts and supports the mandatory core components of the EIM suite (for example, digital rights management).

Product Name or Part Number

Product Description

Licensing Cost per Seat in Canadian Funds

Licensing Cost per Server in Canadian funds

Annual Cost for Maintenance and Software support (either as a fixed cost or % of licensing costs)

Annual Escalation Percentage (%)**, If Any

Section 1: Primary Software

Section 2: Associated Software

Section 3: Complete package (all above products)

Section 4: Value-added software



202

2. GoA Training Costs

Proposals should include information pertaining to the associated optional costs on a Fixed Price basis for the training of staff for use of the proposed Software products. Using the table below as a framework, list the training classes that could potentially be offered to the GoA. Vendors should indicate who will provide the training (e.g. directly by the Vendor, through a certified partner, or through a third party). For the cost columns, indicate the costs for a class of 10-16 users including all class materials, instructors and travel and living expenses for the instructor etc. For other non-classroom materials (for example, Train-the-Trainer courses, CD-ROM, videos etc.) indicate the cost per unit.

Training Type (specify in detail)

Training Provided By

Course Length

Cost per class (units) in Alberta stated in Canadian funds (assume a class size of 10-16 students and daily class duration of 7.25 hours)

Annual Escalation Percentage (%)**, If Any



203

3. Consulting Services

Proposals should include information pertaining to the associated optional costs on a Fixed Price basis for the provision of consulting services to implement the suite of EIM software. Using the table below as a framework, list all the consulting services provided along with their associated pricing structures, in Canadian funds. Vendors must indicate who the service providers will be (e.g. directly by the Manufacturer, through a certified partner, or through a third party).

Consulting Services Cost per Consultant/Hour

Services provided by:

Annual Escalation Percentage (%)**, If

Any Needs Assessment/ Workflow Analysis

API Development/ Integration

Template Development Database Model and Design Hardware Configuration and Design

Software Installation Travel and Lodging Other: • Taxonomy/ Records Classification and Retention Schedule Development

• User Manual Development

Other Services



204

4. Total Cost of Ownership

Using the table below as a framework, Vendors must complete the necessary calculations that will show a 3-year Total Cost of Ownership, including the maximum annual escalation/de-escalation percentage, if any, based on 500 users over a 3-year period. It should be noted that all of the numbers shown in the Total Cost of Ownership must be able to be reconciled to all of the above stated costs in APPENDIX F - Pricing Form.

Pricing Component Proposed Cost in Canadian Funds for 500 users

License Fee (one time) or Annual Fees (ongoing). The Vendor must provide a full description of pricing approach for a 3 year period based on 500 users over a 3 year period.

Maintenance and Support Costs

Maximum Annual Escalation/de-Escalation** (%), if any: - maximum annual % increase/decrease that will be applied to any of the above costs elements (the percentage increase/decrease must be a numeric value and not stated in terms of any indexes and should be applied to the total cost of ownership calculation)

%

Other Costs, if any : Total Cost of Ownership (Total cost of ownership for all costs due to the Vendor for the entire 3 year period. Vendors must show all calculations).

The Minister must require written notification of price increases/decreases from the Vendor identifying the price increases/decreases and the effective date, which must not be earlier than the date of notification to the Minister. Any price increases/decreases must not exceed the maximum annual escalation/de-escalation percentage as stated by the Vendor in the Pricing Form and must not become effective until the Minister receives written notification.

Appendix G – Vendor Recommendations


205

APPENDIX G – Vendor Recommendations

The Proposal should provide the following additional information. This information will not be evaluated.

Information Request

Recommendation

How many days of effort from the Vendor’s Installation/Implementation specialist and the associated cost will normally be required during the initial setup of the Vendor’s Products? How many days effort will normally be required from Government of Alberta resources to support the installation/implementation? Provide details by resource type.

Appendix H - Vendor References


206

APPENDIX H – Vendor References Using the Corporate Reference Form below, The Vendor must provide three (3) independent North American references for three (3) installations of the proposed Software products, of similar scope, nature and complexity to that requested by Her Majesty. At least one (1) reference must be a client where multiple website types (i.e. Intranet/Internet/Extranet) are supported by the proposed EIM Products. Her Majesty may contact these or other references without prior notice to the Vendor. Vendors who, in the opinion of Her Majesty, receive unsatisfactory references may have their Proposal rejected. If the Proposal does not include complete information for the Corporate Reference Forms below, then the Vendor must provide them within 2 Business Days upon request by Her Majesty. Corporate Reference Form:

Corporate Reference #1

Company Name Address,

City, Province/State

Contact Name Title

Phone Number E-mail Address

Alternate Contact Name

(Optional)

Title Phone Number E-mail Address

Years Using Product

Comments

(include details regarding the

technical environment and

current state of operations with

proposed Products)



207

Corporate Reference #2 Company Name

Address, City,

Province/State

Contact Name Title



(Optional)


Years Using Product Comments

(include details

regarding the technical environment and


proposed Software products)



208

Corporate Reference #3 Company Name

Address, City,

Province/State

Contact Name Title



(Optional)


Years Using Product Comments

(include details

regarding the technical environment and


proposed Software products)

Appendix I - Reporting Requirements


209

APPENDIX I – Reporting Requirements The Vendor must, within five (5) Business Days of the first day of each month during the Standing Offer Contract, submit written reports to SMB, Procurement Section, including the following information: a) Purchaser's name; b) order date, description, quantity and value of Software ordered during the reporting

period; and c) total funds expended to the end of the reporting period. The Vendor must immediately submit a written report to SMB, Procurement Section, if the total orders received by the Vendor will expend or exceed 75% of the Contract's value.

SAMPLE STANDING OFFER REPORT To be submitted monthly to: Procurement Section Standing Offer Contract No: ________________ Supply Management Branch Alberta Corporate Service Centre Vendor Name: ________________ Government Services 2nd Floor, 12360 - 142 Street Contract Expiry Date: ________________ Edmonton, Alberta Canada T5L 4X9 Attention: Procurement Officer_______________Contract Upper Limit: $________________ Purchaser’s Name Order Date Description of Software Quantity Value ------------------------------------------------------------------------------------------------------------ Balance remaining as of previous report: $_______________ Total expended during the reporting period: $_______________ Balance remaining on Contract: $_______________ Reporting month: ________________ Report submitted by: ________________ Date of report: ________________

Appendix J - Proposal Submission Letter


210

APPENDIX J - Proposal Submission Letter

(Date, 2004) Alec Chan Contracting Manager Contracted Services Section Alberta Corporate Service Centre 2nd Floor, 12360-142 Street Edmonton, Alberta T5L 4X9 RE: Request for Proposal (RFP) Number 279PA-42, Electronic Information Management (EIM) Software Selection Project Enclosed is our Proposal submitted in response to this RFP. Authorized Signature (Print Name) _____________________________________ (Telephone No.) _____________________________________ (Facsimile)