Supply Tender - Contracts · Web view3.1.1 Service Desk The provision of a Service Call centre (Service Desk) which provides operational Service Support to the Client / user base

ADVERT NUMBER:

CT181/2010

CT FILE NUMBER:

CT2168/2010

DEPT. REF: NBTC065/2010

TENDER FOR THE PROVISION OF A DOCUMENT CONTROL AND QUALITY

MANAGEMENT SOLUTION

Date Published: 16 NOV 2010

Closing Date: 11 JAN 2011 at 10:00am CET

Cost of the Tender Document: €40.00

IMPORTANT: Tenderers are to ensure that the mandatory tender guarantee (bid bond)

of €2,000 is to remain valid up to and including the 10 June 2011.

Clarifications shall be uploaded and will be available to view/download from www.contracts.gov.mt/tenders

http://www.contracts.gov.mt/tenders

Department of ContractsNotre Dame Ravelin, Floriana FRN 1600, Malta. Tel: (356) 21220212. Fax: (356) 21247681 Email:

[email protected]

Tender for a Document Management and Quality Control System

National Blood Transfusion Service

Page 2 of 163

mailto:[email protected]

Table of ContentsVOLUME 1 SECTION 1 – INSTRUCTIONS TO TENDERERS.................3A. GENERAL PART.......................................................................3B. TENDER DOCUMENTS..............................................................6C. TENDER PREPARATION............................................................7D. SUBMISSION OF TENDERS.....................................................10E. OPENING AND EVALUATION OF OFFERS..................................11F. CONTRACT AWARD................................................................14G. MISCELLANEOUS...................................................................16VOLUME 1 SECTION 2 – TENDER FORM.......................................18VOLUME 1 SECTION 3 – TENDER GUARANTEE FORM....................22VOLUME 1 SECTION 4 - TENDERER’S STATEMENTS.....................23VOLUME 1 SECTION 5 – GLOSSARY.............................................26VOLUME 1 SECTION 6 – EXTRACTS FROM THE PUBLIC PROCUREMENT REGULATIONS...................................................28VOLUME 2 SECTION 1 – DRAFT CONTRACT FORM and SAMPLE CONTRACT................................................................................30SAMPLE CONTRACT...................................................................32VOLUME 2 SECTION 2 – GENERAL CONDITIONS...........................63VOLUME 2 SECTION 3 – SPECIAL CONDITIONS.............................64VOLUME 2 SECTION 4 – SPECIMEN PERFORMANCE GUARANTEE...66VOLUME 3 SECTION 1 – CONTRACTING AUTHORITY’S REQUIREMENTS (TERMS OF REFERENCE)...............................................................67VOLUME 3 SECTION 2 – TENDERER’S BUSINESS AND TECHNICAL OFFER......................................................................................88Volume 3 SECTION 3 TENDERER’S ARCHITECTURE RESPONSE...143Volume 3 SECTION 4 INTEROPERABILITY STANDARDS...............150VOLUME 4 - FINANCIAL BID......................................................................160

~~~~~~~~~~~~~~~



Page 3 of 163

VOLUME 1 SECTION 1 – INSTRUCTIONS TO TENDERERS

A. GENERAL PART

1. General Instructions

1.1 In submitting a tender, the tenderer accepts in full and in its entirety, the content of this tender document, including subsequent Clarifications issued by the Central Government Authority, whatever his own corresponding conditions may be, which he hereby waives. Tenderers are expected to examine carefully and comply with all instructions, forms, contract provisions and specifications contained in this tender document.

No account can be taken of any reservation in the tender as regards the tender document; any disagreement, contradiction, alteration or deviation shall lead to the tender offer not being considered any further.

The Evaluation Committee shall, after having obtained approval by the General Contracts Committee, request rectifications in respect of incomplete/non-submitted information pertinent to the documentation as outlined in sub-Clause 16.1(a), 16.1(b), and 16.1(c) of these Instructions to Tenderers. Such rectification/s must be submitted within two (2) working days from notification, and will be subject to a non-refundable administrative penalty of €50: failure to comply shall result in the tender offer not being considered any further.

No rectification shall be allowed in respect of the documentation as outlined in sub-Clause 16.1(d), 16.1(e) and 16.1(f) of these Instructions to Tenderers. Only clarifications on the submitted information in respect of the latter may be eventually requested.

1.2 The subject of this tender is the provision of a Document Control and Quality Management Solution for the National Blood Transfusion Service at the Government of Malta Health Services.

1.3 The place of acceptance of the supplies shall be the National Blood Transfusion Services, Malta

1.4 This is a lump-sum contract, however, the bidder is to quote for each sub-item separately. Non-compliance will the conditions of this sub-clause will invalidate the tender.

1.5 The tenderer will bear all costs associated with the preparation and submission of the tender. The Central Government Authority will in no case be



Page 4 of 163

responsible or liable for such costs, whatever the conduct or outcome of the procedure.

1.6 The Central Government Authority retains ownership of all tenders received under this tender procedure. Consequently, tenderers have no right to have their tenders returned to them.

2. Timetable

DATE TIME*Clarification Meeting/Site Visit(Refer to Clause 9.1) 14th December 2010 10:00am

Deadline for request for any additional information from the Contracting Authority 27th December 2010 12:00

Last date on which additional information are issued by the Contracting Authority 5th January 2011 12:00

Deadline for submission of tenders / Tender Opening Session(unless otherwise modified in terms of Clause 11.3)

11th January 2011 10:00am

* All times Central European Time (CET)

3. Lots

3.1 This tender is not divided into lots, and tenders must be for the whole of quantities indicated. Tenders will not be accepted for incomplete quantities.

4. Financing

4.1 The project is financed from local budget funds.

4.2 The beneficiary of the financing is The National Blood Transfusion Services.

5. Eligibility

5.1 Participation in tendering is open on equal terms to all natural and legal persons of the Member States of the European Union, the beneficiary country, any other country in accordance with Regulation 76 of the Public Procurement Regulations.

5.2 Natural persons, companies or undertakings who fall under any of the conditions set out in Regulation 50 of the Public Procurement Regulations, 2010 (Legal Notice 296 of 2010) may be excluded from participation in and the award of contracts. Tenderers or candidates who have been guilty of making false declarations will also incur financial penalties representing 10% of the total value of the contract being awarded.

5.3 Tenders submitted by companies forming a joint venture/consortium must also fulfil the following requirements:

One partner must be appointed lead partner and that appointment confirmed by submission of powers of attorney signed by legally empowered signatories representing all the individual partners. The tender must include a preliminary agreement or letter of intent stating



Page 5 of 163

that all partners assume joint and several liability for the execution of the contract, that the lead partner is authorised to bind, and receive instructions for and on behalf of, all partners, individually and collectively.

All partners in the joint venture/consortium are bound to remain in the joint venture/consortium until the conclusion of the contracting procedure. The consortium/joint venture winning this contract must include the same partners for the whole performance period of the contract other than as may be permitted or required by law.

5.4 All materials, equipment and services to be supplied under the contract must originate in an eligible country. For these purposes, "origin" means the place where the materials and/or equipment are mined, grown, produced or manufactured and/or from which services are provided.

6. Selection Criteria

6.1 In order to be considered eligible for the award of the contract, tenderers must provide evidence that they meet or exceed certain minimum qualification criteria described hereunder.

In the case of a joint venture, the joint venture as a whole must satisfy the minimum qualifications required below.

6.1.1 No evidence of economic and financial standing is required.

6.1.2 Information about the tenderer's technical capacity.

(An economic operator may, where appropriate and for a particular contract, rely on the capacities of other entities, regardless of the legal nature of the links which it has with them. It must in that case prove to the contracting authority that it will have at its disposal the resources necessary for the execution of the contract, for example, by producing an undertaking by those entities to place the necessary resources at the disposal of the economic operator)

This information must follow the form in Volume 1, Section 4 of the tender documents and include:

Evidence of relevant experience in carrying out services in the provision of similar solutions for the past 3 (three) years including the nature and value, as well as contracts in hand and contractually committed. In so listing the end clients, the tenderer is giving his consent to the Evaluation Committee, so that the latter may, if it deems necessary, contact the relevant clients, with a view to obtain from them an opinion on the works provided to them, by the tenderer.

A list of the key experts and other staff proposed for the execution of the contract. These shall be fluent in English. The Evaluation Committee reserves the right to request the tenderers to substantiate their claims in respect to the staff proposed by requesting CVs of key staff and signed Declarations of Exclusivity and Availability during the evaluation stage.

7. Only One Tender Per Tenderer



Page 6 of 163

7.1 Submission or participation by a tenderer in more than one tender for a contract will result in the disqualification of all those tenders for that contract in which the party is involved.

7.2 A company may not tender for a given contract both individually and as a partner in a joint venture/consortium.

7.3 A company may not tender for a given contract both individually/partner in a joint venture/consortium, and at the same time be nominated as a subcontractor by any another tenderer, or joint venture/consortium.

7.4 A company may act as a subcontractor for any number of tenderers, and joint ventures/consortia, provided that it does not participate individually or as part of a joint venture/consortium, and that the nominations do not lead to a conflict of interest, collusion, or improper practice.

8. Tender Expenses

8.1 The tenderer will bear all costs associated with the preparation and submission of the tender.

8.2 The Central Government Authority will neither be responsible for, nor cover, any expenses or losses incurred by the tenderer through site visits and inspections or any other aspect of his tender.

9. Clarification Meeting/Site Visit

9.1 A clarification meeting/site visit will be held on the date and time indicated in Clause 2, at the premises of MITA at Gattard House, National Road, Blata l-Bajda to answer any questions on the tender document which have been forwarded in writing, or are raised during the same meeting. Minutes will be taken during the meeting, and these (together with any clarifications in response to written requests which are not addressed during the meeting) shall be posted online as a clarification note as per Clause 11.2.

Meetings/visits by individual prospective tenderers during the tender period other than this meeting/site visit for all prospective tenderers cannot be permitted.

B. TENDER DOCUMENTS

10. Content of Tender Document

10.1 The set of tender documents comprises the following documents and should be read in conjunction with any clarification notes issued in accordance with Clause 24:Volume 1 Instructions to TenderersVolume 2 Draft Contract

General Conditions (available online from www.contracts.gov.mt/conditions)

Special Conditions Volume 3 Technical SpecificationsVolume 4 Model Financial Bid



Page 7 of 163

http://www.contracts.gov.mt/conditions

10.2 Tenderers bear sole liability for examining with appropriate care the tender documents, including those design documents available for inspection, and any clarification notes to the tender documents issued during the tendering period, and for obtaining reliable information with respect to conditions and obligations that may in any way affect the amount or nature of the tender or the execution of the works. In the event that the tenderer is successful, no claim for alteration of the tender amount will be entertained on the grounds of errors or omissions in the obligations of the tenderer described above.

10.3 The tenderer must provide all documents required by the provisions of the tender document. All such documents, without exception, must comply strictly with these conditions and provisions and contain no alterations made by the tenderer.

11. Explanations/Clarification Notes Concerning Tender Documents

11.1 Tenderers may submit questions in writing to the Central Government Authority through:

sending an email to [email protected] online from the Registered Users’ Questions and Answers facility

within the tender’s page through www.contracts.gov.mt/contact-us fax number +356 21247681

up to 16 calendar days before the deadline for submission of tenders. The Central Government Authority must reply to all tenderers' questions, and amend the tender documents by publishing clarification notes, up to at least 6 calendar days before the deadline for submission of tenders.

11.2 Questions and answers, and alterations to the tender document will be published as a clarification note on the website of the Department of Contracts (www.contracts.gov.mt/tenders) within the respective tender’s page, under the subheading “Preview & Free Tender Documents, and Clarifications”. Clarification notes will constitute an integral part of the tender documentation, and it is the responsibility of tenderers to visit this website and be aware of the latest information published online prior to submitting their Tender.

11.3 The Central Government Authority may, at its own discretion, as necessary and in accordance with Clause 24, extend the deadline for submission of tenders to give tenderers sufficient time to take clarification notes into account when preparing their tenders.

12. Labour Law

12.1 Particular attention is drawn to the conditions concerning the employment of labour in Malta and the obligation to comply with all regulations, rules or instructions concerning the conditions of employment of any class of employee.

13. Law

13.1 By submitting their tenders, tenderers are accepting that this procedure is regulated by Maltese Law, and are deemed to know all relevant laws, acts and regulations of Malta that may in any way affect or govern the operations



Page 8 of 163


http://www.contracts.gov.mt/contact-us

mailto:[email protected]

and activities covered by the tender and the resulting contract.

C. TENDER PREPARATION

14. Language of Tenders

14.1 The tender and all correspondence and documents related to the tender exchanged by the tenderer and the Central Government Authority must be written in English.

14.2 Supporting documents and printed literature furnished by the tenderer may be in another language, provided they are accompanied by an accurate translation into English. For the purposes of interpretation of the tender, the English language will prevail.

15. Presentation of Tenders

15.1 Tenders must satisfy the following conditions:(a) Documents must be submitted in line with Volume 1 section 22

below. Both documents are to be separately sealed and placed in another sealed envelope/package so that the bid can be identified as one tender submission. Following the tender opening session, the copy shall be kept, unopened, at the Department of Contracts, for verification purposes only should the need arise.

(b) All tenders must be received by date and time indicated in the timetable at Clause 2 and deposited in the tender box at the entrance of the Department of Contracts, Notre Dame Ravelin, Floriana, FRN 1600, Malta.

(c) All packages, as per (a) above, must bear only:(i) the above address;(ii) the reference of the invitation to tender concerned;(iii) the number of the lot(s) to which the tender refers;(iv) the name of the tenderer.

16. Content of Tender (Single-Envelope System)

16.1 The tender must comprise the following duly completed documents, inserted in a single, sealed envelope (unless their volume requires a separate submission:

(a) An original bid-bond for the amount of €2000, in the form provided in Volume 1, Section 3(Note 1)

(b) General/Administrative Information(Note 2)

(i) Proof of Purchase of tender document (receipt) (ii) Statement on Conditions of Employment (Volume 1, Section

4)

Selection Criteria

(c) Financial and Economic standing – as per response format.



Page 9 of 163

(d) Technical Capacity(Note 3)

(i) Evidence of relevant experience and list of experts as per Volume 1 Section 1 (6.1.2), by completing the forms in Volume 1, Section 4 (2) and Section 4 (3)

(e) Evaluation Criteria/Technical Specifications(Note 3)

(i) Tenderer’s Technical Offer in response to specifications (Volume 3)

(f) Financial Offer/Bill of Quantities(Note 3)

(i) The Tender Form in accordance with the form provided in Volume 1, Section 2;

(ii) A financial bid calculated on a basis of Delivered Duty Paid (DDP) for the works/supplies tendered [inclusive of spare parts/after-sales services/maintenance/training as applicable] in the form provided in Volume 4.

g) The tender shall confirm that the following modules are included in the offer: Document Management module, Training management module, supplier management module.

h) All documentation and system instructions shall be submitted in English.

Notes to Clause 16.1:1. Tenderers will be requested to clarify/rectify, within two working days

from notification, the tender guarantee only in the following two circumstances: either incorrect validity date, and/or incorrect value.

2. Tenderers will be requested to either clarify/rectify any incorrect and/or incomplete documentation, and/or submit any missing documents within two working days from notification.

3. No rectification shall be allowed. Only clarifications on the submitted information may be requested.

Tenderers must indicate where the above documentation is to be found in their offer by using an index. All documentation is to be securely bound/filed.

Tenderers are NOT required NOR expected to submit, with their offer, any components of the tender document except those specifically mentioned in Clause 16.

17. Tender Prices

17.1 Tenderers will be deemed to have satisfied themselves, before submitting their tender, to its correctness and completeness, to have taken account of all that is required for the full and proper performance of the contract, and to have included all costs in their rates and prices.

17.2 The tender must be submitted in Euro (€).

17.3 Tenderers must quote all components of the price inclusive of taxes, customs and import duties, and any discounts. Except as may otherwise be provided for in the contract, no payment will be made for items which have not been costed.



Page 10 of 163

17.4 Intentionally left blank

17.5 If the tenderer offers a discount, the discount must be absorbed in the rates of the Bill of Quantities/Financial Statement.

17.6 The prices for the contract, must include all of the works to be provided. The prices quoted are fixed and not subject to revision or escalation in costs, unless otherwise provided for in the Special Conditions.

17.7 VAT and all other taxes as may be applicable are to be quoted in the rates offered.

18. Currencies of Tender and Payments

18.1 The currency of the tender is the Euro (€). All sums in the breakdown of the overall price, in the questionnaire and in other documents must be expressed in Euro (€), with the possible exception of originals of bank and annual financial statements.

18.2 Payments will be made upon certification of supplies by the Contracting Authority, based on the invoice issued by the Contractor, in accordance with the timeframes, terms and conditions of the contract.

18.3 All correspondence relating to payments, including invoices and interim and final statements, must be submitted as outlined in the contract.

19. Period of Validity of Tenders

19.1 Tenders must remain valid for a period of 150 days after the deadline for submission of tenders indicated in the contract notice, the tender document or as modified in accordance with Clauses 11.3 and/or 24. Any tenderer who quotes a shorter validity period will be rejected.

19.2 In exceptional circumstances the Central Government Authority may request that tenderers extend the validity of tenders for a specific period. Such requests and the responses to them must be made in writing. A tenderer may refuse to comply with such a request without forfeiting his tender guarantee (Bid Bond). However, his tender will no longer be considered for award. If the tenderer decides to accede to the extension, he may not modify his tender. He is, however, bound to extend the validity of his tender guarantee for the revised period of validity of the tender.

19.3 The successful tenderer must maintain his tender for a further 60 days from the date of notification of award.

20. Tender Guarantee (Bid Bond)

20.1 The tender guarantee is set at €2,000 (two thousand Euro) and must be an original and valid guarantee presented in the form specified in Section 3. The guarantee must be issued by a local Maltese Bank or a Financial Institution licensed by a recognized Financial Regulator in the country where the company is located and who assumes responsibility for claims and payments to the amount as stated above. It must remain valid up to and including the 10th June 2011. The tender guarantee must be drawn up in the name of the



Page 11 of 163

Director General of the Department of Contracts, Notre Dame Ravelin, Floriana, FRN 1600, Malta.

The tender guarantee (bid bond) is intended as a pledge that the tenderer will not retract his offer up to the expiry date of the guarantee and, if successful, that he will enter into a contract with the Director General of Contracts on the terms and conditions stated in the tender document.

Hence, the guarantee shall be forfeited if the tenderer withdraws his tender before the above-mentioned validity date or if the tenderer fails to provide the Performance Guarantee.

Tender guarantees provided by tenderers who have not been selected shall be released within 30 calendar days from the signing of the contract. The tender guarantee of the successful tenderer shall be released on the signing of the contract, and on submission of a valid performance guarantee.

Offers that are not accompanied with the mandatory Tender Guarantee (Bid Bond) by the Closing Date and Time of the tender will be automatically disqualified.

Tenderers will be requested to clarify/rectify, within two working days from notification, the tender guarantee submitted, only in the following two circumstances: either incorrect validity date, and/or incorrect value. Such rectification/s must be submitted within two (2) working days, and will be subject to a non-refundable administrative penalty of €50. Failure to comply shall result in the tender offer not being considered any further.

21. Variant Solutions21.1 No variant solutions will be accepted. Tenderers must submit a tender in

accordance with the requirements of the tender document.

22. Preparation and Signing of Tenders

22.1 All tenders must be submitted in one original, clearly marked “original”, and one identical copy (including all documentation as in the original) signed in the same way as the original and clearly marked “copy”. Tenders must comprise the documents specified in Clause 16 above.

It is the responsibility of the tenderers to ensure that both the original and the copy are an identical representation of one another.

22.2 The tenderer’s submission must be typed in, or handwritten in indelible ink. Any pages on which entries or corrections to his submission have been made must be initialled by the person or persons signing the tender. All pages must be numbered consecutively by hand, machine or in any other way acceptable to the Central Government Authority.

22.3 The tender must contain no changes or alterations, other than those made in accordance with instructions issued by the Central Government Authority (issued as clarification notes) or necessitated by errors on the part of the tenderer. In the latter case, corrections must be initialled by the person signing the tender.

22.4 The tender will be rejected if it contains any alteration, tampering, addition or deletion to the tender documents not specified in a clarification note



Page 12 of 163

issued by the Central Government Authority.

D. SUBMISSION OF TENDERS

23. Sealing and Marking of Tenders

23.1 The tenders must be submitted in English and deposited in the Department’s tender box before the deadline specified in Clause 2 or as otherwise specified in accordance with Clause 11.1 and/or 24.1. They must be submitted:

EITHER by recorded delivery (official postal/courier service) or hand delivered to:

Department of Contracts,Notre Dame Ravelin,Floriana, FRN 1600Malta

Tenders submitted by any other means will not be considered.

23.2 Tenderers must seal the original and the copy of their tender as outlined in Clause 15.

23.3 If the outer envelope is not sealed and marked as required in Sub clause 15.1, the Central Government Authority will assume no responsibility for the misplacement or premature opening of the tender.

24. Extension of Deadline for Submission of Tenders

24.1 The Central Government Authority may, at its own discretion, extend the deadline for submission of tenders by issuing a clarification note in accordance with Clause 11. In such cases, all rights and obligations of the Central Government Authority and the tenderer regarding the original date specified in the contract notice will be subject to the new date.

25. Late Tenders

25.1 All tenders received after the deadline for submission specified in the contract notice or these instructions will be kept by the Central Government Authority. The associated guarantees will be returned to the tenderers.

25.2 No liability can be accepted for late delivery of tenders. Late tenders will be rejected and will not be evaluated.

26. Alterations and Withdrawal of Tenders

26.1 Tenderers may alter or withdraw their tenders by written notification prior to the deadline for submission of tenders. No tender may be altered after the deadline for submission.

26.2 Any notification of alteration or withdrawal must be prepared, sealed, marked



Page 13 of 163

and submitted in accordance with Clause 23, and the envelope must also be marked with "alteration" or "withdrawal".

26.3 The withdrawal of a tender in the period between the deadline for submission and the date of expiry of the validity of the tender will result in forfeiture of the tender guarantee provided for in Clause 20.

E. OPENING AND EVALUATION OF OFFERS

27. Opening of Tenders

27.1 Tenders will be opened in public session on the date and time indicated in the timetable at Clause 2 (or as otherwise specified in accordance with Clause 11.1 and/or 24.1) at the Department of Contracts, Notre Dame Ravelin, Floriana, FRN 1600, Malta by the General Contracts Committee. They will draw up a ‘Summary of Tenders Received’ which will be published on the notice board at the Department of Contracts and shall also be available to view on the Department’s website, www.contracts.gov.mt/tenders.

27.2 At the tender opening, the tenderers' names, the tender prices, variants, written notification of alterations and withdrawals, the presence of the requisite tender guarantee and any other information the Central Government Authority may consider appropriate will be published.

27.3 Envelopes marked "withdrawal" will be read out first and returned to the tenderer.

27.4 Reductions or alterations to tender prices made by tenderers after submission will not be taken into consideration during the analysis and evaluation of tenders.

28. Secrecy of the Procedure

28.1 After the opening of the tenders, no information about the examination, clarification, evaluation or comparison of tenders or decisions about the contract award may be disclosed before the notification of award.

28.2 Information concerning checking, explanation, opinions and comparison of tenders and recommendations concerning the award of contract, may not be disclosed to tenderers or any other person not officially involved in the process unless otherwise permitted or required by law.

28.3 Any attempt by a tenderer to approach any member of the Evaluation Committee/Central Government Authority directly during the evaluation period will be considered legitimate grounds for disqualifying his tender.

29. Clarification of Tenders

29.1 When checking and comparing tenders, the evaluation committee may, after obtaining approval from the General Contracts Committee, ask a tenderer to clarify any aspect of his tender.



Page 14 of 163


29.2 Such requests and the responses to them must be made by e-mail or fax. They may in no circumstances alter or try to change the price or content of the tender, except to correct arithmetical errors discovered by the evaluation committee when analysing tenders, in accordance with Clause 31.

30. Tender Evaluation Process

30.1 The following should be read in conjunction with Clause 27.

30.2 Part 1: Administrative Compliance

The Evaluation Committee will check the compliance of tenders with the instructions given in the tender document, and in particular the documentation submitted in respect of Clause 16.

The Evaluation Committee shall, after having obtained approval by the General Contracts Committee, request rectifications in respect of incomplete/non-submitted information pertinent to the documentation as outlined in sub-Clause 16.1(a), 16.1(b), and 16.1(c) of these Instructions to Tenderers. Such rectification/s must be submitted within two (2) working days from notification, and will be subject to a non-refundable administrative penalty of €50: failure to comply shall result in the tender offer not being considered any further. No rectification shall be allowed in respect of the documentation as outlined in sub-Clause 16.1 (d), 16.1(e), and 16.1(f) of these Instructions to Tenderers. Only clarifications on the submitted information in respect of the latter may be eventually requested.

