Electronic Document & Records Management System Tender

EDRMS Tender - Appendix G

Electronic Document & Records Management System Tender

of 65


Instructions to Tenderers

1. Tenderers shall treat the details of the Tender Documents as private and confidential.

2. The Council in its absolute discretion may reject a tender if:

• all or part of the Tender Documents are reproduced for submission in a different format from that provided by the Council,

• the Tender is qualified and the qualification materially affects the working of the Contract,

• the Tender contains a financial section which is incomplete,

• the Tenderer makes or attempts to make any variation or alteration to the terms of the Contract Documents except where the variation or alteration is expressly permitted therein.

3. Tenders shall be delivered, sealed in the envelope provided, not bearing any indication of the Tenderer on the envelope, or in the franking thereon, clearly marked with the Contract Name and addressed to the Chief Executive, Civic Offices, 1 Saxon Gate East, Central Milton Keynes, MK9 3EJ, so as to arrive no later than noon on the specified date.

4. Tenderers should note that if this Contract is within the scope of European Procurement Directives, the Council is obliged to publish the contract value and name of the successful Contractor.

5. The Council does not bind itself to accept the lowest or any tender. In the event that no tender is accepted, the Council will not accept liability for any costs incurred by Tenderers in the preparation of their tenders.

6. The Council reserves the right to vary any aspect of the Contract where returned tenders exceed budgetary resources.

7. Where the Council is looking for the Most Economically Advantageous Tender (M.E.A.T.), this may include consideration of price, experience, quality and service delivery. Tenderers must take into account the Evaluation Criteria specified in the Tender Documents and respond by providing information which demonstrates that they understand them and show how they will meet the requirements. Any associated costs of doing so are to be included within the Tender Sum.

8. The price details must be totalled and entered on the appropriate page(s) of the Tender Documents supplied with the Invitation to Tender. All figures and information shall be completed in black ink and signed by an authorised person.

9. Milton Keynes Council requires that all contractors, their employees and where applicable, sub-contractors shall, while working for the Council, conform with all requirements of the Health and Safety at Work Act 1974 and with all other Health and Safety associated Acts and Regulations that relate generally or specifically, to their trade, business or undertaking.

of 65


10. Contractors who fail to comply with Health and Safety legislation, including CDM Regulations where applicable, may be excluded from future opportunities of working for the Council.

11. Tenders or quotations should be fully priced to include all necessary actions or procedures relating to Health and Safety, as required by the Health and Safety at Work Act and associated Acts and Regulations.

12. The Terms of the Transfer of Undertakings (Protection of Employment) Regulations 1981 (TUPE) might apply in the event of this contract being awarded to a tenderer other than the current service provider. Each Contractor must satisfy himself as to whether or not in his view the TUPE regulations will apply and Contractors are advised to seek independent professional advice on the consequences for them if they are the successful tenderer and the TUPE regulations are held to be applicable

13. Where applicable, Tenderers shall clearly indicate whether TUPE has been considered in pricing their tender.

14. A Performance Guarantee Bond or Parent Company Indemnity shall be required for all contracts with a total contract value greater than £100,000. The above shall also apply in cases where a number of lower value contracts are awarded to the same service provider and the aggregated total contract value is greater than £100,000.

15. With this Invitation to Tender and Instructions to Tenderers you should receive:

1. Conditions of Contract 2. Background and General description of Requirement 3. MEAT Tender Evaluation Document 4. Detailed Specification Table 5. Additional Information Requirements 6. Pricing Schedule 7. Collusive Tendering Certificate 8. Form of Tender 9. Insurance Cover Form 10. Form of Agreement 11. Form of Parent Company Indemnity 12. Form of Bond

16. The following documents must be completed and returned with the Tender.

The Pricing Schedule Detailed Specification Response Responses to the Additional Requirements The Form of Tender, The Collusive Tendering Certificate

of 65


17. All other documents are provided for information only at this stage. Following the award of the Contract the successful Tenderer shall be required to complete the following documents; Form of Agreement, Insurance Cover Form, Form of Parent Company Indemnity, Form of Bond.

2. BACKGROUND AND GENERAL DESCRIPTION 2.1. CONTEXT

Milton Keynes Council (MKC) wishes to enhance its capability to capture, retain and access information through the introduction of an enterprise-wide Electronic Document and Record Management System (EDRMS). The recent introduction of the Freedom of Information Act (FOI) has been one of the drivers for better information storage and access. Later in 2005 the requirements of the Electronic Social Care Register (ESCR) will drive compliance on specific aspects of data management, access and shareability. In our Revenues and Benefits department a document imaging system is already in place. However, this application is not scalable; thus any new system would either have to work with it or replace it. For both budgetary and cultural reasons, MKC wishes to introduce an EDRMS on a sequential and scalable basis. We are looking for solutions that can meet this need, can integrate with our existing key systems and architecture and at the same time provide opportunities for improved workflow. These key systems are detailed in Section 2.3. At this stage we are inviting tenders both for the software aspects of EDRMS and the supporting hardware for electronic data capture. In future, we reserve the right to use alternative sources for hardware. The total number of users anticipated at MKC is 2,750, but the contract will commence with a smaller user base.

2.2 COMPLIANCES REQUIRED

We require evidence from tenderers that their solutions comply with the following: PRO2 (aka TNA2) MoReq v5-2.1 The document “Defining the Electronic Social Care Record - December 2003” (Published by the Information Policy Unit - Social Care Department of Health [email protected]) expresses specific ESCR requirements with which

of 65

mailto:[email protected]


tenderers must confirm that their solutions are compliant, or can be modified to achieve compliance.

2.3. TECHNICAL REQUIREMENTS

2.3.1. We will be starting within Social Care. Apart from the need to meet the requirements of ESCR, it will also be necessary for solutions to provide two-way integration with the existing OLM CareFirst product.

2.3.2. We are currently using SAP CRM and SAP R/3, including a SAP Portal. The EDRMS must integrate with these systems.

2.3.3. We require full XML and E-GIF compliance.

2.3.4. Any proposed EDRMS solution must have an email filing, searching and archiving component within it that will integrate with MS Exchange and Outlook.

2.3.5. Other major software products in use within MKC are (this list is not exhaustive):

- I World (Housing) - EMS Education suite - FLARE (Environmental Service) - UNIFORM (Planning) - SBS (Highways/Maintenance) - I World (Revenues + Benefits) - SOLICITEC - MS OFFICE, including Word, XL, Project & PowerPoint

The EDRMS solution must ideally be capable of integrating with all these. In addition the system should not conflict with the PARSOL programme currently being implemented by Planning.

2.3.6. The solution must be able to integrate with MKC’s SAN (Storage Area

Network) infrastructure.

2.3.7. The EDRMS solution proposed must also be capable of storing and accessing any variation of file, including audio and video files.

2.4. OPERATIONAL REQUIREMENTS

The proposed system shall be capable of handling all the business activities of a Unitary Authority, starting with Social Care but progressing over time through all Directorates and departments. We plan to commence implementation within Social Care (300 users), then within Planning & Transport (143 users). It is anticipated that these areas may use up our existing budget for 2005/6. Over the next three years we anticipate a rolling installation and implementation programme as detailed below:

of 65


Area Q3-2005 Q4-2005 Q1-2006 Q2-2006 Q3-2006 Q4-2006 Q1-2007 Q2-2007 Q3-2007 Q4-2007 Q1-2008 Q2-2008

Social Services

Planning

Transport

Creditors

Debtors Revenues & Benefits.

HR

Education

Electoral Reg.

Land charges

Housing

Legal

ICT 2.5. FINANCIAL CONSTRAINTS

Total budget available until end March 2006 is in the region of £500,000, including installation, data migration, training and hardware. Tenderers should include training costs for IT personnel and MKC’s internal training team (‘the trainers’). It is anticipated that the bulk of the training at departmental level will be carried out by MKC staff.

2.6. TENDER PRICING COMPONENTS

In order to enable proper analysis of financial implications within the timescales outlined above, we would like pricing information presented in two scenarios or ‘packages’: Package 1: Implementation in Social Care and Planning & Transport (total 443 users) Software/license costs Annual Maintenance costs Hardware & supporting software costs Implementation/consultancy costs Technical training/skills transfer costs User training costs Any other incidental charges normally made Package 2: The additional cost of rolling out the EDRMS solution to the rest of MKC’s departments (a further 2307 users), projected over 4 years from 2006/7 at current costs NB At this stage we are only able to commit to Package 1. However, the successful tenderer will also be expected to supply the chosen solution to all other MKC departments as funds become available.

of 65


2.7. RESPONSE TO TENDER