30.3 Part 2: Eligibility and Selection Compliance

Tenders which have been considered administratively compliant shall be evaluated for admissibility as outlined below:

(i) Eligibility Criteria

Tender Form (Volume 1, Section 2)

(ii) Selection Criteria

Evidence of technical capacity (sub-Clause 6.1.2)

30.4 Part 3: Technical Compliance

The tender will be awarded to the cheapest bid achieving technical compliance.

At this step of the evaluation process, the Evaluation Committee will analyse the administratively-compliant tenders’ technical conformity in relation to the technical specifications (Volume 3, and the documentation requested by the Contracting Authority as per sub-Clause 16(e)), classifying them technically compliant or non-compliant.

Technical compliance is achieved if the bid meets the minimum score indicated below for each section.

In the event that no bidder obtains a minimum score in all sections, the contracting Authority reserves the right to use the minimum overall score of 470. In the event that no bidder meets the minimum overall score, the



Page 15 of 163

Contracting Authority reserves the right to rank by highest score.

Part 1 Ability to Execute Maximum Score 100, Minimum Score 70

Score Goal 20Vision 20Viability 20Financial Aspects 20Legislation 20

Tenderer’s Technical Offer in response to specifications/Terms of Reference (Volume 3) Maximum Score 700, Minimum Score 400

Maximum Score

Minimum Score

Part 2 General Requirements

100 60

Part 3 Regulatory 100 60Part 4 Document and Process Management

150 100

Part 5 Training Management

100 65

Part 6 Supplier Management

100 25

Part 7 Security 100 65Part 8 Architecture Requirements

50 25

30.5 Part 4. Financial Evaluation

The financial offers for tenders which were not eliminated during the technical evaluation (i.e., those found to be technically compliant) will be evaluated.

The Evaluation Committee will check that the financial offers contain no arithmetical errors as outlined in Clause 31. The financial evaluation will have to identify the best financial offer.

31. Correction of Arithmetical Errors

31.1 Admissible tenders will be checked for arithmetical errors by the Evaluation Committee. Errors will be corrected as follows:

(a) where there is a discrepancy between amounts in figures and in words, the amount in words will prevail;

(b) where there is a discrepancy between a unit price and the total amount derived from the multiplication of the unit price and the quantity, the unit price as quoted will prevail.

31.2 The amount stated in the tender will be adjusted by the Evaluation Committee in the event of error, and the tenderer will be bound by that adjusted amount. In this regard, the Evaluation Committee shall seek the prior approval of the General Contracts Committee to communicate the revised price to the tenderer. If the tenderer does not accept the adjustment, his tender will be rejected and his tender guarantee forfeited.



Page 16 of 163

31.3 When analysing the tender, the evaluation committee will determine the final tender price after adjusting it on the basis of Clause 31.1.

F. CONTRACT AWARD

32. Criteria for Award

32.1 The contract will be awarded to the cheapest priced tender satisfying the administrative and reaching the minimum technical requirements.

33. Right Of The Central Government Authority To Accept Or Reject Any Tender

33.1 The Central Government Authority reserves the right to accept or reject any tender and/or to cancel the whole tender procedure and reject all tenders. The Central Government Authority reserves the right to initiate a new invitation to tender.

33.2 In the event of a tender procedure's cancellation, tenderers will be notified by the Central Government Authority. If the tender procedure is cancelled before the outer envelope of any tender has been opened, the sealed envelopes will be returned, unopened, to the tenderers.

33.3 Cancellation may occur where:(a) the tender procedure has been unsuccessful, namely where no

qualitatively or financially worthwhile tender has been received or there has been no response at all;

(b) the economic or technical parameters of the project have been fundamentally altered;

(c) exceptional circumstances or force majeure render normal performance of the project impossible;

(d) there have been irregularities in the procedure, in particular where these have prevented fair competition.

In no circumstances will the Central Government Authority be liable for damages, whatever their nature (in particular damages for loss of profits) or relationship to the cancellation of a tender, even if the Central Government Authority has been advised of the possibility of damages. The publication of a contract notice does not commit the Central Government Authority to implement the programme or project announced.

34. Notification of Award, Contract Clarifications

34.1 Prior to the expiration of the period of validity of tenders, the Central Government Authority will notify the successful tenderer, in writing, that his tender has been recommended for award by the General Contracts Committee, pending any appeal being lodged in terms of Part XIII of the Public Procurement Regulations (being reproduced in Volume 1, Section 6).

34.2 Unsuccessful bidders shall be notified with the outcome of the evaluation process, and will be provided the following information:(i) the criteria for award;



Page 17 of 163

(ii) the name of the successful tenderer;(iii) the recommended price of the successful bidder;(iv) the reasons why the tenderer did not meet the technical specifications/ notification that the offer was not the cheapest (if applicable); (v) the deadline for filing a notice of objection (appeal);(vi) the deposit required if lodging an appeal.

34.3 The recommendations of the General Contracts Committee shall be published on the Notice Board of the Department of Contracts, and published online on the Department’s website, www.contracts.gov.mt/gcc.

35. Contract Signing and Performance Guarantee

35.1 After the lapse of the appeals period, and pending that no objections have been received and/or upheld, the successful tenderer may be invited to clarify certain contractual questions raised therein. Such clarification will be confined to issues that had no direct bearing on the choice of the successful tender. The outcome of any such clarifications will be set out in a Memorandum of Understanding, to be signed by both parties and incorporated into the contract.

35.2 Within 15 calendar days of receiving the contract (against acknowledgment of receipt) from the Central Government Authority, the successful tenderer will sign and date the contract and return it to the Central Government Authority with the performance guarantee and the Financial Identification Form (if applicable). On signing of the contract by the Central Government Authority, the successful tenderer will become the Contractor and the contract will enter into force.

35.3 Before the Central Government Authority signs the contract with the successful tenderer, the successful tenderer may be requested to provide the documentary proof or statements required to show that it does not fall into any of the exclusion situations listed in Clause 7 of the Tender Form (Volume 1, Section 2). The above mentioned documents must be submitted by every member of a Joint Venture/Consortium (if applicable).

35.4 If the selected tenderer fails to sign and return the contract, other required documentation, and any guarantees required within the prescribed 15 calendar days, the Central Government Authority may consider the acceptance of the tender to be cancelled without prejudice to the Central Government Authority's right to seize the guarantee, claim compensation or pursue any other remedy in respect of such failure, and the successful tenderer will have no claim whatsoever on the Central Government Authority.

The tenderer whose tender has been evaluated as second cheapest may be recommended for award, and so on and so forth.

35.5 Only the signed contract will constitute an official commitment on the part of the Central Government Authority, and activities may not begin until the contract has been signed by the Central Government Authority and the successful tenderer.

35.6 Tender guarantees (bid bonds) provided by tenderers who have not been selected shall be released within 30 calendar days from the signing of the contract. The tender guarantee of the successful tenderer shall be released on the signing of the contract, and on submission of a valid performance guarantee.



Page 18 of 163

http://www.contracts.gov.mt/gcc

35.7 The performance guarantee referred to in the General Conditions is set at 10% of the amount of the contract and must be presented in the form specified in Volume 2, Section 4, to the tender document the performance guarantee shall be released within 30 days of the signing of the Final Statement of Account (Final Bill), unless the Special Conditions provide otherwise.

36. Period of Delivery

36.1 The period of delivery indicated in Clause 1.3 of the Instructions to Tenderers commences from the date of last signature of contract

36.2 The Contractor must inform the Central Government Authority's representative by return that he has received the notice.

G. MISCELLANEOUS

37. Ethics Clauses

37.1 Any attempt by a candidate or tenderer to obtain confidential information, enter into unlawful agreements with competitors or influence the committee or the Central Government Authority during the process of examining, clarifying, evaluating and comparing tenders will lead to the rejection of his candidacy or tender and may result in administrative penalties.

37.2 Without the Central Government Authority's prior written authorisation, the Contractor and his staff or any other company with which the Contractor is associated or linked may not, even on an ancillary or subcontracting basis, supply other services, carry out works or supply equipment for the project. This prohibition also applies to any other programmes or projects that could, owing to the nature of the contract, give rise to a conflict of interest on the part of the Contractor.

37.3 When putting forward a candidacy or tender, the candidate or tenderer must declare that he is affected by no potential conflict of interest, and that he has no particular link with other tenderers or parties involved in the project.

37.4 The Contractor must at all times act impartially and as a faithful adviser in accordance with the code of conduct of his profession. He must refrain from making public statements about the project or services without the Contracting Authority's prior approval. He may not commit the Contracting Authority in any way without its prior written consent.

37.5 For the duration of the contract, the Contractor and his staff must respect human rights and undertake not to offend the political, cultural and religious morals of Malta.

37.6 The Contractor may accept no payment connected with the contract other than that provided for therein. The Contractor and his staff must not exercise any activity or receive any advantage inconsistent with their obligations to the Contracting Authority.

37.7 The Contractor and his staff are obliged to maintain professional secrecy for the entire duration of the contract and after its completion. All reports and documents drawn up or received by the Contractor are confidential.



Page 19 of 163

37.8 The contract governs the Parties' use of all reports and documents drawn up, received or presented by them during the execution of the contract.

37.9 The Contractor shall refrain from any relationship likely to compromise his independence or that of his staff. If the Contractor ceases to be independent, the Central Government Authority may, regardless of injury, terminate the contract without further notice and without the Contractor having any claim to compensation.

37.10 The tender(s) concerned will be rejected or the contract terminated if it emerges that the award or execution of a contract has given rise to unusual commercial expenses. Such unusual commercial expenses are commissions not mentioned in the main contract or not stemming from a properly concluded contract referring to the main contract, commissions not paid in return for any actual and legitimate service, commissions remitted to a tax haven, commissions paid to a recipient who is not clearly identified or commissions paid to a company which has every appearance of being a front company.

38. Data Protection and Freedom of Information

38.1 Any personal data submitted in the framework of the procurement procedure and/or subsequently included in the contract shall be processed pursuant to the Data Protection Act (2001). It shall be processed solely for the purposes of the performance, management and follow-up of the procurement procedure and/or subsequent contract by the Central Government Authority/Contracting Authority without prejudice to possible transmission to the bodies charged with a monitoring or inspection task in conformity with National and/or Community law.

38.2 The provisions of this contract are without prejudice to the obligations of the Central Government Authority in terms of the Freedom of Information Act (Cap. 496 of the Laws of Malta). The Central Government Authority, prior to disclosure of any information to a third party in relations to any provisions of this contract which have not yet been made public, shall consult the contractor in accordance with the provisions of the said Act, pertinent subsidiary legislation and the Code of Practice issued pursuant to the Act. Such consultation shall in no way prejudice the obligations of the Central Government Authority in terms of the Act.

39. Gender Equality

39.1 In carrying out his/her obligations in pursuance of this contract, the tenderer shall ensure the application of the principle of gender equality and shall thus ’inter alia’ refrain from discriminating on the grounds of gender, marital status or family responsibilities. Tenderers are to ensure that these principles are mainfest in the organigram of the company where the principles aforementioned, including the selection criteria for access to all jobs or posts, at all levels of the occupation hierarchy are amply proven. In this document words importing one gender shall also include the other gender.



Page 20 of 163

VOLUME 1 SECTION 2 – TENDER FORM

Publication reference: ................................................A Document Control and Quality Management Solution for the National Blood Transfusion Service <File Reference Number>

A TENDER SUBMITTED BY

Name(s) of tenderer(s) Nationality Proportion of Responsibilities2

Leader 1

Partner 1

Etc …

1. Add/delete additional lines for partners as appropriate. Note that a sub-contractor is not considered to be a partner for the purposes of this tender procedure. If this tender is being submitted by an individual tenderer, the name of the tenderer should be entered as 'leader' (and all other lines should be deleted)2. Proposed proportion of responsibilities between partners (in %) with indication of the type of the works to be performed by each partner (the company acting as the lead partner in a joint venture/consortium, they must have the ability to carry out at least 50% of the contract works by its own means. If a company is another partner in a joint venture/consortium (i.e. not the lead partner) it must have the ability to carry out at least 10% of the contract works by its own means).

Supply intended to be sub-contracted

Name and details of sub-contractors

Value of sub-contracting as percentage of the total cost 3

Experience in similar supplies (details to be specified)

1

2

(.)

3. The maximum amount of sub-contracting must not exceed [......%] of the total contract value. The main contractor must have the ability to carry out at least [......%] of the contract works by his own means.

B CONTACT PERSON (for this tender)

Name Surname

Telephone (____) ________________________ Fax (____) ________________________

Address...............................................................................................................



Page 21 of 163

...............................................................................................................

...............................................................................................................

E-mail

C TENDERER'S DECLARATION(S)

To be completed and signed by the tenderer (including each partner in a consortium).

In response to your letter of invitation to tender for the above contract, we, the undersigned, hereby declare that:

1 We have examined, and accept in full and in its entirety, the content of this tender document (including subsequent Clarifications Notes issued by the Central Government Authority) for invitation to tender No [_________/_______] of [……/……/……]. We hereby accept the contents thereto in their entirety, without reservation or restriction. We also understand that any disagreement, contradiction, alteration or deviation shall lead to our tender offer not being considered any further.

2 We offer to execute, in accordance with the terms of the tender document and the conditions and time limits laid down, without reserve or restriction, the following:The provision of the complete solution as described in this tender..

3 The total price of our tender (inclusive of duties, VAT, other taxes and any discounts) is:

…Euro……………………………………………………………(b/f from Vol 4 Financial Bid)

4 This tender is valid for a period of 150 days from the final date for submission of tenders.

5 If our tender is accepted, we undertake to provide a performance guarantee of 10% of the contract value as required by the General Conditions.