We would like each organisation tendering to ensure that their response covers the following: 7.1. Approach and methodology 7.2. Evidence of compliance with stated requirements 7.3. Names and references of other local authorities or Public Sector clients 7.4. Identification of the unique features and benefits of each solution 7.5. A full explanation of how all technical requirements will be met 7.5. Price proposals per section 6. 7.6. Specification/recommendation for associated hardware and software The detailed requirements are set out in sections 3 to 6. The contracting authority may consider the use of the Competitive Dialogue provisions set out in Articles 28 and 29 of Directive 2004/18/EC during the tender period. The contracting authority is seeking a single contractor to be responsible for all the services and installation of all necessary software. This does not preclude companies working in partnership, but there must be a principal contractor that the contracting authority will deal with.

3. MOST ECONOMICALLY ADVANTAGEOUS TENDER (MEAT) EVALUATION

DOCUMENT

3.1. Introduction

Milton Keynes Council is committed to providing high quality, value for money services. Tenders will be evaluated against price and pre-determined criteria related to quality.

3.1.1. This document sets out the criteria for the assessment of the Tenderer’s ability to provide the specified works or services. All Tenderers shall provide information, which demonstrates their understanding of and ability to meet the Specification.

3.1.2. To ensure that Tenders are evaluated on a consistent basis it is essential that responses are made to all the issues listed in the Evaluation Questions listed in this Document and are clearly referenced to specific evaluation criteria.

Failure to provide the required information may lead to the Tender being rejected. It is appreciated that extracts from procedures manuals, quality assurance documents, etc. may well contain the required information. But we do not require the complete documents. It is essential that relevant information contained within any such extracts be clearly identified and related to the question to which they refer.

of 65


Evaluation 3.1.3. A Tenderer who submits a tender with arithmetical errors leading to a

revised Tender Sum when the errors are corrected will be given the opportunity to accept the revised Tender Sum or withdraw the Tender.

3.1.4. A Tender containing major arithmetical errors or a large number of arithmetical errors may be rejected on the grounds that there is serious doubt about the competence of the Tenderer.

3.2.3. Tenders will be evaluated against the broad criteria listed in Table 1 with their relevant apportionment of scorings.

Table 1

Price – Package 1 20%

Price – Package 2 30%

Business Functionality 20%

Technical Compliance 20% Service requirements 10%

3.3. Evaluation of Tender Prices

3.3.1. A Tender may be rejected if it is too high to be affordable.

3.3.2. A Tender may be rejected if it is too low to be credible, but only after the Tenderer has been given the opportunity to provide an explanation of the Tender or part of the Tender which the Council believes to be too low.

3.3.3. The overall cost to the Council will be calculated, including the Tender Sum and any other allowable costs.

3.3.4. The Tender providing the lowest cost to the Council will be awarded maximum points. This will be the percentage weighting on price as stated in Table 1.

3.3.5. All other tenders will be awarded points on a pro-rata basis. An example (taking Package 1) is given in Table 3.

Table 2

Tenderer Cost to Council (£m)

Calculation Points

Tenderer 1 1.00 20%

Tenderer 2 1.20 1.0/1.2 x 20 16.7%

Tenderer 3 1.40 1.0/1.4 x 20 14.3%

Tenderer 4 1.60 1.0/1.6 x 20 12.5%

of 65


3.4. Evaluation of other Key Criteria

3.4.1. The three other broad criteria will be assessed in greater detail using the Key Evaluation Criteria listed in Table 2.

KEY EVALUATION CRITERIA Must or Want Weight

Price and commercial acceptability (total 50%) Price- package 1 must be close to 500K budget (20%) W 10 Price: Total cost of ownership (30%) W 10 Business Functionality (20%) XML Compliant(e-gif) M y/n Meets ESCR requirements W 10 Scaleability W 8 Ease of Use (Doc input,date management, indexing, document control, user functions, capacity) W 10

Richness of functionality/ inc workflow/security/management reporting/searching W 10

Email archiving/Integration capability W 7 Technical Requirements (20%) Good level of integration with existing systems W 8 2 way integration with Carefirst W 6 Strategic fit with other IT initiatives W 9 Store / Access a comprehensive list of file formats including video & audio W 7

PRO2/TNA Compliant or working towards W 7 System resilience and speed of recovery W 9 Service Elements (10%) Available in Timeframe M y/n Credibility of Implementation plan W 7 Acceptability of contractual terms W 6 Track Record W 7

3.4.2. MUSTS (M) are mandatory requirements and represent a pass/fail hurdle.

Tenderers not meeting these requirements will be rejected. All scores will be totalled and the score carried forward to the Tender Evaluation Sheet where the appropriate weightings from Table 1 will be applied.

3.4.3. WANTS (W) are highly desirable attributes. These have been weighted according to their relative importance and will be scored using a 10-point scale, 10 representing OUTSTANDING in relation to the requirement and 1 representing little or no evidence of meeting the requirement.

3.4.4. Each key Criterion will be assessed and scored out of 10 and then the weighting shown in Table 2 applied, to yield a weighted score. Scoring example: ‘Meets ESCR requirements’, assessed at 8 out of max. 10, multiplied by weighting of 10 = 8X10 = 80.

of 65


’Strategic fit with other IT initiatives’, assessed at 9 out of max. 10, multiplied by weighting of 9 = 9x9 = 81

3.4.5. Assessment of how well tenderers meet each Key Criterion will be based on responses to the detailed requirements Specification and to the information supplied in other elements of the Tender documentation.

3.5. Tenderer Interviews

3.5.4. Tenderers may be asked to attend an interview. Failure to attend may lead to the Tender being rejected. Each Tenderer will need to be represented by at least one member of staff who was involved in compiling the Tender and one member of staff who will be responsible for managing the Contract.

3.5.5. The purpose of the interview will be to:

a) Confirm that the contents of the Tender are accurate.

b) Question the Tenderer about areas of their Tender where the evaluation process indicates that they may have difficulty in meeting the specified requirements.

c) Question the Tenderer about areas of their Tender where the evaluation process indicates that the specified requirements will be exceeded.

d) Assess the suitability of the person who will be managing the Contract.

e) Clarify any uncertainties and / or anomalies in the Tender.

3.5.6. There may also be a requirement to visit other sites where the proposed EDRMS has already been installed

3.6. Form of Response by Tenderer to Requirements Specification

The Tenderer shall prepare a separate document entitled “Response to Requirements Specification” which shall be returned to the Council in accordance with the Instructions for Return of Tender. This document will be held to form part of the Contract Documents. This document shall take the following form:

3.6.1 Introduction

This should be brief and should outline the subject of the proposal and identify a single contact point for correspondence.

3.6.2. Management Summary

This section shall summarise the key aspects of the Service Provider’s System and Service Support Proposals and the Service Provider’s approach.

3.6.3. Proposed Solution To Requirements

of 65


Tenderers shall respond in detail to the Requirements set out in the Requirements Specification addressing all items from Sections 4 and 5. Tenderers must complete the supplier response column in Section 4, showing how well their product matches the requirements by rating their response against each requirement using the following scale: Rating Scale Value Included in the current version of the software

4

Not included in the current version of the software but will be developed and delivered ready for use within 3 months of Project commencement date.

3

Not included in the current version of the software but will be developed but could not be delivered ready for use within 3 months of Project commencement date.

2

Not included in the current version of the software and no existing plans to develop this requirement

1

Tenderers should note that where a response to a requirement is a scale 2 or 3, this must mean that there will be no additional costs charged for the functionality. All costs including future development costs must be included in the tender price. Where a scale 2 or 3 response is given, Tenderer’s should note that they are making a definite commitment to the delivery of the requirement within the stated time scales and the development of the requirement should be included in the Tenderer’s Future Development Plan requested in Section 5, Additional Information Requirements. Tenderer’s must respond in detail to each of the requirements in Section 4.486 – 4.502 (Service Requirements) by indicating compliance and how this will be met or non compliance with the requirements. Tenderers must also answer each of the questions contained in Section (Additional Information Requirements) ensuring that any supporting documentation or information requested is provided.

of 65


4. EDRMS DETAILED SPECIFICATION TABLE 4. EDRMS - Functional Requirements

ID Functional Requirements Supplier Response

4.1 Business Functionality

4.2 The software must conform with all relevant legislation and standards, including BSI PD0008-9 relating to the legal admissibility of electronic documentation

4.3 The software must be able to cope with different priorities and time-scales linked to different document types, from a minimum of one to a user configurable maximum number of working days

4.4 The software must assist the users in ensuring that all correspondence sent to the LA is date stamped and forwarded to the appropriate person or department on the date of receipt, ie the received date must be specified on scanning

4.5 It must be impossible to make changes to the document images once they have been scanned and accepted onto the software

4.6 All documents must have a variable pre-set time in which to be dealt with in line with service standards

4.7 The following functions should be undertaken within a user definable number of working days 1. production of acknowledgements or receipts