6 We are making this application in our own right and [as partner in the consortium led by < name of the leader / ourselves > ] for this tender Ref No]. We confirm that we are not tendering for the same contract in any other form. [We confirm, as a partner in the consortium, that all partners are jointly and severally liable by law for the performance of the contract, that the lead partner is authorised to bind, and receive instructions for and on behalf of, each member, and that all partners in the joint venture/consortium are bound to remain in the joint venture/consortium for the entire period of the contract's performance]. We are fully aware that, in the case of a consortium, the composition of the consortium cannot be modified in the course of the tender procedure.

7 We are not bankrupt or under an administration appointed by the Court, or under proceedings leading to a declaration of bankruptcy. We also declare that we have not been convicted criminally, or found guilty of professional misconduct. Furthermore, we are up-to-date in the payment of social security contributions and other taxes.

8 We accept that we shall be excluded from participation in the award of this tender if compliance certificates in respect of declarations made under Clause 7 of this declaration are not submitted by the indicated dates.



Page 22 of 163

9 We agree to abide by the ethics clauses of the instructions to tenderers and, in particular, have no potential conflict of interests or any relation with other candidates or other parties in the tender procedure at the time of the submission of this application. We have no interest of any nature whatsoever in any other tender in this procedure. We recognise that our tender may be excluded if we propose key experts who have been involved in preparing this project or engage such personnel as advisers in the preparation of our tender.

10 We will inform the Central Government Authority immediately if there is any change in the above circumstances at any stage during the implementation of the contract. We also fully recognise and accept that any false, inaccurate or incomplete information deliberately provided in this application may result in our exclusion from this and other contracts funded by the Government of Malta and the European Communities.

11 Our tender submission has been made in conformity with the Instructions to Tenderers, and in this respect we confirm having included in the appropriate packages as required, the following documentation:

(a) Tender Guarantee (Note 1)

o Bid Bond

(b) General Information (Note 2)

o Proof of Purchase (Receipt)o Statement on Conditions of Employment

Selection Criteria (Note 2)

(c) Technical Capacity (Note 3)

● Experience as Contractor

(d) Evaluation Criteria/Technical Specifications (Note 3)

● Tenderer’s Technical Offer Literature as per response format

(e) Tender Form, and Financial Offer (Note 3)

Notes:

1. Tenderers will be requested to clarify/rectify, within two working days from notification, the tender guarantee only in the following two circumstances: either incorrect validity date, and/or incorrect value. This is indicated by the symbol ○

2. Tenderers will be requested to either clarify/rectify any incorrect and/or incomplete documentation, and/or submit any missing documents within two working days from notification. This is indicated by the symbol ○

3. No rectification shall be allowed. Only clarifications on the submitted information may be requested. This is indicated by the symbol ●

12 I acknowledge that the Central Government Authority and/or Contracting Authority shall request rectifications in respect of incomplete/non-submitted information pertinent to the documentation listed in Clause 11(a), 11(b), and 11(c) of this Tender Form. We understand that such rectification/s must be submitted within two (2) working days, and will be subject to a non-refundable administrative penalty of €50, and that failure to comply shall result in our offer not being considered any further.



Page 23 of 163

13 We note that the Central Government Authority is not bound to proceed with this invitation to tender and that it reserves the right to cancel or award only part of the contract. It will incur no liability towards us should it do so.

Name and Surname: _________________________________________

I.D. / Passport Number: _________________________________________

Signature of tenderer: _________________________________________

Duly authorised to sign this tender on behalf of: _________________________________________

Company/Lead Partner VAT No: _________________________________________(if applicable)

Stamp of the firm/company: _________________________________________

Place and date: _________________________________________



Page 24 of 163

VOLUME 1 SECTION 3 – TENDER GUARANTEE FORM

[On the headed notepaper of the financial institutions providing the guarantee]

Whereas the Director of Contracts has invited tenders for .........................................................................................................................................,and whereas Messrs .................................................................................... [Name of tenderer] (hereinafter referred to as the Tenderer) is submitting such a tender in accordance with such invitation, we ................................................... [Name of Bank], hereby guarantee to pay you on your first demand in writing a maximum sum of ........Two Thousand Euro (€2000) in case the Tenderer withdraws his tender before the expiry date or in the case the Tenderer fails to provide the Performance Bond, if called upon to do so in accordance with the Conditions of Contract.

The guarantee becomes payable on your first demand and it shall not be incumbent upon us to verify whether such demand is justified.

This guarantee is valid for a period of one hundred and fifty (150) days from the closing date of submission of tenders, and expires on the 10th June 2011. Unless it is extended by us or returned to us for cancellation before that date, any demand made by you for payment must be received at this office in writing not later than the above-mentioned expiry date.

This document should be returned to us for cancellation or utilisation or expiry or in the event of the guarantee being no longer required.

After the expiry date and in the absence of a written demand being received by us before such expiry date, this guarantee shall be null and void, whether returned to us for cancellation or not, and our liability hereunder shall terminate.

Yours faithfully,

..................................Bank Manager

..................................Date



Page 25 of 163

VOLUME 1 SECTION 4 - TENDERER’S STATEMENTS

1. Statement on Conditions of Employment

It is hereby declared that all employees engaged on this contract shall enjoy working conditions such as wages, salaries, vacation and sick leave, maternity and parental leave as provided for in the relative Employment Legislation. Furthermore, we shall comply with Chapter 424 of the Laws of Malta (Occupational Health and Safety Authority Act) as well as any other national legislation, regulations, standards and/or codes of practice or any amendment thereto in effect during the execution of the contract.

In the event that it is proved otherwise during the execution of the contract it is hereby being consented that the contract is terminated with immediate effect and that no claim for damages or compensation be raised by us.

Signature: .............................................................(the person or persons authorised to sign on behalf of the tenderer)

Date: .............................................................



Page 26 of 163

2 - List of References

List of contracts for solutions of a similar nature effected during the past 3 years, as per Volume 1 Section 1 (6.1.2).

Description of Solution

Total Value of Supplies

Date of Implementation

Client*/Contracting Authority*

* In so listing the end clients, I am giving my consent to the Evaluation Committee, so that the latter may, if it deems necessary, contact the relevant clients, with a view to obtain from them an opinion on the supplies provided to them.

Signature: ....................................................................(the person or persons authorised to sign on behalf of the tenderer)

Date: ....................................................................



Page 27 of 163

3 - List of Key Experts and other personnel

1. List of Key Experts and other personnel proposed for the execution of the contract, as per Volume 1 Section 1 (6.1.2)

Resource

Description / Title Role in this project

1

2

3

4

5

6

7

8

9

Signature: ....................................................................(the person or persons authorised to sign on behalf of the tenderer)

Date: ....................................................................



Page 28 of 163

VOLUME 1 SECTION 5 – GLOSSARYDefinitions

Note: the present definitions are given here for convenience only, in the context of the tender procedure. The definitions set out in the contract as concluded are determining for the relations between the parties to the contract.

Administrative order: Any instruction or order issued by the Project Manager to the Contractor in writing regarding the execution of the contract.

Breakdown of the overall price: A heading-by-heading list of the rates and costs making up the price for a lump-sum contract.

Central Government Authority: means the Department of Contracts

Contracting Authority: means the final beneficiary.

Conflict of interest: Any event influencing the capacity of a candidate, tenderer or supplier to give an objective and impartial professional opinion, or preventing him, at any moment, from giving priority to the interests of the Central Government Authority and the Contracting Authority. Any consideration relating to possible contracts in the future or conflict with other commitments, past or present, of a candidate, tenderer or supplier, or any conflict with his own interests. These restrictions also apply to subcontractors and employees of the candidate, tenderer or supplier.

Contract value: The total value of the contract to be paid by the Contracting Authority in terms of the agreed terms and conditions.

Contractor: The successful tenderer, once all parties have signed the contract.

Day: Calendar day.

Dayworks: Varied work inputs subject to payment on an hourly basis for the Contractor's employees and plant.

Defects Notification Period: The period stated in the contract immediately following the date of provisional acceptance, during which the Contractor is required to complete the works and to remedy defects or faults as instructed by the Engineer.

Drawings: Drawings provided by the Contracting Authority and/or the Engineer, and/or drawings provided by the Contractor and approved by the Engineer, for the carrying out of the works.

Engineer's representative: Any natural or legal person, designated by the Engineer as such under the contract, and empowered to represent the Engineer in the performance of his functions, and in exercising such rights and/or powers as have been delegated to him. In this case, references to the Engineer will include his representative.

Equipment: Machinery, apparatus, components and any other articles intended for use in the works

Evaluation Committee: a committee made up of an odd number of voting members (at least three) appointed by the Central Government Authority and possessing the technical, linguistic and administrative capacities necessary to give an informed opinion on tenders.



Page 29 of 163

Final acceptance certificate: Certificate(s) issued by the Engineer to the Contractor at the end of the defects notification period stating that the Contractor has completed his obligations to construct, complete, and maintain the works concerned.

Final Beneficiary: The Department/Entity or other government body on whose behalf the Department of Contracts has issued this tender.

Foreign currency: Any currency permissible under the applicable provisions and regulations other than the Euro, which has been indicated in the tender.

General conditions: The general contractual provisions setting out the administrative, financial, legal and technical clauses governing the execution of contracts.

General damages: The sum not stated beforehand in the contract, which is awarded by a court or an arbitration tribunal, or agreed between the parties, as compensation payable to an injured party for a breach of the contract by the other party.

In writing: This includes any hand-written, typed or printed communication, including fax transmissions and electronic mail (e-mail).

Liquidated damages: The sum stated in the contract as compensation payable by the Contractor to the Contracting Authority for failure to complete the contract or part thereof within the periods under the contract, or as payable by either party to the other for any specific breach identified in the contract.

Modification: An instruction given by the Engineer which modifies the works.

National currency: The currency of the country of the Contracting Authority.

Period: A period begins the day after the act or event chosen as its starting point. Where the last day of a period is not a working day, the period expires at the end of the next working day.

Plant: appliances and other machinery, and, where applicable under the law and/or practice of the state of the Contracting Authority, the temporary structures on the site required to carry out the works but excluding equipment or other items required to form part of the permanent works.

Project Manager : The legal or natural person responsible for monitoring the execution of the contract on behalf of the Contracting Authority, where the latter is not the Central Government Authority.

Provisional sum: A sum included in the contract and so designated for the execution of works or the supply of goods, materials, plant or services, or for contingencies, which sum may be used in whole or in part, or not at all, as instructed by the Engineer.Site: The places provided by the Contracting Authority where the works are to be carried out and other places stated in the contract as forming part of the site.Special conditions: The special conditions laid down by the Contracting Authority as an integral part of the tender document, amplifying and supplementing the general conditions, clauses specific to the contract and the terms of reference (for a service contract) or technical specifications (for a supply or works contract).Supervisor/Engineer: The legal or natural person responsible for administering the contract on behalf of the Contracting Authority. Tender document/s: The dossier compiled by the Contracting Authority and containing all the documents needed to prepare and submit a tender.



Page 30 of 163

Tender price: The sum stated by the tenderer in his tender for carrying out the contract.Works: Works of a permanent or temporary nature executed under the contract.Written communications: Certificates, notices, orders and instructions issued in writing under the contract.



Page 31 of 163

VOLUME 1 SECTION 6 – EXTRACTS FROM THE PUBLIC PROCUREMENT REGULATIONS

Part XIII - Appeals

The procedure for the submission of appeals is stipulated in Part XIII of the Public procurement Regulations (Legal Notice 296/2010), reproduced hereunder for ease of reference.

(1)

(2)

Any tenderer or candidate concerned, or any person, having or having had an interest or who has been harmed or risks being harmed by an alleged infringement or by any decision taken including a proposed award in obtaining a contract or a cancellation of a call for tender, may file a notice of objection with the Review Board.

The notice shall be filed within ten calendar days following the date on which the contracting authority has by fax or other electronic means sent its proposed award decision.The communication to each tenderer of the proposed award shall be accompanied by a summary of the relevant reasons relating to the rejection of the tender as set out in regulation 44(3), and by a precise statement of the exact standstill period.

The notice of objection shall only be valid if accompanied by a deposit equivalent to one per cent of the estimated value of the tender submitted by the tenderer, provided that in no case shall the deposit be less than one thousand and two hundred euro (€1,200) or more than fifty-eight thousand euro (€58,000). The Secretary of the Review Board shall immediately notify the Director that an objection had been filed with his authority thereby immediately suspending the award procedure. The Department of Contracts or the contracting authority involved, as the case may be, shall be precluded from concluding the contract during the period of ten calendar days allowed for the submission of appeals. The award process shall be completely suspended if an appeal is eventually submitted.

The procedure to be followed in submitting and determining complaints as well as the conditions under which such complaints may be filed shall be the following:(a) any decision by the General Contracts Committee (or a Special Contracts

Committee) and by a contracting authority, shall be made public at the Department of Contracts or at the office of the contracting authority prior to the award of the contract;

(b) the notice of objection duly filed in accordance with sub-regulation (1) shall be made public by the Review Board not later than the next working day following its filing;

(c) within three working days of the publication of the replies the Secretary of the Review Board shall prepare a report (the Analysis Report) analysing the letter of objection. This report shall be circulated to the persons who file an objection and interested parties. After the preparatory process is duly completed, the Head of the contracting authority

shall forward to the Chairman of the Review Board all documentation pertaining to the call for tenders in question including files, tenders submitted, copies of deposit receipts, any motivated



Page 32 of 163

letter, who shall then proceed as stipulated in Part XIV;

(d) the Director or the Head of the contracting authority shall publish a copy of the decision of the Review Board at his department or at the premises of the relevant contracting authority, as the case may be.

Copies of the decision shall be forwarded by the Secretary of the Board to the complaining tenderer, any persons who had registered or had an implied interest, the Director of Contracts and to the contracting authority concerned.



Page 33 of 163

VOLUME 2

VOLUME 2 SECTION 1 – DRAFT CONTRACT FORM and SAMPLE CONTRACT

Financed by: ................................................. [Specify Source of Financing]Project: ................................................. [Title and Number]Contract Number: ................................................. [Contract Number]

This contract is concluded between:

Department of ContractsNotre Dame RavelinFloriana FRN 1600Malta

hereinafter called “The Central Government Authority” on behalf of National Blood Transfusion Service on the one part, and

[Name of Contractor][Address]

hereinafter called “The Contractor” on the other part,

Whereas the Central Government Authority is desirous that certain services should be provided by the Contractor, as per contract

Contract for A Document Management and Control System

and has accepted a tender by the Contractor for the provision of such supplies and the remedying of any defects therein.

It is hereby agreed as follows:

1. In this contract words and expressions shall have the meanings assigned to them in the contractual conditions set out below and in the Contract..

2. The place of acceptance of the supplies shall be the National Blood Transfusion Services, the time line for implementation shall be in line with Schedule XXX in the Contract.

3. The following documents shall be deemed to form and be read and construed as part of this contract, in the following order of precedence:

(a) this contract,(b) the Special Conditions,(c) the General Conditions,(d) the technical specifications and design documentation,(e) the Contractor’s technical offer (including any clarifications made during adjudication),(f) the financial offer (after arithmetical corrections)/breakdown,(g) the tender form,(h) any other documents forming part of the contract.



Page 34 of 163

Addenda shall have the order of precedence of the document they are modifying.

4. In consideration of the payments to be made by the Contracting Authority to the Contractor as hereinafter mentioned, the Contractor undertakes to provide the solution as defined in the Contract.

5. The Contracting Authority hereby agrees to pay the Contractor in accordance with Schedule C of the Contract.

6. In witness whereof the parties hereto have signed the contract. This contract shall take effect on the date on which it is signed by the last party.

Done in English in three originals: one for the Central Government Authority, one for the Contracting Authority, and one for the Contractor.

Central Government Authority: Contractor:

Signed by:

......................…..................................

Signed by:

...............................….........................

In the capacity of:

...........................….............................

In the capacity of:

.....................................................…...

Being fully authorized by and acting on behalf of

.................................................….......

Being fully authorized by and acting on behalf of

...….....................................................

Date: .................................................... Date: ....................................................



Page 35 of 163

SAMPLE CONTRACT



Page 36 of 163

THIS CONTRACT is for A Document Management and Quality Management Solution, having a reference of [reference number] made this [date]

NOW THEREFORE, the parties hereto agree as follows:

NOW THEREFORE, the parties hereto agree as follows:

Article 1 Definitions

In this Contract the following terms shall have the meanings hereinafter assigned to them unless the context otherwise requires:

Acceptance Certificate means a certificate issued by the Customer indicating that the Solution conforms to the Contract and has been accepted by the Customer.

Charges means the fees payable by the Customer to the Contractor as set out in Schedule C.

Contract means this agreement between the Parties and all Appendices, annexes, appendices and other attachments to this Contract.

Delivery Date means the date specified in this Contract by which the Contractor is to provide or supply the Solution.

Documentation means the manuals and other documents in the English language to be supplied by the Contractor to the Customer, whether in hard or soft copy, including but not limited to the Manufacturer’s licences agreement.

Hardware means the all equipment delivered by the Contractor as listed in Schedule G

Implementation Schedule means the plan set out in Schedule E setting out the milestones to be met by the Contractor .

ITIL means the set of concepts and techniques for managing information technology (IT) infrastructure, development, and operations as updated by the Office of Government Commerce from time to time. The names ITIL and IT Infrastructure Library are registered trademarks of the United Kingdom's Office of Government Commerce (OGC) and ITIL consists of a series publications giving guidance on the provision of quality IT services and on the processes and facilities needed to support them.

Knowledge Transfer means the transfer of knowledge related to the Services that would enable the Customer personnel to carry out the normal, ongoing operation of such services.

Normal Working Hours means the hours between 0800 and 1700 hours each day excluding Saturdays, Sundays and Public Holidays

Parties means the Customer and the Contractor jointly. Policies and Procedures means the policies, standards, procedures, guidelines and

directives related to this Contract or that may be issued or amended by the Government of Malta, from time to time and published on the website http://ictpolicies.gov.mt or provided in hard or soft copy to the Contractor by the Customer.



Page 37 of 163

http://ictpolicies.gov.mt/

http://en.wikipedia.org/wiki/Office_of_Government_Commerce

http://en.wikipedia.org/wiki/United_Kingdom

http://en.wikipedia.org/wiki/Trademark

http://en.wikipedia.org/wiki/Information_technology

Premises means the Data Centres owned by the Customer or any other premises as indicated by the Customer.

Project BoardServices means the maintenance and support services as set forth in

Schedule B.Software means all the software installed by the Contractor as listed in

Schedule GSolution means the Hardware and Software to be provided to the

Customer by the Contractor in accordance with this Contract, and the related services for the implementation and support and maintenance of the solution.

Term means the period of 5 (five) years from the date of signature of the Acceptance Certificate, until date of expiry or termination of this Contract in accordance with its terms, whichever is the earliest. This contract may be renewed for another 5 (five) years.

Third Party means any person or entity which is not a party to this Contract.

Working Hours means 24 hours per day all year round including Malta Public Holidays.

Article 2 Scope and Application of Contract

2.1 The Parties agree that during the Term, the Contractor shall be responsible to:

(a) Deliver and install, configure and test the Solution, with the assistance of the Customer:

(i) in line with the technical and functional requirements as detailed in the Schedule D to the Contract; and

(ii) in accordance with the timelines as detailed in the Delivery and Implementation Schedule attached as Schedule E to the Contract.

(b) Provide the Services as detailed in the Schedule B to the Contract.

2.2 The Parties agree that during the Term, the Contractor shall provide the Customer with the Deliverable Items and Services adhering to all terms and conditions in this Contract.

Article 3 Responsibilities of the Contractor

Provision of Solution and Services

3.1 The Contractor shall be responsible for the successful delivery, installation configuration and testing of the Solution, with the necessary assistance of the Customer, in accordance with Schedule E.

3.2 The Customer may request the Contractor to assist it in the re-configuration of the Solution during the Term.

3.3 Risk of the Hardware shall pass to the Customer upon commissioning of the Solutions. Title to the Hardware shall pass to the Customer upon full payment of all Charges in accordance with Schedule C.



Page 38 of 163

3.4 The standard of the provision of Solution and Services shall be in accordance with the Contract. To the extent that the requirements and/or standard of the provision of Solutions and Services has not been specified in the Contract, the Contractor shall use high quality materials, techniques and standards and shall provide the Services with the care, skill and diligence required in accordance with best industry practices.

3.5 The Contractor shall provide the capability and flexibility to supply the Solution and provide the Services as and when required by the Customer, within the terms and conditions set out in this Contract, in order to provide the best services to the Customer. The Contractor shall ensure that it provides added value in delivering the Solution and Services and not a mere reselling exercise with a mark-up.

3.6 The Contractor shall ensure that the provision of Solution and Services are performed by personnel with the necessary background, training, experience and ability to carry out their duties in a professional and proficient manner to the mutual understanding and reciprocal learning.

3.7 The Contractor agrees to fully comply with regulations and standards related to health and safety and environmental protection.

3.8 The Contractor agrees to comply with the policies of the Customer regarding access to its physical premises and automated systems, and any other rules, procedures and standards which are in force and notified to the Contractor within reasonable time. If the Customer changes its policies or any other rules, procedures and standards, the Customer will give the Contractor reasonable notice of any relevant change.

3.9 The Contractor shall obtain and maintain all approvals, permissions, permits and licenses required to comply with national laws and regulations that may be applicable for the provision of the Solution.

3.10 The Contractor shall maintain complete and accurate records on the scope of this Contract.

3.11 The Contractor will comply at all times with the Policies and Procedures. The Policies and Procedures will, in no event, be interpreted so as to relieve the Contractor from its obligations under this Contract. Nevertheless the Parties agree that a breach by the Contractor of Policies and Procedures that have been amended subsequent to the date of signature and execution of this Contract will not be considered as a material breach of the Contract.

3.12 The Contractor shall provide the Software licences required to the Customer to operate the Solution on a perpetual and non-exclusive basis.

3.13 The Contractor acknowledges that time is of the essence for the performance of its obligations under this Contract.

Delivery and Installation

3.14 The Solution shall be supplied in accordance with the specifications detailed in Schedules C and D.

3.15 The Solution shall be delivered and implemented within the timeframes specified in the Delivery Timeframes Schedule attached as Schedule E.



Page 39 of 163

3.16 A completed testing declaration form and/or quality certification issued by the Manufacturer is to be forwarded to the Customer upon delivery of the Hardware to the Premises.

3.17 Without prejudice to Article 10 of this Contract, the Contractor shall be liable to a penalty for mere delay of Euro 200 per day if the supply of the Solution is not in accordance with the Delivery and Implementation Schedule E.

3.18 The Solution supplied is to be new, original and fully licensed and is to be delivered together with manuals in the English Language.

3.19 The Contractor acknowledges that the cost of delivering, unpacking, installing and commissioning of the Solution is included in the Charges.

3.20 The Contractor is solely responsible for the non-arrival and/or for any loss or damage to the Solution which occurs during the transit of the Solution to the Customer’s site or to any other site indicated by the Customer until the Solution is handed over to the Customer.

3.21 The Customer will assist the Contractor during the configuration on the Hardware and Software installed by the Contractor as set out in Schedule F.

Provision of Maintenance and Support

3.22 The Contractor shall provide the Customer with technical support services during Working Hours and in line with the Service Level management framework based on ITIL, as defined in Schedule A. The Contractor shall provide on line technical support during the Working Hours.

3.23 The Contractor shall provide a support on all Hardware provided as per Schedule G.

3.24 The Contractor shall support all Software and shall make available any patches and updates affecting the Software, together with all the necessary documentation.

3.25 The patches and updates will be installed by the Customer assisted by the Contractor, upon written approval by the Customer. The Parties agree that the Contractor shall make available to the Customer the Hardware (‘cold stand-by appliance’) residing at the Contractor’s premises in order for the Customer to test the patches and updates provided by the Contractor in accordance with Articles 3.21 and 3.22.

Technology Updates

3.26 The Contractor shall keep the Customer updated on any developments in the Hardware and Software that are available on the market. The Contractor shall in particular plan and implement replacement systems by:

(a) Notifying the Customer of impending Hardware end-of-life at least sixty (60) days prior to the end of life period;

(b) Recommending replacement Hardware, consistent with any established Policies and Procedures for that type of Hardware, at least forty-five (45) days prior to the end of life period;

(c) Providing specific configuration and other ordering information to the Customer for the approved replacement Hardware;



Page 40 of 163

(d) Coordinating the existing Hardware de-installation and replacement Hardware installation activities, ensuring that these are accomplished far enough in advance to meet refresh targets.

Access to Location

3.27 The Customer will use their best endeavour to afford to authorised personnel of the Contractor at all reasonable times and with prior agreement, which shall not be unreasonably withheld, access to the Premises as may be necessary for the delivery and installation of the Solution and the provision of the Services.

3.28 The Contractor will ensure that any of its employees, subcontractors or agents, whilst on the Premises shall:(a) use its best endeavours to cause as little interference with and inconvenience to the

operations of the Customer, their personnel and any agents or Contractors engaged by the Customer; and

(b) comply with the security and other reasonable rules and regulations applicable at the Premises; and

(c) If required, take an oath of secrecy or any other similar undertaking as required by the Customer.

3.29 Notwithstanding Article 3.28, the Customer shall have the right to refuse admittance to, or order the removal from, the Premises of any person employed by or acting on behalf of the Contractor who, in the opinion of the Customer (which shall be final) is not a fit and proper person to be on the Premises. The Customer undertakes not to use this right in an unreasonable manner and shall inform the Contractor of the reasons for refusal of admittance. The Contractor undertakes to replace such personnel without jeopardising the performance of the Contract.

3.30 Action taken under Article 3.29 shall forthwith be confirmed in writing to the Contractor by the Customer and shall not relieve the Contractor of its obligations under the Contract.

Documentation

3.31 The Contractor shall furnish the Customer with the Documentation in English.

3.32 At the request of the Customer, the Contractor shall provide such additional copies of the Documentation as the Customer may require for the normal operation of its business.

3.33 The Contractor shall continue supplying any relevant Documentation existing from time to time, technical manuals and other customer literature to the Customer. As a minimum, the combination of the manuals, technical documentation and other customer literature provided hereunder and any training provided shall allow proper use, operation, administration and management of the Solution and Services by appropriately qualified personnel who have access to such documentation and who receive such training.

Knowledge Transfer

3.34 Throughout the Term, the Contractor shall transfer to the Customer personnel the knowledge necessary to enable the Customer to carry out the normal, ongoing operation of the Services in accordance with the Contract.



Page 41 of 163

3.35 The Customer reserves the right to request specific training from the Contractor on the provision of the Services at the rates as agreed between the Parties. Training material/manuals must be provided to all participants in the respective areas.

3.36 The Knowledge Transfer shall not include the Contractor’s intellectual property rights and Confidential Information. Confidential Information and ideas may be included in the Knowledge Transfer if such Confidential Information and ideas do not constitute Intellectual Property Rights and such Confidential Information and ideas are necessary to enable the Customer to carry out the said services. In such case the provisions in this Contract relating to the use of such confidential information and ideas shall regulate and apply to such use by the Customer.

Insurance

3.37 The Contractor shall be responsible to take out an adequate insurance policy for the Solution which shall cover the Solution until date of delivery of the Solution at the Premises.

Personnel

3.38 The Contractor shall provide the Customer with the contact details including emergency telephone number/s of those personnel who may be contacted by the Customer during Working Hours and shall ensure that at all times these Personnel are available to be contacted by the Customer.

3.39 The Contractor’s personnel (including subcontractors’ personnel) involved in anyway whatsoever in the provision of the Service shall provide the Services with the care, skill and diligence required in accordance with the law and with the best industry practices and shall have the necessary background, training, experience and ability to carry out their duties in a professional and proficient manner to the mutual understanding and reciprocal learning. Such personnel shall also have sufficient knowledge of the relevant aspects of the Service and of the practices of the Customer to enable them to properly perform the duties and responsibilities assigned to them in connection with this Contract.

3.40 Where the Customer is unsatisfied with the performance of any Contractor’s personnel or subcontractor providing the Service to the Customer, the Customer shall immediately notify the Contractor giving reasons for its dissatisfaction, and the Contractor shall use its best endeavours to rectify the situation. For the purposes of this clause the performance of the employee or subcontractor shall be deemed unsatisfactory, inter alia, where (i) such employee is incompetent; (ii) such employee is negligent in the performance of his duties; (iii) lacks the skills and experience required; or (iii) his behaviour at the place of work is unacceptable or unsuitable. If the situation is not rectified by the Contractor within ten (10) calendar days from being notified by the Customer, the Customer reserves the right to request in writing a change of the individual concerned and the Contractor is obliged to carry out the necessary change within fifteen (15) calendar days from the written request.

Article 4 Warranties of the Contractor

4.1 The Contractor represents and warrants that: (a) it is suitably qualified and experienced for the provision of the Services and that

the Contractor shall provide the Services with the degree of diligence expected from a contractor in the business of providing similar services;



Page 42 of 163

(b) it is not under any pre-existing obligation in conflict or in any way inconsistent with the provisions of the Contract;

(c) the Hardware or Software shall not infringe upon nor violate any patent, copyright, trade secret, or any right of third party, and shall not be libellous or otherwise unlawful;

(d) it is appropriately licensed and authorised to provide the Services;(e) it will provide the maintenance and support services in accordance with the

Service Levels set out in Schedule B;(f) as at the date of signature of this Contract, there is no litigation, actions, suits or

proceedings or regulatory investigations pending or, to the Contractor ’s knowledge, threatened against or affecting the Contractor before any court or administrative body or arbitration tribunal, nor any contract with a Third Party, which would prevent the performance of its obligations under this Contract;

(g) in performing its obligations under this Contract during the Term, all Software used by or on behalf of the Contractor will be currently supported versions of that Software so long as the Service continue to be provided under the terms of this Contract;

(h) it has and will continue to have, throughout the Term, all necessary rights in and to the Software or any other materials made available by the Contractor to the Customer to the extent necessary to perform the Contractor ’s obligations under this Contract.

Article 5 Responsibilities of the Customer

5.1 The Customer shall remunerate the Contractor at the fixed fees and terms of payment set out in Schedule C.

5.2 The Customer shall assist the Contractor in the implementation of the Solution. The Customer shall also assist the Contractor in any configuration that may be necessary during the Term.

5.3 The Customer will be responsible to monitor the Solution in order to detect any potential faults in the Hardware and/or Software, without prejudice to the Contractor’s responsibility to provide maintenance and support services.

5.4 The Customer’s personnel shall provide assistance to the Contractor in areas requiring particular know how or work experience directly involving the practices of the Customer.

5.5 The Customer shall make available the information and appoint the resources necessary for the Contractor to be able to provide the Solution and Services in accordance with this Contract.

Article 6 Acceptance Procedure

6.1 The Contractor, with the assistance of the Customer, shall test the Solution in accordance with the procedure specified below (‘Acceptance Procedure’). The Customer may appoint a Third Party to assist it during the Acceptance Procedure.

6.2 Each party shall bear its own costs in respect of the Acceptance Procedure. If the Hardware and/or Software continue to fail to meet the acceptance criteria establishing in accordance with Article 6.3 following three iterations of Acceptance Procedure, the



Page 43 of 163

Contractor shall bear all the costs in respect of any subsequent Acceptance Procedures.

6.3 The Parties shall prepare a plan for the performance of the Acceptance Procedure which shall include:(a) a description of the performance of the Acceptance Procedure and the expected

results of the tests;(b) the acceptance criteria which shall as a minimum include the technical and

functional requirements;(c) the planned schedule to carry out the Acceptance Procedure;(d) the responsibilities of the parties during the Acceptance Procedure;(e) any event or condition on which the Acceptance Procedure is dependant.

6.4 In the event that the Customer notifies the Contractor that the test results are not acceptable or the Solution does not function in accordance with the requirements set out in Schedule D the Customer reserves the right to request the Contractor, at the Contractor’s cost, to re-perform the Acceptance Procedure and/or remedy or replace the Hardware and/or Software, without prejudice to Customer’s right to seek any remedies set out in this Contract or as provided by law.

6.5 Without prejudice to the Article 17, in the event that the Hardware and/or Software fails the Acceptance Procedure and the Solution is not implemented in accordance with the Delivery and Implementation Schedule:(a) The Customer shall formally reject the Solution by notice in writing;(b) The Customer shall have the right to source the Solution from another provider.

The Customer shall inform the Contractor of any difference in the cost. Such difference in cost of the Solutions shall be borne by the Contractor;

(c) the Contractor will pay to the Customer, by way of penalty for mere delay, the sum of 10 (ten) percent per week on the value of any works/deliveries which may be in arrears unless the Customer reasonably believes that such delay has arisen from causes which are not within the Contractor’s control and could not be foreseen, in which case the Customer shall decide the extent, if any, to which deduction shall be remitted. The penalty will run from the day following the planned implementation until the successful completion of the Acceptance Procedure.

6.6 Where the Customer determines that the Solution has successfully completed the Acceptance Procedure, the Customer shall issue an Acceptance Certificate confirming that the Solution successfully met all the testing criteria. The Customer endeavours to finalise the Acceptance Procedure and issue an Acceptance Certificate.

6.7 The Contractor acknowledges that due to constraints in the possible testing scenarios, it may not be possible for comprehensive acceptance testing for the Solution to be completed. Notwithstanding the issue of the Acceptance Certificate in accordance with the preceding clause, the Contractor shall remain solely responsible for its obligations under the Contract, including the responsibility for the Solutions to function in accordance with the requirements set out in Schedule D. The issuance of the Acceptance Certificate shall not constitute a waiver of the rights of the Customer under the Contract.

6.8 The warranty period for the Solution shall commence on the date of issuance of the Acceptance Certificate.

6.9 Following the issue of the Acceptance Certificate and throughout the Term, the Contractor shall ensure that:



Page 44 of 163

(a) the Solution is operational in accordance with the specifications set out in Schedule D;

(b) the Services are provided in accordance with Schedule B.

Article 7 Verification and Checks by Auditing Bodies

7.1 The Contractor will allow all auditing bodies identified by the Government of Malta or by an institutions of the European to verify, by examining the documents or by means of on-the-spot checks, the implementation of the project and conduct a full audit, if necessary, on the basis of supporting documents for the accounts, accounting documents and any other document relevant to the financing of the project. These inspections may take place up to 7 years after the final payment.

7.2 The Contractor will allow the auditing bodies to carry out checks and verification on the spot in accordance with the procedures set out in local legislation.

7.3 To this end, the Contractor undertakes to give appropriate access to staff or agents of the auditing bodies to the sites and locations at which the Contract is carried out, including its information systems, as well as all documents and databases concerning the technical and financial management of the project and to take all steps to facilitate their work. Access given to agents of the auditing bodies shall be on the basis of confidentiality with respect to third parties, without prejudice to the obligations of public law to which they are subject. Documents must be easily accessible and filed so as to facilitate their examination and the Contractor must inform the Customer of their precise location.

7.4 The Contractor guarantees that the rights of the auditing bodies to carry out audits, checks and verification will be equally applicable, under the same conditions and according to the same rules as those set out in this Article, to any sub-contractor or any other party.

7.5 This Article shall survive the expiry or termination of the Contract.

Article 8 Security Requirements

8.1 The Contractor shall set up protective mechanisms to ensure that the Hardware and/or Software, including any patches and upgrades provided through any electronic media by the Contractor do not include harmful electronic data (including hostile code) which causes, or is likely to cause detriment, or failure, or loss of performance, or loss of service or harm in any degree, to any computer systems or network systems owned by the Customer or other users.

8.2 The Contractor shall not carry out, and shall procure that its subcontractors shall not carry out, any act or make any omission which has or could reasonably be expected to have an adverse impact on the security of the Solution or Services provided to the Customer, the Customer’s business, activities, customers, or systems.

8.3 At the Customer’s request, the Contractor will co-operate with any investigation relating to security which is carried out by or on behalf of the Customer, including by providing any information or material in its possession or control and implementing new security measures.



Page 45 of 163

8.4 Each party shall advise the other as soon as it is aware of any security breach or potential security breach which may affect the Solution, the Services or the reputation of the Customer. Article 5.5 shall apply to this Article.

8.5 The Contractor’s personnel (including personnel of any subcontractors) may be subject to the provision of the Official Secrets Act.

8.6 The Contractor’s personnel (including personnel of any subcontractors) involved in anyway whatsoever in the provision of the Services may be subjected to security screening procedures at any time during the Term. The Customer shall inform the Contractor that such security screening procedures are necessary in relation to the Contractor’s personnel (including personnel of any subcontractors). It will be the responsibility of the Contractor to carry out the security screening procedures in accordance with local legislation.

8.7 Failure by the Contractor’s personnel to be security cleared as may be requested pursuant to Article 8.6 will constitute ground for the Customer to reject the involvement of the personnel in the provision of the Services.

8.8 A breach of this Article will constitute a material breach of this Contract.

Article 9 Intellectual Property Rights

9.1 The Customer shall retain all Intellectual Property Rights arising from equipment, software, materials and documentation owned by the Customer at the time of signature of the Contract and used in the course of the provision of the Service.

9.2 The Contractor acknowledges that all data, information, text, drawings and other materials related to this Contract which are embodied in any electronic, optical, magnetic or tangible medium, and which are supplied to the Contractor by the Customer is the sole property of the Customer.

9.3 The Contractor acknowledges that the data generated, transmitted or processed through or using the Solution is the property of the Customer.

Intellectual Property Rights Claim

9.4 The Contractor will indemnify, defend and hold harmless the Customer in respect of all losses, costs, claims, demands, actions, fines, penalties, awards, liabilities and expenses (including legal expenses) incurred by or awarded against the Customer in connection with any claim or action against the Customer by any Third Party that the use by the Customer of the Software used by the Customer by virtue of this Contract or the receipt of any Services provided by the Contractor infringes the Intellectual Property of that Third Party (“IPR Claim”) and the Contractor will take all steps necessary to defend the IPR Claim.

9.5 The Customer agrees that:(a) it will notify the Contractor in writing as soon as reasonably practicable of any IPR

Claim of which the Customer has notice;(b) it will not admit any liability or agree to any settlement or compromise of an IPR

Claim without the prior written consent of the Contractor, which will not be unreasonably withheld or delayed;



Page 46 of 163

(c) the Contractor will be entitled to assume exclusive conduct of any proceedings or action, negotiate the settlement of the IPR Claim and of all discussions and dispute resolution efforts in connection with the IPR Claim; and

(d) the Customer will, at the Contractor’s request and expense, give the Contractor all reasonable assistance in connection with the conduct of the IPR Claim.

9.6 If any IPR Claim is made or is likely to be made against the Customer, the Contractor shall be entitled at its own expense and option either:

(a) To obtain for the Customer the right to continue using the Software in accordance with this Contract; or

(b) modify or replace the infringing part of the Software so as to avoid the infringement or alleged infringement, without prejudice to the representations and warranties in this Contract in relation to all or any part of the Software, and without diminishing or curtailing in any material respect the performance or functionality of the Software as described in any relevant specifications.

9.7 The indemnity given under this Article will not apply to the extent that any infringement has arisen directly from any modifications of the Software and/or the Services which are not contemplated by this Contract and which are made by the Customer without the Contractor’s consent or authorisation.

Article 10 Limitation of Liability and Indemnity

10.1 The Contractor shall be liable for any loss, injury, damage, expense or delay incurred or suffered by the Customer arising directly or indirectly from or in any way connected with the provision of the Solution or Services by the Contractor to the Customer in particular but without limitation any loss, injury, damage, expense or delay arising from or in any way connected with: (a) failure of the Contractor to perform its obligations as set out in this Contract, or(b) any act or omission of the Contractor, whether wilful, negligent, fraudulent or

otherwise.

10.2 Neither party excludes or limits liability to the other for death or personal injury to the extent it results from any act or omission of either party, its employees, agents or subcontractors.

10.3 Except as otherwise specifically provided herein and subject to the limits of liability imposed by virtue of this Article, neither party shall be liable to the other for loss of profits, loss of business, or for any other special, punitive, indirect or consequential loss or damages unless arising from gross negligence or a wilful act or omission of the other party.

10.4 The provisions of this Article shall not be taken as excluding or limiting the Customer’s rights under the Contract to claim for costs and expenses which would not otherwise have been incurred by the Customer or which would have ceased or would not have recurred.

10.5 The Customer shall indemnify, protect and defend the Contractor , its employees, agents or authorised representatives from and against all actions, claims, losses or damages arising directly or indirectly as a result of fraud, bad faith, wilful default or negligence of the Customer, its employees, agents or authorised representatives in performing its obligations pursuant to this Contract.



Page 47 of 163

10.6 The Contractor shall indemnify, protect and defend the Customer, its employees, agents or authorised representatives from and against all actions, claims, losses or damages arising directly or indirectly as a result of fraud, bad faith, wilful default or negligence of the Contractor, its employees, agents or authorised representatives in performing its obligations pursuant to this Contract.

10.7 Notwithstanding any other provision of the Contract, the maximum aggregate total liability of the Contractor under the Contract, including liability for any breach of the Contract by the Contractor, whether or not leading to the termination of the Contract, and for any indemnity in terms of the foregoing provisions of this Article, shall be limited to the total value of the Contract inclusive of VAT.

Article 11 Performance Guarantee

11.1 The Contractor shall deliver a duly executed Performance Guarantee in a form and from a bank acceptable to the Customer as set out in Schedule E within ten (10) days from the date of signature of the Contract for the value of [amount]. The Customer may adjust the value of Performance Guarantee after three (3) years from the commencement date of the Contract, which revision shall reflect the balance still payable by the Customer.

11.2 The Contractor agrees to retain the Performance Guarantee if the Parties agree to extend the Term. The Parties will agree on the value and term of the extended Performance Guarantee.

11.3 The Contractor will be considered to be in material breach of the Contract in the event

that the Contractor fails to furnish the Performance Guarantee as set out in this Article.

11.4 The Performance Guarantee will be held against the payment to the Customer for any damages or losses resulting from the Contractor’s failure to perform his contractual obligations fully and properly.

11.5 The Customer will demand payment from the Performance Guarantee of all sums for which the Contractor is liable under the Performance Guarantee due to the Contractor’s default under the Contract, in accordance with the terms of the Performance Guarantee and up to the value thereof.

11.6 The guarantor will, without delay, pay those sums upon demand from the Customer and may not raise any objection for any reason whatsoever.

Article 12 COMMUNICATION

12.1 Communications between the Customer and the Contractor shall be in writing. Both Parties shall ensure that any verbal communications are followed up by a written communication.

12.2 Whenever the Contract provides for the giving or issuing of any notice, consent, approval, certificate or decision, such notice, consent, approval, certificate or decision shall be in writing and delivered by registered post or facsimile or by electronic means as follows:

Notices to the Customer Notices to the Contractor:



Page 48 of 163

Client Address

Attn: E-mail: Telephone number: Facsimile number:

XXX LimitedAddressAddressAddressAddress

Attn: E-Mail: Telephone number:Facsimile number:

12.3 Any communications sent by post shall be deemed to be delivered four (4) business days after posting and if sent by facsimile shall be deemed to have been received at the time of delivery as indicated on the answer back code permitting that such time is not beyond Normal Working Hours in which case the time of delivery is deemed to be 08.00 am of the following working day.

12.4 In the case of communications sent via electronic means, the parties recognise and accept all associated risks including lack of security, unreliability of delivery and possible loss of confidentiality. Such communications shall be regulated by any relevant legislation in force from time to time.

Authorised Signature Authorised Signature

Name and Position Name and Position

Date Date

The Customer The Contractor National Blood Transfusion Service

VAT Reg. MT VAT Reg. MT



Page 49 of 163

Schedule A The Solution

1. Introduction

This Schedule sets out the obligations and responsibilities of the Customer and the Contractor in connection with the implementation of the Solution.

2. General Requirements

2.1 The Services to be provided under this Schedule consist of the following components:

a) The implementation of the Contractor Equipment and Software detailed in Schedule G