for correspondence where required

4.8 2. issuing of requests for further information where required

4.9 3. responding to requests for information

4.10 The software should include an integrated word processing package with standard (user definable) templates for automatic/ad hoc production (plus free text letters)

of 65



4.12 The software should enable users to provide an acknowledgement to communications within a user-definable period for a full response where applicable

4.13 The software must hold address data in a form compliant with BS7666

4.14 The software should be able to link document addresses to the LA’s Local Land and Property Gazette

4.15 The software should provide support for national initiatives such as directgov and Government Gateway allowing national integration of public sector services

4.16 Search and retrieval times for documents stored online should be less than three seconds

4.17 All documents stored electronically must be available to all staff (with authorised access) concurrently. This must not noticeably affect online response times

4.18 The facility must exist to prevent more that one user updating a document’s status or attributes at the same time

4.19 A warning message must alert the user of simultaneous viewing by another user

4.20 The software must allow multiple documents, a single document or part of a document to be viewed simultaneously by more than one user

4.21 It must be possible to print any document or part of a document or group of selected documents on demand

4.22

The system must allow easy transition between Care First and the document management system. It should take no more than two clicks to get from a Care First record to a list of documents related to that client

4.23

The system must facilitate the use of “sealed envelopes” for the storage of highly sensitive information

of 65



4.24

The system must be capable of storing, retrieving and playing video and audio files.

4.25 The system must interface with the Council’s portals technology to allow citizens direct access to their own documents

4.26 The system must facilitate the exchange of documents with all parts of the National Health Service and therefore must be compliant with standards laid down by the NPfIT programme

4.27 Document input

4.28 The software, through password controls, must allow only authorised users to undertake the initial scanning and indexing of documents

4.29 Documents must be scanned into the software at, or better than, the minimum resolution required for optical character recognition

4.30 Scanned documents should be printable to exactly the same size, scale and resolution as the original

4.31 The software must support changes in document resolution to facilitate easy on-screen reading of all documents.

4.32 The software should accommodate colour scanning and storage of images

4.33 It should be possible to scan colour images as black and white

4.34 Documents (or document windows) must be scaleable to fit 17 to 21 inch screens and various laptop screens from 14 inches upwards

4.35 It must be possible to view documents at varying percentages of their original size and allow for different preferred user defaults

4.36 The system must support scanning of single and double-sided documents with single and multi-page automatic document feed

of 65



4.37 The system must support the electronic import of images scanned and indexed by an external supplier, if required by the LA

4.38 The system must support the scanning of different sizes and weights of paper including card

4.39 The system must support different standard and non-standard sizes of document.

4.40

The software and associated scanners must be able to retain image scaling such that measurements on-screen or on printouts from scanned images will remain accurate to the original

4.41 The software must permit pre-set scanner settings for commonly received forms and document types

4.42 The user must be able to classify the document type for scanning with the software automatically resetting the controls accordingly and an override facility

4.43 Once pre-set scanner settings have been changed, the software must revert back to a default scanner setting

4.44 The software must expect a certain number of sides for a given standard document type

4.45 Should the required number of sides not be received for a standard document, the software must alert the user and scanner. An override facility must be provided

4.46 The software should feature a facility to recognise content on a page and omit blank pages thereby reducing file size

4.47 Verification procedures must exist to ensure the identification of duplicate pages or documents

4.48 Quality assurance procedures must exist to enable documents to be viewed during or after input

of 65



4.49 It must be possible for a document to be rescanned if required or parts split and re-indexed

4.50 It must be possible for a document to be rotated or de-skewed before being accepted into the software

4.51 The software must indicate clearly the existence of problem documents, e.g. those with unacceptable images or colours.

4.52 The software must feature the option to capture and input documents optically independent of the later stage of indexing

4.53 The software must support batch scanning, allowing batches of similar or the same type of documents to be directly entered into the software with differing document status

4.54 The software must produce statistics on-screen (and hard copy if required) to meet user requirements relating to the number of scanned documents in a certain batch

4.55 The input of documents into the software must be based on a ‘Write Once, Read Many’ (WORM) functionality

4.56 The software must include at least one scanner with the ability to cope with carbon copies or other poor image quality documents

4.57 Scanners must feature both flat bed and automatic feed.

4.58 The software must maintain batch controls to indicate the status of documents already entered

4.59 The software should permit the following date functions:

4.60 4. the ability to change the system date

4.61 5. the ability to hold dates scanned as pre-system start dates (received dates)

4.62 6. the ability to show the historical date of document input

of 65



4.63 7. the ability to allow manual amendments on date fields, with appropriate security

4.64 The software must be able to provide for barcode scanning and indexing. Barcodes must adhere to the addressing standard, BS7666, to give one unique reference

4.65 Emails and online faxes can be transferred into the software, stored and accessed in the same way as other documents

4.66 Other digital images such as those from digital cameras and voice recorders can be transferred into the software, stored and accessed in the same way as other documents

4.67

Scanning software should be TWAIN compliant

4.68 Document indexing

4.69 The software must be capable of barcode scanning with the facility to index documents according to barcode contents

4.70 The software, through password controls, must allow only authorised users access to the indexing functions

4.71 The software must retain date and time details and the ID of the user who initially indexed the documents.

4.72 The software must allow documents to be split and re-indexed in full or in part. The software must allow additional documents to be combined into a folder or case rather than a single document, as appropriate

4.73 The software must support re-indexing by authorised users, if required, and any additional indexing at any stage (without access to the original hard copy document)

4.74 The software must be able to store forms or documents requiring additional supporting documents at the point of indexing. When such additional documents are received, they must be added to the original document to make one document on the system and then automatically

of 65



routed to an in-tray

4.75 It must be possible to add levels of confidentiality to documents at indexing

4.76

Documents should have the following attributes attached to them at the indexing stage

4.77 8. date received

4.78 9. document type

4.79 10. document status

4.80 11. date to be completed

4.81 12. date completed

4.82 13. date status changed, and the name of the user who changed the status

4.83 14. document origin

4.84 15. user-definable reference such as account number. The system must add a URN to each record.

4.85 The document attributes must include a history of status changes and an audit trail

4.86 The document indexing structures must be capable of being easily configured by user definable parameters

4.87 The software must be capable of indexing documents to several different accounts, properties, claims and people, at the initial indexing stage

4.88

The software must be able to index a document automatically by matching details from data held on the system

4.89 The software must allow the option of utilising bar code or optical character recognition techniques for automatic indexing

of 65



4.90 Additional information relating to a document should be stored in free format text annotations as a document attachment

4.91 The software must allow validation by reference to other LA systems when indexing documents and by display of information from these systems for visual comparison (e.g. OLM’s product Care First. There is also a requirement to hold the NHS number).

4.92 It must be possible to separate part of a document to be re-indexed without reference to the original document

4.93 It must be possible to identify links to other documents or cases at indexing

4.94 Document control

4.95 All scanned documents must remain accessible online for a minimum period of 24 months and retrievable within three seconds

4.96 All offline documents should be retrievable within ten seconds

4.97 Documents must be stored in a compressed format. This format must be based on a standard format, eg ‘tif’ or ‘pdf’

4.98 Users should be unaware of the physical storage location of documents

4.99 The software must be able to automatically identify the location of an archived image and retrieve it should it not be available online

4.100 All completed document images, groups of document images, or even parts of images, eg pages, as relevant, must be capable of being archived from magnetic to optical disk

4.101 The software must, through password controls, allow only authorised users to change the system status of a document or group of documents back to ‘live’ after it has been archived

of 65



4.102 The software must, through password controls, allow only authorised users to define rules relating to documents, which determine the way in which they are viewable, indexed, archived or otherwise treated by the system. Such rules must be compliant with the Data Protection Act 1988 and relevant Codes of Practice issued thereafter.

4.103 The software must be able to store emails and electronic faxes as documents with the same features as scanned images

4.104 It should be possible to access documents through other LA applications

4.105 Access to online and stored images must be available by remote access and by internet browser through the same structure

4.106 The software must allow restricted access to certain document types, eg cases, claims and accounts

4.107 All documents must be retrievable by the selection of one or more identifiers

4.108 It should be possible to search by multiple references in one search

4.109 It must be possible to instigate a search on the software (both online and from storage) for a record or document using a general match or search word

4.110 The software must have the ability to recall a total case, account, or property file on a single search for user specifiable attributes

4.111 The software must be able to gather together relevant documents relating to specific cases, accounts, properties or other user-definable attributes

4.112 It should be possible to store frequently used search criteria

4.113 Relevant nominated staff must have access to in-trays, set up and controlled by the system administrator

of 65



4.114 The in-tray feature must allow for the receipt of any scanned document enabling it to be indexed, automatically routed, allocated and dealt with