b) The provision of Functional Specifications as detailed in Schedule D

c) The design, installation, configuration and implementation of the solution inclusive of any related services for the successful provision of the solution.

d) Services including, project management, training and maintenance and support services.

2.2 In delivering the Services, the Contractor shall have regard for any alerting, advisory or similar notices from the Customer, in particular notices which relate to security risks.

2.3 The Contractor shall avoid as far as possible the effects of known faults or bugs in the Equipment and Software and operate sound Workarounds where these are available.

2.4 The Contractor agrees that the Solution shall achieve the functionality requirements through parameterisation and not customisation of the Solution unless by prior written agreement with the Customer.

2.5 The Contractor shall ensure that all approved parameterisation and customisation shall not prevent, inhibit or compromise the Customer’s ability to implement future releases of the Software being supplied under this Agreement and that such future releases and upgrades incorporate existing parameterisation and customisation. Notwithstanding the foregoing, if the Contractor (1) advises the Customer that such parameterisation and/or customisation will inhibit the Customer’s ability to receive future releases and (2) the Customer approves such parameterisation and customisation in writing, then the Contractor will have no such obligation regarding future releases;



Page 50 of 163

Schedule B Maintenance and Support Services

Part A Service Management Services

1. Principles

This Schedule covers the provision of the management of the maintenance and support services being provided by the Contractor. The Customer follows the ITIL Service Management standard. The Customer’s Service Call Centre is central to the provision of this service management.

2. Definitions

‘Incident’ means any event which is not part of the standard operation of the Software or Equipment which causes an interruption to the use of the Software or Equipment.

‘Problem’ means an unknown underlying cause of one or more Incidents.

‘Resolution’ means an action that will resolve an Incident or Problem resulting in the Incident or Problem being closed.

‘Restoration’ means an action whereby use of the Solution has been restored. This may be either through Resolution or through a Workaround which allows the resumption of the use of the Solution without Resolution.

‘Restoration Time’ means the time that elapses between the initiation of a communication by the Customer’s Service Call Centre notifying an Incident to the Contractor’s Help Desk and Restoration.

‘Target Resolution Time’ means the time that elapses between the initiations of a communication by the Customer’s Service Call Centre notifying an Incident to the Contractor’s Help Desk and the Resolution of the Incident or the notification of a proposed Resolution to Customer by the Contractor.

‘Workaround’ means, in relation to an Incident, a temporary solution to the Incident:

o which is not unnecessarily difficult, time consuming or expensive to put into operation;

o which enables the Customer to use the Solution in such a way as to avoid the Incident having any materially adverse effect on the operation of the Customer’s business; and

o the implementation of which is agreed between the Contractor and the Customer (each party acting reasonably) before it takes place.

3. Roles and Responsibilities

This Section sets out the roles and responsibilities in relation to the maintenance and support of the Solution.

Responsibilities of the Customer

Service Desk



Page 51 of 163

The Customer shall provide a Service Call centre (Service Desk) which provides operational Service Support to the Solution user base, together with the MITA Service Management System (MSMS) to facilitate the management of Incidents as well as for the tracking of other service management disciplines, such as Change Management.

The availability of the Customer Service Call centre is 24x7x365.

The Customer’s Service Call centre will receive calls from end users and will escalate such questions, requests or Incidents to the Contractor’s Help Desk via the MSMS. The MSMS shall be the basis for Service Level measurement and service credit calculations.

MITA shall provide reports from the MSMS to the Contractor as required for the computation of the adherence to Service Levels.

Contractor Responsibilities

The Contractor is responsible for ensuring that all Service Management Services are documented, defined, monitored and reported on in accordance with the processes and operational and technical procedures set out in the Procedures Manual. The Service Management Services shall consist of the following components, based on the ITIL Service Management standard:

a) Contractor’s Help Desk

b) Incident Management

c) Problem Management

d) Configuration Management

e) IT Change Management

f) Release Management

g) Capacity Management

h) Availability Management

i) Service Level Management

j) Business Continuity Management

k) Equipment Lifecycle Management.

The Contractor shall provide an English speaking Help Desk (Call Centre).

The Contractor shall use the MSMS as a means of notification of calls escalated to the Contractor. The Contractor shall update the MSMS incident record with the appropriate feedback. In this way the MSM will contain a full and accurate record of all reported incidents.

The Contractor is responsible for developing and implementing all processes, procedures, and tools, excluding the MSMS, that are required to enable the Contractor to meet its obligation to provide Service Management Services under this Agreement.



Page 52 of 163

The Contractor shall provide end of month reports which clearly indicate the number of incidents logged, the response and resolution time, and any breaches which may have occurred for the respective month.

4. Incident Categorisation

Incidents will be prioritised into Priority 1, 2, or 3 depending on the criticality/impact of the incident. The Customer will determine the prioritisation of reported incidents. The Customer shall act reasonably and in good faith, in the determination of the priority of each incident.

The Service Levels (SLAs) for the respective Incident categories is presented in the table below:

To be updated as per tender requirements

Software Problem Severity

Problem description Response Time

Restoration Time

Target Resolution Time

Critical

(Priority 1)

Entire Solution is unavailable, the Software and/or Equipment is completely inoperable impeding service provision

[time] [time] [time]

High

(Priority 2)

Business critical system function or group of functions of the Software or Equipment is unusable, inaccessible or not operating correctly


Medium

(Priority 3)

Non business critical system function or group of functions or the Software or Equipment is unusable, inaccessible or not operating correctly


Service Credits will apply where the Restoration Time has not been achieved.

For Priority 1 and 2 Incidents the Contractor will assess the nature of the Incident and the degree of difficulty in providing a Resolution. On an issue-by-issue basis and no later than within the Target Resolution Time, the Contractor will notify the Customer of the proposed Resolution of the Incident and will agree with the Customer the proposed actual time for the



Page 53 of 163

Resolution of the Incident, such timeframe not to be unreasonably rejected by the Customer. Penalties will apply where the agreed time for the Resolution of the Incident has not been achieved.

No penalties will apply to the non-achievement of the Target Resolution Times.

Where Restoration or Resolution is delayed because of information or assistance requested from the Customer has been delayed, the Contractor’s Restoration or Resolution time shall be suspended until the Customer responds to the request.

5. Availability of the Solution

To be updated as per tender requirements

The Solution is expected to achieve an availability level of not less than [as per tender requirement] during over a 12-month period of the planned Service-Time in any Measurement Period], using the following formula:

Availability = (1 – (Service Unscheduled Downtime / Service Time)) x 100

Service-Time will be the time that the Solution should be available and excludes any scheduled downtime and any downtime due to unavailability of the system platform supported by the Customer. Service-Unscheduled-Downtime is the time the Solution is not available as a result of a Priority 1 Incident due to application related problems.

6. Service Credits

The Contractor will include all necessary detail in their monthly reports to enable the Customer to determine the Service Levels achieved and calculate any applicable Service Credits.

Service Level measurements and calculations will be based on the information recorded in the MSMS.

Application of Service Credits (Penalties)

A Service Credit will apply to each failure by the Contractor to meet the Incident Service Level set out in this contract, and the required availability of the solution.

The parties shall calculate the total Service Credits due on a monthly basis (except for Solution Availability which will be calculated on an annual basis) and shall accrue such an amount to be deducted from the Service Credit Payment applied annually in accordance with Schedule C Charges

Service Credits

Incident Priority Minimum achievable service level achievement calculated on a monthly basis

Penalty

Priority 1 95% must meet the required SLA

Euro 60 per hour of delay



Page 54 of 163


Euro 30 per hour of delay


Euro 80 per day of delay

7. Downtime

Subject to the prior written agreement of the Customer, which shall not be unreasonably withheld or unreasonably delayed, downtime will be scheduled based on planned implementation of releases, upgrades, emergency fixes and/or other interventions required to maintain the applications and corresponding infrastructure. Both parties will agree in advance on scheduled downtime through a change management process.



Page 55 of 163

Part B Operational Services

[To include document describing the responsibilities of the parties in a PRE setup, as attached to the ITT]

Part C Maintenance Services

This Part sets out the roles and responsibilities in relation to the maintenance and support of the Solution. In this Part, the following words shall have the following meanings:

‘Equipment Upgrade’ means any modification or upgrade of any one of the Equipment by the Contractor, Subcontractor and/or original manufacturer of such Equipment that materially changes the efficiency or functional capability of the Equipment and/or Contractor System and that are subject to an additional charge.

‘Software Updates’ shall mean any modification, improvement, or error correction (which means any modification of the Software that corrects an error/malfunction by bringing the Software into material conformity with the specifications) to the Software;

‘Software Upgrades’ means any new release of the Software that is any release that adds material functional capabilities to such Software.

‘On site Support’ means support performed at the Customer’s sites or at any other site of a GOM Body where the Solution is made use of.

‘Remote Support’ means (i) support provided through VPN Connectivity Service where the Solution allows it, and/or (ii) telephone support.

‘Spare Parts’ shall mean parts necessary to carry out Maintenance Services pursuant to this Schedule and with regard to the Equipment pursuant to clause 3.1 of the main Agreement.

1. Software Maintenance Services shall consist of the following services:-

i. Investigation, diagnosis and identification of alleged Incidents in the Software, difficulties or problems associated with its operation, reported by the Customer to the Contractor’s Service Desk including restoration, calibration, testing and full system validation after recovery;

ii. Notification to the Customer by appropriate means and the provision to the Customer of recommended Software Updates, modification and alterations to the Software (such notices being referred to herein as "Software Notices"). The Contractor accepts no responsibility or liability in respect of any such recommendation where the Customer has not carried out all other relevant recommendations contained in other Software Notices received by the Customer;



Page 56 of 163

iii. Software Updates, patches for updates aimed at correcting Incidents;

iv. Software Upgrades;v. Provision of advice to the Customer regarding the operation of the

Software;vi. Technical advice by telephone through the Contractor’s Service

Desk in relation to the Software.

2. When an Incident is recorded, Maintenance Services include:

i. investigation of operational problems and, provision of advice on the likely cause and recommend a course of action or implement remedial measures;

ii. investigation of data corruption and advice on the likely cause and, where possible, the rebuilding or restoration of the data from a full workable back-up that the Customer shall provide to the Contractor at the Contractor’s request.

iii. where the investigation highlights that the Incident relates to Software, the Maintenance Service will include the provision of advice, work around options, specification, development, release and supervision or implementation of remedial measures;

iv. the resolution of Incidents, which may be delivered to the Customer electronically, or in the case of third priority Incidents as provided for in Part A of this Schedule.

3. The Contractor shall provide the Customer with one copy of each Software Update and/or Software Upgrade without additional charge, and once installed such Software Update and/or Software Upgrade shall be deemed part of the Software and shall then be maintained in accordance with this Agreement at no additional cost.

4. The Contractor shall provide Remote Support for any Incident or On Site support, at its discretion. The Contractor shall be responsible to ensure that the type of support provided to GOM shall be as provided in this Schedule 6.

5. The Customer responsibilities in relation to the Maintenance Services5.1 Throughout the Term, the Customer shall:

i. Not, without the Contractor's prior written consent, permit persons other than the Contractor to effect any modifications or changes to the Software or its operating conditions or to access or copy the Software code.

ii. [Provide VPN Connectivity Service to the Software as agreed between the parties].

5.2 The Customer hereby undertakes not to de-compile, disassemble or reverse engineer nor to alter or modify the whole or any part of the Software in any way whatever nor to permit the whole or any part of the Software to be altered or modified or to be embedded in or with or incorporated in any other programs without the Contractor's prior written consent.



Page 57 of 163

6. Equipment

6.1 In providing Maintenance Services the Contractor shall provide, at the Contractor’s sole cost (i) any necessary replacement Equipment or Spare Parts at the sole discretion of the Contractor, and (ii) the related installation services.

6.2 In providing support in relation to the Equipment, the Contractor shall be entitled to

use refurbished replacement Equipment or parts as long as it uses the same quality control procedures and warranties as for new parts.

6.3 All Replacement Equipment or Spare Parts shall be provided either on a “standard exchange” basis (i.e. the Equipment or parts being refurbished to a condition that is in all relevant respects similar to that of new parts) or as new Equipment or parts. Replaced Equipment and parts shall become the Contractor’s sole property.

6.4 Without prejudice to the Contractor’s responsibility to implement a Solution and provide Services in accordance with the terms of this Agreement, the Contractor reserves the right to provide the Client with “substantially equivalent” Equipment, and Spare Parts. (Substantially equivalent shall mean any component which by vendor type is similar in technology and functionality).

6.5 The Maintenance Services do not include the provision of any accessories or Spare Parts.



Page 58 of 163

Schedule C Charges

1 Procurement of the Solution

As per tender submission

1.1 Charges a) Procurementb) Maintenance and Support

2 Maintenance and Support Charges


3, Charges for additional Services


4. Terms of Payment

4.1 Payment of the Solution Procurement shall be divided in the following manner:25% on delivery and commissioning of the h/w including o/s implementation 25% for the implementation and go live of each module that is for i) document management system module; ii) supplier management module; iii) training module.

4.2 Payment of the maintenance and support shall be made in the following manner:

The Contractor shall invoice the Customer at the end of each quarter. The Customer shall submit payment within 60 days of receipt of the invoice unless

the Customer protests in writing such an invoice during this period. The Contract Reference Number must be specified with every invoice.

All charges are VAT inclusive.



Page 59 of 163

Schedule D Technical and Functional Requirements

As per tender document and tender submission



Page 60 of 163

Schedule E Delivery and Implementation

1. Delivery Timeframes

As per tender document and tender submission1. Implementation Plan

1.1 The Implementation Plan clearly identifies all of the Milestones which are linked to the Payment Milestones referred to in Schedule C Charges.

1.2 The parties shall consider and review the Implementation Plan and progress towards its successful implementation at the Project Board meetings

2. Milestones and Milestone Dates

2.1 The Contractor shall perform its obligations so as to achieve each Milestone by the Milestone Date.

2.2 Changes to the Milestones set out in the Implementation Plan shall only be made in accordance with the Change Control Procedure and subject to approval by the Project Board.

3. Project Management

3.1 The Contractor will execute and manage all project activities on an ongoing basis in accordance with Good Industry Practice and with Contractor’s standard project management process and methodology.

3.2 The Contractor will further provide detailed Implementation Plans including Contractor and Client resource requirements prior to the implementation of each phase/ module forming part of this project. The Contractor shall provide such ancillary services that are necessary during the implementation of the Solution. These services should include but not be limited to:(a) assistance during Testing;

(b) assistance during data collation, preparation and entry;

(c) Provide Training as described in Schedule E of this Schedule;

(d) lead and work with users and technical personnel during the parameterisation and configuration.

(e) Provide experience in the implementation of the Solution;

(f) Manage the process of any necessary skills transfer to the Customer and provide knowledge transfer to the Customer’s

Page 61

personnel throughout the provision of the Services.

3.3 The Contractor shall provide status updates to the Project Board.3.4 The Contractor appointed project manager(s) will be responsible for the

following activities:

Scope management; Design; Resource management; Schedule management; Risk management; Change management; Communication management; Quality management; Financial management; Deployment.

4. Training Plan

As per tender documents

5. Implementation Plan (Gantt Chart)

Page 62

Schedule F Performance Guarantee

As per Tender Document Volume 2 Section 4 Performance Guarantee

Page 63

Schedule G SOFTWARE AND EQUIPMENT LIST

1. General

1.1 This schedule details the various elements of the Solution and categorises them into Specially Written Software, Contractor's Software, Third Party Software and Contractor Equipment. This schedule also lists which elements of the Software are to be are placed into escrow as Deposited Software.1.2 The Software is licensed in accordance with the provisions of Section G of the Agreement.1.3 The parties agree that they will update this schedule periodically to record any software or equipment subsequently acquired from third parties or developed for the delivery of the Services.1.4 The Contractor acknowledges that the obligation of the Contractor to provide the Solution shall not be limited by the list of the Equipment and Software included in this Appendix. The Contractor shall provide, at its sole cost, such further equipment and software as the Contractor may consider are required to provide the Solution in line with the requirements detailed in this Schedule, in accordance with and subject to the terms and conditions of this Agreement.2. Specially Written Software

The Specially Written Software shall consist of any programs, codes and software written by or on behalf of the Contractor for use by the Contractor specifically in the provision of the Services (including any modifications or enhancements made to such software during the Term) and including (but not limited to) the following items:

Software

Supplier (if Affiliate or Sub-contractor of the Contractor)

Purpose

To be deposited in Escrow (Deposited Software)?

Yes / No

Yes / No

Yes / No

3. Contractor Software

The Contractor Software comprises the following items:

Page 64

Software

Supplier (if Affiliate of

the Contractor)

Purpose

Number of

Licences

Restrictions

Number of

Copies

To be deposited in Escrow

(Deposited Software)?

Yes / No

Yes / No

Yes / No

4. Third Party Software

The Third Party Software shall consist of the following items:

Third Party Software

Supplier

Purpose Number of

Licences

Restrictions

Number of

Copies

To be deposited in Escrow

(Deposited Software)?

Yes / No

Yes / No

Yes / No

5. Deposited Software

The Contractor shall deposit the Software identified in paragraphs 2, 3 and 4 above as Deposited Software into escrow in accordance with the provisions of clause 34 (Escrow):

Category (Specially Written Software, Contractor Software or Third Party Software)

Supplier Description Restrictions Date Deposited

Page 65

6. Equipment

Equipment Supplier (if Affiliate or Sub-contractor of the Contractor)

Purpose

Page 66

Schedule H Contractor Undertakings

Declaration for Non-Disclosure <To be included only if specific personnel of the Contractor will be required to sign the Declaration for Non-Disclosure>

VPN Terms and Conditions

Page 67

VOLUME 2 SECTION 2 – GENERAL CONDITIONS

The full set of General Conditions for Supply Contracts (Version 1.01 dated 15 March 2010) can be viewed/downloaded from:

www.contracts.gov.mt/conditions

It is hereby construed that the tenderers have availed themselves of these general conditions, and have read and accepted in full and without reservation the conditions outlined therein, and are therefore waiving any standard terms and conditions which they may have.

These general conditions will form an integral part of the contract that will be signed with the successful tenderer/s.

Page 68

http://www.contracts.gov.mt/conditions

VOLUME 2 SECTION 3 – SPECIAL CONDITIONS

These conditions amplify and supplement, if necessary, the General Conditions governing the contract. Unless the Special Conditions provide otherwise, those General Conditions remain fully applicable. The numbering of the Articles of the Special Conditions is not consecutive but follows the numbering of the Articles of the General Conditions. Other Special Conditions should be indicated afterwards.

Article 2: Law Applicable

2.1 The laws of Malta shall apply in all matters not covered by the provisions of the contract.

2.2 The language used shall be English.

Article 4: Communications

As per general conditions.

Article 7: Supply of Documents

As per general conditions.

Article 8: Assistance with Local RegulationsAs per general conditions.

Article 9: The Contractor’s Obligations

9.6 As per general conditions.

Article 10: Origin


Article 12: Insurance


Article 14: Contractor’s Drawings


Article 15: Tender Prices

Page 69


Article 16: Tax and customs arrangements


Article 17: Patents and Licences


Article 18: Commencement Order

18.1 Upon the date of last signature of contract.

Article 19: Delays in Execution


Article 26: Methods of Payment

26.1 Payments will be made in Euro.

Payments shall be authorized by the Contracting Authority, and paid by the Treasury Department.

Article 29: Delivery

29.1 The Contractor shall bear all risks relating to the goods until provisional acceptance at destination. The supplies shall be packaged so as to prevent their damage or deterioration in transit to their destination.


Article 35: Breach of Contract

35.3 Without prejudice to the Government’s right to dissolve ‘ipso jure’ the contract in the case of infringement of any condition thereunder and apart from the deduction established for delay in delivery, any such infringement shall render the contractor, in each case, liable to a deduction by way of damages of 5 per cent of the value of the contract, unless the Government elects, with regard to each particular infringement, but not necessarily with regard to all infringements, to claim actual damages incurred.

Article 41: Dispute Settlement by Litigation

Any dispute between the Parties that may arise during the performance of this contract and that has not been possible to settle otherwise between the Parties shall be submitted to the arbitration of the Malta Arbitration Centre in accordance with the

Page 70

Arbitration Act (Chapter 387) of the Laws of Malta.

This law is based on “Model Law” which is the Model Law on International Commercial Arbitration adopted on June 21, 1985 by the United Nations Commission on International Trade Law reproduced in the First Schedule of the Arbitration Act.

Page 71

VOLUME 2 SECTION 4 – SPECIMEN PERFORMANCE GUARANTEE

(LETTERHEAD OF THE REGISTERED FINANCIAL INSTITUTION PROVIDING THE GUARANTEE)

Director of ContractsDepartment of ContractsNotre Dame RavelinFloriana FRN1600Malta

[Date]Dear Sir,

Our Guarantee Number .......................... for €......................

Account: [Account Holder’s Name] In connection with the contract entered into between yourself on behalf of the Director of Contracts and [Name and Address of Contractor] hereinafter referred to as “the Contractor” as per the latter’s tender and your acceptance under [CT File Reference], whereby the contractor undertook the [title of contract] in accordance with Article 11 of the Special Conditions the [works/services/supplies] as mentioned, enumerated or referred to in the Specification and/or Bills of Quantities forming part of the contract documents, we hereby guarantee to pay you on demand a maximum sum of €[amount in works and numbers] in case the obligations of the above-mentioned contract are not duly performed by the Contractor.This guarantee will become payable on your first demand and it shall not be incumbent upon us to verify whether such demand is justified.

For avoidance of doubt it is hereby declared that although this instrument gives rise to legal relations between the guarantor and the beneficiary, it is hereby specifically declared for all intents and purposes of law that this guarantee does not exempt the above-mentioned Contractor from any obligations, acts of performance or undertaking assumed under the tender documents as ratified in the contract.

Any payments due to the contractor in respect of the obligations entered into under the contract above referred to shall be made through this Bank.

This guarantee expires on the [expiry date] and unless it is extended by us or returned to us for cancellation before that date any demand made by you for payment must be received in writing not later than the aforementioned expiry date.

This document should be returned to us on utilization or expiry or in the event of the guarantee being no longer required.

After the expiry date and in the absence of a written demand being received by us before such expiry date, this guarantee shall be null and void, whether returned to us or not, and our liability hereunder shall terminate.

This guarantee is personal to you, and is not transferable or assignable.

Yours Faithfully,

.............................................[Signatory on behalf of Guarantor]

Page 72

VOLUME 3 SECTION 1 – CONTRACTING AUTHORITY’S REQUIREMENTS (TERMS OF REFERENCE)

1.0 Introduction

The National Blood Transfusion Service (NBTS) is part of the Health Service of the Government of Malta (GOM). The ICT infrastructure for GOM is provided by MITA, a government owned ICT Agency. Section 1.1 below introduces NBTS, while Section 1.2 introduces the key technology principles of MITA.

1.1 The NBTS

The National Blood Transfusion Service (NBTS) collects blood and blood products from voluntary, non- remunerated donors. This blood is screened, processed and tested so that conforming products are released and distributed for clinical use.

The NBTS operates under a Quality Management System which incorporates the following:

Quality monitoring and control

Data is attained to validate each process in the processing of blood and blood components to ensure that they meet specifications. All critical processes are validated. There is Quality Control data to demonstrate that the processes are in control. Acceptance criteria are based on a defined set of specifications for each blood and blood component.

Internal and external audits

Audits take place to ensure that the Quality System (QS) is being operated correctly and effectively by performing planned and documented checks designed to ensure that:

The QS documentation adequately defines the needs of the Blood Bank; The documented procedures and processes are practical, understood, and implemented; The training of employees is adequate to allow them to do their tasks.

Personnel and organisation

The personnel available are qualified to perform their tasks. They have appropriate qualifications and experience and are provided with initial and continued training in order to assure the quality and safety of blood and blood components. Only persons that are authorised by defined procedures and documented as such are involved in the collection, manufacturing and distribution processes.

Premises, equipment and material

The NBTS is investing in a new Blood Bank which is to be constructed and adapted to suit the operations to be carried out. It is designed to permit effective cleaning and maintenance to minimise risk of contamination. The workflow in the new building will be arranged in a logical sequence to minimise the risk of errors.

All equipment is validated and maintained to suit its intended purpose and not to present any unacceptable risks to both donors and operators.

Only materials that meet documented requirements and specifications are used.

DocumentationPage 73

The pyramid below illustrates the hierarchy of documentation governing the NBTS.

1.2 ICT Environment

1.2.1 High-level technology guiding principles

The Government of Malta strives to ensure that maximum benefit and operational efficiency is derived from all technology investments. A number of technology strategic principles are therefore in place to engage vendors and suppliers towards providing solutions that follow this direction.

These principles include abstraction, interoperability, loose coupling, cohesiveness and generality.

In this context, and where applicable, Government will give preference to solutions that exhibit concrete evidence of a number of key attributes that enable these principles. These attributes are identified in constituents that clearly reflect engineering patterns based on discrete yet highly interoperable elements. All inter-connectivity and information exchange (at hardware, network and software levels) between the solution constituents is to be built on the standards applicable in context. The software, network and hardware elements should be independent of each other to the maximum extent possible.

Virtualization and Open Standards are key enablers of the principles discussed herewith, as well as appropriate segregation at key layers of the solution stack. Specifically with respect to the latter (and irrespective whether the implementation is physical, virtual or otherwise) access to external (from the sandboxed environment) resources (including databases, directory services etc. etc, is governed by appropriate adaptation ('adapters') schemes. Adapters are logical segregators - these adapters vary in shape and form, ranging from in-house developed software, off-the shelf software or specialised devices / environments (including firewalls, VLAN's) as well as specific commercial arrangements.

The desktop element is considered even more critical in terms of the application and adherence to these principles. In this respect and to the maximum extent possible, dependencies on specific hardware and software stacks and respective configurations should be avoided or appropriately mitigated.

Service provisioning, Authentication and IdentityIn line with Government’s high level technology principles identified above, the need to abstract and further de-couple solutions (both line of business applications and servers) from dependencies such as the desktop and / or other services that a solution interacts with, such as directory services, authentication services, etc. has become critical. The application of these technology principles will facilitate the replacement and/or de-coupling

Page 74

QUALITY MANUAL / SITE MASTER FILE

POLICIES / OFFICIAL DOCUMENTS

STANDARD OPERATING PROCEDURES

MEMOS AND RECOMMENDATIONS

EU DIRECTIVE / LEGAL REQUIREMENT

of such dependencies with minimal impact and cost to the underlying solutions, whilst guaranteeing business continuity.

Identity management, Authentication and the Desktop are three key areas that critically need to be abstracted and de-coupled from provisioned solutions to the maximum extent possible.

Government’s Current Identity Management and Authentication PositionGovernment’s identity management services are currently implemented via the Corporate Directory Services (CORP AD) implementation, which is based on Windows 2003 Active Directory and is mainly used for:

i)Core Identity and ServiceIdentity and Authentication of users interacting and using Government’s Corporate/Shared Assets/Service (Email, Internet etc.) which must employ MITA's identity persistence provisioning schemes currently through CORP AD.

ii) Centralised Desktop and User ManagementDesktops managed by MITA are currently centrally administered through the CORP AD, this technology facilitates and allows MITA to centrally manage and govern desktops in an efficient and coherent manner.

From a policy perspective centralisation will remain a key driver within Government’s ICT strategy, as such MITA will centralise Government’s users and workstations into the CORP AD to achieve economies of scale and provide increased management efficiency and technology coherency were appropriate. To accommodate flexibility and degrees of autonomy required by certain clients with respect to user and workstation management and line of business solutions, MITA will consider governed decentralised/federated approaches to identity and authentication management.

The decision whether a centralised or federated identity and authentication approach is employed (i.e. MITA's or other authentication persistence and provisioning solution) will depend on various influencing factors and will be agreed on a case by case bases with MITA and the respective client. The factors that will influence such a decision includes but not limited to political sensitivity, strategic value, revenue generation, technology and business complexity, degree of autonomy required, operational costs, security profile and European Union context.

In the case of a decentralised/federated approach, Authentication exchange and/or sharing within and across domains (line of business, Corporate, etc.) has to be abstracted and governed through the use of appropriate industry standard protocols such as SAML.

Application ProvisioningFrom an application provisioning perspective, the current tight coupling of applications to the desktop is posing a high degree of dependency on the desktop configuration and therefore limiting the desktop of moving ahead in terms of technology. As a result of this, MITA has identified the need to abstract to the maximum extent possible, applications from the desktop stack in order to allow both the desktop and applications to evolve independently of each other. ‘Webification’, Application virtualisation and Remote Desktop Services are three technologies that have been identified to promote such application abstraction.

Application Authentication

The two main authentication schemes currently employed throughout Government information systems are mainly:

i) system authentication (local username and passwords) which introduce additional overheads, lack of control and policy enforcement.

ii) Corporate Directory Services (Microsoft Active Directory - CORP AD) authentication which leads to applications which are tightly bound to the implementation and associated technology stack.

As a result of the above, the need of appropriate identity management (mainly life cycle management), authentication exchange and single sign on functionality becomes prominent. In this respect abstraction through the use of an industry standard claims based framework such as SAML should be implemented.

1.2.2 ICT Operations Page 75

In order for MITA to achieve the objectives / programmes assigned to it under its Strategic Plan, MITA has identified the need to increase the involvement of the private industry for the operation of solutions intended for Government. In this respect, MITA is inviting ICT providers to manage and operate the solution being provided in a controlled environment within MITA's facilities and referred to as a 'Private Runtime Environment, under the same conditions that MITA itself provides its services to Government. The providers will therefore be expected to adhere to all relevant Government ICT policies, standards, procedures (http://ictpolicies.gov.mt) and security requirements that apply to MITA. A description of the Private Runtime Environment (PRE) is found in Section G of this document.

1.3. The Document Management System Solution

This section outlines the solution to be purchased by the Government through this ITT.

1.3.1. Functionality

To effectively and efficiently implement an automated system within the National Blood Transfusion Service to achieve the following goals as required by Good Practice and in conformity with relevant EU Directives:

Document and Process Management: Full-featured document management – document control system incorporating controlled electronic storage, document collaboration and approval, integrated automatic PDF publishing, full document life cycle management and auto workflow launching with the introduction of any new document (independent of file format).

The system should allow the National Blood Transfusion Service to employ any form in use today, and render it into a PDF file and introduce it as a form template. While forms should be accessed and viewed as PDF files, all captured form data should be maintained in a database.

Training Management: A solution incorporating a comprehensive learning management and automated training records management. The learning management capabilities should include training courses, training exams, curriculums, trainers, trainees and job code relationships to ISO documents. Training management should integrate with document management to drive training notifications upon new or changed documents and control release and effective dates.

Supplier Management: System automating supplier management and supplier compliance in the regulated environment of Blood Banking. Supplier quality information (such as non conforming material reports) should be automatically contained in a single location. Supplier quality issues should be detected early and corrective action implemented immediately. System should offer an easy to maintain Approved Vendor List as well as Bill of Materials for supplied components. Should automatically track and create a history of approved vendor information.

The above modules should be integrated in a main menu to offer a complete quality management solution. The main menu should manage an easy to use (Role based) Graphical User Interface, approval workflows, notifications, system security, analytics (reports & dashboards) and PDF publishing.

The system must be easy to maintain and provide a single source for users to store, approve, access and manage controlled records. The system must be able to be validated to a level of compliance to EU regulations and GAMP version 5 as a minimum.

1.3.2. The solution - Private Runtime Environment

The total Solution shall be made up of the following:

a) the software and the related maintenance, support, implementation and training services;b) the PRE environment for hosting the software and the related maintenance, support, implementation

and other related services

1.3.3. Volumetrics

At any given time there is a minimum of 34 users and a maximum of 50 users (including 9 super users).

1.3.4 Implementation Strategy and Project Plan

Page 76

The implementation strategy should be drawn up so that the modules will go-live in phases, rather than in a big-bang approach, and that all modules will go-live within a period of one year from contract signing.It is preferred that the modules will be implemented in the following order:

1. Document and Process Management.

2. Training Management.

3. Supplier Management and Bills of Material.

It should be noted that although modules will go-live in a phased approach, it would be acceptable that certain project implementation activities are carried out simultaneously for some (or all) of the modules, possibly because of interdependencies of one other. It is expected that bidders will use their experience in implementations of this type to devise an optimised plan that reduces costs.The implementation should include a full-cycle validation to assure the accuracy, reliability, and consistent intended performance of the system. Comprehensive on-site validation support would be required from the successful bidder for Installation Qualification (IQ) tests, Operational Qualification (OQ) tests, and Performance Qualification (PQ) tests to ensure that the system is fully compliant with the relevant EU Directives and latest Good Automated Manufacturing Practice (GAMP). Validation should be inclusive of all the necessary documentation and reporting.As part of their response, bidders are required to submit a detailed implementation strategy of all the steps that will be followed for the successful implementation of the modules, together with a detailed project implementation plan that reflects the strategy. The implementation strategy and plan should clearly indicate all activities that will need to be carried out by the NBTS.

The project plan should detail the tasks and activities that will be undertaken within each phase of the implementation, and should outline the following:

a) Timescales, starting from the contractual date.

b) Hardware Delivery

c) Hardware Installation

d) Operating System Installation

e) Network and Infrastructure Implementation.

f) Validation of Hardware

g) Effort required for each activity or task.

h) The resources required to carry out each task on the plan.

i) Milestones and deliverables.

j) The resource commitment level required by both the bidder and the client for each phase and activity on the plan.

k) Any pre-requisites to be provided for the completion of each phase.

l) Database and Application Software Installation

Implementation is expected to include:

1. Review the NBTS business requirements and processes with the NBTS.

2. Documentation of the business requirements and processes for review and acceptance by the NBTS.

3. Configuration of the System according to the agreed business requirements.

4. The delivery of End user downtime procedures for instances when the system is unavailable.

5. Procedures that users will need to follow to update the system when it becomes available again.

1.3.5 Validation

Page 77

Validation should include tests to establish documented evidence which provide a high degree of a high level of assurance that processes within the system will consistently produce a result which meets the pre-determined specifications and quality attributes.Test Scripts will need to be prepared and used to confirm that the system meets the business requirements. Validation will be carried out in conformance to the latest GAMP validation guidelines, and will include Installation Qualification (IQ) tests, Operational Qualification (OQ) tests, and Performance Qualification (PQ) tests, together with business process tests.

1.3.6 User Acceptance Testing

Formal testing (carried out by NBTS) with respect to user needs, requirements and business processes conducted to determine whether or not the system satisfies the acceptance criteria and to enable NBTS to determine whether or not to accept the system.

1.3.7 Training

Training is a crucial aspect of the project. It is important that the following is provided:

1. System Administrator training. The successful bidder will be required to prepare all training material, and deliver the training on-site.

2. Super User Training. The successful bidder will be required to prepare all training material, and deliver the training on-site.

3. End User Training. The ‘train the trainer’ approach will be adopted for end user training. The successful bidder will be required to prepare all end-user training material. End user training will be delivered by the ‘Super Users’. During ‘End User training’ user will also be trained in the application of the downtime procedures.

1.3.8 Go-Live

The implementation strategy and project plan should include a go-live plan for each module. The go-live plan must address, but should not be limited to:

1. The transfer of all application software and configuration files from the test environment to the live environment.

2. PC Configuration.

3. Printer Configuration.

4. The setup of any master files by super users.

5. The provision of application login names and passwords to the end users.

6. Access to functionality.

7. On-site Go-live assistance to end users by the successful bidder during the initial go-live period so as to ensure that any issues are addressed immediately.

1.3.9 Support Services

To ensure business continuity and after the lapse of the warranty period, and other contractual conditions, Government is prepared to enter into a minimum of 36 months maintenance and support agreement with the option to extend after the lapse of such period for a maximum period of 60 months upon Government’s discretion. The supplier is to take into account such requirements and the proposal shall cater for all support levels or per support element.The Bidder is to state that he will provide the service highlighted in the Contract in Part II of this ITT.

1.3.10 Documentation

All systems need to be thoroughly documented. All documentation shall be written in English and should be made available in electronic format. The Bidder should list all the documents, manuals and handbooks that will be supplied. Documentation should include but is not limited to:

Page 78

a) The Procedure manual including set-up sequence; checklist of tests to verify the correctness of the installation; the architecture of the solution.

b) The System Administration Guide covering operator functions, file backups and recovery procedures, and management of security access.

c) Application Software documentation, including screen designs, report formats, programme specifications, system test plan, implementation plan and post implementation support plan.

d) User manuals including a comprehensive list of all error messages.

e) Fault finding guides.

f) The data dictionary defining all data entities and attributes, data groups and data relationships

Page 79

Appendix A– Private Runtime Environment

1. Principles

A Private Runtime Environment (PRE) is an environment which enables Contractors to locate their resources in a segregated environment within premises provided by MITA. Within this environment, the following applies:

(a) MITA will provide the space for the Contractor to install its Solution;

(b) The Contractor will be fully responsible for managing its Solution;

(c) At its discretion, MITA may provide the necessary computing resources itself;

The PRE will be governed by terms of this document. The responsibilities of MITA and the Contractor in relation to the PRE are as articulated in this document.

In order to operate in a PRE, the Contractor must adhere to the following principles:

i. The Contractor fully operates and manages the Solution, including the environment irrespective whether the implementation is physical or virtual.