4.115 In-trays must be provided at global, ward, workgroup and individual levels (or other user defined structures, as appropriate)

4.116 In-tray destinations must be decided from index details, but must also allow manual override

4.117

The software must feature in-tray facilities for individuals and groups to review incoming documents and link documents together where relevant

4.118 The in-tray facility must display information to the user for processing documents, eg document type, status, priority, and date

4.119 All documents and their attributes within each in-tray must be displayed

4.120 The software should present a summary line for each document with the option to reveal document images and free text notes that may have been added to the document during processing

4.121 The in-tray should be able to display thumbnail images of documents

4.122 The software must be able to sort documents in the in-tray by any attribute shown

4.123 As default, when browsing individual or team in-trays, users must be presented with the oldest or highest priority documents first, as defined by the user

4.124 The software must allow any existing in-tray defaults to be changed by authorised users

4.125 The in-tray must feature options to list items in different ways, eg by document type, to satisfy different individual working methods

4.126 The order of the rows in the display of document attributes and the positions of each field within rows should be alterable with the ability for users to set their own defaults or preferences

of 65



4.127

The software must permit a user to mark a document as pending or change to any status and move onto the next document

4.128 The software must feature a separate in-tray for all pending items for the user. These items should also show up in the standard in-tray when they reach their expiry date

4.130 The software must assign a status to documents automatically and manually

4.131 The software must allow user-definable rules and notifications for overdue documents

4.132 The software must permit the presentation of a history for all items linked to person, case, family, account or property

4.133 Users must be able to forward documents to any other user

4.134 The software must feature the ability for authorised users to set up their own predefined address groups for the distribution of documents

4.135 The software must allow the linking of documents with the same reference number

4.136 The in-tray must allow the selection of documents within an in-tray matching only certain user-specified criteria, such as document type or status

4.137 Unopened post must be evident within in-trays for individual users and able to be viewed by supervisors and managers

4.138 The software must feature an online facility to show a ‘totals only’ summary of all documents residing within each in-tray

4.139 A user must be able to perform the following functions for a group of documents:

4.140 16. forward the documents to another user

4.141 17. close the documents as required

of 65



4.142 Authorised users must be able to perform the following functions for a selected document:

4.143 • Add to or update index information

4.144 • Add or change document status including changing to pending

4.145 • view the document image

4.146 • print the document

4.147 • print all associated documents without opening and view them all

4.148 • add free text annotations

4.149 • list associated documents

4.150 • view audit trail for the document

4.151 • forward the document to another user or users

4.152 • copy the document

4.153 • close the document as completed

4.154 • create a response document

4.155 The software must permit the display of multiple pages and documents simultaneously

4.156 The software must feature the ability to undertake the following functions:

4.157 • scaling

4.158 • panning

4.159 • scrolling

4.160 • rotation

4.161 • zooming of part and whole images

4.162 • full support for the VF (Verification Framework)

4.163 Users should be able to add free text annotations to documents, in colour if required

of 65



4.164 Users must be able to view and print documents with or without any free text annotations

4.165 The software must allow printing to all standard paper sizes in both metric and imperial measures.

4.166 The software must allow printing of selected parts of documents

4.167 The software must have automatic filing of outgoing documents created by word processing, email and other systems, alongside scanned documents to create a complete correspondence file, which is available for viewing

4.168

The software should allow the selection of a standard letter or other document from a list of standard documents in word processing or other desktop systems

4.169 Selected standard documents should have the relevant name and address details automatically entered by the system (from a user definable source). The user must be able to manually overwrite these details – including OLM’s Care First

4.170 The software should offer the option to print standard documents with a copy of the letter linked automatically to the appropriate file

4.171 The software should allow a user to tailor standard documents on an individual basis

4.172 The software must permit users to create new documents to record any telephone conversations and actions that are required and add these to the software in the appropriate location. These must then be subject to all normal document management procedures

4.173 The software must allow the generation of letters from the software using word processing and other systems

4.174 The software should allow the generation of a processed response from the reference information associated with the document in question

of 65



4.175 The software should feature the availability of pre-set standard paragraphs and phrases in user generated documents and allow the user to email, fax or print these

4.176 Documents created through pre-set formats must be automatically referenced, set appropriate document status and filed for future access

4.177 The software should be able to provide version control for draft and final versions of outgoing documents

4.178

The software should flag out-of-date versions of documents with a link to the most recent version

4.179 The software should record the history of version-controlled documents

4.180 The software should have the ability to create standard and personalised letters using word processing and other systems that have not been initiated in response to an incoming document

4.181 All scanned documents must have an archive and delete attribute to allow automatic handling of archiving and ‘weeding’

4.182 The software must be able to store miscellaneous documents which are not part of any case or process with the same capture, storage, retrieval, reporting and printing facilities as the scanned images forming part of a workflow or other process

4.183 The software should produce daily reports (or as required) on outgoing post by department exportable to spreadsheets or other systems

4.184 The software must be able to provide for optical character recognition

4.185 Each document must have an audit trail attached with the ability to view information on each action undertaken

4.186 Full audit trails and a full life history of all documents must be maintained

of 65



4.187 The audit trail must include:

4.188 18. date and time of all document movements

4.189

19. who accessed the document and when

4.190 20. date, time and user details for all status, indexing and other changes

4.191 There must be the ability for user defined periods of time before deletion to be set for certain documents

4.192 Deletion of documents must be restricted to authorised users and recorded on the audit trail

4.193 The audit trail must not be capable of being suppressed or altered by users

4.194 Management reporting

4.195 Reports must be available giving statistical and analytical details of documents processed or waiting to be processed

4.196 A range of standard reports or on line search facilities must be available on request to provide management statistics on the following:

4.197 • volume of documents being received and scanned into the system by document type per time period

4.198 • processing times for document types by group and individual, by specifying time periods

4.199 • age analysis of documents by document type

4.200 • work done by each user per time period by document type

4.201 • total number of documents/scanned between selected periods by document type and user

4.202 • work unallocated to users

4.203 • pending work in users In-trays by team and

of 65



individual

4.204 • completed work by team, individual and document type by age analysis of documents

4.205 • outstanding work by team and individual by document type, scanned/completed by date and priority level

4.206 • average time for work completion by document type for an individual/team and range of duties

4.207 • weekly and monthly workflow statistics

4.208 The software should allow the generation of reports for system administration purposes including the following:

4.209 • utilisation of disk space

4.210 • document transfer and retrieval response times

4.211 • retrieval statistics from magnetic and optical storage

4.212 • analysis of retrieval by document type

4.213 The software must be capable of audit trail interrogation of sufficient detail to allow legal admissibility of electronic documents

4.214 Computer Output to Laser Disk (COLD)

4.215 The software must automatically transfer reports and notifications from all servers and interfacing systems to COLD on a daily, weekly, monthly or less frequent basis as required

4.216 The software must feature the facility to select and re-direct pages or sections of reports

4.217 The software should have the facility to annotate reports

4.218 On the COLD browse, index or store screen or page, the software must include the following:

4.219 • report name

of 65



4.220

• pages in the report

4.221 • report status

4.222 • report date

4.223 • any notes attached

4.224 • whether report has been checked

4.225 • user-defined reference number

4.226 • address

4.227 • topic

4.228 The software should allow the annotation of documents sent to COLD if the document is not issued or duplicated

4.229 The software should permit the entering of notes, eg exceptions, prior to documents being saved to COLD

4.230 The software must allow the finding by character or text searches, of such exceptions quickly and/or identify exceptions separately

4.231 The software should allow the reformatting of large reports to enable the listing of scattered exceptions together or individually

4.232 The software should allow the use of arrow keys and Home and End keys to facilitate moving around reports

4.233 The software should allow for printing of highlighted sections of COLD reports

4.234 The software must include user-friendly viewing software to allow the viewing of COLD reports

4.235 The software must index and store COLD documents by user definable parameters

4.236 The software should allow the routing of reports to relevant users, eg via report type or index information in the report

of 65



4.237 The software must permit different access levels, eg read only, update

4.238 COLD should permit the storage of specific documents in a separate structure

4.239 Interface requirements

4.240 In addition to the interfaces defined in the Technical Specification document:

4.241 21. the software must be fully e-GIF compliant, allowing transfer of indexing and other document data, with the exception of image data, via XML

4.242 22. the software should be adaptable to allow future links to the internet/intranet/extranet and public service kiosks or other public access systems, subject to appropriate security arrangements

4.243 23. the software must be able to accept electronic data downloads from external systems to be translated into images and automatically indexed

4.244

The system must allow easy passage between the Care First system and the document repository. The user, having selected a client within Care First, should be able to get to a list of documents related to that client within two clicks and be able to display a specific document within a further two clicks.

4.245

The user must be able to get from a document relating to a specific Social Care client to a record held within the Care First system, subject to the necessary security permissions

4.246 The software must not conflict with any elements or functionality required by PARSOL

4.247 Workflow

4.248 The software must be adaptable to follow user-definable guidelines to guide users through each stage of a process

4.249 The workflow system must allow the definition

of 65



of workflow processes either in conjunction with business systems or independently from them

4.250 The software must allow designated staff to re-allocate the workload amongst staff, to prevent work remaining dormant when staff are absent

4.251 Users must be notified automatically under the following circumstances:

4.252 • when particular documents have not been dealt with within a specified time

4.253 • when pending documents approach their deadline

4.254 • when documents have reached the end of their time for action

4.255 Managers must be notified automatically under the following circumstances:

4.256 • when particular documents have not been dealt with within a specified time

4.257 • when documents have reached the end of their time for action

4.258 The software must provide the facility to direct one document to more than one in-tray with the same or different status

4.259 The software must allow the reallocation of documents to any user and change of document status, subject to the appropriate security

4.260 The software must feature the following in-tray facilities:

4.261 • the facility to allow extraction of work from the in-tray for supervisors and managers for their staff

4.262 • pending documents

4.263 • overdue documents

4.264 • totals to be dealt with

of 65



4.265 • documents within a specified number of days of becoming overdue

4.266 • completed documents

4.267 The software must feature a summary of all unread post, including the following functions for individual users, supervisors and managers:

4.268 an online facility to show a ‘totals only’ summary of all ‘unread post’ residing within each in-tray

4.269 the facility to allow the extraction of ‘unread’ post from the in-tray by supervisors and managers

4.270 the software must feature a summary of all ‘unread’ expired pending items

4.271 the software must feature a summary of all ‘unread’ overdue items and identify in-tray

4.272 the software must feature a summary of all ‘unread’ totals to be dealt with and identify in-tray

4.273 unread documents within a specified number of days of becoming overdue and identify in-tray

4.274 User hierarchy within the department must be reflected within the application allowing supervisors to carry out functions on documents allocated to users under their responsibility

4.275 Supervisors, managers or senior staff must have the ability to view summary information relating to documents allocated to their teams or departments without affecting document status

4.276 Nominated authorised staff must have the ability to redirect and forward documents within a team or elsewhere on an individual document or in bulk, for instance if a person leaves or takes prolonged sick leave

4.277 Reports must be produced warning of documents that have not been dealt with within the stipulated time and/or are approaching a due date

of 65



4.278 The software should use colours to denote proximity of deadlines as well as a code or symbol

4.279 The software should feature an easy-to-use diary facility to ensure that adherence to procedures is not reliant on a users memory

4.280 Any diary facility should link to the LA’s diary system

4.281 The software must incorporate a hierarchical procedure for alerting the users, team leaders and managers when documents are approaching a specified completion date

4.282 The allocation of work must be undertaken by multiple references for example by document type and geographic location

4.283 In-trays should show a visual distinction between live, urgent and pending work

4.284 Workflow must monitor the progress of all documents and warn users of deadlines

4.285 The software, through password control, must only allow authorised users to define and change workflow processes

4.286 Email should be able to be integrated onto the workflow process

4.287 The software should allow user-definable workflow reports

4. EDRMS - Technical Specification

ID Technical Specification Supplier Response

4.288 Overall Software Design

4.289 The software shall be designed to allow constants and options to be accessible and updateable by users with access permissions.

4.290 The software shall provide a set-up of parameters to allow the user to determine whether updating shall be performed immediately

of 65



on-screen, or by batch at user defined intervals.

4.291 The software shall be designed to allow 24. support for access to the software via several

user interfaces, including:

4.292 - windows based PC (running Windows 2000, or XP)

4.293 - Web browser on a PC

4.294 - handheld device (please state compatible operating systems and/or devices)

4.295 - kiosk

4.296 - digital television

4.297 • full interoperability and integration of software modules, in accordance with e-GIF requirements as specified in section 14.

4.298 The system must enable remote working.

4.299

The system must facilitate information access via a Web browser as well as the more ‘traditional’ system access via a PC workstation.

4.300 The system must comply with the Government’s e-GIF criteria.

4.301 The system should allow future integration with the LA’s telephone system so that a Caller ID function is provided allowing operators to link the telephone number being used by the caller to details held about the person on the software.

4.302 Legislation

of 65



4.303 The supplier will be required to make such modifications to the software so as to ensure that it conforms to any change of legislation or new legal requirement that affects any function or facility of the software. The supplier shall implement the modifications to the software as soon as reasonable practicable thereafter, but not later than two weeks prior to the date on which the relevant legislation comes into force. The implementation and development of such modifications should be co-ordinated by the software User Group, assuming such a group exists.

4.304 The supplier shall provide test versions of modified software as soon as is practicable, so that the council can test upgrades before implementing them in a live environment.

4.305 User Interface

4.306 Input screens shall be clear, well structured and, where possible all relevant data should appear on one screen.

4.307 The software shall provide a means of guiding users through common tasks, using ‘Wizards’ or other process automation or simplification processes to allow faster completion of standard tasks .

4.308

There shall be a consistency throughout the software relating to:

4.309 • keyboard shortcuts

4.310 • menu structures and terminology

4.311 • screen layout, where possible

4.322 It must be possible, where appropriate, to go backwards as well as forwards in any sequence of screens or commands

4.323 It must be possible to have several screens or windows open at once. However, each additional screen or window opened on a user workstation should not represent an additional user licence

of 65



4.324 It must also be possible to limit the number of windows/screens a user can have open at any one time, in order to control the impact on performance of the use of concurrent screens/windows

4.325 The system should be flexible in its use, so that users can maximise their productivity. Examples of such features include, but are not limited to:

4.326 • the ability to pause and later resume processes whilst moving around other screens or systems, eg if a telephone call is received whilst a process is partially complete

4.327 • appropriate ‘undo’ facilities allowing rectifying of recent mistakes, with an audit trail of the actions ‘undone’ and authorised person access only

4.328 • automation of common processes using ‘wizards’ structured screens or some other means of simplifying processes

4.329 colour coding or other annotation of significant fields such as those that are mandatory

4.330 utilisation, where possible, of descriptive and intuitive field names and/or data types rather than codes or abbreviations. Where codes are used these must be fully described in the online help facility

4.331

• there should be fast-track access for experienced users without going through menus

`

4.332 • users must be able to move and resize viewing windows

4.333 The system must be able to provide the following clear and concise warning and error messages:

4.334 • warning messages must warn, but further action should be permitted

4.335 • warning and error messages must be written in plain English with a description of what action should be taken by the user

4.336 • error messages must inhibit further action

of 65



4.337 Search facilities

4.338 The software shall include comprehensive search facilities easily accessible from any screen

4.339 2.1.1 Note pad facilities 2.1.2

4.340 The software should provide a comprehensive note pad facility

4.341 The note pad should, at a minimum, be able to:

4.342

• hold notes specific to different areas of revenues and benefits activity, but interlinked such that users can view notes from all areas for which they have access permission

4.343 • provide a fully featured editing facility for the note pad which allows users to edit notes or parts of notes and perform simple formatting functions such as paragraph breaks

4.344 • hold an audit trail of notes made, edited and deleted by staff, recording relevant details, eg the changes made to the date and the user ID

4.345 • allow the user to determine the priority or urgency of a note or part of a note

4.346 There should be a facility to organise notes or note pad entries in a meaningful way, preferably with the most recent entries displayed at the top of the note or list of notes

4.347 Users should be able to define the order in which notes or note pad entries are displayed, possibly ordering notes by date, priority, user, subject or other criteria

4.348 It should be possible to use notes, or parts of notes, in management reporting and in the production of standard documents, such as letters, from the system without the need to retype text

4.349 Management reporting

`

of 65



4.350 The software must provide plain English management reports on any range of operational information

4.351 The software must provide a range of statistical information in standard reports

4.352 Users should be able to determine the number of copies of reports printed and, where appropriate, the output type and location, eg Word format on file, printed to LaserJet Printer

4.353 A ‘print preview’ function should be provided allowing the user to see the output that will be generated on-screen prior to the processing of the print action

4.354 There must be a facility to schedule report production as required by the user, or run an ad-hoc report immediately, providing the user has appropriate access permissions

4.355 The software must allow users to produce reports on local printing facilities or on externally provided bulk printing services

4.356 Facilities must be available to manage report scheduling such that reports can be produced on a pre-determined frequency and timescale

4.357 The priority of report processing should be configurable so that reports can be run as a ‘foreground’ process for maximum production performance or as a ‘background’ task for minimal effect on system responsiveness for users