ii. Access from the PRE to any external resources (including databases, directory services) is governed by 'adapters'. These 'adapters' vary in shape and form, ranging from software, specialised devices / environments (such as firewalls, VLAN's), or specific operating or contractual procedures as defined in the contract between MITA and the Contractor.

iii. When the Computing Resources are to be provided by MITA, the Solution may be operational in a virtualised environment.

iv. Failure to ensure any appropriate visibility and proof that these control mechanism are in place and effective, as well as the non-adherence to any applicable policies will trigger a process where pre-established control and/or total service immobilization procedures may be considered and applied if necessary and as further defined in the Contract.

2. Definitions

i. ‘Computing Resources’ shall comprise:(a) processing power,(b) storage capacity, and(c) memory.

ii. ‘Solution’ shall comprise:(a) the application software and all its constituents, (b) the operating software and all its constituents, and (c) the necessary computing resources, if provided by the Contractor.


This Section sets out the roles and responsibilities in relation to the operation and management of the PRE.

Page 80

3.1 Responsibilities of MITA

In providing a PRE, MITA’s responsibilities shall be limited to the responsibilities included in this section.

3.1.1 Data Centre facilities

MITA will make available the premises for the physical location of the infrastructure to be provided by the Contractor. MITA will be responsible to provide:

(a) rack space in order to rack-mount the Hardware; (b) Data Centre facilities, covering electricity, air conditioning, fire fighting equipment and UPS

power; and(c) Access, as may be required, to back-end infrastructure, including the Malta Government

Network (MAGNET), which MITA is responsible to administer, monitor and support.

3.1.2 Provision of Computing Resources (optional)

MITA may decide to provide the necessary Computing Resources itself based on the specifications as defined by the Contractor. In such a case, MITA will also be responsible for the provision of maintenance and support on the Computing Resources.

In such an eventuality, the Computing Resources to be provided by MITA may be managed and operated by third parties appointed by MITA. MITA will co-ordinate the relationship between all parties within a spirit of commercial co-operation infusing mutual trust, commitment and collaboration to accrue increased value-added to Government.

3.1.3 Backup media administration

MITA will carry out the loading and unloading of the backup media based on a time-table to be agreed between MITA and the Contractor. As part of the backup media administration responsibilities, MITA shall be responsible for the proper storage and safe-keeping of the tapes as set out in the Operations Manual to be provided by the Contractor and agreed to by MITA.

3.1.4 Access to external resources

The specific external resources to be accessed through adapters by the Solution, if any, will be specified in the Contract entered into between MITA and the Contractor. MITA will provide access to these external resources as set out in this document.

3.1.5 Session Recording

MITA may use its own mechanisms, that will be external to the PRE in order to monitor access to the Solution by the Contractor.

3.1.6 ICT Change Management

When MITA requires to carry out a change, MITA shall notify the Contractor with the plan for the implementation of the change. It will be the responsibility of the Contractor to take any remedial action that may be necessary in order to ensure that the proposed changes have no impact on the PRE. The Contractor may request MITA to delay the implementation of the changes to allow it the time to implement the remedial action. However, MITA reserves the right to proceed with the implementation of the changes, in particular where the changes are deemed by MITA to be of a critical nature. The Contractor will be responsible to inform the entities owning the Solution of the change.

Page 81

Following approval and implementation of the change, MITA shall inform the Contractor of the outcome of the change.

3.1.7 Governance

MITA may carry out audits to ensure that the Contractor is performing its responsibilities as set out in this document.

In such an event, the Contractor will ensure that its personnel, subcontractors or agents provide MITA with access to the PRE. MITA shall be bound by confidentiality where information belonging to the Contractor and/or a third party is accessed during the course of the audit.

If, as a result of an audit, MITA considers that any activity or omission by the Contractor has or could reasonably be expected to have an adverse impact on the Solution, MITA’s business, activities, customers, or systems, MITA shall inform the Contractor of the actual or potential adverse impact. The Contractor shall immediately take all the necessary measures to rectify the situation within the shortest possible timeframe to be agreed upon between MITA and the Contractor.

In the event that the Contractor fails to take the necessary measures in the agreed timeframe, MITA shall have the right to suspend access of the PRE to the external resources.

3.2 Responsibilities of the Contractor

3.2.1 Implementation

The Contractor will be responsible to:a. identify and define the necessary Computing Resources that specifically address the

requirements for the implementation of the Solution;b. procure and install the Computing Resources, if this is to be provided by the Contractor;c. install and configure the operating software and all its constituents, and the application

software and all its constituents; andd. test the Solution.

3.2.2 Operations and Management

Within a PRE, the Contractor will be responsible to fully manage the Solution, including but not limited to:

a. all operational and administration activities, including monitoring; andb. the provision of maintenance and support services, including on the Computing Resources (if

applicable); and c. maintaining the specifications of the Computing Resources throughout the operational lifetime

of the Solution.

In performing the operations and management of the Solution, the Contractor shall abide with the following responsibilities:

(a) Access Control

The Contractor shall ensure that its personnel accessing the PRE: (ii) are given the minimum rights and privileges needed to execute the work arrangements;(iii) do not use the Contractor’s equipment connected to the Internet, nor connect to the Internet

whilst accessing the Solution, unless as provided for in this document;

Page 82

The Contractor shall connect through a Virtual Private Network (VPN) in the event that the Contractor requires remote access to the Solution. If two factor authentication is required by the Contractor, the Contractor shall contact MITA in order to be provided with the code generated by the token kept by MITA.

External resources shall be accessed through the use of adapters.

Upon request by MITA, the Contractor shall provide a report listing the resources outside the PRE that are being accessed by the Solution and the tools being used for such access.

(b) Account Management

Accounts shall be assigned to individual personnel. These accounts may not be transferred to any other individual. If an individual no longer works with the Contractor, then the Contractor shall ensure that the account is immediately disabled.

Where the Contractor cannot avoid the use of specific generic accounts to operate and manage the Solution, the Contractor shall provide MITA with the procedure it shall be using for handling, storing, accessing and changing the passwords. MITA shall review the details submitted and may request the Contractor to revise such procedures to ensure an effective way of securing the passwords.

Upon request by MITA, the Contractor shall provide a report listing all accounts associated with the Contractor, their status and applicable reasons e.g. any accounts which were deleted due to the fact that employee no longer works with the Contractor.

(c) End Point Security

The Contractor will be responsible to ensure that the Solution is protected by end point security software compatible with its Solution. The Contractor will:

(i) install and configure an end point security software;(ii) ensure regular updating of the virus definition files;(iii) ensure regular scanning of the Solution;(iv) update the virus signature file before each login, where possible or at lest once every week;

and(v) be capable of disinfecting the Solution and remove any viruses which are identified.

If the Contractor requires access to the Internet for the provision of this service, the Contractor shall provide MITA with the security procedures it will apply to ensure that such access does not have an adverse impact on the security of MITA’s business, activities, customers, or systems.

Upon request by MITA, the Contractor shall issue a report indicating which end point security updates have been installed and which updates have not been installed and the reasons for the non-deployment. MITA may query the updates not deployed and may request that a plan of action is submitted by the Contractor for their deployment. MITA will carry regular process reviews to ensure that the end point security requirements are being adhered to.

(d) ICT Change Management

The Contractor will be responsible to have a change management process in place in order to manage changes to the Solution. The operational details of the change management process will be agreed between MITA and the Contractor and included in the Operations Manual.

When the Contractor has to carry out a change to the PRE which may impact the external resources and/or the back-end infrastructure provided by MITA, the Contractor shall notify MITA with the

Page 83

change and request MITA’s prior approval for the implementation of the change. In such cases, the Contractor must file a Request for Change (RFC) with MITA. The RFC must include the plan for the implementation of the change. MITA will be responsible to inform the entities owning the external resources that will be impacted of the change.

MITA may (a) approve the change or (b) reject the change either by providing reasons to the Contractor for the rejection of the change or until more information is submitted by the Contractor.

Approval of the change does not mean that MITA is taking responsibility of the impact or liability that may arise as a result of its implementation.

Following approval and implementation of the change, the Contractor is responsible to inform MITA of the outcome of the change.

In those cases where the Contractor has to carry out a change to the PRE which is not envisaged to impact the external resources and/or the back-end infrastructure provided by MITA, the Contractor shall provide to MITA a list of such changes, including changes to the Solution, on a quarterly basis.

(e) Patch Management

The Contractor shall be responsible to deploy and install any patches related to:(a) the application software and all its constituents,(b) the operating software and all its constituents, and(c) the Computing Resources, if applicable

using his own solutions and procedures.

The Contractor shall maintain a proper patch management procedure indicating as a minimum the method of deployment and the testing period. MITA reserves the right to review the patch management procedure used by the Contractor and may decline particular setups if these are not up to standard and recommend alternatives.

If the Contractor requires access to the Internet for the provision of this service, the Contractor shall provide MITA with the security procedures it will apply to ensure that such access does not have an adverse impact on the security of MITA’s business, activities, customers, or systems.

Upon request by MITA, the Contractor shall issue a report indicating which patches have been installed and which patches have not been installed and the reasons for the non-deployment. MITA may query the patches not deployed and may request that a plan of action is submitted by the Contractor for their deployment. MITA will undertake periodic process reviews to ensure that the patch management procedure is being adhered to.

(f) Security Hardening

The Contractor is to ensure that the Solution is security hardened to ensure that those features on the ICT devices / software that are either not required for the business operation or which may pose a security risk are disabled or re-configured to minimize the associated risk.

Upon request by MITA, the Contractor shall issue a report showing the features that are disabled. MITA will undertake periodic process reviews to ensure that security hardening is being adhered to.

(g) Event Logs

The Contractor shall enable all security logs on the Solution. Such security logs, which shall be listed in the Operations Manual, shall be kept online for a minimum of 1 month.

Page 84

Logs should be stored in native format. Upon request by MITA, the Contractor shall provide the security logs to MITA. MITA may also request a soft copy of the security logs, in which case the Contractor shall provide MITA with a tool which would enable MITA to read such logs without having actual access to the Solution in question.

(h) Business Continuity

The Contractor shall be responsible for the Solution’s Business Continuity and shall develop any Recovery plans applicable to the Solution. The Recovery plans should cater for all instances where the Solution is affected, whether:

(a) the problem rests within the Solution; or(b) when action is required on the Solution as a result of a problem that arises from external

resources.

The Contractor shall liaise with MITA on those aspects falling under MITA’s responsibilities as stated in this document and have a bearing on the Recovery plans.

The Contractor shall be responsible to provide MITA with a copy of the updated Recovery plans.

3.2.3 Maintenance and Support

The Contractor is responsible for the maintenance and support of the following:(a) the application software and all its constituents, (b) the operating software and all its constituents, and (c) the Computing Resources, if applicable.

The Contractor shall immediately notify MITA of any incidents that have an adverse impact on the security of the private runtime environment together with the actions that will be taken by the Contractor in order to rectify the incident. For the purpose of incident management procedure such incidents shall be classified as critical incidents.

3.2.4 Backups

With the sole exception of MITA’s responsibilities for Back-ups as detailed in Section 2.1.3 above, the Contractor shall be responsible for all aspects related to the back-ups. These responsibilities will include, but are not limited to;

(a) the provision of the back-up media;(b) the configuration of the backup process;(c) checking and ensuring the integrity of the data in accordance with the backup procedures (d) diagnosing any issues with such backups as they arise;(e) performing periodical test restores of the backup in order to ensure that written data can be

read back from tape and to verify the integrity of the data.

The Contractor shall maintain proper backup procedures which will be incorporated in the Operations Manual.

MITA will undertake periodic process reviews to ensure that the backup procedure is being adhered to.

3.2.5 Alert Management

The Contractor shall be responsible to monitor and manage all alerts generated by the Solution and take all the necessary remedial action.

Page 85

The Contractor may be requested to configure the Solution to ensure that all alerts are also copied to the MITA Network Management System (MNMS). The Contractor shall provide MITA with the monitoring scripts/ tools and the integration of the Solution with the MITA Network Management System based on the Simple Network Management Protocol.

The Contractor shall provide MITA with an alert reference guide which shall include an exhaustive list of events that may impact the Solution.

Page 86

Appendix B– Service Management

1. Principles

This appendix covers the provision of the management of the support services being provided by the Contractor. MITA follows the ITIL Service Management standard. MITA’s Service Call Centre is central to the provision of this service management.

2. Definitions

(a) ‘Incident’ means any event which is not part of the standard operation of the Licensed Software or Hardware which causes an interruption to the use of the Licensed Software or Hardware.

(b) ‘Hardware’ means the hardware provided by the supplier(c) ‘Licensed Software’ means the Software provided by the supplier.(d) ‘Problem’ means an unknown underlying cause of one or more Incidents. (e) ‘Solution’ shall comprise:

1. the application software and all its constituents, 2. the operating software and all its constituents, and 3. the necessary computing resources, if provided by the Contractor.

(f) ‘Resolution’ means an action that will resolve an Incident or Problem resulting in the Incident or Problem being closed.

(g) ‘Target Resolution time’ means the time that elapses between the initiations of a communication by the MITA Service Call Centre notifying an Incident to the Contractor’s Help Desk and a the notification of a proposed Resolution to Customer by the Contractor.


This Section sets out the roles and responsibilities in relation to the maintenance and support of the Solution (s) provided by the Contractor,

3.1 Responsibilities of MITA

3.1.1 Service Desk

o The provision of a Service Call centre (Service Desk) which provides operational Service Support to the Client / user base.

o The provision of a Service Management tool MSM for incident management as well as for the tracking of other service management disciplines such as Change Management.

o The availability of the MITA Service Call centre is 24x7x365.o MITA Service Call centre will receive calls from end users and will escalate such questions, requests or

incidents to the Contractor via the MITA Service Management System.o The MITA Service Management System shall be the basis for Service Level measurement and service

credit calculations.o The provision of reports from the MSM to the Contractor as required for the computation of the

adherence to Service Levels.

3.2 Contractor Responsibilities

o The Contractor shall use the MITA Service Management System as a means of notification of calls escalated to the Contractor,

o The Contractor shall update the MSM incident record with the appropriate feedback. In this way the MSM will contain a full and accurate record of all reported incidents.

Page 87

o The Contractor shall provide an English speaking Help Desk, (Call Centre)o The Contractor shall provide end of month reports which clearly indicate the number of incidents

logged, the response and resolution time, and any breaches which may have occurred for the respective month.

o In the event that solution monitoring is the responsibility of the Contractor as per PRE Appendix B, then the supplier shall log such incidents arising from these alerts in the MSM.

4. Incident Categorisation

o Incidents will be prioritised into Priority 1,2, or 3 depending on the criticality/impact of the incident. o In the first instance MITA will determine the prioritisation of reported incidents. If the user is not

satisfied with the assigned priority, the matter shall be escalated in the second instance to the Contractor’s operations Manager. Finally, the Customer shall act reasonably and in good faith, in the determination of the priority of each incident.

o The Service Levels (SLAs) for the respective incident categories is presented in table 1 below. This table shall only apply to the Licensed Software and Hardware provided by the Contractor.

Response Resolution FixHigh Priority Incident – all modules of system non functioning

1 hour 6 hours 1 week or as mutually agreed with the Client

Medium Priority Incident – a large number of users not working

2 hour Next Day 15 days or as mutually agreed with the Client

Low Priority Incident – a small number of users impacted

Next Business day

5 days 30 days or as mutually agreed with the client.

Service Credits will apply where the Restoration Time has not been achieved.

For Priority 1 and 2 Incidents the Contractor will assess the nature of the Incident and the degree of difficulty in providing a Resolution. On an issue-by-issue basis and no later than within the Target Resolution Time, the Contractor will notify GOM of the proposed Resolution of the Incident and will agree with the GOM the proposed Actual Resolution Time, such timeframe not to be unreasonably rejected by the GOM. Penalties will apply where the Actual Resolution Time has not been achieved.

No penalties will apply to the non-achievement of the Target Resolution Times.

Where Restoration or Resolution is delayed because of information or assistance requested from the GOM has been delayed, the Systems Integrator’s Restoration or Resolution time shall be suspended until GOM responds to the request.

5. Application Availability

The Licensed Software or Hardware is expected to achieve (i) an availability level of not less than 99.5% during the first 2 months following implementation and acceptance and, (ii) thereafter an availability level of not less than 99.9% over a 12-month period of the planned Service-Time in any Measurement Period, using the following formula:

Licensed Software or Hardware Availability = (1 – (Service Unscheduled Downtime / Service Time)) x 100

Page 88

Service-Time will be the time that the Licensed Software or Hardware should be available and excludes any scheduled downtime and any downtime due to unavailability of the system platform supported by MITTS. Service-Unscheduled-Downtime is the time the Licensed Software is not available as a result of a Priority 1 Incident due to application related problems.

6. Service Credits

o The Contractor will include all necessary detail in their monthly reports to enable GOM to determine the Service Levels achieved and calculate any Service Credits applicable

o Service Level measurements and calculations will be based on the information recorded in the Service Management Tool.

o Contractor shall not be responsible for any Service Credit, the cause of which is determined to be one or more of the following conditions:

i) any action taken by Contractor or one of the Contractor’s Subcontractors at the authorised request of GOM, provided that the shall advise GOM if it is aware of any possibility that compliance with that request would have adverse consequences;

ii) without prejudice to other conditions in this Agreement, actions or omissions on the part of GOM employees providing support to the System under the supervision of the Contractor during the fifth, sixth and last year of the Agreement, subject to the System Integrator providing sufficient evidence that such action or omission has resulted in a breach of the Service Level;

iii) In any particular Measurement Period where GOM’s volumes for a particular item exceed the Business Volume threshold specified in Annex 2.

iv) caused or exacerbated by an error originating from a component or service being supported directly by MITTS (i.e. network, backups, server hardware, Etc)

v) any event or cause in respect to which Systems Integrator’s performance under the Agreement is excused.

vi) The Contractor shall not owe any Service Credits for any Service Level default(s) that may occur during the first two months following the Go-Live Date. All other provisions of the Agreement (including, without limitation, all other provision of this Schedule 2) shall apply during such period of time.

vii) If the Contractor breaches both Service Levels GSL2 and GSL3 when providing support to an Incident under Priority 1, only the Service Credit applicable to GSL3 will apply to that specific Incident. If the breaches both Service Levels GSL6 and GSL7 when providing support to an Incident under Priority 2, only the Service Credit applicable to GSL6 will apply to that specific Incident. If the Contractor breaches both Service Levels GSL10 and GSL11 when providing support to an Incident under Priority 3, only the Service Credit applicable to GSL11 will apply to that specific Incident.

7. Application of Service Credits

a. A Service Credit will apply to each failure by the Contractor to meet a Service Level.

b. Service Credits will be split into three categories:

i. Failure to meet a Service Level

ii. Multiple failures of the same Service Level within the same measurement period

iii. Persistent failure to meet a Service Level.

c. For selected Service Levels, GOM has allocated a percentage which represents the percentage of the Service Credit for each failure of a Service Level occurring within any measurement period on that Service Level. The allocated percentages are indicated in Appendix 1 to this schedule.

d. In order to meet the changing business demands and seasonal requirements GOM may request a change in the allocation of the Service Credits within the Agreement between GOM and Contractor by submitting the request through the Change Control Procedure in Schedule 15. An approved change will take effect at the start of the next Measurement Period.

Page 89

e. The failure to meet the same Service Level for the number of occurrences as indicated in Appendix 1 to this Schedule shall constitute grounds for material breach

f. GOM and the Contractor shall calculate the total Service Credits due on a monthly basis (except for Application Availability which will be calculated on an annual basis) and shall accrue such an amount to be deducted from the Service Credit Payment applied annually in accordance with Schedule 4 (Invoicing).

g. Limitations

i. The maximum aggregate Service Credits which may accrue as a result of Systems Integrator’s failure to meet one or more Service Levels (excluding -to avoid doubt- for the purposes of this Section 7.7i, GSL13) during any given month shall be capped at 5% percent of the aggregate Charges for Maintenance Services payable in that month, not including Taxes.

ii. The maximum aggregate Service Credits which may accrue as a result of Systems Integrator’s failure to meet one or more Service Levels (including -to avoid doubt- for the purposes of this Section 7.7ii, GSL13) during any given year shall be capped at 5% percent of the aggregate Maintenance Charges payable in that year, not including Taxes.

8. Earn-back of Service Credits

a. Where Contractor fails to meet a Service Level in a month then in the following month the Contractor will have an opportunity to earn back 90% of the Service Credit applicable to that failure by over-achieving on that Service Level.

b. The amount which the Contractor earns back is calculated in the following way:

o Illustrative Example1

GSL 02 (as shown in Appendix 1) has a Service Level of 95%. The Contractor achieves the following performance:

Month Performance result Result

1 94.5% (under-performance of 0.5%)

Contractor incurs Service Credits according to Appendix 1

2 95.2% (over-performance of 0.2%)

Contractor receives the earn-back amount calculated against the Service Credits incurred in Month 1 for the same Service Level.

o Illustrative Example 2

GSL13 (as shown in Appendix 1) has a Service Level of 99.9%. The Contractor achieves the following performance:

Month Performance result Result





3 99.902% (over-performance of 0.002%)

An Earn-back is only given in relation to month two.

c. Over-performance is only counted in the case of underperformance in the preceding month. For the avoidance of doubt, over-performance cannot be carried forward.

9. Downtime

Page 90

Subject to the prior written agreement of GOM, which shall not be unreasonably withheld or unreasonably delayed, downtime will be scheduled based on planned implementation of releases, upgrades, emergency fixes and/or other interventions required to maintain the applications and corresponding infrastructure. Both parties will agree in advance on scheduled downtime through a change management process.

10. Table of Service Levels

Service Level Criteria per individual System Service Level Ref

Service Level

Description

Service Level Scope

Measurement Period Metric Service Level

Service Credit

AllocationGrounds for

Material Breach

GSL1 Average Response Time

All Priority 1 Incidents

Monthly Average time to respond (calculated as total time taken to respond to all priority 1 Incidents divided by the total number of priority 1Incidents)

<= Response Time specified in the Incident Categorisation Table

No Service Credit applicable

>=15 occurrences for the same module in the same quarter

GSL2 Percentage Restoration Time


Monthly Number of Priority 1 Incidents during the period restored within the Restoration Time specified in the Incident Categorisation Table during the period expressed as a percentage of the total number of Priority 1 Incidents during the period.

>=95% 1% of monthly support fees

Service Level not achieved for four consecutive months; or on six months over a twelve month period

GSL3 Tolerance Restoration Time


Monthly Number of Priority 1 incidents during the period that exceeded the Restoration Time specified in the Incident Categorisation Table plus an additional amount of time for ‘tolerance’.

Restoration time specified in the Incident Categorisation Table plus an additional 100% for tolerance

0.5 % of monthly support fees per Incident in breach


GSL4 Agreed Resolution Time


Monthly Number of Priority 1 incidents during the period not resolved within the agreed Resolution Time.

The Resolution time for the specific Incident to be agreed to by both Parties

2% of monthly support fees per Incident in breach

Service Level not achieved for three consecutive months; or on six months over a twelve month period



Monthly Average time to respond (calculated as total time taken to respond to all priority 2 Incidents divided by the total number of priority 2 Incidents)

<= Response Time specified in the Incident Categorisation Table





Monthly Number of Priority 2 incidents during the period restored within the Restoration Time specified in the Incident Categorisation Table during the period expressed as a percentage of the total number of priority 2 incidents during the period.

>= 90% 0.75% of monthly support fees



All Priority 2 incidents

Monthly Number of Priority 2 incidents during the period exceeded the Restoration Time specified in the Incident Categorisation Table and an additional amount of time for ‘tolerance’.


0.4% of monthly support fees per Incident in breach


Page 91

Service Level Criteria per individual System Service Level Ref

Service Level

Description

Service Level Scope

Measurement Period Metric Service Level

Service Credit

AllocationGrounds for

Material Breach





1% of monthly support fees per Incident in breach

Service Level not achieved for three consecutive months; or on six months over a twelve month period



Monthly Average time to respond (calculated as total time taken to respond to all priority 3 Incidents divided by the total number of priority 3Incidents)

<=Response Time specified in the Incident Categorisation Table





Monthly Number of Priority 3 Incidents during the period restored within the Restoration Time specified in the Incident Categorisation Table during the period expressed as a percentage of the total number of priority 3 incidents during the period

>=85% 0.5% of monthly support fees

Service Level not achieved for four consecutive months;



Monthly Number of Priority 3 Incidents during the period exceeded the Restoration Time specified in the Incident Categorisation Table and an additional amount of time for ‘tolerance’.


0.3% of monthly support fees

Service Level not achieved for four consecutive months;





0.5% of monthly support fees per Incident in breach

Service Level not achieved for three consecutive months;

GSL13 Individual System Availability

The uptime availability of each Individual System

Annually (see 4(ii)

100 * (Planned Availability period of measurement period in hours - Total Un Planned downtime in hours caused due to application related Incidents) / Planned Availability period of measurement period in hours.

99.9 % 2.5% of annual support fees

Service Level not achieved for two consecutive years

Page 92

VOLUME 3 SECTION 2 – TENDERER’S BUSINESS AND TECHNICAL OFFER

This offer must be submitted by completing the forms in this section.

Page 93

Tenderers MUST complete the forms in this section and the Tenderer MUST ensure that the information requested in this Section has been provided in the Tender. Maximum marks are provided.

When shaded leave blank

Comments should never exceed more than half a page of an A4.

Part 1 – Ability to Execute (100 marks) Provided/Not Provided

Comments

1.1 Goal ( 10) (a) The bidder is to state clearly his understanding of the required Solution.

(b) Provide a written statement that the bidder will provide the services required.

(c) Provide a written statement to demonstrate that the bidder understands how the Contract will work.

1.2 Vision (10) (a) The Bidder’s vision of how it will evolve its service during the next five (5) years.

(b) The Bidder’s vision in terms of continuous improvement of its support capabilities as well as in terms of its professional services.

(c) The Bidder’s strengths and weaknesses and anticipated changes.

(d) Written documentation regarding the qualities and qualifications of the following personnel (including CVs):- The Bidder’s Project Manager- The Bidder’s Service Manager.- The Bidder’s Training Personnel.

- The Bidder’s Implementation Team.

(e) The role(s) of each of the member(s) of the Bidder’s consortium, if any.

Page 94





Comments

1.3 Viability (20) (a) i. Provide a clear indication of the ability to secure the viability of the product in the event of acquisition by another company, transfer of the business concern, division of the company.

ii. Provide a statement to guarantee the minimum warranty period.

iii. Provide a statement regarding the licensing conditions.

(b) Provide information regarding the dependence on ‘alliances’ partners and or ‘independents’ and the ability to maintain and upgrade the Services in the event that such relationships are, during the course of the contract, terminated for whatever the reason.

1.4 Financial aspects (20)

(a) i. Submit the Bidder’s financial position for the past two years, including a copy of the latest audited financial statements.

ii. Submit the Bidder’s long-term strength and financial stability represented through revenue, cash position and net income for the past five years.

iii. Describe how the bidder’s research and development ability meets schedules including the investment allocated to research and development.

Market (b) i. Provide evidence of the bidder’s ability to penetrate and dominate the technology

Page 95





Comments

space of the solution provided for business areas related to the National Blood Transfusion Services.

ii. Provide a description of the bidder’s market strategy.

iii. Provide documentation regarding the market share evolution over the past ten years and as anticipated between 2009 and 2014.

References (c) i. Provide written documentation regarding the bidder’s experience and track record in the provision of similar systems and solution within the set timeframes for similar business areas provided by the National Blood Transfusion Service.

ii. Indicate reference sites and case studies where similar solutions have been implemented, together with contact persons at these sites. Bidders are to indicate which reference sites provide similar services to the National Blood Transfusion Service.

Project plan (d) Demonstrate the Bidder’s ability to achieve the targeted project dates and a commitment to a detailed Project Plan.

Demo (e) Confirm bidder’s acceptance to provide a demonstration of the system being proposed at the Contracting Authority’s premises at the bidders expense.

Page 96





Comments

1.5 Legislative (a) Confirm that the Bidder is willing to abide by the General Contractual Conditions Volume 2 Section 2 and the Special Conditions Volume 2 Section 3

(b) Confirm the bidders willingness to abide by the Sample Contract Volume 2 Section 1

(c) Confirm your willingness to provide perpetual

licences; how software licences are bundled,

distributed and controlled, any limitation for software licences any Third Party software, OS or database licences required

Page 97

Tenderers MUST use the following Response Format and the Tenderer MUST ensure that the information requested in this Section has been provided in the Tender. Maximum



Part 2 – General Requirements Applicable to all Modules - Maximum Marks 100

Met/Not Met

Comments

2.1 General (a) (i) Delivery of a highly available and scalable architecture located at the Government Data Centres and governed by the Private Runtime Environment principles as defined in Volume 3 Section 1 Appendix A. Preference would be given to solutions that have the least footprint and consumptions of power and cooling.(ii) The availability must be as defined in Volume 3 Section 1 Appendix B Service Management

(b) Explain how the solutions are achieving Government’s high level technology principles as defined in Volume 3 Section 1 (1.2 ICT Environment). Such an explanation should also include:i) how interoperability is being achieved for data exchange, interconnection (how systems are connected), security and data persistency apart from others (Volume 3 Section 4) below provides a non exhaustive list of interoperable standards.)ii) how application decoupling from the desktop is being achieved and any limitations in this regardiii) an explanation of how application virtualisation, webification and/or remote desktop