4.358 There should be facilities to provide information about reports either on-screen or on the reports themselves. For example, the report might be configured to have a header page showing the report name, how may pages the report has, what date it was produced, and who should receive the report

4.359

Fully comprehensive ad-hoc reporting tools must be provided for users to easily create non-standard reports

4.360 The ad-hoc reporting facility should include the following functionality:

`

of 65



4.361 • built-in support and configuration for the full database structure so that the ad-hoc query tool can effectively be used to report on any field or other element of the database

4.362 • an easy to use report production facility, preferably with a graphical interface

4.363 • the ability to create complex reports with minimal knowledge of query languages or other development environments

4.364 • an on-screen output facility so that the results of ad-hoc reports can be displayed quickly

4.365 • tabling and charting facilities allowing reports to be analysed and presented visually

4.366 • drill-down facilities allowing the user to review on-screen the raw data making up the report output and hence reconcile any errors

4.367 validation rules incorporated in the report-writing tool minimising the probability of errors in reporting

4.368 Standard reports should be editable by the ad-hoc reporting facility, although the original standard report should be protected from inadvertent corruption, eg by being marked read-only

4.369 Performance management

4.370 In addition to the provision of management reports relating to the service, the software must be able to provide the following facilities to allow the monitoring and management of staff performance

`

4.371 • facilities to allow team leaders and other senior staff to monitor and validate tasks, eg checking of outgoing documentation with or without the knowledge of the user

4.372 • facilities for the remote control or viewing of users PC desktops, so that management staff can monitor staff or assist them with difficult transactions

of 65



4.373 • reports on performance standards for users, eg document throughput or in-tray queue volume

4.374 • performance indicator measurement reports, for users, teams or the service as a whole

4.375 Security and audit requirements

4.376 Audit trail

4.377 Software control and integrity of data are fundamental to the operation of the software. The software must produce an effective audit trail of all transactions and system changes

4.378 All update transactions must be logged with user ID, user name, date and time

4.379

All history data must be marked similarly to show when it was changed. Screen availability of the history must include the change information

4.380 The software should provide an on-screen viewing facility showing, for each amendment to existing data, a before and after image of the amendment, which shall include the user identity, and the date and time of amendment

4.381 Where transactions backdate changes there must be no loss of any original audit trail. Suppliers must describe how this is achieved

`

4.382 The system must provide an audit trail for any system codes created or deleted, eg transaction codes

4.383 The audit trail must be considered as data for reporting and archiving purposes

4.384 The system must be secure enough to prevent deliberate or accidental penetration

4.385 Authorised users must be able to retain control over any default auditing actions, and amend these whenever necessary. However, such changes must be recorded in a permanent log with the identity of the user making such changes and the date and time of such changes

of 65



4.386 Software access control

4.387 Security must be sufficiently flexible to restrict user access by

• job function • hierarchy within the organisation or section • other user-definable levels

4.388

The software must allow different levels of access based on user set-up, ranging from no access at all (hidden) to full control

4.389 The system’s access control set-up process must allow for the setting up of user groups, which can be subsequently tailored for individuals within the group or on an individual basis

4.390 Security access control should be provided down to field level within the database, eg access to specific data fields can be restricted to individual users

4.391 Data entry and input screens must be customisable to reflect the level of security granted to the user, such that only admissible menu items, icons or windows are available

`

4.392 Comprehensive password security and management should be provided which includes, but is not limited to, the following characteristics

4.393 • passwords must not be visible during entry

4.394 • passwords format must be definable by administrative users

4.395 • password data must be encrypted at all times

4.396 • users entering an incorrect password more than a preset number of times must be locked out, with access permission being reinstated following rules defined by administrative users, eg after a preset time or after being reset by an administrator

of 65



4.397 • users must be forced to change passwords after a preset time interval, with rules applied preventing users from reusing a password within a preset time, number of password iterations, or other user-defined rules

4.398

The software must record and report incidents of failed access due to the use of invalid passwords

4.399 The System Administrator (the highest access level user) must be able to reset passwords, to set up or delete users from the software and to change rules relating to user access

4.400 A user should be logged out of the software automatically after a time period, preset by an administrative user, of no activity with no loss of data integrity

4.401 Any software products used in association with the main software should comply with the access criteria set for each user in the main software. The generation of users’ access profiles in the main software must be replicated automatically in any associated products and should not require separate user access profile set up An example will be third party reporting tools where each user’s access must be in accordance with that allowed in the main software

`

4.402 Data validation

4.403 The software shall apply comprehensive validation rules to all data to ensure that it is consistent, reasonable and within specified ranges

4.404 Validation rules and ranges shall be configurable by users with relevant access permissions

4.405 Data must be validated at the point of entry to ensure it is consistent with database rules relating to field size, field type, duplication, code type and other integrity issues

4.406 User-definable validation rules must be applied to data being imported to or exported from the software database

4.407

Similarly, rules relating to the treatment of invalid data imported, exported or input by users must

`

of 65



be included in the software, including user definable rules where appropriate

4.408 Data lost due to software or power failure must be minimal and recovery procedures easy to establish, with warnings given for any invalid or incomplete data held

4.409 In the event of operational problems, data archival and recovery procedures must be available, preferably using automated procedures and built-in data integrity checking

4.410 The software must facilitate compliance with the requirements of the Data Protection Act 1998 and the Freedom of Information Act 2000

4.411

Resilience and backup

4.412 The LA has a requirement for a reliable and resilient transaction audit recovery service that is easy to operate and which is not significantly detrimental to system performance

4.413 Placement of application code, data files and audit recovery files should reflect resilience requirements, with regard to the Council’s Application Data Security Policy.

4.414 After hardware, software or other failures ‘roll out’ of incomplete transactions must be immediate and automatic

4.415 All system and application software changes and patches must be documented and subject to fully documented change control procedures

4.416 All failures must be automatically logged on the system

4.417 A fast means of taking security/backup copies of part and/or whole databases should be available together with restore procedures matched in performance

`

4.418 The system must have the facility for both automatic and user defined archiving procedures

of 65



4.419 The application database should be designed with security copies in mind and as such split into areas that can be archived on a daily, weekly, monthly or yearly basis as appropriate

4.420 A log of all security copies taken and restores done should be kept automatically

4.421 Server exchange media support will include, but is not limited to, CD-ROM, DVD-ROM, DLT and DAT drives

4.422 The backup and restoration facilities provided must include automatic procedures to check the appropriateness of the data and state of the media. For example, when restoring from a tape the system should check the availability of the relevant file(s), and when backing up to a tape, the system should check the tape is suitable for overwriting

4.423 Archiving of Older Records

4.424 In addition to system backup facilities, the software shall provide a facility to archive records to removable media such as CD-ROM or DVD-ROM, under the control of authorised users

4.425 It should be possible to mark any record so that archiving does not take place in respect of that record

4.426 The software will report and create a batch of records/accounts appropriate for archiving on request (user to define criteria within each application)

4.427 Online help facilities

4.428 The online help facility shall:

4.429 • be accessible from any screen by clicking a single icon, menu item or key

4.430 • be context sensitive dependent on the screen or function currently being accessed

4.431 • include reference to relevant legislation where applicable

of 65



4.432 • include links to the Web or other third party help where appropriate

4.433 • allow customised content specific to users to be added by the LA as required

4.434 Batch processing

4.435 The software must provide a facility to schedule and run batch jobs

4.436 Such facilities must be operable by users

`

4.437 Any error messages, particularly relating to failed batch jobs, shall be clear and easy to understand

4.438 The software shall allow user-definable behaviour when errors in batch processes take place, with full reporting of all errors and a facility to ‘roll back’ a failed job to a previous state or re-run it from the point where it failed

4.439 System priorities for handling of batch and on-line functions shall be controllable by users

4.440 Users should be able to specify limits to any run, either as a number of records to be processed or as an amount of elapsed time. When a run terminates having reached its limit, it shall be easily possible to restart at the next record

4.441 Central monitoring of batch run progress must be available, including appropriate action should a batch run fail or some other error occur

4.442 A journal or other record must be available of all batch runs done, including any errors encountered and the action taken

4.443 System performance and testing

4.444 Response times shall be within the following bands:

4.445 • on-screen search/enquiries – less than three seconds

4.446 • on-screen update – less than three seconds