Page 98



are being used and implemented so as to minimize application dependencies on the client devices

(c) Confirm and explain the delivery of hardware, configured to the Solution requirements and meeting the agreed architecture.

(d) Confirm the willingness to integrate with current and future Government’s Shared Services such as the eID, mGov, myAlerts, myBills, eForms, etc where appropriate.

(e) Confirm the delivery of best of breed and proven off the shelf applications which through configuration and parameterisation will satisfy the requirements of this ITT.

(f) Confirm and explain how the Solution will be scalable in a way that can accommodate usage growth and hence utilize the proposed infrastructure as a core building block which can be extended horizontally.

(g) Confirm that the tenderer will abide by all relevant Government ICT Policies and Standards as published at http://ictpolicies.gov.mt. The Tenderer must undertake to check and abide by the latest updates found on this URL.

(h) Confirm that maintenance of back end systems provided through this

Page 99


When shaded leave blankITT are to be maintained and supported remotely; and also confirm that. the tenderer shall connect through VPN whereby authentication shall be achieved through two-factor authentication. Confirm that all other devices connected to the Solution will have on site maintenance and support and not via remote administration.

(i) The Solutions must target a service uptime as per Volume 3 Section 1 Appendix B

(j) Were appropriate, explain how integration with Government’s Corporate Active Directory will be achieved for purposes of identity exchange and/or sharing.

(k) Provide the approach how User Authentication and Authorisation will be controlled and managed. This should include information such as: i) how will access rights – view, modify, create and delete be controlled, ii) how is password lifetimes handled, iii) what audit trails are supported, iv) how are concurrent sessions of a same user ID controlled, v) what industry standard authentication mechanisms are supported, vi) how and what password policies are supported, vii) explain the accounts management, viii) what other authentication factors are supported – such as two factor authentication using tokens, etc.

(l) Security - Apart from the security requirements identified in the Private

Page 100


When shaded leave blankRuntime Environment in Volume 3 Section 1 Appendix A, provide any other security related information that is relevant to this ITT. Such information should include:

a) confirmation if the solutions procured under this ITT are HIPAA compliant and an explanation of how such compliancy is being achieved.

b) an explanation of how information security is assured. This should include how information integrity, confidentiality and availability are implemented.

c) what and how are transactional audit trails achieved and how can they be effectively used to trace any security breaches. d)) an explanation of the security measures implemented depending on the data classification as designated by MHEC – this should include backup media disposal procedures.

(m) Provide detailed information of the solutions backend databases. Such information should include i) database technical specifications, ii) how high availability is achieved, iii) what open interfaces are supported, iv) what tools are included for management of the databases including backup and recovery, etc.

(n) Confirm that the solutions procured under this ITT are not tightly bound to the CORP AD for identification and authentication purposes.

Page 101



(o) Confirm that servers procured under this ITT are not being directly serviced through the CORP AD services i.e. the servers should not be a domain member of the CORP AD. This is in line with the PRE principles and avoids issues of shared liability between contractor and MITA

(p) Confirm and explain how user identification and authentication of the solutions procured under this ITT will be implemented and based on an industry standard claims based framework such as SAML. Such an explanation should also include how authentication exchange and/or sharing within and across domains are being handled and also were appropriate, explain how integration with Government’s Corporate Active Directory will be achieved for purposes of identity exchange and/or sharing.

(q) Confirm that authorization and role management are localised and managed within the solutions themselves

(r) Confirm that the Solutions should provide a comprehensive on-line help function in English

(s) Explain what measures the Tenderer will take during the term of the contract in terms of the continuous improvement in the provision of the service.

Page 102



Explain how it is proposed to carry out solution maintenance and support throughout the contract period.

(t) Confirm and explain the delivery of Business continuity strategy and the provision of an implementable Exit and Disaster Recovery Plans. Such information should apart from others include information related to:i) Backup procedures – including retention period and Recovery point objectives (RPO)

(u) Confirm that the Solution can work on both a physical and a virtual environment without negatively impacting its performance.

(v) Confirm that the Bidder is compliant with the GMICT policies that are relevant to the delivery of the service being requested in the ITT.

(w) The system should be a real-time system.

(x) The system should have an established user base.

(y) The system should provide a full-function, task-oriented, graphical user interface for its users, administration and configuration.

(z) The system should be capable of accepting input through the following devices including but not limited to: Keyboard Mouse

Page 103



Barcode Scanner

(aa) System should have the ability to handle an unlimited number of concurrent users.

(ab) Provide information regarding the Bidder’s ability to provide knowledge transfer to the NBTS.

2.2 Private Runtime Environment (PRE) Requirements

(a) Provide the back-up procedure and the time-table to be followed by MITA for back-up purposes.

(b) End point security software:

i) Provide the name of the software being proposed; ii) Provide the features of the software;iii) Provide the procedure for handling zero-day attacks;iv) Provide the frequency of the updates for the software and the procedure for installing such updates;v) Provide the configuration of the software.

(c) Provide the change management process to be adopted.

(d) Provide the patch management process to be adopted.

(e) Application Maintenance:

State the application release

Page 104


When shaded leave blankfrequency and what maintenance is required on the application.

(f) Application Logging/Monitoring:

Provide the following information: a) Which actions / exceptions will be logged?b) What logging data will be stored?c) Where will the logging data be stored?

(g) Application Security:

Provide in depth information on how the application will be secured against cross site scripting, sql injection and others.

(h) Data Security:

State how secure/sensitive data is being protected. In the case of Symmetric-key and Asymmetric-key algorithm please state how the key will be securely stored on the hosting infrastructure.

(i) Data model availability:

Will the Solution’s data model be made available so that other (then those provided within the Solution) applications can programmatically connect and access the underlying data and perform adhoc querying? If not, what other methods are available to maximise re-use of the underlying data?

(j) Data/Object caching strategy:

Page 105


When shaded leave blankProvide technical details of any other data/object caching to be implemented by the system.

(k) Application Integration

Confirm that the solution will provide the interface documentation and/or API Documentation during implementation.

(l) List of methods/web methods:

a) Give a high level description of each web method.b) Give detailed information about the new business process (or link to the existing business process) being exposed by each web method.c) List the input and output parameters together with a description of each parameter.d) Give details of the expected output and error messages Authentication and Authorization.e) Give a detailed description of application-to-application authentication mechanism to be used.f) Give a detailed description of citizen-to-application or business-to-application authentication mechanism to be used (if required).g) Give a detailed description of authorization mechanism to be used.h) State how the authentication and authorization will be managed (security administration).

(m) Session management vs. Stateless

Page 106



services:

a) State whether the authentication and authorization information will be persisted using some type of session management.b) State whether the web methods/methods are provided as stateless services or otherwise.

Page 107



2.3 End User Interface

(a) The system should use a graphical user interface with the following attributes:

A pointer (symbol) that appears on the display screen and that enables the user to move or to select objects and commands.

Should allow the use of a pointing device, such as a mouse or trackball that shall be used to control the pointer.

Should make use of icons to represent commands, applications, files, or minimised windows.

Should make use of windows. In each window, the system shall be capable of executing different applications. The system should allow the resizing and independent movement of windows around the screen.

Should employ the use of dialog and message boxes to alert the user of any warning or error message, and to request specific input.

Should utilise the concept of menus to select functions and commands.

Should allow the use of keyboard shortcuts for accessing the functionality of the system.

Page 108



(b) The visual interface shall be capable of different resolutions and different number of colours.

(c) The visual interface should fit in a minimum 800x600 resolution without the need of scrolling or panning.

(d) The system should allow the customisation of the layout of the interface.

(e) The system should allow the administrator to change buttons, icons and menus, in order to create the best possible interface for specific users.

(f) The system should highlight any critical information displayed as part of a screen.

(g) The system should allow the switching from one application to another without the need to close the previous window.

2.4 Usability (a) Display a user’s personal “things to do” list upon login.

(b) Provide a “dashboard” view of the system to quickly access critical metrics and pending tasks.

(c) The system should provide a comprehensive on-line help function in English.

(d) The system should enable simple and straightforward navigation

Page 109


When shaded leave blankmethods (within the authorised levels of access) across the functionalities of the system; (i.e. should not force the user to quit completely from a particular application to access another).

(e) Where it is necessary to use more than one view/screen for adding, viewing or amending transaction details it is essential that the core identifying information is displayed on each view/screen.

(f) The types of search and enquiry facilities provided will be tailored to individual user privileges. As far as possible flexible search and enquiry facilities should not be detrimental to the system performance.

(g) The system should guide users through the logical flow of the process being followed through prompts and drop-down menus.

(h) The system should warn and guide the user whenever incorrect data entry is made.

2.5 Querying and Search Facilities

(a) The system shall provide a search and enquiry facilities that is flexible and includes various searching methods. These must include searching by:

Single field.

Multiple field.

Field ranges.

Multiple field ranges.

Page 110



Partial field.

Partial field ranges.

Wildcards.

Confirm and explain how querying and searching is achieved.

(b) Solution should allow for searches of all available data bases on user-defined search parameters.

2.6 Documentation (a) Bidders are to provide a list of all the documents, manuals and handbooks that will be supplied as part of the solution. The documentation provided should include, and should not be limited to:

i) The System Administration Guide covering system administrator functions, file backups and recovery procedures, and management of security access.

ii) Application Software documentation, including screen designs, report formats,

iii) User manuals including a comprehensive list of all error messages.

iv) Trouble Shooting guides.

Page 111



(b) All systems need to be thoroughly documented, and written in English.

(c) All supplied documentation should be made available in electronic format.

(d) Confirm the Tenderer’s acceptance of the responsibility for the provision and the accuracy of all relevant solution documentation for the lifetime of the service.

2.7 Ad-hoc reporting tool

(a) The system should provide a reporting and statistical tool that gives end users the facility to create ad-hoc reports using user defined criteria. Bidders are requested to provide information regarding:i. The reporting tool being

supplied as part of the solution.ii. How ad-hoc reporting is

achieved.iii. Are report templates

supported.iv. Report provisioning such as

displayed to screen, emailed, exported, etc.

v. Support for re-printing.vi. What filtering, sorting, and

formatting are supported;vii. Printing preferences, etc.

(b) The system requires a flexible and sophisticated report writer / generator that:

i. Can create ad-hoc reports using user-definable criteria, for

Page 112



example, using an individual data item or a combination of data items.

ii. Can access all files / tables and all aspects and combinations of elements of the data.

iii. Can format reports from more than one file/table simultaneously.

iv. Can access and format data from other integrated or interfaced systems.

v. Has comprehensive selection, sorting and formatting facilities.

vi. Can be used in batch and on-line mode.

vii. Can have the output retained, directed to any output device or transmitted.

viii. Is fully compatible with any hardware or software proposed.

ix. Can process both database information and statistical information.

x. Can search for free text words xi. Has full Boolean options where a

combination of codes and free text exists it should be possible to enquire or report on either.

xii. Can perform linked searches.xiii. Can search on a daily basis.xiv. Will generate reports without

adversely affecting the

Page 113


When shaded leave blankperformance of the system.

(c) The report generator should be capable of producing output files and of accepting data in formats, which can be accepted by third party software applications such as spreadsheet, graphics and word processing packages.

(d) Training to end users in the use of the reporting tool is required. As part of their response, bidders should indicate the type of training that will be delivered as part of the implementation process.

(e) System should allow querying of all transactions records and fields.

(f) A comprehensive data dictionary defining all tables, data entities, data attributes, relationships, and explanations of each data item needs to be supplied as part of the solution.

(g) The reporting tool should have the facility to save queries as “templates” or other similar forms, for future use. It should also be possible to attach saved queries to end users menus so that the saved queries can be called up easily by the end users.

2.8 Pre-set reports (a) Reporting templates should be made available of the pre-set reports supplied as part of the system. The pre-set reports should be modifiable to meet the blood bank’s specific requirements. As part of their

Page 114



response, bidders should provide information how pre-set reports can be modified by end users.

(b) Solution should be capable of displaying site specific reports or roll up metrics from all the sites to display in an enterprise wide report.

2.9 Office Automation Integration

(a) As part of their response, bidders should provide information of system integration capabilities with desktop products and office automation tools.

As a minimum, the systems should offer out-of-the-box integration with MS Office and Adobe Acrobat.

(b) The system should allow and facilitate exportation and importation of data to and from more commonly used applications, such as Microsoft Office applications.

2.10 Email Facilities (a) The systems should provide standard email notifications and reminders as part of the proposed solution. Bidders are to confirm and explain how alerting, notifications, and reminders work.

(b) System must identify and send out e-mail notifications of processes (e.g. document approval) which require attention or are overdue.

(c) Send out e-mail notifications at

Page 115



defined intervals before a process or task is overdue.

(d) Email notifications should contain a mechanism to guide users to the right record.

2.11 Data Import and Data Export

(a) The system should have import facilities to allow for the import of data from other systems.

(b) The system should have export facilities to allow for the export of all data stored within the system.

2.12 Data Reliability (a) The system should ensure adherence to the rules governing the normalisation of data.

(b) The system should guarantee data uniformity and integrity across all its components, including instances when uniformity is lost due to technical interventions such as power failures. In such cases, uniformity should be re-established in an automatic manner.

2.13 Electronic Signatures

(a) The system should utilise electronic signatures at user determined stages for all modules.As part of their response, bidders should provide detailed information as to how electronic signatures can be applied for all the modules being

Page 116



procured as part of this tender.

(b) The solution must be capable of signing documents using digital certificates.

(c) The bidder must confirm that the electronic signature practices implemented in the solution comply with the EU signatures Directive 1999/93/EC.

(d) The bidder must confirm that signature verification processes are implemented. The bidder must also provide an explanation of such verification processes.

2.14 Form Configuration

(a) Allow the system administrator to configure forms by adding, amending, deleting, and moving fields.

(b) Allow the system administrator to enforce specific fields as mandatory or optional.

(c) Be capable of presenting forms with different configurations for different department set up.

(d) There should be no limit to the number of fields that a given data entry form can handle.

(e) There should be no limit to the number of characters in each field.

(f) Provide document changes which have the following options:

i) Immediately available AND

Page 117



ii) Schedulable for future dates and times.

2.15 Collaboration (a) The system should provide the facility for users to create and participate in on-line discussions so as to collaborate on compliance-related topics. They should be notified of opened and updated discussions. This facility should be available for system end users only.

Bidders are to confirm that the solution procured under this ITT provides a mechanism to allow collaboration and on-line discussions related to compliancy related topics. An explanation of how this is achieved should be included.

2.16 Upgrades (a) In the case of a system upgrade, the system should preserve document and configuration changes, thus eliminating the need to revisit customised items.

Bidders are to confirm how upgrades are implemented to achieve this.

2.17 Printing (a) System should be capable to generate legible copies of all online documents and signatures in paper form. All paper copies should be

Page 118



printed with an expiration date/time noted on each page (i.e. the paper copy is not to be considered accurate 24 hours after printing).

2.18 Character Sets (a) As part of the implementation, the successful bidder will need to ensure that the proposed system is configured to work with both the Maltese and English Languages for documents.

(b) As part of their response, bidders are to state what other languages does the system support for documents.

Page 119

Tenderers MUST use the following Response Format and the Tenderer MUST ensure that the information requested in this Section has been provided in the Tender.



Part 3 – Regulatory Maximum Marks 150 Met/Not Met Comments

3.1 Quality Assurance (a) Bidder is to confirm and provide documentation that an independent department or company conducts quality assurance of the development and internal validation of the proposed system.

As part of their response, bidders are to provide information regarding their QA testing process and procedures.

3.2 Validation (a) End-user required changes that are configured using the application after the implementation, should not require IQ, OQ, PQ validation to ensure there is no negative impact to the application.

3.3 Audit Trails (a) The system should keep a full audit trail of all the transactions made by the systems.

Bidders should confirm that all transactions made on the system are fully audited.

(b) Audit data that should be maintained (but not limited to) by the system should include: Audit Trail ID. Date. Time. Action. Application User ID.

Page 120



Station Name. Network Address (IP number and MAC

address). Document Created, Amended, or

Viewed. Access Type:

Viewed Created Modified Deleted

Item Changed (if any). Item Before Change (if any).

(c) The audit trail should keep track of:i) All successful user logins and

logouts.ii) Any unsuccessful login attempts by

users.iii) Any unauthorised login attempts to

the system by the users. An unauthorised login attempt is when an invalid login name is used to access the system.

(d) System should maintain approval / rejection history for each build of a document revision. This should include all decisions, comments, attachments and signatures related to the document build.

(e) System should provide audit trails to track all changes, including deletions to any attachments against electronic records.

(f) Audit trail records should not be overwritten/modified or deleted.

Page 121



(g) Controls should be applied to limit access to audit trails.

(h) Recorded date and time stamps on all database transactions should be stored using the server date and time. When users view records, dates and times should be displayed in local format.

Page 122




Part 4 – Document and Process Management 150 Marks Met/Not Met Comments

4.1 Document Management

(a) Provide a unique alphanumeric identifier for each document which is definable by the ’document control officer’.

(b) Documents and procedures should be accessible from all locations within the system.

(c) Each document should be classified by document type.

(d) The document management system should allow for documents to be inserted and managed by the system through a “check-in” process. Such documents must be stored as PDF files.

(e) System should manage both the editable copies and the PDF copies of the document.

(f) The system should support any type of document formats. These should include, but not limited to, Microsoft Word, Microsoft Excel, Powerpoint, Visio, Smartdraw, etc.As part of their response, bidders are to provide details of any limitations.

(g) Provide the ability for documents to be made available to users as read-only.

(h) Provide a document record which contains –i) Document history, ii) references and comments, for each

Page 123



document revision.

4.2 Document approval workflow

(a) Provide the facility for the document control administrator to create document approval workflows

(b) Provide document approval workflow which supports serial, parallel, and conditional routing.

(c) Document Approval Workflows should provide escalation capabilities.

(d) Provide document approval workflow which supports review rules such as ‘all reviewers have to unanimously approved’, ‘3 out of 5 reviewers to approve’ etc’.

(e) The system should have the ability to:i) allow the predefined workflows

to be changed at any time in the process.

ii) allow the addition or deletion of review groups / members at any time.

(f) System should provide the ability to define review schedules for a document. System should track the scheduled dates and notify appropriate personnel.

(g) System should force an annual review of documents, i.e. documents checked out, reviewed, and checked back in under the same edition date without revision.

Page 124



(h) System should provide for the electronic approval and rejection of documents. The system should record the approver’s response, comments, attachments and electronic signature.

(i) A date and time stamp should be captured for each approval signature. This information should also be captured in the system’s audit trail.

(j) The document control administrator should define the date of publication of Documents.

(k) The system should send email notifications when a document is:i) reviewed, ii) approved, iii) rejected or iv) released.

(l) Document-based training should be available through integration with a training management system. This should include the ability to assess users on their knowledge of the document’s content.

(m) Document training history should be maintained through integration with a training management system.

(n) The document control process should support changes to multiple documents from a single workflow. This includes the creation of new documents, document revision, temporary document changes, and document

Page 125



expiration.

(o) Documents / SOPs should be referenced to audit records, CAPA records, equipment and calibration records, inspection records, training records.

(p) The CAPA process should be integrated with the rest of the quality system. For example, the resolution of a corrective action should be capable of triggering other changes such as SOP changes.

(q) The system should be capable of linking approved planned deviations to a particular document.

(r) The system should provide users with the ability to request changes on a document.

(s) The system should provide Document authors / administrators with the ability to view multiple change requests, combine them together and address them through one single change workflow.

(t) The system should provide the ability to review the changed documents individually or as a package.

(u) The system should provide the ability to release changed documents together as a package or individually.

(v) The system should include steps to verify understanding of documents after review/reading, prior to sign-off.

Page 126



(w) The system should provide a “pack & go” feature so that a group of documents can be written to a disc for use at remote locations without access to the network.

4.3 Process Management

(a) The system should provide the facility for the creation and deletion of process models.

(b) The solution should provide pre-defined process models, together with relative documentation for validation purposes. As part of their response, bidders should list the process models that will be made available as part of the solution.

The pre-defined models should include but not be limited to the following:

Change control CAPA Complaint management Audits Equipment monitoring Incident reporting Non conformance management Deviations Management

Processes should be able to connect to related processes allowing easy navigation between the processes.

(c) The solution should provide the facility for the document administrator to customise and configure pre-defined process models.

Page 127



4.4 Workflows and Review Models

(a) Provide workflows which may be defined centrally by the document control administrator, and applied across multiple departments.

(b) Provide department-specific workflows.

(c) Provide the ability to create review models containing the schedules of when to perform reviews during a system workflow.

(d) Provide the facility to create an unlimited number of review models.

(e) Provide the ability to define escalation policies in the event that a user does not perform his/her task assignment or provide an approval response in a designated time period.

(f) The system should include a function that advises the user of any pending tasks, through various mediums including email.

(g) The system should provide the tools that allow the administrator to monitor workflow processes at each stage.

(h) The system should provide different methods of routing:

Sequential routing.

Parallel routing.

Conditional routing.

Pending routing.

Page 128



4.5 Pre-set Reports (a) Solution should provide “out of the box / pre-set” reports. As part of their response, bidders are to provide a list of pre-set reports that will be provided with the “Document and Process Management” module.

(b) Solution should provide a standard report to track documents created and released in a month.

(c) Solution should provide a standard report of all review groups for each and every document type.

(d) Solution should provide a standard report with a list of documents, with the ability to launch the actual selected document in a new window.

(e) Solution should provide a standard report to view all changes requested against a specific document.

(f) Solution should provide a standard Document Training / Competence report including:i. All Employees required to be

trained and certified competent.ii. Employees who have been

trained and certified competent already.

iii. Employees who are pending to be trained and certified competent.

4.6 Search Facilities (a) Solution should provide full text search

Page 129



capabilities on all controlled documents, records and attachments. As part of their response, bidders are to provide details of search features available.




Part 5 – Training Management Maximum 100 Marks Met/Not Met Comments

5.1 Employee training (a) Providing a training system which tracks employee skills versus required training.

(b) Provide notification to managers of gaps in their employee’s training. This includes:

i) missing.ii) expired.iii)near-expired training.

(c) Provide a Training history record for each employee, including current and past certifications.

(d) The system should provide access for all employees to their training requirements and gap analysis, so users can understand their training path.

Page 130



(e) The system should track: i) on-the-job training.ii) classroom (scheduled)

training.iii) self-training.iv) document based training. v) web-based training.vi) computer based training.vii) competency assessment.

(f) The system should provide managers with the facility to identify which employees are qualified and competent for a particular job through Employee resource enquiries.

(g) The system should provide the facility for a training attendance sign-off by each individual upon attendance of each training session. As part of their response, bidders should provide information of how training attendance signoff is recorded in the system.

(h) Employees should be able to monitor and sign-off on training completion through a user-friendly interface.

(i) Training assessments must ensure that employees understand the training’s content.

(j) Training assessments may be linked to any type of training in the system (document based, web-based, self-training, etc.)

(k) The system should provide the facility to define the period intervals for refresher training. The system should notify managers and employees when

Page 131



refresher training is due.

(l) The system should integrate with the document management system to track document based training history.

(m) The system should provide the flexibility to skip some versions of the documents for training.

(n) The system should track an employee changing positions within the organization.

(o) The system should provide the ability for the manager to approve an employee’s training completion.

(p) The system shall randomly pull from a bank of questions on a particular topic to ensure staff performing the assessment at the same time does not have the same list of questions.

(q) The system must ensure that a staff member does not receive the same set of questions as the previous assessments in cases when the assessment is repeated.

(r) The system should log and verify prerequisites for courses.

(s) The courses should be able to be designed so that designated questions will fail a staff member if answered incorrectly.

5.2 Pre-set Reports (a) Solution should provide “out of the box / pre-set” reports. As part of their

Page 132



response, bidders are to provide a list of pre-set reports that will be provided with the “Training Management” module.

(b) Solution should provide a standard gap analysis report for employees.

(c) Solution should contain a standard catalog report of all the courses offered.

(d) Solution should provide a standard report of all users waiting to complete a specific training requirement.

(e) Solution should provide a standard report of all users waiting to be trained on a document.

(f) Solution should provide a standard report for every manager indicating documents that their employees need to read and sign off.

(g) Solution should provide a standard report of all training sessions scheduled, and all employees scheduled to attend the training.

(h) Solution should provide a standard summary report for every manager containing details of training sessions attended by every employee.

(i) Solution should provide a standard report of requirements that an employee needs to complete based on their position and/or job functions.

(j) Solution should provide a standard report of training history by department,

Page 133



role or employee.

Page 134




Part 6 – Supplier Management & Bill of Material - Maximum 100 Marks

Met/Not Met Comments

6.1 Supplier Management

(a) Provide the facility to maintain a list of suppliers. As a minimum, the following information needs to be maintained for each supplier: Company Name. Company Address. Contact Information, including

name, fixed line telephone number, mobile telephone number, fax number, email address.

Company Vat registration number.

(b) Maintain a list of parts, materials, and services supplied by each supplier.

(c) Allow approval of vendor list within the system based on:i) individual part.ii) service.iii) material level.

(d) Have the facility to change the status of suppliers from approved to unapproved for a particular part, material, or service.

(e) Have the facility to change the status of suppliers from unapproved to approved for a particular part, material, or service through a

Page 135



formalised process set up in the document management system.

(f) Allow for the linking of other documents (e.g. specification sheets, supplier appraisal questionnaires, etc.) to be linked to the supplier data stored in the system.

(g) Provide for collaboration on documents, Bill of Materials (BOM), processes in a secure environment.

6.2 Bill of Materials (a) The system should support Bills of Material (BOM).

(b) The BOM should be integrated to the supplier management module to provide an Approved Vendor List (AVL) for a specific BOM.

(c) The BOM should allow for the materials list update.

(d) The solution should allow for collaboration on Bills of Materials.

(e) The solution should allow for version control for all BOM changes.

(f) The solution should allow BOMs to be routed and approved on an electronic workflow defined in the Document Management System.

(g) Changes in BOMs should go through a Change Management Process.

Page 136



6.3 Pre-set Reports (a) Solution should provide “out of the box / pre-set” reports. As part of their response, bidders are to provide a list of pre-set reports that will be provided with the “Supplier Management and Bill of Materials” Module.

(b) The solution should provide a standard report outputting a complete list of suppliers.

(c) The solution should provide a standard report outputting a complete list of materials.

(d) The solution should provide a standard report outputting materials and their respective approved supplier.

(e) The system should provide a standard report of approved vendors (approved vendor list).

(f) The system should provide a standard report of unapproved vendors.

(g) The system should provide a standard report of bill of materials.

Page 137




Part 7 – Security Maximum 100 Marks Met/Not Met Comments

7.1 Password Management

(a) The system should allow the creation of a unique username and password for each authorised user of the system.

(b) The system should keep track of a pre-defined number of passwords for each user – password history.

(c) The system should not allow user access to password history.

(d) The system should use the password history in order to forbid the user from reusing any previously used password.

(e) The system should allow the administrator to select a subset of characters, of which passwords shall be composed.

(f) The system should allow the administrator to select a subset of characters, of which the passwords shall have at least one of these characters.

(g) The system shall automatically verify that only passwords having a length within the acceptable length range set by the administrator shall be generated or selected.

Page 138



(h) The system shall allow the administrator to enable a password lifetime; once a password has expired the system shall request the user to change his password at his next sign-on.

(i) The system should allow the administrator to delete or replace a user’s password (subsequent to authenticating the identity of the administrator).

(j) The system shall have the capability of maintaining a record of when a password was created and changed.

(k) The system should automatically check passwords selected or created by users or the administrator, to assure that they meet the specifications of composition and length, before they are accepted as valid passwords.

(l) The system should store the passwords in such a way that only the password system itself can access it.

(m) The system shall authenticate personal passwords each time a claim of identity is made.

(n) System should require password to be reset upon initial use.

(o) System should lock out users

Page 139



after a certain number of successive unsuccessful logon attempts. The number of successive unsuccessful logon attempts should be configurable by the systems administrator.

(p) System should log users out after a pre-defined period of inactivity. This period of inactivity should be configurable by the systems administrator.

(q) The system should automatically disable user IDs that have been idle for a predefined period of time. This pre-defined period of time should be configurable by the systems administrator.

(r) Locked accounts shall only be unlocked by a system administrator.

(s) The system should keep an audit trail of all logon or sign-on attempts – both successful and unsuccessful

7.2 Access Control (a) System must support role-based access for administrators (e.g. local administrator controls user access to local data only; central administrator controls user access to all data).

(b) The system should organise the individual usernames in groups, to reduce the administrative task

Page 140


When shaded leave blankof maintaining the access rights given to users.

(c) The system should allow the creation of groups / organisational units that shall be used to group together users and resources for better manageability.

(d) The system should allow the administrator to define access rights in varying granularity (i.e. systems, functions, forms, fields).

(e) The system should allow the creation of rules that specify the necessary roles and rights required to perform an action and a particular target and under specific conditions.

(f) The system should be capable of controlling access rights. These should be categorised as follows:

Read

Modify

Create

Delete.

(g) The system should allow varying access level granularity within the same view/screen (i.e. a user can have the right to access a view/screen, but only the right to modify a single field within the view/screen).

Page 141



(h) The system should allow the use of user/group profiles:i. These should define the

screen layout and available systems.

ii. These should be roaming profiles, that are attached to the user and not the workstation (i.e. a user. will always be presented with the same system layout regardless of which workstation he is currently using).

iii. The system should allow the creation of a default profile.

iv. The system should allow the administrator to copy a profile in order to create a new one.

v. The system should allow profiles to be linked to individual users or group of users. This group of users can be from a single department or else from a single job type within multiple departments.

vi. The system should organise the individual usernames in groups, to reduce the administrative task of

Page 142



maintaining the access rights given to users.

(i) The system should include a super user with the rights to override security and access settings.

(j) The system should allow the delegation of specific administrative roles.

(k) System should allow system administrator to immediately disallow system access for a particular user account.

(l) Data security measures are required to ensure data consistency, integrity and confidentiality. The system should provide data security by means of user accessibility rights.

(m) The system should allow the configuration of the number of concurrent sessions to be allowed with the same user id or group.

(n) The system should ensure that necessary rights are available for every transaction requested.

(o) The system should support the addition, amendment and deletion of data, according to the user’s rights.

(p) The system should check the necessary user rights for each

Page 143



and every user’s action.

7.3 Data Security (a) The safekeeping of data and information are restricted to individuals who have need, reason, and permission for access to such data and information.

(b) Electronic data is protected throughout its life cycle from unauthorised access, modification, destruction or disclosure.

7.4 Security (a) Describe the underlying security model of the product. Identify where features of the security model are a function of the product or the underlying operating system.

(b) Provide a description of compliance to security requirements as per EU regulations.

(c) Describe the security implications surrounding the implementation of the system on the internet.

Page 144

Volume 3 SECTION 3 TENDERER’S ARCHITECTURE RESPONSE

Maximum Marks 50

1. Server Environment

Provide the following information in relation to the server requirements (attach detailed specifications with your submission.)

ResponseServer System

Virtual QuantityMemoryProcessing Power

Physical QuantityMemoryProcessing Power

Storage Requirements

CapacityIOPSCan the storage requirements be resourced from a separate storage environment?

Rack Space required No of Rack Height UnitsPower Supply required

single/three phaseload in KW;single/dual feed

Operating Environment

Temperature (degrees Celsius)

Humidity

Page 145

Total Heat Dissipation BTU / HrTotal weight of equipment

Kgs

Air Flow Direction (eg Front-back)

2. Operating Software Technologies including 3rd Party Components

Operating Software Details 3rd Party Information(*)

Proposed Others Supported

Server/s Operating System:DBMS Engine:Application Servers:Specific System Software:Security Related Software: (Anti-Virus, etc)(*) Include details of 3rd Party, if applicable, (such as company, information website url, whether source code is available)

3. Operations Manual

Provide an operations manual which should include amongst others:

3.1 Back-up Procedure

Page 146

System Name

1Year Specify Backup tool used

BackupsTimetableTo Disk To Tape

Type

[F, I, D]

Capacity

<GB>

Type

[F, I, D]

Capacity

<GB>

Frequency Time

F = Full, I = Incremental, D = Differential1 Provide data for Year 1 up to Year 2

3.2 Downtime

System Name1Scheduled Downtime

Downtime Reason Monthly Average <HRS> Yearly Total <HRS>

1 Scheduled downtime - support, maintenance, updates and upgrades.

Page 147

4. Database Details

Database Name

Application Name

Database size on deployment

Y/N Estimated database 3-year growth

triggers, DBMS audit etc.

Percentage queries vs data entry

e.g. 70:30

Transaction Logging(If No Logging, recovery must be

made from previous days’ backup)

Y/N

Database auditing implemented

Y/N Method triggers, DBMS audit etc.

Envisaged frequency of database enhancements

daily / weekly / monthly / other Method

restore, upload etc.

Connection type shared memory / tcp/ip

Total no of users

No of concurrent users

Est. Annual increase in Userbase

Development environment required

Y/N

5. Network Connectivity

Bandwidth Specifications:High

(Transfer of GIS / images)

Medium(Client Server

Application)

Low(Web

Interface)

Specify Bandwidth requirements between PRE and other Devices (PCs, printers, etc), as well as any relevant bandwidth requirements between the solutions intra-constituents.

Page 148

6. Desktop Environment

Provide the following information in relation to the desktop requirements.

ResponseMinimum Desktop Configuration:

MemoryProcessing PowerRuntimesConfigurationOthers (please specify)

7. Technical Specifications

Provide the detailed architecture and functional design documents indicated below, including the following information:a) Any interfacing that may be required to any other systems must also be clearly detailed. b) The functional documentation must include the failover and failback processes (in the case of clustered systems) c) The interaction that takes place between each system, including systems such as Active Directory Services, DNS and any other systems such as the

Storage Area Network must be included

7.1 System Infrastructure Architecture

Insert a logical system / network architecture diagram of how all the components including servers, firewalls, routers and links are connected together and to external networks such as the Internet.

7.2 System Technical Flow Diagram

Provide a high-level flow diagram that shows the flow between the client, the front-end and back-end and the technologies used such as HTTP, SSL, SOAP, XML, Operating System, Java, .NET, SQL Server, Oracle, IIS etc.

8. Monitoring Details

Page 149

1. Include a Problem Notification and Escalation Procedure.2. Include an Alert Reference Guide.

3. State if the solution requires a dedicated monitoring console (DMC) or does it support SNMP? DMC SNMP

If a dedicated monitoring console is required provide details of the console, (which will be provided as part of the total solution).

4. Component to monitor

Monitoring tool to be used (*)

After office hours support required? (Y/N)

Threshold when escalation is required

(*)The following is a list of tools utilised by MITA for monitoring purposes which can be indicated. If other monitoring tools are required, please specify (in which case the tools, together with any training required, are to form part of the Solution to be provided by the Contractor).

(a) HP Openview Network Node Manager (NNM) (b) HP Procurve Manager Plus(c) System Log Protocol tool (SYSLOG) (d) D-View(e) Cisco Works LMS 2.5 (f) Fujitsu Server View(g) Microsoft Operation Manager (MOM) (h) HP Insight Manager(i) ECC IBM Director

Page 150

Volume 3 SECTION 4 INTEROPERABILITY STANDARDS

Tenderers are to indicate which of these standards, or their equivalent, the Solution being proposed meets.

Interconnectivity

Component Standard Standards Body

Tick if applicable

State the equivalent standard if not applicable

Web transport Hypertext Transfer Protocol HTTP v1.1 (RFC 2616)

IETF/W3C

Email transport Simple Mail Transfer Protocol SMTP (RFC2821, RFC2822)

IETF

Internet message format Multipurpose Internet Mail Extensions MIME (RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2077)

IETF

Mailbox access Internet Message Access Protocol IMAPV4.1 (RFC 3501)

IETF

Email Security S/MIME V3. This includes RFC 2630 to RFC 2633.

IETF

Directory X.500 core schema (ISO/IEC95948). Lightweight Directory Access Protocol LDAP V3 (RFC4510) is to be used for general-purpose directory user access.

ITU/I EC/ISO IETF

Domain Name System DNS (RFC 1032 to RFC1035 and related updates)

IETF

File transfer protocols FTP (RFC 959, RFC1579, RFC2428)

Secure copy over ssh (OpenBSD reference implementation)

IETF

Page 151


Tick if applicable


LAN/WAN interworking Internet Protocol IPv4 (RFC 791)Internet Protocol IPv4 (RFC 2460)

IETF

IP security IP-SEC (RFC2402/2404) IETF

IP encapsulation security Encapsulating Security Payload ESP (RFC2406)

IETF

Transport Transport Control Protocol TCP RFC793 with extensions as referred in RFC4614User Datagram Protocol UDP (RFC768) IETF

IETFTransport security TLS 1.1 (RFC 4346) IETF

Encryption algorithms Stream Ciphers: RC4, Rabbit, Decim, TSC4 (ISO/IEC18033-4)

Block Ciphers: AES (FIPS 197), Twofish, RC6, Blowfish, IDEA (ISO/IEC18033-3)

Asymmetric: RSA(ISO/IEC18033-2); Elliptic Curve Cryptography (ECC SEC1) (ISO/IEC15946)

ISO

ISO

ISO

Hashing SHA-256, SHA-512 (FIPS Pub 180-2);

SHA-384; RIPEMD-160; WHIRLPOOL-512 (ISO/IEC 10118-3)

FIPS

ISO

Page 152


Tick if applicable


Digital Signatures With Appendix: RSA f ISO/I EC14888}

With Message Recovery: RSA (ISO/IEC9796-2/3); DSA(FIPS Pub 186-2), EC-DSA, Rabin, Nyberg-Reuppel (ISO/IEC14888))

Key Management Diffie-Hellman (ANSI X9.42 - DH-MQV); EIGamal, Nyberg-Reuppel, RSA (ISO/IEC11770-2/3))

Data Interoperability

Component Standard Standard Body

Tick if applicable


Metadata/MetaLanguage XML (Extensible Markup Language) W3CXML MetaData definition XML-Schema

RelaxNGW3C OASIS/ISO

XML Data transformation XSL (Extensible Stylesheet Language) W3CXML Data query Xpath W3CXML Signature XMLDSIG W3CXML Security mark-up SAML v2.0 (Security Assertion Markup

Language)OASIS

Public Key Infrastructure X509v3 ITU-TMinimum interoperable character set

Transformation Format - 8 bit UTF-8 (RFC3629), individual items in the XML schema may be further restricted in character set on a case by case basis.

IETF

Modelling and Description Language

UML (Unified Modelling Language) RDF (Resource Description Framework)

OMG W3C

Ontology-based information exchange

OWL (Web Ontology Language Semantics and Abstract Syntax)

W3C

Page 153


Tick if applicable


Model exchange XMI (XML Metadata Interchange), version 2.1

OMG

Form Representation and Data

Xforms W3C

Geospatial data GML (Geospatial Markup Language) Open Geospatial Consortium

Web Services


Tick if applicable


Web service request delivery

Simple Object Access Protocol SOAP v1.2

W3C

Web service request registry

Universal Description, Discovery and Integration UDDI v3.0

OASIS

Web service description language

WSDL1.1 W3C

Information Access


Tick if applicable


Hypertext interchange formats

Those parts of Hypertext Markup Language HTMLv4.0 and XHTML implemented in common by Firefox v2.0 or later, and MS Internet Explorer v6 or later, plus their interoperable extensions

W3C

Working Office Document formats (word-processing, spreadsheet, presentation)

UTF-8/ASCII Formatted TextOpen Document Format (ODF) vl.O (ISO26300) and later Oasis versionsISO/IEC 29500:2008 Office Open XML

IETF

OASIS/ISO

Page 154


Tick if applicable


File FormatsComma-Separated Values (CSV) RFC4180

ISO/IEC

IETFDocument formats for presentation view

XHTML markup PDF (version 1.6)

W3C Adobe1

Relational Database Access

Structured Query language SQL93 ANSI

Character sets and alphabets

UNICODE ISO/I EC 10646-1:2000

ISO/I EC

Graphical/still image information exchange

Joint Photographic Experts Group/ISO standards 10918Portable Network Graphics (ISO/IEC15948:2001)For images that will not tolerate information loss use tag Image File Format (.tif)

ISO ISO

Adobe

Multimedia audio/visual content

Moving Picture Experts Group (.mpg) MPEG-1 (ISO/IEC 11172) MPEG-2 (ISO/IEC 13818) MPEG-4 and ogg (http://www.xiph.org)

ISO

Browser scripting JavaScript (ECMA 262)

ECMA

Internet Conferencing H323 SIP(RFC3261)

ITU-T

IETF

File compression tar (POSIX. 1-2001) gzip (RFC1951 and RFC1952) zip (http://www.pkware.com) bzip2 (http://www.bzip.org/) POSIX

Page 155


Tick if applicable


IETF

Instant Messaging Extensible Messaging and Presence Protocol (XMPP) - RFC 3920 IETF

Content Management Metadata


Tick if applicable State the equivalent standard if not applicable

Content management metadata elements and refinements

Dublin Core ISO15836

Metadata harvesting Open Archives Initiative Protocol for Metadata Harvesting 2.0 (OAI-PMH) for metadata collection. Protocol Version 2.0 of 2002-06-14 Document Version 2003/02/21 T00:00:00Z http ://www.openarchives.o rg/OA/openarchivesprotocol.html

Content syndication RSS (RDF Site Summary) Version 1 The RSS is a standard format for syndicating news content over the web using Dublin Core and RDF Published by the RSS-DEV Working Group http://web.resource.0rg/rss/l.O/RSS (Really Simple Syndication) Version 2 The RSSwas originally designed as an alternative standard format for syndicating news content over the web, however RSS can be and is being used to publish various types of data over the web, not just news data. The RSS 2.0 is offerred by Berkman

Page 156



Center for Internet & Society at Harvard Law School under the terms of the Attribution/Share Alike Creative Commons license http://blogs.law.harvard.edu/tech/rss

Content-sensitive linking OpenURL 0.1 (migrating to 1.0) for context-sensitive linking http://www.exlibrisgroup.com/sfxopenurl.htm The openURL is designed to enable the transfer of the metadata from the information service to a service component that can provide context-sensitive services for the transferred metadata

Distributed searching Z39.50 or Search/retrieve Web Service (SRW)ISO 23950:1998 Information and documentation -Information retrieval (Z39.50) -Application service definition and protocol specification http://lcweb.loc.dov/z3950/agency/

Identifiers



Persistent and unique logical identifiers

z39.84 provides a syntax for unique identification for digital content

ANSI/NISO

Mobile Phones

Component Standard Standard Body Tick if applicable State the equivalent standard if not applicable WAP specifications WAP2.0 WAP Forum

http://www.openPage 157

Component Standard Standard Body Tick if applicable State the equivalent standard if not applicable mobileallia nce.org/

GPRS The General Packet Radio Service specifications for Mobile Stations including: EN No: 310 113, 301 344, 301 347 and TS 101 297, 101 351

European telecommunications Standard Institute (ETSI)

SMS The Short Message Service specifications for Mobile Stations including ETS 300 536, 537, 300 559, 300 560, see www.etsi.org

European Telecommunications Standards Institute (ETSI)

MMS The Multimedia Messaging Service specifications for Mobile Stations including: TS 122 140, 123 140, 126 140

European Telecommunications Standards Institute (ETSI)

Biometric Data Interchange


Tick if applicable


Secure XML Encoding for exchanging biometric data

OASIS XCBF 1.1 Specification. Secure XML encodings for the patron formats specified in CBEFF, the Common Biometric Exchange File Format (NISTIR 6529).

OASIS

Data Element Specification ISO/I EC 19785-1 Information Technology - Common Biometric Exchange Formats Framework - Part 1: Data Element specification

ISO/IEC

Interchange format framework

ISO/IEC 19794: Information Technology Biometric data interchange formats - Part 1: Framework

ISO/IEC

Interchange formats for ISO/IEC 19794: Information Technology ISO/IECPage 158

http://www.etsi.org/


Tick if applicable


finger minutiae data Biometric data interchange formats - Part 2: Finger minutiae data

Interchange formats for Finger pattern spectral

ISO/IEC 19794: Information Technology Biometric data interchange formats - Part 3: Finger pattern spectral

ISO/IEC

Interchange formats for Finger image data

ISO/IEC 19794: Information Technology Biometric data interchange formats - Part 4: Finger image data

ISO/IEC

Interchange formats for Face image data

ISO/IEC 19794: Information Technology Biometric data interchange formats - Part 5: Face image data

ISO/IEC

Interchange Formats for Signature/sign behaviour data

ISO/IEC 19794: Information Technology Biometric data interchange formats - Part 7: Signature/sign behaviour

ISO/IEC

Graphical/still image information exchange specifications

ISO/IEC 10918-1:1994 Information technology - Digital compression and coding of continuous-tone still images: Requirements and Guidelines

ISO/IEC 10918-1:1994/CD C or 1

ISO/IEC 10918-2: 1995 Information technology - Digital compression and coding of continuous-tone still images: Compliance testing

ISO/IEC 10918-3: 1997 Information technology -Digital compression and coding of continuous-tone still images: Extensions

ISO/IEC 10918-3:1997/Amd 1:1999

ISO/I EC 10918-4:1999 Information

ISO/IEC

Page 159


Tick if applicable


technology -Digital compression and coding of continuous-tone still images: Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types and Registration Authorities (REGAUT)

Additional Standards

The Tenderer is to state what standards, not listed above, are adopted by the Solution to be provided.


Reference to Standard

Page 160

VOLUME 4 - FINANCIAL BIDNo rectification shall be allowed. Only clarifications on the submitted information may be requested.

Price Schedule 1 - Fee for the Purchase of the different of Modules The cost per module, and the cost of implementation of each module is to be provided below.

Module Name Cost of Module

Price Schedule 2 Fee for the provision of LicensesThe table below should be completed as applicable.

Cost € State if an annual cost or a one time cost

State if the license cost is per user or per concurrent user

Site licenseUser license (read only)(If applicable)User license (all rights)Other options

Price Schedule 3 – Fee for Third party licensesPlease provide the cost of an itemised list of third party licences. Indicate clearly whether the license cost is per user, or per concurrent user, and whether this is an annual cost or a one time cost.

Item Cost € State if an annual cost or a one time cost

State if the license cost is per user or per concurrent user

Price Schedule 4 – Fee for the provision of Hardware Please provide the cost of an itemised list of hardwareitem Cost €

Price Schedule 5 – Fee for Implementation Servicesitem Cost € CommentsH/w implementation including validation of implementation including o/s and all other tasks required for a successful implementation of the hardware, up to and including the o/sSoftware implementation including application /

Page 161

solution validation, project management, ad all other tasks required for a succesful implementation of the solution.

Price Schedule 6 - Fee for Annual Maintenance and Supportitem Cost €

Yr 1Cost €Yr 2

Cost €Yr 3

Cost €Yr 4

Cost €Yr 5

Application Software Hardware Managed hosting service Others

Price Schedule 7 - Fee for Training All the types of training listed below are to be provided.item Cost € State if an annual cost

or a perpetual license.State if per concurrent user

Train the trainer trainingEnd user Training Administrator TrainingSuper User Training

Price Scedule 8 - Other Ad Hoc costs

Description of Service Skill Type Hourly Rate (in Euro)

Daily Rate (in Euro)

Monthly Rate (in Euro)

The total cost of ownership of the Solution is __€________________.

I, the undersigned, confirm that the values included in these Price Schedules are all quoted in EURO. All prices are inclusive of VAT and all duties, taxes, levies, ECO contribution and other charges as may be applicable for the delivery of the solution requested in this ITT.

Signature of Tenderer Name of Firm / Organisation E-Mail Address

Full Name in Block letters

ID. No.

Address Fax Number

Capacity in which Employed VAT Reg. Number Telephone Number

Page 162

Page 163