`

4.447 • simple report enquiry – less than one minute

of 65



4.448 • complex report – less than 30 minutes

4.449 Ad-hoc enquiries of the database must be available during the day without noticeably affecting performance on the on-line system. It is NOT expected to have to resort to the use of an archived or compacted database for this and backup enquiry services

4.450 Suppliers shall make allowance within sizing for the permanent residence on the system of suitable sized training and testing databases and application systems

4.451 The software shall provide the facility to generate a test version of the system and database

4.452 The test version must be a fully functional version with all features available that are present in the live version

4.453 Integration and interfaces

4.454 System interfaces will be required as part of the project implementation to the following systems:

4.456 Council Tax , NDR and Benefits system I World (Housing) EMS Education suite FLARE (Environmental Service) UNIFORM (Planning)

SBS (Highways/Maintenance) I World (Revenues + Benefits) SOLICITEC MS OFFICE, including Word, XL, Project & PowerPoint

4.457 • HB Overpayments debtor system 4.458 • Corporate Property Gazeteer

4.459 • Verification Framework (VF) application

4.460 • telephone system

4.461 • XML compliant databases

4.462 • ODBC compliant databases

4.463 The system must be able to accept electronic

of 65



data downloads from external systems to populate the system database

4.464 • full XML support

4.465 Office automation product integration

4.466 The software must be integrated with the LA’s existing word processing package

4.467 Integration must include, but is not limited to:

4.468 • the ability to output documents and reports using data from the software database to populate the document, which might be a single ad-hoc document or a large mail-merge

4.469 • the ability to edit reports and documents produced from the software

4.470 • the ability to view Word documents using the software

4.471 • the facility to use report templates as the basis for standard documentation used by the software

4.472 The software should be integrated with the LA’s existing spreadsheet package

4.473 The software should be integrated with the LA’s existing database package

`

4.474 Integration must include, but is not limited to:

4.475 • the ability to output data and reports, using data from the software database to populate the spreadsheet/database

4.476 • the ability to import reports and documents produced from into the software

4.477 • the software should be able to allow the text for any spreadsheet/database to be held with variable data being drawn from within the software through coded fields

of 65



4.478 All integration features described above should apply equally to the systems and applications, which the LA may migrate to in the foreseeable future

4.479 There shall be an audit report of all documents produced

4.480 It shall be possible to set up standard paragraphs etc and use them in a document by specifying a code or choosing from a menu list

4.481 The software shall be able to print labels and envelopes, with the format and date defined by user

4.482 Documents or links to documents must be stored in the DMS such that users can reproduce exact copies of the documents produced on demand from the DMS software

4.483 Capacity

4.484 The proposed system must allow at least 200 concurrent Package 1 on – line users (see section 2.6) utilizing any combination of the functionality described in this document. For Package 2 at least 750 concurrent on-line users should be allowed for

4.485 The proposed system must allow for online scanning and indexing at each location, with no loss of system performance.

4 EDRMS – Service Requirements ID Service Requirement Supplier Response 4.486

Implementation

4.487 The Tenderer will be responsible for ensuring that the installation and implementation of the system results in a secure, reliable, fully functional system performing in accordance with the requirements stated in this specification and operated by adequately trained staff.

of 65


ID Service Requirement Supplier Response

4.488 The Tenderer in their bid should set out all installation costs which shall include but not be limited to: • carry out site visit/audit to establish delivery

requirements and suitable installation • install server hardware (if required) • install and configure the disks • install and configure the magnetic tape device •

•

•

•

•

•

•

•

install, configure and test remote systems diagnostics

install, set up and test UPS for automatic tidy shutdown in the event of power shutdown

• install OPERATING SYSTEM on

server/hardware

configure OPERATING SYSTEM with appropriate patches to latest repair level

determine database/application configuration

• install and configure any OEM software

required • install the application modules

set up all database/application automatic start up and shutdown scripts

• determine local print strategy • configure system for bulk output requirements

configure and test back up and recovery. Tenderers are requested to provide full details of all necessary scripts

set up PC clients

set up batch scheduler requirements for interfaces, job failures out of hours and batch runs

• test and optimise performance • compile system documentation

of 65


ID Service Requirement Supplier Response

4.489 The Tenderer should provide on-site help when requested by the user. This must cover system consultancy and advice as well as technical assistance if required, for the duration of the implementation period and beyond

4.490 Support and Maintenance

4.491 The Tenderer should ensure that the level of support provided is maintained to an acceptable standard on days specified by the user not withstanding that the Tenderer might have different Bank Holidays from the user.

4.492 Due to the critical nature of the system, the Tenderer will be required to guarantee replacement of any key hardware/software components within 24 hours of logging the problem if on-site repair proves impossible

4.493 The Tenderer should provide the facility to dial into the system by RAS connection via the Council’s firewall as per the Council’s Third Party Access Policy to enable potential problems to be rectified. This facility should be under the control of the LA’s IT staff or its appointed agents

.494

The Tenderer must provide expert support and maintenance for the lifetime of the system.

4.495 Documentation

4.496 The Tenderer should provide supporting user documentation for the current version of the software supplied which must be updated with all new releases of software. This assistance should consist of on-line help screens provided by the Tenderer, which can be tailored by the LA’s System Administrator if necessary. The help documentation should provide a quick reference guide for easy navigation throughout the system

4.497 The Tenderer should provide comprehensive documentation describing the resolution of known faults and problems areas. The documentation should provide guidance on error handling routines and error messages

4.498 The Tenderer should provide full supporting documentation for the supplied system interfaces. This must also contain the file layouts for all

of 65


ID Service Requirement Supplier Response input/Output files

4.499 Project Management Responsibilities

4.500 The Tenderer’s Project Manager will be responsible for the following:

• prime responsibility for all project communication

•

•

•

•

•

planning, organising and controlling all Tenderer project activities

project reporting

responsibility for all sub-contractor activities and contractual matters

responsibility for agreeing the implementation procedures in conjunction with Milton Keynes Council’s Project Manager

creating and maintaining a quality plan for the project

4.501 Training

4.502 The Tenderer must deliver all implementation and user training at Milton Keynes Council’s Headquarters or at any remote offices as required.

of 65


5. ADDITIONAL INFORMATION REQUIREMENTS

Tenderers must answer all of the questions detailed below ensuring that all of the information requested is provided.

5.1. Hardware

Recommended hardware specifications should be provided separately, along with details of how the proposed configuration has been sized. Note: Milton Keynes Council reserves the right in future to purchase any hardware from alternative service providers.

5.2. Response Times / Performance Issues/Capacity

5.2.1. Tenderers are requested to provide details of the average search and

retrieval times for documents stored both online and offline.

5.2.2. Tenderers must demonstrate a detailed knowledge of the document: “Defining the Electronic Social Care Record” published by the Department of Health and understand the implications of the document for EDRMS systems.

5.2.3. Any proposed solution must achieve the performance requirements as

defined in items 4.443 to 4.449 of the Technical specification whilst utilising existing wide and local area data communications facilities currently in place within Milton Keynes (as described in Section 2.1) If Tenderers feel that this is not achievable they are requested to provide details of (i) the specifications required to achieve the stated performance requirements and (ii) the performance capability of the Tenderer’s proposed solution given the Council’s stated data communications facilities.

5.2.4. Tenderers are requested to provide appropriate specifications for

servers, client and any other hardware required to enable the proposed system to exhibit the required level of performance for the proposed number of users.

5.3. Scanners / Hardware / Software etc

5.3.1. Tenderers are requested to provide specifications for both the flat bed

and automatic feed scanners required to counter scan at any location and also for bulk scanning.

5.3.2. Tenderers are requested to provide appropriate specifications for the

scanners required to handle the volumes of documents which the proposed system would be expected to process both in central and remote area offices.

5.3.3. Tenderers are requested to detail their proposed hardware solution for

document storage and retrieval.

of 65


5.3.4. Tenderers are requested to detail any additional hardware or software requirements to allow the implementation of COLD technology.

5.3.5. Tenderers are requested to detail their proposed hardware and software

solutions for hand held devices utilising wireless technology.

5.3.6. Tenderers are requested to provide details of how software licences are priced and what device is used to gauge banding.

5.3.7. Tenderers are requested to propose hardware platforms on which the

software will run.

5.3.8. Tenderers are requested to provide details of the PC capacity and monitor size and type, which they recommend for the operation of their software, i.e. the minimum standards including the hardware configuration.

5.4.

5.4.1.

5.5. Training

5.5.1.

5.5.2.

5.6.

5.6.1.

5.6.2.

5.6.3.

5.6.4.

Data Conversion

Tenderers are requested to detail how any database required for document indexing is created in the first instance.

Tenderers are requested to provide details of the training courses available as part of the implementation, providing details of which staff should attend and the length and content of each course and at what stage in the project training would take place.

Tenderers are requested to provide details of the technical training available for staff involved in the set up, maintenance and support of the system.

Support and Maintenance

Tenderers are requested to provide details of any on line help facility, which is available. Tenderers are requested to provide full details of their user help desk service, including information on availability. Tenderers are requested to provide details of their escalation procedures for dealing with software faults and system failures. Tenderers are requested to provide details of the company’s technical facilities in respect of the following:

• logging and management of queries and requests for assistance via the help desk

• number of staff dedicated to support

• ability of the company to provide a response to faults on-site at Milton Keynes Council offices within a specified time span

of 65


• location from which that support would be provided 5.6.5.

5.6.6.

5.6.7.

5.6.8.

5.6.9. 5.6.10.

5.6.11.

5.6.12.

5.6.13.

5.7. Implementation

Tenderers are requested to provide details of the response performance criteria and committed service levels for specific categories of faults, errors or other technical problems. Tenderers are requested to provide details of their policy regarding new issues of software. This must include how many product version releases are made each year, the procedure for installation and any associated costs. Tenderers are requested to provide details of their procedures for the provision of Software upgrades, enhancements and maintenance requests including the handling of legislative requirements and any associated costs. Tenderers are requested to provide details of their management of change control and also of their system design methodology for software changes brought about by User request or legislative change. Tenderers are requested to provide details of any internet support provided. Tenderers are requested to provide details of any user groups and any associated costs. Tenderers are requested to provide copies of their standard supply and maintenance contracts, including service level agreements. Tenderers are requested to advise whether they are prepared to enter into an ESCROW agreement with NCC and the Council and if so the associated costs. Tenderers are requested to provide details of the levels of service offered for post implementation hardware, operating system and database support.

Note: Milton Keynes Council reserves the right to pursue their own arrangements for any or all of the above post implementation support services.

5.7.1. Tenderers are requested to provide an Implementation Programme

showing the order in which the Tenderer proposes to carry out the Services. This Implementation Programme must be expressed in terms of elapsed time and calendar dates. Tenderers should note that acceptance of a Tender shall not imply acceptance of an Implementation Plan.

To assist Tenderers in this task the critical dates anticipated by the Council are as follows: - • Submission of Tenders 6th June 2005 • Possible interviews/site visits w/c 13th June 2005 • Notification of Successful/

Unsuccessful Tenders 27th June 2005 • Contract Commencement Date By 4th July 2005 • Live Implementation date (ESCR

live for new records) 30th October 2005

of 65


5.7.2. Tenderers are requested to provide details of the development stages and the anticipated level of Milton Keynes Council resource that would be required to support the implementation.

5.7.3. Tenderers are requested to provide details of any aspect of the proposed

solution that is provided by a third party or secondary supplier giving details of how this will be managed and co-ordinated.

5.8. Printing

5.8.1. Tenderers are requested to provide details of any proposed printing solutions requiring additional hardware along with a specification for the hardware.

5.9. Technical Environment

5.9.1. Tenderers are requested to provide details of appropriate technical environments for their proposed solution including the following:

• Hardware Platforms (Client and all proposed servers) • Function of all proposed servers • Scanners • Development Software, including report writing software • Relational Database Management Systems • Operating Systems • Graphical User Interfaces • Terminal Emulators/Connectivity • Communications (Hardware and Software) • Networking Hardware and Software • Middleware • Local and Remote Printing

5.10. Intranet

5.10.1.Tenderers are requested to provide details of how their solution integrates

with Microsoft’s Exchange and Internet Information Server, providing detailof any future plans or developments in this area.

5.11. Internet

5.11.1.Tenderers are requested to provide details of how Internet technology can currently be used in their proposed system, providing details of any future plans or developments in this area.

5.12. PC Windows Applications

5.12.1.If the proposed system has the facility to import/export to/from PC Windows applications, e.g. word-processing, spreadsheets package etc, tenderers should provide details of the package and version compatability.

of 65


5.13. Archiving

5.13.1.The system must provide for the archiving of data. Tenderers are requested to provide details of how this would be implemented, providing specifications of any additional hardware required.

5.13.2.Tenderers are requested to provide details of how archived data is retrieved

on the system. 5.14. Back Up Facilities

5.14.1.Tenderers are requested to provide the following details about back up facilities:

• data back up routines • data recovery in the event of system and or machine failure • data recovery in the event of corruption • disaster data recovery • length of time required to recover data

5.15. Future Developments

5.15.1. Tenderers are requested to provide details of their proposed

programme of future system development.

5.16. Back-Scanning

5.16.1. Tenderers are requested to provide a cost indication for scanning 1 million documents contained within Social Care files and to provide details of how volume back-scanning could be utilised for selected documents, giving details of past experience of this task.

5.17. Documentation

5.17.1. The Tenderer must detail the system documentation available giving the

numbers which will be provided free of charge and the cost of additional copies.

5.18. Disaster Recovery

5.18.1. The Tenderer must provide details of the business continuity arrangements it has in place for its software and any associated hardware.

5.19. Security

5.19.1. The Tenderer must detail the how the system prevents unauthorised

deliberate or accidental penetration.

of 65


6. PRICING SCHEDULE

The service provider shall provide a detailed breakdown of all Prices in relation to their solution, including all software costs, hardware costs, licence costs. These costs should be supplied for a five-year period. Please note the option to extend the contract period as specified in Special Condition 1 of the Contract Conditions.

6.1. Where the proposed solution includes requirements that are subject to future

development, these costs must be detailed separately under the relevant heading

6.2. All Prices for the implementation and maintenance of the proposed system should be

included

6.3. Costs detailed elsewhere in the service provider’s proposal but not included here will

presume to have been waived

6.4. Prices should be quoted at current Sterling prices (exclusive of VAT).

6.5. Prices shall be list price with any discounts being offered shown separately

6.6. Prices should be detailed in the attached schedules for Package 1 and Package 2

6.7. Where any quoted Prices are based on the number of users, volumes of transactions or

other measurements, the service provider shall give full details of the methodology and

numbers used in the notes / comments column of the schedules

6.8. If additional space is required please use the page (s) provided

of 65


NAME OF SERVICE PROVIDER PACKAGE 1 COSTS

DESCRIPTION

PACKAGE 1 COSTS 2005/6 £

ANNUAL PACKAGE 1 COSTS 2006/7 £




NOTES / COMMENTS

LICENCES Application Software Database Software Other Software - please specify

Sub-Total of Software Costs

of 65


of 65

NAME OF SERVICE PROVIDER

DESCRIPTION






NOTES / COMMENTS

HARDWARE

OPERATING SYSTEM SOFTWARE

Sub-Total of Hardware and Operating System Software Costs



DESCRIPTION






NOTES / COMMENTS

IMPLEMENTATION SERVICES Project Management/Consultancy Installation Data Conversion/Extract System Configuration / Testing

Sub - Total for Implementation Services Costs

of 65



DESCRIPTION






NOTES / COMMENTS

DOCUMENTATION

Sub - Total for Documentation Costs

TRAINING - TECHNICAL TRAINING – USER

Sub - Total for Training Costs MAINTENANCE

Sub - Total for Maintenance OTHER COSTS - please specify

Sub - Total for Other Costs TOTAL PACKAGE 1 COSTS

of 65 ADDITIONAL NOTES RELATING TO ITEMS DETAILED IN PACKAGE 1



NAME OF SERVICE PROVIDER PACKAGE 2 COSTS

DESCRIPTION





NOTES / COMMENTS

LICENCES Application Software Database Software Other Software - please specify

Sub-Total of Software Costs

of 65


of 65


DESCRIPTION





NOTES / COMMENTS

HARDWARE

OPERATING SYSTEM SOFTWARE

Sub-Total of Hardware and Operating System Software Costs



DESCRIPTION





NOTES / COMMENTS

IMPLEMENTATION SERVICES Project Management/Consultancy Installation Data Conversion/Extract System Configuration / Testing

Sub - Total for Implementation Services Costs

of 65



DESCRIPTION





NOTES / COMMENTS

DOCUMENTATION

Sub - Total for Documentation Costs

TRAINING - TECHNICAL TRAINING – USER

Sub - Total for Training Costs MAINTENANCE

Sub - Total for Maintenance OTHER COSTS - please specify

Sub - Total for Other Costs TOTAL PACKAGE 2 COSTS

NAME OF SERVICE PROVIDER ADDITIONAL NOTES RELATING TO ITEMS DETAILED IN PACKAGE 2 COSTS SCHEDULE

of 65



FUTURE DEVELOPMENT COSTS (Detail here costs relating to any items which the Service Provider has committed to the delivery of in the Response to the Requirements Specification – IF THESE COSTS ARE NOT ALREADY INCLUDED IN PRICE TABLES ABOVE)

DESCRIPTION

COSTS £

NOTES / COMMENTS

Software – please specify Other Costs – please specify

Total of Future Development Costs


ADDITIONAL NOTES RELATING TO ITEMS DETAILED IN FUTURE DEVELOPMENTS COSTS SCHEDULE This Pricing Schedule is signed for and on behalf of Name Date Position

of 65

Electronic Document & Records Management System Tender

Documents

Transcript of Electronic Document & Records Management System Tender