INDIAN NAVY IMPLEMENTATION OF PAPERLESS · PDF fileINDIAN NAVY IMPLEMENTATION OF PAPERLESS ... Scope of Paperless Office Solution for Indian Navy ... E-mail ids of contact personnel:

Directorate of Information Technology

Room No – 128, ‘C’ Wing, Sena Bhawan Integrated Headquarters of Ministry of Defence (Navy) New Delhi – 110 011

INDIAN NAVY

IMPLEMENTATION OF PAPERLESS OFFICE SOLUTION FOR INDIAN NAVY REQUEST FOR PROPOSAL

TABLE OF CONTENTS

Contents

TABLE OF CONTENTS .................................................................................................. 2

INTRODUCTION ............................................................................................................. 1

5. Pre-Bid Vendor Conference ............................................................................... 2

PART I – GENERAL INFORMATION ............................................................................. 3

1. Last Date and Time for Depositing the Bids ....................................................... 3

2. Manner of Depositing the Bids ........................................................................... 3

3. Time and Date for Opening of Bids .................................................................... 3

4. Place of Opening of Bids .................................................................................... 3

6. Forwarding of Bids ............................................................................................. 3

7. Clarification Regarding Contents of the RFP ..................................................... 3

8. Modification and Withdrawal of Bids .................................................................. 4

9. Clarification Regarding Contents of Bids ............................................................ 4

10. Rejection of Bids ................................................................................................ 4

11. Validity of Bids .................................................................................................... 4

12. Earnest Money Deposit ...................................................................................... 4

13. Cost of Bid.......................................................................................................... 5

PART II – ESSENTIAL DETAILS OF ITEMS AND SERVICES REQUIRED .................. 6

Technical Details ......................................................................................................... 6

(k) Requirement of Training / On- Job Training ....................................................... 6

(m) Acceptance ........................................................................................................ 7

(n) Requirement of Technical Documentation ......................................................... 7

3. Delivery Period ................................................................................................... 7

PART III – STANDARD CONDITIONS OF RFP ............................................................. 9

1. Law .................................................................................................................... 9

2. Effective Date of the Contract ............................................................................ 9

3. Arbitration ........................................................................................................... 9

4. Penalty for Use of Undue Influence .................................................................... 9

5. Agents/ Agency Commission ........................................................................... 10

6. Access to Books of Accounts ........................................................................... 10

7. Non-Disclosure of Contract Documents ........................................................... 10

8. Liquidated Damages ........................................................................................ 10

9. Termination of Contract .................................................................................... 11

10. Notices ............................................................................................................. 12

11. Transfer and Sub-letting ................................................................................... 12

12. Patents and Other Property Rights .................................................................. 12

13. Amendments .................................................................................................... 12

14. Taxes and Duties ............................................................................................. 13

PART IV – SPECIAL CONDITIONS OF RFP ............................................................... 17

1. Performance Guarantee ................................................................................... 17

2. Repeat Order Clause ....................................................................................... 17

3. Tolerance Clause ............................................................................................. 17

4. Change Orders/ Alteration/ Variation. .............................................................. 17

5. Change Order .................................................................................................. 18

10. Procedures for Change Order .......................................................................... 18

16. Conditions for Extra Work/ Change Order ........................................................ 20

17. Payment Terms ................................................................................................ 20

18. Advance Payments .......................................................................................... 21

19. Paying Authority ............................................................................................... 21

20. Risk & Expense Clause .................................................................................... 22

21. Force Majeure .................................................................................................. 22

22. Specification ..................................................................................................... 23

23. OEM Certificate ................................................................................................ 23

24. Quality .............................................................................................................. 23

25. Quality Assurance ............................................................................................ 24

26. Inspection Authority .......................................................................................... 24

27. Warranty .......................................................................................................... 24

28. Product Support ............................................................................................... 24

29. Annual Maintenance Contract Clause .............................................................. 25

PART V – EVALUATION CRITERIA & PRICE BID ISSUES ....................................... 27

1. Evaluation Criteria ............................................................................................ 27

2. Price Bid Format .............................................................................................. 28

Appendix 'A' - EMD Bank Guarantee Format ............................................................ 29

Appendix 'B' - Scope of Paperless Office Solution for Indian Navy ....................... 30

Introduction ................................................................................................................ 30

Existing Process - Documents/ File Transactions at IHQ MOD (N) ........................... 31

Proposed Solution ..................................................................................................... 33

Scope of Work ........................................................................................................... 33

Scope of Work – Latter Phases ................................................................................. 42

Annexure I to Appendix ‘B’ – Implementation Schedule ......................................... 43

Part I – Applications/ Software Development for Common Functionalities & Customisation ............................................................................................................ 43

Part II – Roll out in all Directorates ............................................................................ 45

Part III -Acceptance of Project ................................................................................... 46

Annexure II of Appendix ‘B’ - Methodology For Execution ..................................... 47

Annexure III of Appendix ‘B’ - Methodology For Scanning Documents ................. 53

Annexure IV of Appendix ‘B’ - End To End Security Features ................................ 55

Appendix ‘C’ - Technical Qualitative Requirement................................................... 56

Annexure I of Appendix ‘C’ - Specification For Paperless Office Solution ............ 58

Annexure II of Appendix ‘C’ - Vendor Selection Criteria ........................................ 115

Appendix 'D' - Undertaking for Handing Over IPR ................................................. 122

Appendix ‘E’ - Certificate: Terms And Conditions ................................................. 123

Appendix ‘F’ - Confidentiality Certificate ................................................................ 124

Appendix ‘G’ - Certificate of Compliance to Decisions by TEC & PNC ................ 125

Appendix ‘H’ - Guidelines for ATP of Application Software .................................. 126

Annexure I to Appendix ‘H’ - Certificate on Successful Completion of ATP ....... 127

Appendix ‘J’ - Service Level Agreement for Support ............................................. 128

Appendix - 'K' - Price Bid Format ............................................................................. 132

This document is intended solely for the use of the individuals or entities participating in bid process. Any use, dissemination,

forwarding, printing or copying of this document without prior permission of DIT, Indian Navy is strictly prohibited.

Page | 1

INTRODUCTION

INVITATION OF BIDS FOR IMPLEMENTATION OF PAPERLESS OFFICE SOLUTION FOR INDIAN NAVY

Request for Proposal (RFP) No. IT/0631/31 dated – 24 Sep 15

1. Bids under two - bid system i.e. Technical Bid and Commercial Bid to be submitted in separate sealed covers are invited for 'Implementation of Paperless Office Solution for Indian Navy’ as per details at enclosures. Please superscribe the above mentioned Title, RFP number and date of opening of the Bids on the two sealed covers to avoid the Bid being declared invalid. 2. The address and contact numbers for sending Bids or seeking clarifications regarding this RFP are given below:-

(a) Bids/ queries to be addressed to:-

Directorate of Information Technology (DIT) Room No – 128, ‘C’ Wing, Sena Bhavan Integrated Headquarters of Ministry of Defence (Navy) New Delhi - 110011

(b) Postal address for sending the Bids:-

Directorate of Information Technology (DIT) Room No – 128, ‘C’ Wing, Sena Bhavan Integrated Headquarters of Ministry of Defence (Navy) New Delhi - 110011

(c) Name/designation of the contact personnel: Joint Director Information Technology (Software) (d) Telephone numbers of the contact personnel: +91-11-23010523 (e) E-mail ids of contact personnel: [email protected] (f) Fax number: +91-11-23010612

3. This RFP is divided into five Parts as follows :-

(a) Part I – Contains General Information and Instructions for the Bidders about the RFP such as the time, place of submission and opening of tenders, Validity period of tenders etc.



Page | 2

(b) Part II – Contains Essential details of the application and services required, such as the Schedule of Requirements (SOR), Technical Specifications, Delivery Period, Mode of Delivery and Consignee details. (c) Part III – Contains Standard Conditions of RFP, which will form part of the Contract with the successful Bidder. (d) Part IV – Contains Special Conditions applicable to this RFP and which will also form part of the contract with the successful Bidder. (e) Part V – Contains Evaluation Criteria and Format for Price Bids.

4. This RFP is being issued with no financial commitment and the Buyer reserves the right to change or vary any part thereof at any stage. Buyer also reserves the right to withdraw the RFP, should it become necessary at any stage. 5. Pre-Bid Vendor Conference. A pre-bid conference will be held at ‘C’ Wing, Sena Bhavan, IHQ MoD(N)/DIT, New Delhi at 1500 Hrs on 08 Oct 15. In order to obtain the requisite security clearance, the vendors are to forward the following information with regard to the participants (maximum 02 representatives per vendor). The information is to be forwarded at-least one day prior to the Pre-Bid Conference date. (a) Name, Nationality, Age, Address and Contact Nos. (b) Any other information relevant to the subject. 6. The aforesaid information is to be forwarded to JDIT (SW) by 1800 Hrs (One day prior to pre-bid conference date) either through e-mail ([email protected]) or to Room No. 127- B, First Floor, 'C' – Wing, Sena Bhavan, New Delhi - 110011. He can also be contacted on telephone Nos +91-11-23010523 or Fax no +91-11-23010612.

mailto:[email protected]



Page | 3

PART I – GENERAL INFORMATION

1. Last Date and Time for Depositing the Bids. 10 Nov 15/1400 Hrs. Both Technical and Commercial bids will be submitted in separate sealed envelopes marked ‘Technical Offer’ and ‘Commercial Offer’ respectively by the due date and time. The responsibility to ensure this lies with the Bidder. 2. Manner of Depositing the Bids. Separate sealed Bids should be dropped in the Tender Box marked as “Implementation Of Paperless Office Solution for Indian Navy” so as to reach by the due date and time. Late tenders will not be considered. No responsibility will be taken for postal delay, non-delivery or non-receipt of Bid documents. Bids sent by Fax or e-mail will not be considered. 3. Time and Date for Opening of Bids. 10 Nov 15/ 1500 Hrs. (If due to any exigency, the due date for opening of the Bids is declared a closed holiday, the Bids will be opened on the next working day at the same time or on any other day/time, as intimated bythe Buyer). 4. Location of the Tender Box. Gate No.1, Sena Bhavan, New Delhi - 110011. Only those Bids that are found in the tender box marked as per Para 2 above will be opened. Bids dropped in wrong Tender Box will be rendered invalid. 4. Place of Opening of Bids. Directorate of Information Technology, Room No.127B, ‘C’ Wing, Sena Bhavan, New Delhi – 110 011. Interested bidders may depute their representatives, duly authorised in writing, to attend the opening of Bids on the due date and time. Technical bids of all bidders will be opened in the presence of the representatives of firms present. This event will not be postponed due to non-presence of your representative. 5. Two-Bid System. Only the Technical Bid would be opened on the time and date mentioned above. Date of opening of the Commercial Bids will be intimated to all qualified firms after acceptance and evaluation of Technical Bids. Commercial Bids of only those firms will be opened on the subsequent date, whose Technical Bids are found compliant after technical evaluation is done by the Buyer. 6. Forwarding of Bids. Bids should be forwarded by Bidders under their original memo or letter pad inter alia furnishing details like TIN number, VAT/CST number, Bank address with NEFT Account details, etc and complete postal address, telephone number of contact persons and e-mail address of their office. Also only the original document of the tender with seal will be used for submission of bids, in case vendors submit in any other format the bids will be rejected. 7. Clarification Regarding Contents of the RFP. A prospective bidder who requires clarification regarding the contents of the RFP shall notify to the Buyer in writing about



Page | 4

the clarifications sought, prior to the date of pre-Bid meeting. Copies of the query and clarification by the buyer will be discussed during the pre-bid meeting and minutes of the meeting will be hosted as corrigendum on the Internet. Any clarification requested after pre-bid meeting will not be considered. 8. Modification and Withdrawal of Bids. A bidder may modify or withdraw his bid after submission, provided that the written notice of modification or withdrawal is received by the Buyer prior to deadline prescribed for submission of bids. A withdrawal notice may be sent by fax but it should be followed by a signed confirmation copy to be sent by post and such signed confirmation should reach the purchaser not later than the last date for submission of bids. No bid shall be modified after the deadline for submission of bids. No bid may be withdrawn in the interval between the deadline for submission of bids and expiration of the period of bid validity specified. Withdrawal of a bid during this period will result in Bidder’s forfeiture of bid security. 9. Clarification Regarding Contents of Bids. During evaluation and comparison of bids, the Buyer may, at its discretion, ask the bidder for clarification of his bid. The request for clarification will be given in writing and no change in prices or substance of the bid will be sought, offered or permitted. No post-bid clarification on the initiative of the bidder will be entertained. 10. Rejection of Bids. Canvassing by the Bidder in any form, unsolicited letter and post tender correction may invoke summary rejection with forfeiture of EMD. Conditional tenders will be rejected. 11. Validity of Bids. The Bids should remain valid for a minimum period of six months from the last date of submission of the Bids. 12. Earnest Money Deposit. Bidders are required to submit Earnest Money Deposit (EMD) payable to PCDA(N), Mumbai for an amount of ₹ 10,00,000/- (Rupees Ten Lakhs only) along with their bid. In case EMD is not found attached with the Technical Bid, the bids are liable for rejection. The EMD may be submitted in the form of an Account Payee Demand Draft, Fixed Deposit Receipt, Banker's Cheque or Bank Guarantee from any of the public sector banks or a private sector bank authorised to conduct government business as per Form DPM-13 (also placed at Appendix ‘A’). EMD is to remain valid for a period of 60 days beyond the final bid validity period. EMD of the unsuccessful bidders will be returned to them at the earliest after expiry of the final bid validity and latest on or before the 30th day after the award of the contract. EMD of unsuccessful vendors may be collected by hand post determination of L1 bidder. Balance EMDs will be dispatched by post. The Bid Security of the successful bidder would be returned, without any interest whatsoever, after the receipt of Performance Security from them as called for in the contract. EMD is not required to be submitted by those Bidders who are registered with the Central Purchase Organization (e.g. DGS&D), National Small Industries Corporation (NSIC) or any Department of MoD or MoD itself. The EMD will be forfeited if the bidder withdraws, amends, impairs or derogates from the tender in any respect within the validity



Page | 5

period of their tender. Bids received without EMD or certificate of valid registration with the authorities mentioned above will be rejected. 13. Cost of Bid. Tender fee is set at ₹ 500.00 (Rupees Five Hundred only) and can be submitted in the form of in the form of Account Payee Demand Draft, Fixed Deposit Receipt or Banker's Cheque made payable to PCDA (N), Mumbai. Bidders downloading the tender document from the website must submit the cost of tender document along with the Technical Bid.



Page | 6

PART II – ESSENTIAL DETAILS OF ITEMS AND SERVICES REQUIRED 1. Schedule of Requirements. List of items/ services required are as per Appendices as mentioned below. Technical Details

(a) Appendix ‘B’. Scope of the project. (i) Annexure-I - Implementation Schedule. (ii) Annexure-II - Envisaged methodology for execution of software package. (iii) Annexure III - Document Capture Details (iv) Annexure-IV - Security Features.

(b) Appendix ‘C’. Technical Qualitative Requirement.

(i) Annexure I - Software / Application Requirements. (ii) Annexure-II - Vendor Selection Criteria.

(c) Appendix ‘D’ - IPR.

(d) Appendix ‘E’ - Certificate on Terms and conditions.

(e) Appendix ‘F’ - Confidentiality certificate. (f) Appendix ‘G’ - Certificate of Compliance to Decisions by TEC and PNC. (g) Appendix ‘H’ - Procedure and guidelines for Acceptance Testing Procedure (ATP) of Application Software. (h) Appendix ‘J’ -Warranty Support & AMC. (j) Technical Details with Technical Parameters. List of items/ services required are as per Appendix ‘B’. (k) Requirement of Training / On- Job Training. The Bidder is responsible to provide a minimum of 3 days Training to at least 500 users comprising Officers, sailors and civilian personnel of IHQ MoD (Navy) at Sena Bhavan in convenient batch sizes during the roll out phase on the usage of the implemented solution. Successful Bidder has to provide Training tools and material, space will be provided by the Indian Navy. The training will be basically on user management, System administration, and exploitation of application package software. Additionally, 05 personnel of DIT will be trained on system administration, database administration and API documentation and exploitation. The users



Page | 7

training will be conducted as per the schedule worked out mutually between the Buyer and the Seller after completion of Final Release during the roll out phase. Modalities of training schedule will be submitted along with the technical bid. (l) Requirement of Installation / Commissioning. Refer Appendix ‘B’. (m) Acceptance. Delivery of the Application Software and other deliverables will be at DIT / IHQ MoD(N), New Delhi. The system will be subjected to detailed Acceptance Testing Procedure (ATP) to test individual components before and after successful integration at IHQ MoD(N). The VENDOR and Project Implementation Team (PIT), will work out the details of testing jointly. The PIT will issue a Product Acceptance Certificate as per Annexure I to Appendix ‘H’ on successful liquidation of observed anomalies.

(n) Requirement of Technical Documentation. Soft Copy and hard bound booklets of installation, usage, maintenance and troubleshooting guides will be supplied by the VENDOR within 30 days after completion of the project.

2. Two-Bid System. Bidders are required to furnish clause by clause compliance of specifications bringing out clearly the deviations from specification, if any. The Bidders are advised to submit the compliance statement in the format of Technical Bid placed at Appendix ‘B’ and it’s Annexures. Additional sheets, brochures of the items being supplied and any other technical documents duly linked with the serial number of technical QR will be submitted along with Technical Bid by the bidder duly stamped and signed. All relevant certificates which are valid will be submitted duly certified. 3. Delivery Period. Details of project implementation are as under:-

(a) Proposed Implementation Schedule for the project is given at Annexure I to Appendix ‘B’ but vendors are at liberty to complete the project earlier, but not later than time frame specified herein. (b) The deliverables for the application software mentioned herein for each Stage/ iteration as applicable will be delivered by the vendor as per the schedule given at Annexure II to Appendix ‘B’.

Note:- Please note that Contract can be cancelled unilaterally by the Buyer in case items are not received within the contracted delivery period. Extension of contracted delivery period will be at the sole discretion of the Buyer, with applicability of LD clause.

4. Consignee Details. The Principal Director Directorate of Information Technology (DIT)



Page | 8

Room No – 128, ‘C’ Wing, Sena Bhavan Integrated Headquarters of Ministry of Defence (Navy) New Delhi - 110011



Page | 9

PART III – STANDARD CONDITIONS OF RFP

The Bidder is required to give confirmation of their acceptance of the Standard Conditions of the Request for Proposal mentioned below which will automatically be considered as part of the Contract concluded with the successful Bidder (i.e. Seller in the Contract) as selected by the Buyer. Failure to do so may result in rejection of the Bid submitted by the Bidder. 1. Law. The Contract shall be considered and made in accordance with the laws of the Republic of India. The contract shall be governed by and interpreted in accordance with the laws of the Republic of India. 2. Effective Date of the Contract. The contract shall come into effect on the date of signatures of both the parties on the contract (Effective Date) and shall remain valid for a period of four years or until the completion of the obligations of the parties under the contract, whichever is later. The deliveries and supplies and performance of the services shall commence from the effective date of the contract. 3. Arbitration. All disputes or differences arising out of or in connection with the Contract shall be settled by bilateral discussions. Any dispute, disagreement or question arising out of or relating to the Contract or relating to construction or performance, which cannot be settled amicably, may be resolved through arbitration. The standard clause of arbitration is as per Forms DPM-7 (Available in MoD website and can be provided on request).

4. Penalty for Use of Undue Influence. The Seller undertakes that he has not given, offered or promised to give, directly or indirectly, any gift, consideration, reward, commission, fees, brokerage or inducement to any person in service of the Buyer or otherwise in procuring the Contracts or forbearing to do or for having done or forborne to do any act in relation to the obtaining or execution of the present Contract or any other Contract with the Government of India for showing or forbearing to show favour or disfavour to any person in relation to the present Contract or any other Contract with the Government of India. Any breach of the aforesaid undertaking by the Seller or any one employed by him or acting on his behalf (whether with or without the knowledge of the Seller) or the commission of any offers by the Seller or anyone employed by him or acting on his behalf, as defined in Chapter IX of the Indian Penal Code, 1860 or the Prevention of Corruption Act, 1986 or any other Act enacted for the prevention of corruption shall entitle the Buyer to cancel the contract and all or any other contracts with the Seller and recover from the Seller the amount of any loss arising from such cancellation. A decision of the Buyer or his nominee to the effect that a breach of the undertaking had been committed shall be final and binding on the Seller. Giving or offering of any gift, bribe or inducement or any attempt at any such act on behalf of the Seller towards any officer/employee of the Buyer or to any other person in a position to influence any officer/employee of the Buyer for showing any favour in relation to this or any other contract, shall render the Seller to such liability/ penalty as the Buyer may deem proper,



Page | 10

including but not limited to termination of the contract, imposition of penal damages, forfeiture of the Bank Guarantee and refund of the amounts paid by the Buyer. 5. Agents/ Agency Commission. The Seller confirms and declares to the Buyer that the Seller is the original manufacturer of the stores/provider of the services referred to in this Contract and has not engaged any individual or firm, whether Indian or foreign whatsoever, to intercede, facilitate or in any way to recommend to the Government of India or any of its functionaries, whether officially or unofficially, to the award of the contract to the Seller; nor has any amount been paid, promised or intended to be paid to any such individual or firm in respect of any such intercession, facilitation or recommendation. The Seller agrees that if it is established at any time to the satisfaction of the Buyer that the present declaration is in any way incorrect or if at a later stage it is discovered by the Buyer that the Seller has engaged any such individual/firm, and paid or intended to pay any amount, gift, reward, fees, commission or consideration to such person, party, firm or institution, whether before or after the signing of this contract, the Seller will be liable to refund that amount to the Buyer. The Seller will also be debarred from entering into any supply Contract with the Government of India for a minimum period of five years. The Buyer will also have a right to consider cancellation of the Contract either wholly or in part, without any entitlement or compensation to the Seller who shall in such an event be liable to refund all payments made by the Buyer in terms of the Contract along with interest at the rate of 2% per annum above LIBOR rate. The Buyer will also have the right to recover any such amount from any contracts concluded earlier with the Government of India. 6. Access to Books of Accounts. In case it is found to the satisfaction of the Buyer that the Seller has engaged an Agent or paid commission or influenced any person to obtain the contract as described in clauses relating to Agents/ Agency Commission and penalty for use of undue influence, the Seller, on a specific request of the Buyer, shall provide necessary information/ inspection of the relevant financial documents/ information. 7. Non-Disclosure of Contract Documents. Except with the written consent of the Buyer/ Seller, other party shall not disclose the contract or any provision, specification, plan, design, pattern, sample or information thereof to any third party. A certificate as given in Appendix ‘F’ to this RFP has to be attached along with the bids, duly signed by the bidder with company seal.

8. Liquidated Damages. In the event of the Seller’s failure to submit the Bonds, Guarantees and Documents, supply the stores/ goods and conduct trials, installation of equipment, training, etc as specified in this contract, the Buyer may, at his discretion, withhold any payment until the completion of the contract. The Buyer may also deduct from the Seller as agreed, liquidated damages to the sum of 0.5% of the contract price of the delayed/ undelivered stores/ services mentioned above for every week of delay or part of a week, subject to the maximum value of the Liquidated Damages being not higher than 10% of the value of delayed stores. The Buyer will have the right to terminate the



Page | 11

Supply Order in case of such delay beyond 10 weeks and the Buyer will have the option to buy the software or application developed and hardware from the market at the Sellers risk and cost. The mode and method of such risk purchase would be at the total discretion of the Buyer.

(a) Calculation of Liquidated Damages. Liquidated Damages as mentioned above, shall be calculated and shall be deducted out of the payments due to the Seller, for failure to complete the project/ phase in full. Liquidated Damages at the rate of point five percent (0.5%) of the total project/ phase (as applicable) cost for each complete week or part thereof, of delay up to a maximum of ten percent (10%) of the total project Cost. Deductions against 10% Performance Bank Guarantee shall be applicable in case of inordinate delays on part of the Seller in delivery of application software. (b) Method of Payment of Liquidated Damages. The amount charged as liquidated damages shall be deducted by the Buyer from the amount due for payment to the Seller. If the amount of such liquidated damages exceeds the payments due to the Seller, he shall within 30 (thirty) days make payment to the Buyer in FULL and FINAL settlement of claims, failing which the Performance Bank Guarantee will be encashed to make good such amount exceeding the amount due to the Seller.

9. Termination of Contract. The Buyer shall have the right to terminate this Contract in part or in full in any of the following cases :-

(a) Where the Indian Navy is of the opinion that there has been such Event of Default on the part of the Seller which would make it proper and necessary to terminate this Contract and may include failure on the part of the Contractor to respect any of its commitments with regard to any part of its obligations under its Proposal, the Tender or under this Contract. (b) Where it comes to the Indian Navy’s attention that the Seller (or the Sellers Team) is in a position of actual conflict of interest with the interests of the Indian Navy, in relation to any of terms of the Sellers Proposal, the Tender or this Contract. (c) Where the Sellers ability to survive as an independent corporate entity is threatened or is lost owing to any reason whatsoever, including inter-alia the filing of any bankruptcy proceedings against the Seller, any failure by the Seller to pay any of its dues to its creditors, the institution of any winding up proceedings against the Seller or the happening of any such events that are adverse to the commercial viability of the Seller. In the event of the happening of any events of the above nature, the Buyer shall reserve the right to take any steps as are necessary, to ensure the effective transition of the project to a successor Implementation Agency/ service provider, and to ensure business continuity.



Page | 12

(d) Termination for Insolvency. The Buyer may at any time terminate the Contract by giving written notice to the Implementation Agency, without compensation to the Implementation Agency, if the Contractor becomes bankrupt or otherwise insolvent, provided that such termination will not prejudice or affect any right of action or remedy which has accrued or will accrue thereafter to the Buyer. (e) Termination for Convenience. The Buyer, may, by prior written notice sent to the Seller at least three months in advance, terminate the Contract, in whole or in part at any time for its convenience. The notice of termination shall specify that termination is for the Buyer’s convenience, the extent to which performance of work under the Contract is terminated, and the date upon which such termination becomes effective. The Contractor may, subject to approval by the Buyer, terminate this Contract before the expiry of the term for insolvency or Force Majeure by giving the Indian Navy a prior and written notice at least three months in advance indicating its intention to terminate the Contract. (f) The Buyer has noticed that the Seller has utilised the services of any Indian/ Foreign agent in getting this contract and paid any commission to such individual/ company etc. (e) As per decision of the Arbitration Tribunal.

10. Notices. Any notice required or permitted by the contract shall be written in the English language and may be delivered personally or may be sent by FAX or registered pre-paid mail/ airmail, addressed to the last known address of the party to whom it is sent. 11. Transfer and Sub-letting. The Seller has no right to give, bargain, sell, assign or sublet or otherwise dispose of the core component of Contract, as well as to give or to let a third party take benefit or advantage of the present Contract. 12. Patents and Other Property Rights. The prices stated in the present Contract shall be deemed to include all amounts payable for the use of patents, copyrights, registered charges, trademarks and payments for any other property rights. The Seller shall indemnify the Buyer against all claims from a third party at any time on account of the infringement of any or all the rights mentioned in the previous paragraphs, whether such claims arise in respect of manufacture or use. The Seller shall be responsible for the completion of the supplies including technical literature and training aggregates irrespective of the fact of infringement of the supplies, irrespective of the fact of infringement of any or all the rights mentioned above. 13. Amendments. No provision of present Contract shall be changed or modified in any way (including this provision) either in whole or in part except by an instrument in



Page | 13

writing made after the date of this Contract and signed on behalf of both the parties and which expressly states to amend the present Contract. 14. Taxes and Duties

(a) General (i) If Bidder desires to ask for excise duty or Sales Tax/ VAT extra, the same must be specifically stated. In the absence of any such stipulation, it will be presumed that the prices include all such charges and no claim for the same will be entertained. (ii) If reimbursement of any Duty/ Tax is intended as extra over the quoted prices, the Bidder must specifically say so. In the absence of any such stipulation it will be presumed that the prices quoted are firm and final and no claim on account of such duty/ tax will be entrained after the opening of tenders.

(iii) If a Bidder chooses to quote a price inclusive of any duty/ tax and does not confirm inclusive of such duty/ tax so included is firm and final, he should clearly indicate the rate of such duty/ tax and quantum of such duty/ tax included in the price. Failure to do so may result in ignoring of such offers summarily.

(iv) If a Bidder is exempted from payment of any duty/ tax up to any value of supplies from them, he should clearly state that no such duty/ tax will be charged by him up to the limit of exemption which he may have. If any concession is available in regard to rate/ quantum of any Duty/ tax, it should be brought out clearly. Stipulations like, the said duty/ tax was presently not applicable but the same will be charged if it becomes leviable later on, will not be accepted unless in such cases it is clearly stated by a Bidder that such duty/ tax will not be charged by him even if the same becomes applicable later on. In respect of the Bidders, who fail to comply with this requirement, their quoted prices shall be loaded with the quantum of such duty/ tax which is normally applicable on the item in question for the purpose of comparing their prices with other Bidders.

(v) Any change in any duty/ tax upward or downward as a result of any statutory variation in excise taking place within contract terms shall be allowed to the extent of actual quantum of such duty/ tax paid by the supplier. Similarly, in case of downward revision in any duty/ tax, the actual quantum of reduction of such duty/ tax shall be reimbursed to the Buyer by the Seller. All such adjustments shall include all reliefs, exemptions, rebates, concession etc. if any obtained by the Seller.



Page | 14

(b) Excise Duty (i) Where the excise duty is payable on advalorem basis, the Bidder should submit along with the tender, the relevant form and the Manufacturer’s price list showing the actual assessable value of the stores as approved by the Excise authorities. (ii) Bidders should note that in case any refund of excise duty is granted to them by Excise authorities in respect of Stores supplied under the contract, they will pass on the credit to the Buyer immediately along with a certificate that the credit so passed on relates to the Excise Duty, originally paid for the stores supplied under the contract. In case of their failure to do so, within 10 days of the issue of the excise duty refund orders to them by the Excise Authorities the Buyer would be empowered to deduct a sum equivalent to the amount refunded by the Excise Authorities without any further reference to them from any of their outstanding bills against the contract or any other pending Government Contract and that no disputes on this account would be raised by them.

(iii) The Seller is also required to furnish to the Paying Authority the following certificates:-

(aa) Certificate with each bill to the effect that no refund has been obtained in respect of the reimbursement of excise duty made to the Seller during three months immediately preceding the date of the claim covered by the relevant bill. (ab) Certificate as to whether refunds have been obtained or applied for by them or not in the preceding financial year after the annual Audit of their accounts also indicating details of such refunds/applications, if any. (ac) A certificate along with the final payment bills of the Seller to the effect whether or not they have any pending appeal/protest for refund or partial refund of excise duties already reimbursed to the Seller by the Government pending with the Excise authorities and if so, the nature, the amount involved, and the position of such appeals. (ad) An undertaking to the effect that in case it is detected by the Government that any refund from Excise Authority was obtained by the Seller after obtaining reimbursement from the Paying Authority, and if the same is not immediately refunded by the Seller to the Paying Authority giving details and particulars of the transactions, Paying Authority will have full authority to recover such amounts



Page | 15

from the Seller’s outstanding bills against that particular contract or any other pending Government contracts and that no dispute on this account would be raised by the Seller.

(iv) Unless otherwise specifically agreed to in terms of the contract, the Buyer shall not be liable for any claim on account of fresh imposition and/ or increase of Excise Duty on raw materials and/ or components used directly in the manufacture of the contracted stores taking place during the pendency of the contract.

(c) Sales Tax/ VAT (i) If it is desired by the Bidder to ask for Sales tax/ VAT to be paid as extra, the same must be specifically stated. In the absence of any such stipulation in the bid, it will be presumed that the prices quoted by the Bidder are inclusive of sales tax and no liability of sales tax will be developed upon the Buyer. (ii) On the Bids quoting sales tax extra, the rate and the nature of Sales Tax applicable at the time of supply should be shown separately. Sales tax will be paid to the Seller at the rate at which it is liable to be assessed or has actually been assessed provided the transaction of sale is legally liable to sales tax and the same is payable as per the terms of the contract.

(d) Octroi Duty and Local Taxes

(i) Normally, materials to be supplied to Government Departments against Government Contracts are exempted from levy of town duty, Octroi Duty, Terminal Tax and other levies of local bodies. The local Town/Municipal Body regulations at times, however, provide for such Exemption only on production of such exemption certificate from any authorised officer. Seller should ensure that stores ordered against contracts placed by this office are exempted from levy of Town Duty/Octroi Duty, Terminal Tax or other local taxes and duties. Wherever required, they should obtain the exemption certificate from the Buyer, to avoid payment of such local taxes or duties. (ii) In case where the Municipality or other local body insists upon payment of these duties or taxes the same should be paid by the Seller to avoid delay in supplies and possible demurrage charges. The receipt obtained for such payment should be forwarded to the Buyer without delay together with a copy of the relevant act or bylaws/ notifications of the Municipality of the local body concerned to enable him to take up the question of refund with the concerned bodies if admissible under the said acts or rules.



Page | 16

15. All certificates attached as Appendices to this RFP is required to be attached with Technical Bid in original. In case of any certificate not found in original, the vender will be liable for rejection.



Page | 17

PART IV – SPECIAL CONDITIONS OF RFP

The Bidder is required to give confirmation of their acceptance of Special Conditions of the RFP mentioned below which will automatically be considered as part of the Contract concluded with the successful Bidder (i.e. Seller in the Contract) as selected by the Buyer. Failure to do so may result in rejection of Bid. 1. Performance Guarantee. The L1 Bidder will be required to furnish a Performance Guarantee by way of Bank Guarantee through a public sector bank or a private sector bank authorised to conduct government business (ICICI Bank Ltd., Axis Bank Ltd or HDFC Bank Ltd.) for a sum equal to 10% of the estimated contract value within 30 days of signing of this contract. Performance Bank Guarantee will be valid up to 60 days beyond the date of expiry date of the proposed contract. The specimen of PBG is given in Form DPM-15, (Available in MoD website and can be provided on request). 2. Repeat Order Clause. The contract will have a Repeat Order Clause, wherein the Buyer can order up to 50% quantity of the items under the present contract within six months from the date of successful completion of contract, the cost, terms and conditions remaining the same. The Bidder is to confirm acceptance of this clause. It will be entirely the discretion of the Buyer to place the Repeat Order or not.

3. Tolerance Clause. To take care of changes in the requirement during the period starting from issue of RFP till placement of the contract, Buyer reserves the right to increase or decrease the quantity of the required goods/ customisation of the application up to ±10% without any change in the terms and conditions and prices quoted by the Seller. While awarding the contract, the quantity ordered/ customisation to application package can be increased or decreased by the Buyer within this tolerance limit.

4. Change Orders/ Alteration/ Variation. The Contractor agrees that the requirements given in specifications of the Bidding Documents are minimum requirements and are in no way exhaustive and guaranteed by IHQ MoD(N)/ DIT. It shall be the responsibility of the Contractor to meet all the requirements of Design criteria contained in the Bidding Documents and any upward revisions and/or additions of quantities, specifications, sizes given in Specifications and drawings etc. of the Bidding Documents required to be made during commissioning of the project shall not constitute a change order and shall be carried out without a change order and shall be carried out without any time and cost effect to the Indian Navy. Further upward revisions and or additions required to make Contractor’s selected Automation project space, facilities, equipment and installation procedures to meet Bidding Documents requirements expressed and to make entire facilities safe, operable and as per specified codes and standards shall not constitute a change order and shall be carried out without any time and cost effect to IHQ MoD(N)/ DIT. Any upward revision and/or additions consequent to errors, omissions, ambiguities, discrepancies in the specification and Drawings etc. of the Bidding Documents which the Contractor had not brought out to the IHQ MoD(N)/ DIT’s notice in his tender shall not constitute a change order and such upward revisions and/or



Page | 18

addition shall be carried out by Contractor without any time and cost effect to IHQ MoD(N)/ DIT. 5. Change Order. The change order will be initiated only in case:-

(a) DIT directs in writing the Contractor to include any addition to the scope of work covered under this Contract or delete any part of the scope of the work under the Contract (b) Contractor requests to delete any part of the work which will not adversely affect the operational capabilities of the facilities and if the deletions proposed are agreed to by IHQ MoD(N)/ DIT and for which cost and time benefits shall be passed on to IHQ MoD(N)/ DIT (c) IHQ MoD(N)/ DIT directs in writing the Contractor to incorporate changes or additions to the Design Criteria requirements already covered in the Contract.

6. Any changes required by IHQ MoD(N)/ DIT over and above the minimum requirements given in the specifications and drawings etc. included in the Bidding Documents before giving its approval to detailed design or Engineering for complying with design criteria and changes required to ensure systems compatibility and reliability for safe (As per codes, standards and recommended practices referred in the Bidding Documents) and trouble free operation shall not be construed to be change in the Scope of work under the Contract. 7. Any change order as stated above comprising an alteration which involves change in the cost of the works (which sort of alteration is hereinafter called a “Variation”) shall be the Subject of an amendment to the Contract by way of an increase or decrease in the Contract Price and adjustment of the implementation schedule if any. 8. If there is a different of opinion between the Contractor and IHQ MoD(N)/ DIT whether a particular work or part of the work constitutes a change order or not, the matter shall be handled in accordance with the procedures set forth in Clause under Procedures for Change Order. 9. Within fourteen (14) working days of receiving the comments from IHQ MoD(N)/ DIT or the drawings, specification, purchase requisitions and other documents submitted by the Contractor for approval, the Contractor shall respond in writing, which item(s) of the Comments is/are potential changes(s) in the “Scope of work” of the tender document covered in the Contract and shall advise a date by which change order (if applicable) will be submitted to IHQ MoD(N)/ DIT. 10. Procedures for Change Order. During detailed Engineering and subsequently, if the Contractor observes that any new requirement which other than that required for meeting the design criteria is not specific or intended by the Contract has been stipulated



Page | 19

by IHQ MoD(N)/ DIT, while approving the specifications, calculations, purchase requisitions, other documents etc. he would verbally discuss the matter with IHQ MoD(N)/ DIT’s representative. In case such requirement arises from the side of the contractor, he would also verbally discuss the matter with IHQ MoD(N)/ DIT representative giving reasons thereof. 11. In either of the two cases as explained in Clause above, the representatives of both the parties will discuss on the new requirement for better understanding and to mutually decide whether such requirement constitutes a change order or not. If it is mutually agreed that such Requirement constitutes a “Change Order” then a joint memorandum will be prepared and signed by the Contractor and IHQ MoD(N)/ DIT to confirm a “Change Order” and basic ideas of necessary agreed arrangement. 12. Upon completion of the study referred to above Clause the results of this study along with all relevant details including the estimated time and cost effect thereof with supporting documents would be submitted to IHQ MoD(N)/ DIT to enable the Indian Navy to give a final decision whether Contractor should proceed with the change order or not in the best interest of the works. The estimated cost and time impact indicated by Contractor shall be considered as a ceiling limit and shall be provisionally considered for taking a decision to implement change order. The time impact applicable to the Contract shall be mutually agreed, subsequently, on the basis of the detailed calculations supported with all relevant back up documents. In case Contractor fails to submit all necessary substantiation/ calculations and back up documents, the decision of the IHQ MoD(N)/ DIT regarding time and cost impact shall be final and binding on the Contractor. 13. If IHQ MoD(N)/ DIT accepts the implementation of the change order under Clause above in writing, which would be considered as change order, then Contractor shall commence to proceed with the relevant work stipulated in the change order pending final agreement between the parties with regard to adjustment of the Contract Price and the Construction Schedule. 14. In case, mutual agreement whether new requirement constitutes the change order or not, is not reached, then Contractor in the interest of the works, shall take up the implementation of the work, if advised in writing to do so by IHQ MoD(N)/ DIT representative pending settlement between the two parties to the effect whether such requirement constitutes a change order or not as per the terms and conditions of Contract documents. The time and cost effects in such a case shall be mutually verified and recorded. Should it establish that the said work constitutes a change order, the same shall be compensated taking into account the records kept in accordance with the Contract. 15. The Contractor shall submit necessary back up documents for the change order showing the break-up of the various elements (e.g. Centre Space facilities provisioning, Engineering, Procurement, Development, Installation, etc.) constituting the change order for IHQ MoD(N)/ DIT review. If no agreement is reached between IHQ MoD(N)/ DIT and Contractor within 60 days after IHQ MoD(N)/ DIT instruction in writing to carry out the



Page | 20

change concerning the increase or decrease in the Contract price and all other matters described above, either party may refer the dispute to arbitration. 16. Conditions for Extra Work/ Change Order. The provisions of the Contract shall apply to extra work performed as if the Extra work / Change order has been included in the original Scope of work. However, the Contract Price shall increase / decrease and the Time Schedule shall be adjusted on account of the Extra work / Change orders as may be mutually agreed in terms of provisions set forth in Clause above. Contractor’s obligations with respect to such work remain in accordance with the Contract. The rates provided by the Contractor as part of its commercial quote will be considered as benchmark rates for placing change orders, if any. 17. Payment Terms. It will be mandatory for the Bidders to indicate their bank account numbers and other relevant e-payment details so that payments could be made through ECS/ EFT mechanism instead of payment through cheques, wherever feasible. A copy of the model mandate form prescribed by RBI to be submitted by Bidders for receiving payments through ECS is at Form DPM-11 (Available in MoD website and can be given on request). The payment will be made as stage wise on production of the requisite documents. As per current practices, no advance payment is permissible. The payment terms for stage wise payment will be as under:-

S No Stage % of

Order Value

Remarks

For Delivery of Licences

(a) -- 100% 100% value of software licences on delivery.

Services (for all components other than software licences)

(a) First 20 %

Submission of SRS and preliminary design document. Based on the deliberations with users, vendor will prepare final design document. On approval of the final design document by the Navy, the user will issue a suitable certificate based on which the firm can claim the stage payment

(b) Second 15 %

Vendor will qualify to claim this stage payment on attainment of the following:- (i) Delivery, Testing and VA of the complete system. (ii) Migration of application to production environment. (ii) Commencement of Hand Holding Phase.

(c) Third 25 %

Vendor will qualify to claim this stage payment on attainment of the following:- (i) Complete acceptance of the application with full functionality. (ii) Delivery of all balance deliverables.



Page | 21

(iii) Imparting training of all types to all designated personnel. (iv) Delivery of all agreed documentation after it is duly approved by the user.

(d) Fourth 10%

Vendor will qualify to claim this stage payment on attainment of the following:- (i) Successful completion of hand holding period. (ii) Commencement of warranty period.

(e) Fifth 10% On successful completion of 1st year of Warranty.

(f) Sixth 10% On successful completion of 2nd year of Warranty.

(g) Seventh 10% On successful completion of 3rd year of Warranty.

18. Advance Payments. No advance payment(s) will be made. 19. Paying Authority. “PCDA-Mumbai” will be the Paying Authority. Payment of bills will be made on submission of the following documents by the Seller to the Paying Authority along with the bill:-

(i) Ink-signed copy of Contingent Bill / Sellers bill. (ii) Ink-signed copy of Commercial Invoice/ Sellers bill. (iii) Copy of Contract with U.O. number/ Copy of Supply Order and date of IFA’s concurrence, where required under delegation of powers. (iv) Claim for statutory and other levies to be supported with requisite documents/ proof of payment such as Excise duty challan, Customs duty clearance certificate, Octroi receipt, proof of payment for EPF/ ESIC contribution with nominal roll of beneficiaries, etc, if & as applicable. (v) Exemption certificate for Excise duty/ Customs duty, if applicable. (vi) Supply and Installation/ Acceptance certificate by the buyer. (vii) Bank guarantee for advance, if any. (viii) Performance Bank guarantee/ Indemnity bond where applicable. (ix) DP extension letter with CFA’s sanction, U.O. number and date of IFA’s concurrence, where required under delegation of powers, indicating whether extension is with or without LD. (x) Details for electronic payment viz Account holder’s name, Bank name, Branch name and address, Account type, Account number, IFSC code, MICR code (if these details are not incorporated in contract).



Page | 22

(xi) User Acceptance/ Job Completion/ Satisfactory work certificate by the Buyer.

20. Risk & Expense Clause

(a) Should the stores or any instalment thereof not be delivered within the time or times specified in the contract documents, or if defective delivery is made in respect of the stores or any instalment thereof, the Buyer shall after granting the Seller 45 days to cure the breach, be at liberty, without prejudice to the right to recover liquidated damages as a remedy for breach of contract, to declare the contract as cancelled either wholly or to the extent of such default. (b) Should the stores or any instalment thereof not perform in accordance with the specifications/ parameters provided by the Seller during the check proof tests to be done in the Buyer’s country, the Buyer shall be at liberty, without prejudice to any other remedies for breach of contract, to cancel the contract wholly or to the extent of such default. (c) In case of a material breach that was not remedied within 45 days, the Buyer shall, having given the right of first refusal to the Seller be at liberty to purchase, manufacture, or procure from any other source as he thinks fit, other stores of the same or similar description to make good:-

(i) Such default. (ii) In the event of the contract being wholly determined the balance of the stores remaining to be delivered there under.

(d) Any excess of the purchase price, cost of manufacturer, or value of any stores procured from any other supplier as the case may be, over the contract price appropriate to such default or balance shall be recoverable from the Seller. Such recoveries shall not exceed 10% of the value of the contract.”

21. Force Majeure

(a) Neither party shall bear responsibility for the complete or partial non-performance of any of its obligations (except for failure to pay any sum which has become due on account of receipt of goods under the provisions of the present contract), if the non-performance results from such Force Majeure circumstances as Flood, Fire, Earth Quake and other acts of God as well as War, Military operation, blockade, Acts or Actions of State Authorities or any other circumstances beyond the parties control that have arisen after the conclusion of the present contract.



Page | 23

(b) In such circumstances the time stipulated for the performance of an obligation under the present contract is extended correspondingly for the period of time of action of these circumstances and their consequences. (c) The party for which it becomes impossible to meet obligations under this contract due to Force Majeure conditions, is to notify in written form the other party of the beginning and cessation of the above circumstances immediately, but in any case not later than 10 (Ten) days from the moment of their beginning. (d) Certificate of a Chamber of Commerce (Commerce and Industry) or other competent authority or organization of the respective country shall be a sufficient proof of commencement and cessation of the above circumstances. (e) If the impossibility of complete or partial performance of an obligation lasts for more than 6 (six) months, either party hereto reserves the right to terminate the contract totally or partially upon giving prior written notice of 30 (thirty) days to the other party of the intention to terminate without any liability other than reimbursement on the terms provided in the agreement for the goods received.

22. Specification. The following Specification clause will form part of the contract placed on successful Bidder - The Seller guarantees to meet the specifications as per Part-II of RFP and to incorporate the modifications to the existing design configuration to meet the specific requirement of the Buyer Services as per modifications/ requirements recommended after the Maintenance Evaluation Trials. All technical literature and drawings shall be amended as the modifications by the Seller before supply to the Buyer. The Seller, in consultation with the Buyer, may carry out technical upgradation/ alterations in the design, drawings and specifications due to change in manufacturing procedures, indigenisation or obsolescence. This will, however, not in any way, adversely affect the end specifications of the equipment. Changes in technical details, drawings repair and maintenance techniques along with necessary tools as a result of upgradation/ alterations will be provided to the Buyer free of cost within 10 days of affecting such upgradation/ alterations.

23. OEM Certificate. In case the Bidder is not the OEM, the agreement certificate with the OEM for sourcing the items shall be mandatory. However, where OEMs do not exist, minor aggregates can be sourced from authorised vendors subject to quality certification. 24. Quality. The quality of the stores delivered according to the present Contract shall correspond to the technical conditions and standards valid for the deliveries of the same stores for in Seller’s country or specifications enumerated as per RFP and shall also include therein modification to the stores suggested by the Buyer. Such modifications will be mutually agreed to. The Seller confirms that the stores to be supplied under this Contract shall be new i.e. not manufactured before (Year of Contract), and shall incorporate all the latest improvements and modifications thereto and spares of improved



Page | 24

and modified equipment are backward integrated and interchangeable with same equipment supplied by the Seller in the past if any. The Seller shall supply an inter changeability certificate along with the changed part numbers wherein it should be mentioned that item would provide as much life as the original item. 25. Quality Assurance. The software would be tested, if required, by the buyer (or buyer designated agency) at the discretion of the Buyer. Separate security testing, including vulnerability assessment is required to be undertaken through CERT-IN empanelled vendors at the cost of vendor.

26. Inspection Authority. By the Consignee. The mode of Inspection will be Departmental Inspection / User Inspection / Joint Inspection / Self-certification.

27. Warranty. Warranty obligations of the Seller to the Buyer are enumerated as under:-

(a) Warranty for three years post completion of hand holding phase. Broad aspects are at Appendix ‘J’.

(b) Warranty shall be followed by Annual Maintenance Contract (AMC).

(c) The following activities on the part of the Seller shall constitute Warranty obligations:-

(i) Analysis and bug fixing on being notified by the Buyer. (ii) Enhancement/ modification within the scope of SRS. (iii) Provision of regular patches on physical media as clean single-step executable files.

(iv) Systematic training support with training artifacts and User Support Materials fully updated to reflect changes in software. (v) Regular presence/ availability of software engineers in reasonable time-frame for problem-solving

28. Product Support. The vendor will provide service support post acceptance of the software application for seven years for the customised product. The service support shall be provided under the following heads:-

(a) Hand holding. The vendor will provide hand holding for a period of six months. In this period he shall assist the user in implementation of application in optimum way. Firm would also undertake minor modifications as per user requirement and ensure 100% implementation of the software.



Page | 25

(b) Warranty. The vendor will provide warranty for three years on the developed system and customised product. The warranty on the product would commence on completion of the hand holding period post commissioning and acceptance of the project by Indian Navy. This warranty shall include the service support also. The service support shall comprise of technical support and on premise “help desk” services for the performance, functionality and operation of the Information System supplied. On receiving a complaint, the “help desk” will analyse the problem and call for relevant technical experts. It is to be noted that no remote access / remote logging will be allowed by the Navy to the vendor for the purpose of providing product support. (c) Annual Maintenance Contract. Post completion of the warranty period the application shall undergo AMC for a further period of three years as contracted and all the support shall be provided as per Sl (b) above. (d) Service Level Agreement. Vendor shall maintain 98% uptime for the application during warranty and AMC period. Any application down time would result in a penalty of 0.5% of payment due for every 1% downtime for a max of 10% calculated on six months basis. Thereafter Navy may consider short closing the project while initiating appropriate action against vendor towards black listing/ debarring from future contracts

(e) In the event of any obsolescence during the above mentioned period of product support in respect of any component or sub-system, mutual consultation between the Seller and Buyer will be undertaken to arrive at an acceptable solution including additional cost, if any. (f) Any improvement/ modification/ up gradation being undertaken by the Seller or their sub suppliers on the stores/equipment being purchased under the Contract will be communicated by the Seller to the Buyer and, if required by the Buyer, these will be carried out by the Seller at Buyer's cost.

29. Annual Maintenance Contract Clause. The following AMC clause will form part of the contract placed on successful Bidder:-

(a) The Seller would provide comprehensive AMC for a period of three years after completion of Warranty. AMC may be renewable annually at the discretion of the user. The AMC services should cover the repair and maintenance of all the applications and services purchased under the present Contract. The Buyer furnished equipment which is not covered under the purview of the AMC should be separately listed by the Seller.

(b) Response Time. The response time of the Seller should not exceed four hours from the time the breakdown intimation is provided by the Buyer.



Page | 26

(c) Serviceability of 98% per year is to be ensured. This amounts to total maximum downtime of seven days per year. Also un-serviceability should not exceed two days at one time. Required spares / hardware to attain this serviceability may be stored at site by the Seller at their own cost. Total down time would be calculated at the end of the year. If downtime exceeds permitted downtime, LD would be applicable for the delayed period. (d) Maximum repair turnaround time for equipment/system would be two days. However, the spares should be maintained in a serviceable condition to avoid complete breakdown of the equipment/system.

(e) Technical Documentation. All necessary changes in the documentation (Technical and Operators manual) for changes carried out on hardware and software of the equipment will be provided.

(f) During the AMC period, the Seller shall carry out all necessary servicing/ repairs to the equipment/ system under AMC at the current location of the equipment/ system. Prior permission of the Buyer would be required in case certain components/ sub systems are to be shifted out of location. On such occasions, before taking over the goods or components, the Seller will give suitable bank guarantee to the Buyer to cover the estimated current value of item being taken.

(g) The Buyer reserves its right to terminate the AMC contract at any time without assigning any reason after giving a notice of one months. The Seller will not be entitled to claim any compensation against such termination. However, while terminating the contract, if any payment is due to the Seller for maintenance services already performed in terms of the contract, the same would be paid to it as per the contract terms. (h) Rate and modalities for AMC will be quoted and negotiated as part of the initial offer and will not be left for subsequent negotiation. AMC rates will be considered for determination of L1 firm. However, concluding contract for AMC is at the sole discretion of buyer.

(j) 10% of AMC cost would be deposited to IHQMoD(Navy)/DIT as performance bank guaranty at the time of AMC contract.

(k) Additional clauses for AMC, if any, will be worked out between vendor and IHQMoD(Navy)/DIT.

30. Placement of Order. The Purchase orders will be placed on L1 firm.



Page | 27

PART V – EVALUATION CRITERIA & PRICE BID ISSUES

1. Evaluation Criteria. The broad guidelines for evaluation of Bids will be as follows:-

(a) Only those Bids will be evaluated which are found to be fulfilling all the eligibility and qualifying requirements of the RFP, both technically and commercially. (b) The technical Bids forwarded by the Bidders will be evaluated by the Buyer with reference to the technical characteristics of the equipment as mentioned in the RFP. The compliance of Technical Bids would be determined on the basis of the parameters specified in the RFP and Notice Inviting Tenders published in newspaper. The Price Bids of only those Bidders will be opened whose Technical Bids would clear the technical evaluation. (c) The Lowest Bid will be decided upon the lowest price quoted by the particular Bidder as per the Price Format given at Para 2 below. The consideration of taxes and duties in evaluation process will include all taxes and duties (including those for which exemption certificates are issued) quoted by the Bidders. The ultimate cost to the Buyer would be the deciding factor for ranking of Bids.

(d) The Bidders are required to spell out the rates of Customs duty, Excise duty, VAT, Service Tax, etc in unambiguous terms; otherwise their offers will be loaded with the maximum rates of duties and taxes for the purpose of comparison of prices. If reimbursement of Customs duty / Excise Duty / VAT is intended as extra, over the quoted prices, the Bidder must specifically say so. In the absence of any such stipulation it will be presumed that the prices quoted are firm and final and no claim on account of such duties will be entrained after the opening of tenders. If a Bidder chooses to quote a price inclusive of any duty and does not confirm inclusive of such duty so included is firm and final, he should clearly indicate the rate of such duty and quantum of excise duty included in the price. Failure to do so may result in ignoring of such offers summarily. If a Bidder is exempted from payment of Customs duty / Excise Duty / VAT duty up to any value of supplies from them, they should clearly state that no excise duty will be charged by them up to the limit of exemption which they may have. If any concession is available in regard to rate/quantum of Customs duty / Excise Duty / VAT, it should be brought out clearly. Stipulations like, excise duty was presently not applicable but the same will be charged if it becomes leviable later on, will not be accepted unless in such cases it is clearly stated by a Bidder that excise duty will not be charged by him even if the same becomes applicable later on. In respect of the Bidders who fail to comply with this requirement, their quoted prices shall be loaded with the quantum of excise duty which is normally applicable on the item in question for the purpose of comparing their prices with other Bidders. The same logic applies to Customs duty and VAT also.



Page | 28

(e) If there is a discrepancy between the unit price and the total price that is obtained by multiplying the unit price and quantity, the unit price will prevail and the total price will be corrected. If there is a discrepancy between words and figures, the amount in words will prevail for calculation of price. (f) The Lowest Acceptable Bid will be considered further for placement of contract / Supply Order after complete clarification and price negotiations as decided by the Buyer. The Buyer will have the right to award contracts to different Bidders for being lowest in particular items. The Buyer also reserves the right to do Apportionment of Quantity, if it is convinced that Lowest Bidder is not in a position to supply full quantity in stipulated time. (g) Any other criteria as applicable to suit a particular case.

2. Price Bid Format. The Price Bid Format is placed at Appendix ‘K’. Bidders are required to fill this up correctly with full details.



Page | 29

Appendix ‘A’ (Refers to Para 12 Part I of RFP)

EMD Bank Guarantee Format

Whereas ……………………………........……… (hereinafter called the “Bidder”) has submitted their offer dated…………..……2014 for the supply of ‘Microsoft Product Licenses under Select Plus Agreement between Indian Navy and M/s Microsoft Ltd’ (hereinafter called the “Bid”) against the Buyer’s Request for proposal No. IT/0631/19 dated ............. 2014 KNOW ALL MEN by these presents that WE ………………................……………of …………………………………………….. having our registered office at …...............………… ……………………………………………. are bound unto ...………………. (hereinafter called the “Buyer) in the sum of …….............................................................................……………… ………………………………………………………for which payment will and truly to be made to the said Buyer, the Bank binds itself, its successors and assigns by these presents. Sealed with the Common Seal of the said Bank this…………… day of …………….2014. The conditions of obligations are –

(1) If the Bidder withdraws or amends, impairs or derogates from the Bid in any respect within the period of validity of this tender. (2) If the Bidder having been notified of the acceptance of his tender by the Buyer during the period of its validity.

(a) If the Bidder fails to furnish the Performance Security for the due performance of the contract. (b) Fails or refuses to accept/ execute the contract.

WE undertake to pay the Buyer up to the above amount upon receipt of its first written

demand, without the Buyer having to substantiate its demand, provided that in its demand the Buyer will note that the amount claimed by it is due to it owing to the occurrence of one or both the two conditions, specifying the occurred condition or conditions. This guarantee will remain in force up to and including 45 days after the period of tender validity and any demand in respect thereof should reach the Bank not later than the above date.……………………………. (Signature of the authorized officer of the Bank) Name and designation of the officer Seal, name & address of the Bank and address of the Branch



Page | 30

Appendix ‘B’ (Refers to Para 2(a) of Part-II of RFP)

SCOPE OF PAPERLESS OFFICE SOLUTION FOR INDIAN NAVY

Introduction 1. Indian Navy (IN) is the premier arm of the Indian Armed Forces and has been the pioneer Service in terms of adopting new IT technologies for improving efficiency and effectiveness of processes. From its humble beginnings in the last decade of 20th Century, the IN can today boast of almost universal IT penetration including its floating platforms. The Navy Enterprise Wide Network (NEWN), with a backbone of 34 Mbps, provides a highly reliable end to end connectivity for units ashore as well as afloat. 2. Pursuit of excellence towards achieving highest standards of efficiency in the IN has seen implementation of many enterprise wide E-Governance initiatives such as for financial, material and HR management. Directorate of Information Technology, Integrated Headquarters of Ministry of Defence (Navy) is the nodal agency for implementation of IT projects in the Indian Navy. 3. In government organisational context, the information plays a vital role and it is important to stream line the flow of data inside the organisation. The Indian Navy feels the need to give a structure to the data flow so that it is available when required for better management. Accordingly IHQ MoD(N)/ DIT is implementing Knowledge Management Processes in major departments and organisation which is the set of processes and practices which helps people in an organisation to act efficiently and effectively by providing ready access to its accumulated experience including much of what is known but not documented. Continuing to move in this direction, DIT has decided to initiate the office automation across the Indian Navy for all offices spread across the nation with respect to File Movement and tracking, Mail Movement and tracking, Office Note Approval, Movement and tracking, and Circular Management. Additionally, the agency has also envisioned the use of IT to digitise and archive the files, mails, letters, notes, Circulars, etc. in a Document Management System. 4. High volume of establishment work, multiple levels of processing, difficulty in monitoring actions or activities, loss of instructions and approvals, a large file base for clearance, delay in decision making, and so on are problems faced by the IN today. The IN desires to implement an effective Paperless Office Solution that aims at increasing the organisational efficiency by instituting better administrative processes and reducing the time/ cost involved in paper based transactions. The project is envisaged for all units of the Indian Navy spread across the nation, in phases, and shall start with pilot implementation in IHQ MoD(N) at New Delhi. On the successful completion of the Pilot project, the solution will be rolled out in all other Command Headquarters and other units in phases.



Page | 31

5. The IN’s apex Headquarter at New Delhi, IHQ MoD(N), has approximately 90 Directorates (Dte) and Secretariats (Sectt). While most Dte’s and Sectt’s are located at Sena Bhawan, other units are spread over a wide geographical area connected over LAN/CAN/MAN. Presently, the official communication/ correspondence takes place by faxes, letters, inter departmental notes (SMS), files etc. (Herein after referred as Documents). Drawbacks of the present document handling are as follows:-

(a) Delay due to physical file movement. Movement of correspondences/ file is manpower intensive and time consuming and results delays. (b) Consumes considerable amount of stationery, printer and storage resources etc. (c) Archival, retrieval of file/ document is extremely difficult.

Existing Process - Documents/ File Transactions at IHQ MOD (N) 6. Within the Directorate

(a) Incoming Mail. Documents within a Directorate/ Secretariat are received at ‘Coordination/ Mail section’. Details of documents are entered in File Management System (FMS), a bar coded electronic file/ document tracking system, and then the documents are put up for review of the Principal Director/ Head of Department (PD/ HOD) by the Staff Officer/ Coord section. PD/ HOD appends his comments/ directives on the document during the review, to be executed by his subordinates. The whole set of documents are then put up for Director(s) review. The Director then appends his comments/remarks for the Joint Director who is to take action on that particular document. In essence, every document flows top down from the Head of Department/ Organisation to the actual action addressee. During the process, notes/ comments/ directives on actions to be taken are passed down to the action addressee. There can be one or more levels from the Head of Department/ Organisation to the action addressee depending upon the organisation and staffing for a Directorate/ Department. Typical actions on an incoming document include:- (i) File it in the relevant file. (ii) Initiate a new file on the subject.

(iii) In case of file belonging to other Directorate/ Unit, provide comments and despatch.

(b) Outgoing Mail. Joint Director/ Deputy Director or the action addressee prepares draft reply/ draft comment for review of the Director who makes appropriate changes in the document, or returns the draft document for



Page | 32

amendment by the originator. Once the draft is cleared by the Director, the letter is put up for Principal Director’s review. Principal Director may return the draft with observations or approve the document for dispatch. Finalisation of a document within a Dte may involve multiple iterations of the draft document till it is finalised. The final document may be signed and released by any of the officers within the Dte, and in all cases, the final document after clearance is put up to the next higher authority for perusal and confirmation of dispatch. Approved documents are finally routed through the Coord Section of the Directorate for dispatch. There may be one or more levels of review before the document is cleared for dispatch to APSO.

Note. A document may move vertically as shown above or may also move horizontally for remarks/ clarifications etc by other Dte’s or Sectt’s. Sometimes, multiple copies of the document may be sent to many Dte’s or Sectt’s in parallel to speed up information collation process. 7. Within a Secretariat. A similar process as outlined at Para 6 above is followed for creation and approval of a document prior dispatch. The only difference is that an

DDs

JDs

Director

PDs

APSOs

PSOs

CNS

Review Comments/ Take Action

Give Inputs as per Comments

If not recommended back to Dir. for

further justification

If not approved back to PD for


Check/Add inputs to Draft File

Create Draft Document

Check Final Version & Recommend/ Not Recommend

Check/Add Inputs & Forward

Approve/ Return or Forward to PSO

Approve/ Return or Forward to CNS/ MoD

If not approved back to APSO for


If not approved back to PSO for


Directo

rate

Se

cre

taria

t

Bra

nch



Page | 33

additional authority who is the Asst. Principal Staff Officer (APSO), controlling the Secretariat is added at the top of the chain for vetting / clearance of a document prior dispatch. 8. Within a Branch. Documents that necessitate review at PSO level are forwarded to concerned PSO post recommendation of APSO and a similar process as above is followed. Further, documents meriting attention of CNS are marked to him. At the level of APSO, PSO or CNS and other higher authorities, documents are first reviewed by their Staff Officer, Technical Assistant or Naval Assistant and put up to the APSO, PSO or CNS along with recommendations. 9. External Agencies. Documents may also be routed to external agencies such as the Integrated Financial Advisors (IFA’s) and/ or Ministry of Defence (MoD).

Proposed Solution 10. Technology. The system is to be developed in n-Tier (minimum three), Web enabled component based architecture accessible through any browser on the client using reputed back end databases. The framework should consist of reputed Enterprise Document Management System (DMS) and Business Process Management (BPM) solution for creating, managing delivering and archiving large volumes of documents and contents. There should be provision to encrypt the documents with algorithm provided with third party / proprietary security overlay. 11. The development process should follow SDLC standards and agile development methodology. The phase wise implementation schedule and the deliverables at each stage are given in Annexure I & II of Appendix ‘B’. Scope of Work 12. The selected bidder shall supply, Install and maintain “Paperless Office for Indian Navy” for a minimum period of three years (post hand holding phase) from the date of successful completion of Acceptance Test (AT) in Phase I. The minimum specified work to be undertaken by the bidder for setting up and operating automation project has been categorised as under:-

(a) Provisioning for Process Management, Digital Workflow Automation and Enterprise Document Management Software. (b) Implementation Services (c) Maintenance and support for at least three years

13. The proposed software package/ application will be a common platform for all the Dtes / Sectts located at IHQMoD(N)/ New Delhi, outlying units and other units of Indian



Page | 34

Navy. Post successful implementation at New Delhi, the Indian Navy will look to extend the solution to all units and platforms across the Navy. Modalities, procedure and pricing for roll out beyond New Delhi in subsequent phases will be treated as a separate project. However, the application has to be designed with adequate flexibility to meet requirements of all kinds of organisations in the Indian Navy. The exact requirement has to be studied during the system study phase as defined later. 14. Implementation of Paperless Office Navy wide (including the present and future projects) would entail a total user base of approximately 20000 users (minimum 4000 concurrent users). The scope of implementation in the present project will include all Directorates and Units at IHQ MoD(N) at New Delhi as detailed above for a user base approximately 2000 users (minimum 400 concurrent users). 15. Indian Navy intends to implement a centralised comprehensive Office Automation Solution for the Directorates/ Secretariat and Offices at Integrated Headquarters, Ministry of Defence (Navy) at New Delhi. The scope envisages a complete turnkey solution which may inter-alia include procurement, system software, application software, third party software and customisation, parameterisation and implementation of the application software and system integration with training to the designated personnel. 16. DIT/ IHQ MoD(N) intends to implement State-of-the-art technology solutions that would support all the current and future automation needs of the Indian Navy as described below:-

(a) Provide centralised application software for office automation covering File Movement and Tracking, Document movement and tracking, Office Notes movement and tracking, various operational reports, etc. (b) Customise the solution as per Indian Navy’s requirements. (c) Procure the necessary system software and other third party software required for implementation of the solution. (d) Procurement/ supply, installation, integration, implementation and maintenance of necessary application software at IHQ MoD(N), New Delhi. (e) Implement and maintain (including Updates and upgrades) the application software during the period of Warranty and AMC. (f) Development of New Modules for the application software as and when required. (g) Implement a Help Desk cum support centre for onsite support services for a period of three years.



Page | 35

17. The vendor shall be required to take care of the following:-

(a) Undertake requirement/ GAP Analysis, customisation and installation of existing/ customised integrated product as per the needs of the Indian Navy including the offices at Sena Bhavan and other outlying units for a minimum ‘concurrent user base of 400’. (b) The IHQ MoD(N) comprises of approximately 90 Directorates and outlying units covering approximately 2000 users (400 concurrent users) across all offices are expected to use the solution immediately. (c) Undertake hardware sizing and indicate the minimum and recommended hardware requirement for implementing the project. (d) Study the existing system and suggest necessary re-engineering of the processes so as to enable adoption of the product/ solution proposed. (e) Supply of Installation Manual, Administration Manual and User Reference/Training Manual. (f) Define overall training requirements and preparation of the training plan. (g) Conduct project specific training for users in the customised software.

18. Supply/ Installation. The scope includes following:-

(a) The selected bidder shall procure, supply and install the application. (b) Software components required for successfully running the solution should be latest and the licences should be Perpetual in nature. (c) Application Software as per required specifications. (d) Installation shall mean to install, configure and integrate every component and subsystem component, required for functioning of the solution, integration with IT infrastructure consisting of Computer, Printers, Scanners, etc. for end users of the system. IHQ MoD(N) comprises of 90 directorates, mainly co-located in the Sena Bhavan and South Block. (e) Suggest and implement suitable central scanning mechanism for documents and implement it. (f) Configuration and integration on Navy Enterprise Wide Network (NEWN) (already existing).



Page | 36

19. Help Desk Services. The successful bidder will provide help desk service which will serve as a single point of contact for all solution related incidents and service requests. The service will provide a Single Point of Contact (SPOC) and also resolution of incidents. The scope of work includes:-

(a) Help Desk facility for reporting issues / problems with the IT infrastructure. (b) To implement a call logging system in line with the severity levels as mentioned in the SLA. (c) The Help Desk shall undertake the following activities:-

(i) Log issues / complaints related to IT under the scope of work and issue an ID number against the issue / complaint. (ii) Assign severity level to each issue / complaint. (iii) Track each issue / complaint to resolution. (iv) Escalate the issues/ complaints, to department if necessary as per the escalation matrix defined in discussion with IHQ MoD(N)/ DIT. (v) Provide feedback to the callers. (vi) Analyze the issue / complaint statistics. (vii) Creation of knowledge base on frequently asked questions to aid the users of this solution

20. Functional Requirement. The application seeks to achieve a set of objectives like increasing efficiency and effectiveness of the processes, employee productivity, efficient management of data, information & knowledge within the Indian navy, better communication & co-ordination and advancement towards knowledge-led organisation. The proposed solution shall be the backbone of Work Automation System on which the functionalities are built. It covers functionalities such as Correspondence / File Creation, File Approval / Rejection, Draft creation, Notings etc. A suggestive list of various important features is provided below:-

(a) Knowledge Management. The Knowledge Management shall enable the Indian Navy to store scanned documents, manage and deploy all type of documents, including HTML, graphics, multimedia and traditional documents created. It shall consists of a repository for documents and a set of applications and interfaces to manipulate the information related to the documents e.g. date of publish, description etc. It shall have provision for storing and managing the documents that are created and processed during file movement across various



Page | 37

levels. Any document can be searched on the basis of its name, description, publish date, etc. Searching within a document should also be possible for various text files (.doc, .txt, .pdf, etc.)

(b) File Management. The File Management shall be automated to cater to the file processing requirements of the Indian Navy. It shall ensure that files dealing with any subject in any directorate/ department are processed in a similar manner. This includes Creating Inward/Outward, Creating File and moving it, Monitoring File and Tracking, Generating Order and Maintaining record room for Files and Correspondences. The proposed system should provide all features of the Whitehall filing system being followed in the Indian Navy. Please refer to Manual of Office Procedure issued by Ministry of Personnel, Public Grievances and Pensions Department of Administrative Reforms for guidelines.

(c) Document Management. The Document Management shall have provision to track life cycle of business objects, Creation of Logical Folders by subject/ project etc, organisation of the documents into these folders, Indexing of the Documents – by date, by subject, by sub subject codes, Association of Keywords to the files – Content, Subject Codes etc. (d) Workflow/ Organisation Module. The Workflow/ Organisation Module shall contain the organisation structure of Departments / Divisions / Sections in the IHQ MoD(N). It contains the hierarchy of people in the Department, their roles, reporting relations, the subjects they deal with and the sections they belong to. Organisation Model shall be the heart of the organisation and will be used by multiple subsystems. Bidders are expected to study on their own and bid for the project. (e) Access Controls. The Access Controls shall provide controls for work processing at user level, subject level, designation level, field level and ensure that only the relevant information at the relevant level is available to relevant users at relevant times.

(f) Dashboard. There should be a provision for Dashboard providing a proactive Executive Information System in the form of visual alerts. The threshold for the alerts can be personalised according to the user’s preference. This is mainly provided for the senior officers for monitoring the health of the department and taking proactive action on appropriate time.

(g) MIS. MIS shall present the analysis of day-to-day activities of a Directorate such as files, correspondences on various dimensions such as time period, Directorate/ division/ section, subject, person, etc. Reports can be generated which help in measuring the efficiency in the file disposal and tracking the productivity. Real Time reporting is required, as per RFP.



Page | 38

(h) User Interface. The proposed system components should be simple to use. The total set of functionalities must be uniform in their User interface, being consistent in their use and meaning of keystrokes and sequences and in their visual presentations to the User. The User interface should be graphical (i.e. GUI) in nature. (j) Personalisation. Users of the system should be able to organise the Knowledge Bank with personal requirements for information delivery. The System should provide an online Dashboard, which enables monitoring of work related to their Sections/Directorates. Users should also be able to organise their Dashboard with personal requirements and indicators for information statistics. All the applications should be logically grouped so as to enable access to the relevant group of users.

(k) System Requirement Study and Design. The vendor will undertake in depth study of existing procedures of handling documents at nominated Dtes / Sectts. of IHQ MOD (N), units at Delhi and at three Naval Commands at Mumbai, Visakhapatnam and Kochi (at least 10 in number). The vendor is to use Graphical Use Case to demonstrate work processes graphically to the user and take his Approval before getting into the design phase. The SRS is to be signed and approved by each Dte / Sect./ Unit for the processes / procedures being followed by them. (l) Technical Requirement

(i) The creation, numbering and closure of files are proposed to be handled centrally for the entire Sena Bhavan. Certain aspects of security, access permissions etc. are also proposed to be managed centrally / commonly. (ii) Entire management of user ids, security, permissions, etc shall be handled centrally from the helpdesk.

(iii) The solution shall be based on Single and Royalty-Free (RF) Open Standard using Fair, Reasonable and Non Discriminatory terms and conditions (FRAND) as per GoI policy on Open Standards for e-Governance. (iv) The system should be completely scalable both horizontally and vertically to accommodate the changing user numbers and data volumes. The workflows for movement of documents and files within the system should have flexibility in terms of customisation vertically and horizontally. (v) Should be on web based multi-tiered architecture.



Page | 39

(vi) Scalable architecture to support clustering at each layer i.e., Web Server, Application Server and Database for fault tolerance & load balancing. (vii) Should have been built on a J2EE, .Net based or equivalent approach. (viii) Support for interoperability with cross platforms specifically (Windows, Linux and Unix, Sun Solaris), Databases and Web Servers. (ix) Interfaces with popular office software like MS Office, Libre Office and Open Office. (x) The system should support SSL, TLS etc. (xi) Support the Digital Certificates as per IT Act of India, 2000. (xii) A single sign-on to the application should provide basic access to the fundamental functionalities, namely document management system, workflow management system, knowledge management system, file management system, collaboration tools like discussion forum, dashboard, etc. (xiii) The product should support integration with existing e-mail (MS Exchange 2010), Active Directory (Windows Server 2012) and fax integration. (xiv) Support Alert Mechanisms (Reminders, Notifications), Escalation Mechanisms (Flexible routing of files, Calling back the files by the superior) etc. (xv) Be User Friendly and support Drop Down List for most of the fields, Single window for interacting with the application. (xvi) Provide support for biometric based access.

(m) Application Package Development. The vendor is to develop an application package consisting of different modules to automate activities / procedures in respect of handing of documents / files followed at IHQ MOD (N) as given under :-

(i) Document Capture. Scanning Services for the entire contract period is to be provided by the vendor. Digitisation needs will be performed at IHQ MOD (N), New Delhi. Successful bidder is to deploy full-fledged scanning teams at this location to carryout digitisation activities. Uploading



Page | 40

of digitised contents will be at a central Document Management server. Space, electricity, furniture, computers and network infrastructure for four workstations will be provided by Indian Navy. Any other requirement like manpower, scanners, which is required for the execution of the scanning activity shall be provided by the successful bidder. (ii) The details on quantum of documents, sizes and the methodology required for each type of document capture are given at Annexure III to Appendix ‘B’. Please refer technical compliance section Annexure I to Appendix ‘C’ for Technical and Functional scope for Document capture. (iii) Document Management. Please refer to technical compliance section (Annexure I to Appendix ‘C’) for detailed scope. (iv) Business Process Management. Business Processes workflow engine is one of the key components of the application framework wherein all the document process / procedures will be modelled, developed and implemented. Please refer technical compliance section (Annexure I to Appendix ‘C’) for detailed scope.

(v) The Indian Navy may have digitised versions of older documents that are available in PDF format along with metadata in a database. The system should provide means to seamlessly import these existing documents along with their metadata into the proposed system. Details of the existing archived document will be shared with the L1 vendor.

21. Non Functional Requirements

(a) Security. The solution must provide end-to-end security model that protects applications, services, data and the infrastructure from malicious attacks or theft from both external and internal users. The solution should allow features for storing data in encrypted format in the database. The solution should provide fine grained authorisation and access control mechanisms to ensure that sensitive and confidential information is not accessible to unauthorised persons. Please refer Annexure IV to Appendix ‘B’ for detailed security requirements. (b) Performance. The database should be normalised to the required level (up to three) in order to achieve a response time of max five seconds and should not exceed 8 seconds any case per transaction per table and should not exceed 10 seconds for generating any reports. The scanned documents should also open within 5 secs of request generated. (c) Availability. All the components of the application must be available during office working hours with 98% uptime. However, the system should have provision for working during non working hours or when network connectivity is not available



Page | 41

- Offline Mode and syncing data at the time of regaining connectivity with the central server. (d) Scalability. The architecture should be highly scalable and capable of delivering high-performance with the increase in data volumes as well as increase in user base. It is required that all the applications and deployment architecture should provide for Scale-Up and Scale out on the Application Server, Web Server and Database Server. The platform of the proposed application must conform to interoperability standards without using any virtualization software. The Bidder should ensure that the DMS and BPM components of the proposed solution shall be scalable and interoperable for future growth of data. (e) Backup and Recovery. It is required to implement the Storage Solution to address the Data backup / storage and retrieval requirements of the Project. A disaster recovery site will be configured on the hardware to be provided by the Buyer. (f) Extension/ Flexibility. Extensibility/ Flexibility encompasses the ease of extending the architecture to include new functions and technologies in future. (g) Portability. System will be developed using industry standards frameworks/ open standards that will facilitate the coexistence and inter-changeability of multiple hardware and software technologies, tools, protocols, and interfaces. System should also support data to be exported / imported in XML format. (h) Interoperability. System should support the application/data/ information level integration with other Service Headquarters and Ministry of Defence based on business requirements. The solution should support integration with heterogeneous environments/platforms being used in other services. The software should meet both internal and external agencies’ need of exchanging Data / reports which are already catered and included to be catered electronically in XML format either online or using a media. It should enable seamless integration with other enterprise. The application package should provide complete documentation for required Application Programming Interfaces (APIs) for all Commercial Software to be integrated in the solution. (j) Licensing. Indian Navy will ultimately deploy the application developed across all units of the Indian Navy in phases. This includes ships and submarines that may or may not be connected to the central servers at all times. Thus, there may be a requirement to deploy the solution at a large number of places. The licensing of the application software shall be such that once procured, the application can be deployed at any number of locations. However, Indian Navy will procure the required number of named/ concurrent user licences.



Page | 42

(k) Testing. Software will be developed at the vendor location using resources of the Vendor. Testing will be carried out right from requirement gathering stage and the reports will be submitted to the Project Implementation Team (PIT). The software may also be tested (including Code Review) at any independent software testing agencies to confirm technical requirements including performance, security and reliability. Testing shall include ease of installation, user friendliness, management & security and coding methodology besides adherence to the functional requirements in the SRS. Getting the developed software tested will be the responsibility of the Vendor. It will be tested by CERT-IN empanelled vendor for vulnerability assessment. No remote testing of SW under development will be done on the internet. Acceptance after testing of each phase/ iteration will be given by PIT. (l) Parallel Run. A parallel run of manual and automated systems for a minimum duration of two months is required during implementation of the project.

22. Hardware Requirement. Hardware will be provided by the Buyer. All bidders are required to carry out hardware sizing for the required concurrent users mentioned above and provided minimum as well as recommended hardware requirement for implementing the project. 23. User Management. User authentication will be carried out from the Active Directory (LDAP) on Windows Server 2012. User Management for authorised roles and access/ rights management shall be done centrally for all application by the respective Administrators in each Dte / Sectt. through the Active Directory of Naval Unified Domain. Scope of Work – Latter Phases 24. Post completion of implementation at New Delhi, roll out for three Naval Command Headquarters at Mumbai, Visakhapatnam & Kochi followed by all other naval units shall be taken up separately. This may be a continuation of the present project or a fresh project, depending upon the circumstances.



Page | 43

Annexure I to Appendix ‘B’ (Refers to Para 11 of Appendix ‘B’)

IMPLEMENTATION SCHEDULE

1. Implementation at IHQ MoD(N) shall take place over three parts each consisting of two stages. The package shall be first tested and implemented at DIT and other nominated Directorates. Each stage have a finite number of steps. Implementation of each step would cover all activities from software delivery, user training, migration of data and testing of functionalities at IHQ MOD (N) as per SRS. 2. Each construction iteration shall culminate in the delivery of a build of software with required documentation. Part I – Applications/ Software Development for Common Functionalities & Customisation 3. Stage I - Inception Stage. This has the following steps spread over eight weeks (D is the date of supply order):-

Activity Time Required (Weeks)

Total Time (Weeks)

Presentation of plans by Project Manager (Vendor)

Two weeks from the date of supply order

D + 2

Study of Workflow and various functionalities of all Directorates of IHQ MOD (N), units at Delhi and three Commands at Mumbai, Visakhapatnam and Kochi. Analysis of existing procedures and Identify and suggest business process re-engineering for better functioning. Definition, validation and base lining of architecture. Review and acceptance of deliverables of.

One month D + 6

Review and acceptance of deliverables of Inception Stage by PIT.

Two Weeks D + 8

4. Stage II. This phase has the following three stages spread over 13 weeks as under:-



Page | 44

(a) Construction Stage. This has two Iterations. L Day is the date of acceptance of Inception Stage deliverables or D + 8 weeks, whichever is later.

(i) First Iteration


Total Time (Weeks)

Study and baseline requirements for 1st Iteration and sign off baseline documents.

One week

L + 1

Develop and deploy 1st Iteration Six Weeks L + 7 (to be deployed at DIT)

Testing and acceptance of 1st Iteration

One Week L + 8

(ii) Second Iteration. M Day is the date for acceptance of First Iteration deliverables or L + 8, whichever is later.


Total Time (Weeks)

Study and baseline requirements for 2nd Iteration and sign off baseline documents

One week

M+ 1

Develop and deploy 2ndIteration Three Weeks M+4 (at DIT and nominated Directorates)

Testing and acceptance of 2nd Iteration

One Week M+5



Page | 45

Part II – Roll out in all Directorates

5. Implementation Stage. P Day is the date of acceptance of Second Iteration deliverables or M + 5, whichever is later.


Total Time (Weeks)

Incorporate changes from 2nd Iteration, refining and finalization of URS, sign off

One week

P + 1

Deploy application at all Directorates / Sectt.) Conduct user training

Four weeks P + 5 (at all Dtes and Sectt.)

6. Parallel Run Stage. Q Day is the date for commencement of Parallel Run of software at all Directorates of IHQ MOD (N), or P+5, whichever is later.


Total Time (Weeks)

Parallel Run at all components of IHQ(N).

Eight Weeks Q + 8



Page | 46

Part III -Acceptance of Project 7. Final Release Stage. R Day is the date of commencement of release of the final version of the software package to all Dtes / Sectt. or Q + 8, whichever is later.


Total Time (Weeks)

Rectification of problems and enhancements identified by users

Three weeks

R + 3

Porting of Final Release One Week R + 4

Acceptance Testing Three Weeks R + 7

Review of test results and fine-tuning

Two Weeks R + 9

Delivery of revised software package with revised WBT and User Manual to all Dtes and Sectts..

Two Weeks R + 11 (date of issue of Final Acceptance Certificate)

Total – 45 weeks from placement of order



Page | 47

Annexure II of Appendix ‘B’ (Refers to Para 11 of Appendix ‘B’)

METHODOLOGY FOR EXECUTION OF SOFTWARE PACKAGE FOR AUTOMATION OF INDIAN NAVY

1. The project shall be executed using a suitable software development process, mutually acceptable to the BUYER and the VENDOR. Prospective vendors are expected to make a presentation to the Technical Evaluation Committee (TEC) on the methodology to be followed by them at the time of evaluation of technical bids. 2. Guidelines for tailoring of software development process are given in the succeeding paragraphs. These guidelines are by no means exhaustive by themselves, but are meant to convey the methodology as thought of by the project Implementation Team (PIT). It is recommended that the prospective vendors tailor the software development process to a maturity level that refines the iteration method of design to include regular feedback loops. These loops enable the continuous evolution of software and related deliverables, while building in traceability and consistency across all phases of implementation. Tools not held with the Navy may be provided for the duration of the project by the vendor by means of a client installation free of cost.

3. Development of application package for users at IHQ MoD (N), will have the following stages during Part I – Applications / Software development for Common functionalities & Customisation:-

(a) Stage I

(i) Inception Stage. The aim of this stage is to crystallize the lifecycle objectives of Software Package by involving all stakeholders. This stage will have following objectives :-

(aa) Establishment of detailed scope of the project, with finalization of operational vision (SRS). (ab) Identifying potential risks. (ac) Identifying a suitable architecture for the package.

(ii) Essential Activities of Inception Stage. These are as follows :-

(aa) Study & Analysis. SRS will be evolved by study and design of functional requirement at the nominated Directorates / Secretariats forming are presentative sample with a view to



Page | 48

comprehensively identify technical and business imperatives for an integrated application to cover all aspects of functioning. (ab) Outlining of Potential Risks. This involves identification of all potential risk and evaluating risk management alternatives. (ac) Acceptance Criteria. This includes capturing of the most critical requirements/ constraints to formulate Acceptance Criteria for the end product. (ad) Preparation of Business Case. Drawing up the project plan and schedules.

(iii) Inception Stage Objectives. At the end of the Inception Stage, the following objectives are expected to be met :-

(aa) Concurrence amongst stakeholders on definition of scope and schedule of implementation. (ab) Agreement on the adequacy of requirements capture and the understanding of requirements. (ac) Agreement on the appropriateness of schedule estimates, priorities and identification of risks. (ad) Agreement on mitigation strategies for identified risks.

(iv) Deliverables at end of Inception Stage

(aa) Vision Document. Listing out of core requirements, key features and main constraints. (ab) Risk List. Listing out of initially identified project risks. (ac) Software Development Plan. Listing out of phases, durations, objectives. Draft Acceptance Plan is also to be drawn up. (ad) Iteration Plan. To be drawn up as reviewed. (ae) Development Process. Adaptations and extensions to RUP/ equivalent development process, to include project-specific guidelines and the Software Development Plan to include development process.



Page | 49

(af) Development Infrastructure. Listing of all tools required to support the project and their installation. (ag) Glossary. Definition of important terms.

(v) Elaboration Stage. The baseline architecture for design in the Construction Stage and implementation methodology is formalised at this stage. The objectives of this stage are:-

(aa) Ensuring robust architecture, design of application package, implementation plan and mitigation of risks. (ab) Ensure addressing of all architecturally-significant risks. (ac) Establishment of a baselined architecture after analysing all risk scenarios.

(ad) Demonstrating that baselined architecture supports all the system requirements.

(vi) Essential Activities in Elaboration Stage (aa) Defining, validating and baselining the architecture rapidly.

(ab) Creating and baselining detailed iteration plans for Construction Stage.

(ac) Refining development process.

(vii) Elaboration Stage Deliverables

(aa) Architectural Prototype. Definition of architecture prototype with respect to critical functionalities.

(ab) Risk List. Updated and reviewed.

(ac) Development Process. Refined in the light of early project experiences and sufficiently defined for construction to commence.

(ad) Development Infrastructure. In place, including all tools and automation support.

(ae) Software Architecture Document. Created and baselined to include detailed descriptions of design and the deployment view.



Page | 50

(af) Design Model. Defined and baselined to include all constituent artifacts.

(ag) Data Model. Defined and baselined to include definition and review of all major data model elements.

(ah) Implementation Model. Initial structure created and major components prototyped.

(aj) Software Development Plan. Updated and expanded to cover Construction, Parallel Run and Final Release Stages.

(ak) Iteration Plan. Reviewed for Construction Stage.

(al) Supplementary Specifications. Listing of all non-functional requirements, documented and reviewed.

(am) Test Suite. Tests designed to validate the stability of the build for each executable release.

(b) Stage II

(i) Construction Stage. This phase completes the system development based on the baselined architecture in three iterations as under :-

(aa) First Iteration. Initial Test Release. (ab) Second Iteration. Alpha Test Release. (ac) Third Iteration. Beta Test Release.

(ii) Construction Stage Objectives.

(aa) Optimisation. To avoid unnecessary rework. (ab) Quality. Obtaining adequate quality rapidly. (ac) Usefulness of Versions. Ensuring useful versions developed rapidly. (ad) Analyse, design, develop and test all functionalities. (ae) Iteratively develop a complete product ready for transition.

(iii) Construction Stage Deliverables.

(aa) Executables. Delivery of executables and begin beta testing.



Page | 51

(ab) Test Suite. Drawn up to validate the stability of each build for the executable releases. (ac) User Support Material. User Manuals and other training material in preliminary draft form. (ad) Design Model. Updated with new design elements identified in completing all requirements.

4. Implementation of application package for users at IHQ MoD (N) will have the following phases during Part II – Roll out in all Directorates.

(a) Parallel Run Stage. This phase ensures availability of the new package to users, even while the existing system is still under exploitation. The beta-release version is subjected to intensive user trials with a view to obtain practical feedback on all functionalities for remediation and inclusion in the final release.

(b) Parallel Run Stage Objectives.

(i) Beta testing to validate new system against user expectations. (ii) Beta testing and parallel run with existing system. (iii) Undertaking activities like bug fixing, enhancement. (iv) Assessment of deployment baselines against Acceptance Criteria for the product. (v) Achieving stakeholder concurrence on satisfaction of functional requirements.

(c) Parallel Run Stage Deliverables.

(i) Product Build. Complete in accordance with product requirements. (ii) User Support Material. User Manuals, CBTs and other build documentation.

5. Acceptance of application package at IHQ MoD (N) will have the following phases during Part III – Acceptance of the Project :-

(a) Final Release Stage. This stage involves the final rollout of the updated package, complete with all fixes and enhancements reported in the Parallel Run Stage.

(b) Final Release Phase Objectives.

(i) Smooth and complete transition to new package.



Page | 52

(ii) Ensuring user confidence in new package. (iii) Ensuring stakeholder concurrence on translation of requirements to

functionalities in an adequate manner. (iv) Ensuring all vendor obligations are discharged as per initial

requirements.

(c) Final Release Deliverables

(i) Final Build. Complete in all respects as per product requirements. (ii) User Support Material. User Manuals, CBTs and other final release

documentation.



Page | 53

Annexure III to Appendix ‘B’ (Refers to Para 20(m)(ii) of Appendix ‘B’)

METHODOLOGY FOR SCANNING DOCUMENTS

1. The documents for scanning are to be collected from the Central Sectt., scanned, uploaded in system and returned back by the vendor. Appropriate security mechanism will be worked out between DIT and the vendor to avoid any loss or damage to the collected documents. 2. The documents are to be scanned and imaged in the database in a timely manner. The letters are typically in A4/ Letter sheet printouts / cyclostyled paper. Scanning of all types of paper and storing image should be possible. Output of the scanned docs is to be a searchable PDF (at minimum of 300 DPI) that supports ISO 19005-1:2005(PDF/A). 3. The scanned documents should be verified and validated as digitized records. The scanned documents should be securely transported to the storage facility over the network. 4. Document preparation is to include removal of tags/staples/paper clips and removal of select document types defined as unnecessary. 5. Size, Volume and Document Details for Implementation Duration. All incoming and outgoing documents are to be scanned at the central facility during the currency of the project. Estimates for a quarter for Phase I at New Delhi are as below:-

Sl Page Type Total Pages

1 Legal size 20,000

2 A4 size 1,70,000

3 Other Sizes 10,000

Total 2,00,000

Note: Total Files and total pages mentioned in above table are approx volume and may increase or decrease by 15% to 25%. Indian Navy has estimated the physical quality and other document parameters to the best of the knowledge and also request bidders to re-examine the details for their satisfaction and bidding. The payment for the scanning services beyond the quantity mentioned above would be made as per actual.

6. Indexing/Meta Data Entry. Successful bidder is expected to take utmost care while carrying out this activity to ensure the proper retrieval.



Page | 54

(a) Indexing will be performed for approx nine fields (of average 10 chars/ field) of alphanumeric in nature and will be in English language only. (b) Indexing field’s information will be available on first page of all records with in a file. (c) Some of the Meta Data Entry / Indexing fields are as follows and remaining will be mutually discussed before commencement of the project:

• File Number • File Volume number • Unit Name • Date of Letter • Subject • Authorized Signatory (Name and Appt) • Designation of Authorized Signatory • Letter Reference Number and Date • Letter Type

(d) More fields may be required to be added to the above list. The same shall be discussed and finalized with the successful bidder before the commencement of work.

7. Uploading to Central DMS Server. After successful scanning and indexing, documents will be uploaded to central DMS server. Although the connectivity to the central DMS server is provided by Indian Navy, but if due to some reason, if online uploading is not feasible through scanning centres, then vendor will create suitable media for uploading it to the central DMS server in offline mode. The uploading through media is responsibility of the vendor. Successful bidder must ensure that all records are uploaded successfully and there is no duplicate, partial uploading. The log report generated by online uploading software must be submitted to Indian Navy project coordinator to evaluate and estimate the quality of digitization activity performed by the vendor. Dtes / Sectt. at IHQ MOD (N) will be part of the digitization process and should be given login details to perform quality assurance and acceptance. 8. Inventory – Out. After scanning, the physical document would have to be binded (if unbinded before scanning), pinned together/tagged in the same form as it was given for scanning by the Indian Navy and handed over top Central Sectt for further processing.



Page | 55

Annexure IV of Appendix ‘B’ (Refers to Para 21(a) of Appendix ‘B’)

END TO END SECURITY FEATURES FOR THE APPLICATION SOFTWARE

1. User Management and Security. The system will provide a module for user management where the user can be assigned into groups and roles by respective administrator of each Directorate/ Secretariat. The application will be accessed by domain users and will be authenticated by the Domain server through Active Directory. The user's logon ID and password must be protected from capture or eavesdropping. The System Administrator must be notified of any unsuccessful access attempts. The security system should reject the user after a predetermined number of unsuccessful sign on attempts (maximum three attempts). Administrators do not have access privileges to files that they do not own. If an administrator takes ownership of an object, the owner should be intimated. 2. Access Control and Rights management. The system should provide for object level access control to be assigned by the author/ the administrator of the system. Access control will be defined based on the group/role of the user. Role based user authorisation using Access Control Lists and appropriate user provisioning, would be implemented to conditionally grant/deny access to sensitive areas within the system. 3. Data Security. The software must have facilities for minimum 128 bit encryption/ decryption of data that is created/ imported into the system. Direct access with User ID/ password for the database would be permitted for database management only and not for the content stored therein. Information in memory and transit is to be protected from unauthorised access. 4. OS Security. All unwanted services and ports which are not required for the operation of Paperless Office Solution should be disabled and catalogued. 5. Audit Trails. Maintain a record of system/ application/ user activity. Audit trails should assist in detecting security violations, performance problems, and flaws in applications. A computer system may have several audit trails, each devoted to a particular type of activity and help system administrators to ensure that the system has not been harmed by hackers, insiders, or technical problems. 6. Integration with Naval Infrastructure. The system should be fully capable of integrating with Identity Management System, Rights Management System and PKI infrastructure/ digital signature for users in future.



Page | 56

Appendix ‘C’ (Refers to Para 2 (b) of Part-II of RFP)

TECHNICAL QUALITATIVE REQUIREMENT FOR AUTOMATION OF INDIAN NAVY

1. Technical Proposal. Please provide a brief write-up on the Technical aspects of the package proposed to be developed by your Company and submit the following details :-

(a) Methodology and deliverables proposed for the system.

(b) Software development process to be adopted for execution of this project shall include:-

(i) Deliverables at the end of each phase, stage and iteration.

(ii) Quality controls proposed to be employed from Requirements Capture till final deployment of the proposed package.

(c) Proposed team size showing Technical and Functional Personnel separately, along with qualifications and experience of each member. A certificate for commitment of these team members till successful implementation of the project and final acceptance of the software is to be submitted at the time of receipt of Supply Order. (d) Recommended hardware requirements for the proposed package.

(e) Operating Systems and browsers for which the proposed package shall have support. (f) Security measures proposed for the package like System Administration, Audit Trail, Authentication of Transactions, etc.

(g) Recommendations for enhancing user friendliness, user experience and Data Entry validation for the proposed package.

(h) Levels of Performance, Reliability, Response Time, Concurrency (number of simultaneous users supported) expected in the proposed package. Provide test reports wherever applicable.

(i) Recommended methodology for porting / migration of data. (j) Software Maintenance Tasks proposed during Warranty and AMC.

(k) Any other Technical aspects to be brought to the notice of TEC.



Page | 57

2. Duly filled technical fact sheet placed at Annexure I to Appendix ‘C’ is to be submitted. 3. General Proposal. This should include a brief description of domain knowledge available in the field of Manpower Planning/HR Management functions to state your understanding of the scope of work and functionalities. Following aspects are to be elaborated in detail :-

(a) Your understanding of the scope of work. (b) Details of similar software projects in the office automation domain by your company, if any. (c) Detailed Effort Estimation for the project using standard Functional Point Analysis (FPA) tools.

4. Duly filled vendor selection criteria placed at Annexure II to Appendix ‘C’ is to be submitted along with technical bid. 5. Proof of Concept (POC). A Proof of Concept (POC) to demonstrate feasibility in the form of prototype, bringing out comprehensiveness, user friendliness and richer user experience of your proposed package to verify that the product being offered by you has the potential of adhering to all the requirements mentioned in the tender. POC will be required at the TEC stage. The scope to be covered during POC will be promulgated during Pre-bid meeting.



Page | 58

Annexure I of Appendix ‘C’ (Refers to Para 2 of Appendix ‘C’)

SPECIFICATION FOR PAPERLESS OFFICE SOLUTION FOR INDIAN NAVY

TECHNICAL FACT SHEETS

REQUIREMENTS PROPOSAL/ SOLUTION

REMARKS REFERENCE

C – 10 (Fully Complied) CL – 07 (Complied with low customization) CM – 05 (Complied medium customization) CH – 02 (Complied with high customization) NC - 00 (Not Complied)

Please indicate

related pages in the

detailed proposal

1 Scope of work

1.1 Supply, deployment and implementation of an Enterprise Wide Document Management and Office Automation System for Whitehall File Movement & Tracking, Mail Movement & Tracking, Office Note Approval, Handling for Subject Files & Special Files.

1.2 System study of the requirements in Indian Navy which includes nominated five Directorates at IHQ MoD(N) at Delhi. Implementation of the solution in IHQ MoD(N), Delhi

1.3 Roll out of the solution in the Indian Navy at IHQMoD(N) in all Offices in phased manner



Page | 59



REMARKS REFERENCE

1.4 Handholding for a period of six months

1.5 Warranty of the solution for a period of 3 years post completion of hand holding

1.6 Scanning services & Records Management

1.7 Technical trainings of personnel on the proposed solutions/ systems and training of the users on the systems to be implemented

1.8 Complete user manual and system documentation (soft and hard copies) of the proposed solutions

2 General Compliance

2.1 Open Standard - The proposed solution should support Open Standard (Refer to Content Management Interoperability Services (CMIS) Version 1, available at docs.oasis.org), interoperable & should be supported for three years. The bidder should have supplied in at least one IT / e-Governance Project in Government with any State/ Central Government(s), PSU or Defence services in India during the last five (5) years for an order value of not less than Rs 3 crores. Or should have executed at least 3 similar projects of at least 1 Crores each in India.



Page | 60



REMARKS REFERENCE

2.2 Content Manager: Solution should be such that the content can be reused

2.3 Real Time Dashboards: Solution should include real time dashboards for the Process / Business Intelligence Alerts and SLA monitoring and tracking

3 General Technical Requirement of System

3.1 Proposed Document Management System should figure in the Gartner Quadrant for at least previous three years. Bidder is required to submit a letter from OEM validating the same.

3.2 The solution shall utilise the existing IT infrastructure which is based on Windows Servers and MS SQL, Oracle databases.

3.3 The solution shall be compatible with MS SQL Server for database requirement

3.4 Inter-operability - The systems must seamlessly integrate with any or all of the existing legacy and Core applications listed below and shall support interface with other open-standard systems. 1. Windows all versions 2. MS Office all versions 3. Open office/ Libre Office 4. MS – Project / EPM 2008 and above 5. ERP systems such as SAP etc

3.5 High Availability – The systems shall be designed for 24x7 operations. A highly available architecture shall be presented to address



Page | 61



REMARKS REFERENCE

planned outages for upgrades or unplanned outages caused by hardware or software failures.

3.6 Clustering - Clustering setup is to be presented, both active-passive and active-active configuration are acceptable. The system shall also support native database initiated high availability solution like clustering and replication.

3.7 Server Based Computing – The computing architecture must be Web based. The applications will reside in the servers and will be delivered to the users through other Browser based computing facility/technology. The solution must be responsive, browser neutral and support leading browsers such as Edge, IE, Firefox, Chrome etc.

3.8 Access and Interface – The systems must be user friendly, intuitive and equipped with help/support facilities

3.9 Bulk Scanning - The vendor should have solution for desktop based Bulk Scanning solution that shall allow integration with the proposed solution

3.10 Version Control and Management – The proposed System shall have versioning features to track and document and process revisions made.

3.11 Source codes – For systems or part of the system that will be customized or built from



Page | 62



REMARKS REFERENCE

scratch, the vendor shall be required to turn-over to Client all the source codes of all developed programs. Client shall have full rights to these.

3.12 Test and development environment - The vendor shall provide a separate test and development environment bundled with software licenses, including the development tools

3.13 The proposed systems must be able to provide interface with the existing systems and databases

3.14 Web based process designer & No client install. Proposed system should be such that it should not require any client to be installed and System Processes can be used / modified using any standard web browser. The system should be HTML 5 compliant.

3.15 Bidder agree to share the OEM's Standard Support Guide that highlights the Support Mechanisms, with Severity level and Escalation level details, and also provide a link URL where, this Support Guide can be found on the OEM website.

3.16 The Scanning Interface Should allow re-arrangement of the files post Scanning (Drag and Drop)

3.17 The Solution should Support Browser based scanning and Indexing – Scanning Client Installation should not be required to support Scanning. The solution should provide



Page | 63



REMARKS REFERENCE

Standardizations and central governance to the quality of Images Scanned.

3.18 System should have encryption facility for stored content so that even the system administrator can’t see the content from file system

Detailed Technical and Functional Requirement of System

4 Architecture Considerations

4.1 The system shall support Open, Scalable, Multi-tier architecture with each tier fully independent

4.2 The proposed system shall adopt a J2EE/ .Net based approach so that the solution is able to integrate with other platforms.

4.3 The system shall support Scalable architecture to support clustering at each layer i.e. Web server, Application server and Database for Fault Tolerance & Load Balancing.

4.4 The system would be deployed in clustered environment on minimum 2 servers, clearly mention the add-on product cost for deploying on clustered environment

4.5 Horizontal clustering (multiple channels) and vertical clustering (multiple instances per machine) - The System shall be scalable through both horizontal clustering (multiple channels) and vertical clustering (multiple instances per machine).



Page | 64



REMARKS REFERENCE

4.6 Document / Image server - The system shall support separate Document / Image / Metadata Information servers for better management of documents.

4.7 Distributed Document Repositories - The system shall support distributed Document Repositories for document upload and access at local level , which can be replicated with central repository at scheduled intervals

4.8 The solution shall be based on Single and Royalty-Free (RF) Open Standard using Fair, Reasonable and Non Discriminatory terms and conditions (FRAND) as per GoI policy on Open Standards for e-Governance

4.9 RDBMS Support - The system shall support & use either of the top 3 RDBMS worldwide as per Gartner/ IDC

4.10 Toolkit - The system shall provide XML based API toolkit for system integration and application development

4.11 Image processing - The system shall provide Image processing libraries that support image enhancements, and other imaging features like compression and extraction etc. These libraries should be owned and supplied by the OEM of DMS solution.



Page | 65



REMARKS REFERENCE

4.12 Response - The system shall be able to handle large Data with search capabilities in time less than 8 seconds

4.13 Free Search and handling - The system shall have an ability to handle millions of images. (The bidder must specify 3 reference site having more than 10 million images in India / worldwide and at-least one should be from Indian Government/PSU)

4.14 Storage Volume - The system shall support unlimited storage capacity by automatic / manual creation of Volume disks of predefined sizes and disk labelling

4.15 Unicode compliant & support for local Hindi language - The system shall be Unicode compliant for supporting different languages (English & Hindi). The System shall support .Net, Java API, XML API and SOA Architecture

4.16 Folder Filing : System should have classification module for Automated Content Classification

4.17 Content Integration - The system should have facility for multiple content integration which will help in Ease of Integration across multiple content (including data, documents and video content files in different formats) repositories

4.18 User Interface for content integration: System should have Content Management Widgets which



Page | 66



REMARKS REFERENCE

can help to create quick User Interfaces for content integration.

4.19 Must provide a common integrated repository to handle all types of enterprise content management, including documents, web content, digital assets, collaborative content, document images, records etc.

4.20 The system shall support replication of content across repositories enabling version and state of content to be synchronized. When replicated content is checked out in one repository a user in another repository will not be able to also checkout a replica.

4.21 Distributed architecture should also provide the ability to support placement of content files at remote sites while metadata access is at a central location

4.22 In-built support for file encryption both at transport and in storage

4.23 The system should provide facility for local caching capability for remote offices for faster access the content. The local caching must provides read as well as write capability.

4.24 The local server at remote office should be able to do predictive caching for content

4.25 Distributed architecture must provide the ability to support placement of content files at remote sites while metadata access is at a central location



Page | 67



REMARKS REFERENCE

5 Image Server Operations

5.1 Images store - The system should have a provision to store images on an image server

5.2 Image retrieval - The system should support prefetching of remote Images, for fast retrieval at local site

5.3 Caching - The system should support for caching of remote content at each respective remote office site for fast future accesses of same data. The required application software licenses, hardware and infrastructure software must be quoted for the same.

5.4 Bandwidth Utilization - The system should support page-wise data fetching of multi-page images for better bandwidth utilization

5.5 The system should support for Replication on immediate as well as scheduled basis

5.6 The system should support replication between the local and central storage servers via direct TCP/IP connectivity

6 Document Scanning Feature

6.1 Temporary Archival - The System shall support the scanned documents to be temporarily archived before uploading to the central server

6.2 Document Capturing Tool - The s/w should provide a powerful and fast browser based document capturing tool for scanning as well as auto document categorization system. It should



Page | 68



REMARKS REFERENCE

also provide image assisted data entry. Scanning of documents in batches should be possible.

6.3 Compression Technique - Scanned images should provide a document compression technique based on industry standard formats (e.g. CCIT algorithms in TIF format). Access to these encrypted documents must not have dependence on the OEM vendor for any type of use in future.

6.4 TWAIN and ISIS compatibility - The document capture tool should have blank sheet / Barcode document separator facility and should support TWAIN and ISIS compatible scanners.

6.5 Markings Of Image Attributes - The system should have standard and user-defined markings of image attributes for effective track keeping of the scanned images. It should pop up all scanned documents one by one till the last document is categorized i.e. the indexing interface should display the scanned documents for easy indexing.

6.6 Import Of Electronic Documents - The s/w should support direct import of electronic documents of commonly available office suites like MS office, Open office, star office, PDF, single static images (e.g. JPEG, GIF, TIFF), documents produced by text editors; emails and attachments; audio and video files;- CAD files;- XML and HTML documents etc.



Page | 69



REMARKS REFERENCE

6.7 Scanning And Indexing Of Bulk Documents – The system shall support Quick scanning and indexing of bulk documents. The stages of scanning, quality check and Indexing shall be preferably mapped as stages in scanning solution, Scanning through browser plug-in

6.8 Categorization Of Scanned Images - Automatic categorization of scanned images as different documents like mail, Office file document, Supporting documents, Field report etc.

6.9 Support for automatic indexing from specified zones like Application id using OCR functionality

6.10 GUI - Easy to use GUI for setting the scanning properties like indexing parameters, document and folder nomenclature, zones for data extraction etc

6.11 Facility to upload scanned batches from different field offices with Auto folder/Subfolder creation document filing & indexing on user defined fields.

6.12 System ability to provide Compression of scanned image files in TIF Format.

6.13 The System shall support Image Editing operations such as page insertion, deletion merge/split pages, etc.

6.14 The system shall provide facility for merging/ splitting documents based on bar-code/page count, etc. To assemble documents from scanned batches



Page | 70



REMARKS REFERENCE

6.15 Support all the special image enhancement functionality offered by the scanner through the driver interface

6.16 Automatically Recognize The Beginning And End Of Individual Documents - The system scanning feature may automatically recognise the beginning and end of individual documents when scanning in bulk: i.e. it should be able to identify separate document without requiring the use of barcodes or blank insert sheets.

6.17 Import Feature and Multiple channels Scanning – The Solution should support digitization of paper document Through Multiple channels – Scanning, Import of pre scanned Images, Fax , Browser Based Scanning etc

6.18 Importing Existing Documents – Indian Navy possesses archive of old scanned documents in PDF format along with necessary metadata. The system should provide seamless import of existing archives.

6.19 Control of Quality of Images - should be centrally govern The operator at remote location should not be able to change the predetermined standard decided for a specific type of document

6.20 The Product Should provide auto extraction OCR, OMR, Barcode and 2D Barcode

7 Document Acquisition Features



Page | 71



REMARKS REFERENCE

7.1 The system shall support Bulk Import of image and electronic documents and also the external acquisition source through an integrated functionality

7.2 The system shall support Automatic archival of In-coming Fax as images through an integrated functionality and shall also automatically index on required parameters

The system must enable a user, using Microsoft-based authoring tool (MS Office), to save their work directly into the repository from within the Microsoft application interface. The user must also be able to profile the content while saving the file into the repository.

7.4 The system shall support Integration with Mail server for direct Uploading of Emails for corresponding users and indexing on user defined parameters.

7.5 The system shall support Scheduled uploading from directories i.e. Folder Mapping so that files from subordinate offices can be scheduled for upload.

7.6 Multiple Initiation Methodologies - The system shall support remote scanning of multiple applications and supporting documents and initiating them in the approval route / workflow.

7.7 The system should issue a warning if a user attempts to capture a document that has the



Page | 72



REMARKS REFERENCE

same title, content or metadata as another document, which is held within the same folder.

7.8 It should be possible to configure the system so that it operates in one of the following ways when a user sends or receives an email: a) it automatically captures the email; b) it determines whether to capture the email according to pre-defined rules; c) it automatically prompts the user, giving the user an option to capture the email; d) it takes no action (and thus relies on the user to initiate a capture, if appropriate).

8 Handling of Un-scanned documents

8.1 The system shall support facility to generate paper profile for tracking of physical documents, which are not scanned.

8.2 The system shall support inbuilt facilities to electronically move paper profiles and complete user level tracking on the same.

8.3 The system shall support scanning of the document at the end of processing and auto-replacing the paper profile with the image.

9 Archival of electronic documents

9.1 The System shall support categorization of documents in folders-subfolders just like windows interface. Please specify if any limit on number of folders and sub-folders.



Page | 73



REMARKS REFERENCE

9.2 The System shall provide facility to link cross-related documents like Application form and Field report, subject and reply sent etc.

9.3 The system shall provide search facility in the same interface, so that users are able to search the documents to be linked

9.4 The system shall support versioning of documents with facility to write version comments

9.5 The system shall allow Locking of documents for editing and importing it back into the system through check in/Check-out features

9.6 Policy Engine - Provides a policy engine that can execute storage placement and migration policies to optimise storage, while reducing the content storage cost to the Buyer and maintain accessibility and compliance needs as its value changes over time

Provides policy-based content placement and migration capabilities across storage devices from a wide variety of storage vendors such as EMC, IBM, Hewlett Packard, Hitachi, and others.

10 Document View

10.1 User Rights - The s/w should allow users to view and annotate documents as per user rights assigned to them.

10.2 Platform Independent - Viewing of documents should also be platform independent both for multi page image and text documents.



Page | 74



REMARKS REFERENCE

10.3 Operations - While viewing users should be able to perform all types of imaging operations like rotate, invert, adjustment of brightness/contrast, zoom-in, zoom-out etc.

10.4 Annotations - Users should also be able to put all types of graphic and image annotations like highlighting, marking text, underlining, pointing arrows, putting sticky notes on documents and putting image and text stamps.

10.5 Thumbnail Views - It should support thumbnail views on image and electronic documents including current and older versions of the documents.

10.6 Printing of documents with or without annotations should also be possible based on access control.

10.7 The s/w should also give the facility to selectively secure the annotations for users as per rights assigned to them.

10.8 Even for multi page document. The download and view should be page by page.

10.9 The System shall facilitate Document View without the native application using a viewer. It must support viewing for MS office, Email, PDF, Autocad, and all other file formats that are used in an office scenario.

10.10 The system shall facilitate zoom-in/zoom-out, zoom percentage and Zoom lens to zoom in on a



Page | 75



REMARKS REFERENCE

part of image and other image operations like Invert, rotate etc.

10.11 Document view shall have the provision to draw a line, insert arrows etc over image document.

10.12 Document view shall have the provision to highlight or hide certain text by drawing line rectangle and solid rectangle.

1013 Document view shall have the provision to insert text over image document

10.14 The System shall support for viewing documents in native application

10.15 The system shall provide facility of putting text, graphic and image annotations on document pages

10.16 Offline Capabilities - Solution should provide offline capabilities allowing users to work offline and then synchronize their edited or newly created documents with the repository.

10.17 Support - Shall provide support for features on all thick and thin clients

10.18 Link to Parent Document - The UI shall provide support for the creation, editing and management of virtual or compound documents. The system shall provide the features to link any type/ format of documents while providing capabilities to automatically update the version of the linked document whenever the original is updated.



Page | 76



REMARKS REFERENCE

Solution should support Virtual documents i.e. system should support feature in which all the document can be clubbed together and relate to parent document.

10.19 Versioning of contents - The system should support storage of complete and multiple versions of content. The end user should be able to access previous and next versions. It should have major & minor release for draft & final release version of the document. System should provide a robust “reason for change” comment entry and version label entry must also be provide

11 Annotations

11.1 The Image applet shall support comprehensive annotation features like highlighting, marking text, underlining putting sticky notes on documents, and support for text and image stamps etc.

11.2 The system shall support automatic stamping of annotations with user name, date and time of putting annotations

11.3 The system shall provide facility for securing annotations for selective users

11.4 The system shall provide facility to configure bitmap stamps at corporate level, so that it is available to all users

11.5 The system shall store annotations as separate file and at no time, the original image shall be



Page | 77



REMARKS REFERENCE

changed. The system shall provide facility of taking print outs with or without annotations

11.6 Review Security Level - Comments / annotations should have separate security level

12 Office Note creation & Approval workflow

12.1 The system shall have an In-built Web based Text Editor with all functionalities as available in industry standard word processing software’s.

12.2 The system shall have a draft folder to save Office Notes that are created through in-built text editor.

12.3 Office Note in draft folder shall be available to the user for editing.

12.4 Using workflow feature of a system, user shall be able to route the Office Note for approval

12.5 The system shall provide a facility to Add / Edit comment to a Note in a workflow. Spell check and time stamping feature must be available.

12.6 All the comments shall be appended to the main content of the Note.

12.7 The system shall capture the signature of user working on a Note

12.8 The system shall capture complete Revision History of a Note at the top of the Note itself

12.9 The system shall have the facility to print the Note with Revision history at any point of time.



Page | 78



REMARKS REFERENCE

12.10 The system shall have a facility to ‘approve’ a Note through some actionable control.

12.11 The system shall provide an interface to search and check the status of a Note in workflow

12.12 The system shall have a facility to securely archive the Note on approval / completion.

12.13 Capabilities like real time ad-hoc routing of work items should be included in the proposed system.

13 Archival of Files

13.1 System should differentiate between general files (Subject Files) and specific files (Special Files)

13.2 System should support handling of both types of files

13.3 The system shall have a facility to create/open a new electronic subject file.

13.4 Subject File creation shall take at least File Number and File Subject as inputs.

13.5 The system shall have a facility to create both main as well as part files.

13.6 The system shall have a facility to save the file in the desired folder in the system.

13.7 The system shall also generate a Barcode number on successful creation of a file. This barcode can be pasted on a physical file for tracking, in case physical file is also used.

13.8 The system shall have facility to print barcode number of file at any point of time.



Page | 79



REMARKS REFERENCE

13.9 The system shall have facility to add documents in the File.

13.10 The system should have a facility to search a file on File number, file subject, dates etc.

13.11 The system should have an index table of all created files

13.12 The system should have a provision to define searching attributes for files

14 File creation & Movement tracking (Whitehall)

14.1 The system shall replicate the Present file handling in the same manner as followed i.e. Electronic files shall give the same look and feel of Physical file

14.2 The system shall support the Whitehall view of the file

14.3 The system shall have a facility to create/open a new electronic file.

14.4 The system shall have a facility to create both main as well as part files.

14.5 File creation shall take at least File Number and File Subject as an input.

14.6 The system shall have a facility to save the file in the desired location folder.

14.7 The system shall also generate a Barcode number on successful creation of a file. This barcode can be pasted on a physical file for tracking, in case physical file is also used.



Page | 80



REMARKS REFERENCE

14.8 The system shall have facility to print barcode number of file at any point of time.

14.9 The system shall have facility to add documents in the File.

14.10 The system shall provide facility to view all letters/documents at the right hand side (RHS) of the folder with green note-sheet on left hand side

14.11 The system shall support browsing through the noting on the LHS to facilitate easy identification of any filed document.

14.12 The system shall provide facility to users to append their notes, which shall be automatically stamped with user name, date and time

14.13 The system shall provide facility to secure notes in File View

14.14 The system shall provide facility to users to link the notes to any document, file and previous notes, so that corresponding objects can be directly opened from the note view

14.15 The system shall provide facility to users to append notes in the same paragraph

14.16 The system shall provide security on notes so that Noting/comments once written, signed and forwarded shall not be amendable by any user including originator and administrator of the system, however if a new note has not been written, the user shall be able to modify the latest note, which he is writing.



Page | 81



REMARKS REFERENCE

14.17 The system shall provide facility to take print out of the noting for filing in paper folder as record

14.18 The system shall provide a facility to add new documents in the file by calling native application like Word, Excel etc. from the same interface.

14.19 The system shall provide facility to open multiple documents simultaneously.

14.20 The system shall have a facility to create a paper profile of a document in the file, in case document is not available in electronic form.

14.21 Using workflow feature of a system, user shall be able to route the file. The workflow should be flexible to route the file as per user requirement.

14.22 The system shall provide a feature to recall a File from other user.

14.23 The system shall provide an interface to search the status of a file in a workflow.

14.24 The system shall provide a facility to track a department where a File is pending.

14.25 The system shall support the case file management

14.26 File view shall provide facility to view all documents inside file, Noting / commenting, Edit file properties etc.

14.27 The system should have an index table of all created files in the form of a "File Register" as per the Manual of Office procedure by Government of India.



Page | 82



REMARKS REFERENCE

14.28 There should be a provision to digitally sign documents/ files.

14.29 System should automatically create and update “Correspondence Register" as per the Guidelines of Office procedure promulgated by Government of India.

14.30 System should automatically generate and update "File Movement Slip" as per the Manual of Office procedure by Government of India.

14.31 The system should allow for creation of ‘Shadow Files’ which is a copy of the main file.

15 Correspondence movement & tracking

15.1 The system shall have a repository or predefined folder / area where all new correspondences (letters, memos, faxes etc) are received after scanning.

15.2 The system shall have a facility to create Paper profile of a document in the repository, in case correspondences are not scanned.

15.3 The system shall have a facility to add correspondences in electronic format from local computer drive.

15.4 The system shall provide a facility to view correspondences on RHS and indexing fields on LHS.

15.5 The system shall have a facility to add a Note with a correspondence.



Page | 83



REMARKS REFERENCE

15.6 The system shall have a facility to save the correspondence in an existing file.

15.7 The system shall have a facility to route the correspondences using workflow feature of the system.

15.8 The system shall support ad-hoc routing of a document

15.9 The system shall have a facility to prepare response and attach with the correspondences workflow

15.10 The system shall provide an interface to track & search the status of a correspondence in a workflow

15.11 The system shall have a facility to send reminders.

15.12 The system shall have a facility to generate various reports w.r.t correspondences workflow such as pending with users, pending since, elapsed time, initiated by, completed by etc

15.13 The system shall have a facility to track a department where a correspondence is pending.

15.14 The system shall provide an advanced search interface for tracing & searching a correspondence based on dates, subject, pending with, completed by, pending since etc

15.15 The system shall have a feature to recall a correspondence from other user



Page | 84



REMARKS REFERENCE

16 General

16.1 The system shall provide an easy to use email like interface for routing & working on workflow items

16.2 The system shall provide an inbox like feature to receive workflow item

16.3 The system shall provide an Sent Item like feature to view forwarded workflow item

16.4 The system shall have a tree like structure for frequently use features.

16.5 The system should provide connector to common office suite (MS Office, Open Office, Libre Office) tools so that users can directly access repository from office suite menu options.

16.6 The system should provide connector to Email tools so that users can directly access repository from menu options.

16.7 Web interface shall enable users to select from a range of themes/skins that define the look-and-feel of the interface

16.8 The interface shall provide support for the creation, editing and management of virtual or compound documents (VD). The system shall provide the features to link any type/ format of documents while providing capabilities to automatically update the version of the linked document whenever the original is updated



Page | 85



REMARKS REFERENCE

16.9 System needs to be capable of assembling and/or binding the linked document to specific versions regardless of the current version status of the original document

16.20 The system should provide support for unlimited file formats

16.21 Shall support content reuse through management of links as points to a single document or object.

17 Indexing

17.1 The System shall provide facility to index folders and documents on user-defined indexes like directorate/ department, section, file number, year etc.

17.2 The system shall provide facility to set particular fields as mandatory or unique

17.3 The system shall facilitate manual and automatic indexing using OCR functionality or from other applications.

17.4 The System shall support Automatic full text indexing for text search including search within documents

18 Search and Retrieval

18.1 The system shall provide extensive search facility to retrieve documents or Folders/Files

18.2 The system shall support saving of search queries and search results

18.3 The system shall be able to handle Tera-bytes of data with search time less than 8 seconds



Page | 86



REMARKS REFERENCE

18.4 The system shall support combined search on Profile, Indexed and Free Text Search

18.5 The system shall support search for documents or folders on document or folder on profile information such as name, created, modified or accessed times, keywords, owner etc.

18.6 The system shall support search for documents/ Folders using user-defined indexes and document classes i.e. file number, name, section, department, date etc.

18.7 The system shall support Free Text Search on image and electronic documents. Metadata and other remarks attached to store images are required to be searched.

18.8 The system shall support highlighting of searched string with a facility to browse between pages for a multiple page document and moving between hit pages

18.9 The system shall support advanced search using Boolean and logical operators like and, or, greater than etc. For example searching application form on the basis of “file subject and origin department”

18.10 The system shall support facility to export results in excel format

18.11 The system should provide support for configuring and saving search criteria’s



Page | 87



REMARKS REFERENCE

18.12 The system should allow users to refine (i.e. narrow) a search without having to re-enter the full search criteria. A user should, for example, be able to start with the hit list from a search, and then perform a further search within that list.

18.13 The system should allow users to sort search results ('hit lists'): e.g. by title, by date, by version number, by author etc

18.14 The system should provide implicit or explicit relevance ranking of the search results.

18.15 The system should provide federated / grouped search capability to allow searching across multiple repositories

18.16 The system should have auto complete feature in search to assist the user in searching.

19 Security and User Management

19.1 The Document management system shall support definition of Users, Groups and Roles relation in the system. It should integrate with the Identity Management and Single Sign On solution of the Indian Navy. However, the solution shall include full-fledged independent user management module.

19.2 The system shall support access permissions on Folders, documents and object level

19.3 ‘Information Rights Managements’ - The system shall support multiple levels of access rights (Delete/ Edit/ View/ Print/ Copy or Download).



Page | 88



REMARKS REFERENCE

The system must also provide inbuilt ‘Information Rights Managements’ functionality where access to a document can be restricted even when the document is out of the system like sent out along with an email. The system should be able to integrate with the naval IRM solution when implemented in future.

19.4 System shall support for application based rights

19.5 The system shall support system privileges like Create/ Delete Users, Define indexes etc.

19.6 The system shall support secure login id and passwords for each user and passwords shall be stored in encrypted format in database.

19.7 The system shall have a facility to define password policy with extensive password validations like passwords must be of minimum 8 characters, shall be alphanumeric, locking of user-id after three un-successful attempts, password expiry, password history so that passwords are not same as previous passwords etc.

19.8 The system shall support Disaster recovery by replicating the data at remote locations

19.9 The system shall provide support for HTTPs/SSL for secured data transfer and session timeouts.

19.10 The system shall provide LDAP support for integrating with directory services and shall support single sign on.



Page | 89



REMARKS REFERENCE

19.11 The system shall support Extensive Audit-trails at document, Folder and for highest levels for each action done by particular user with user name, date and time

19.12 The System shall support integration with database based authentication.

19.13 The system shall support integration with PKI infrastructure as well as bio-metric solution for enhanced security.

19.14 Pre-Defined Rights & Privileges - The proposed system should allow the administrator to define the access rights & privileges of the different users of the system. The proposed system should be able to restrict the users to access documents/ images based on their pre-defined rights & privileges as given in the list below

No access to document

Only search access to metadata but no privilege to view the document.

Read Rights

Comment Rights

Version only rights this means the user can’t modify the original document but can create a new version

Write Rights

Delete Rights

19.15 Solution should have In-built support for file encryption both at transport and in storage.



Page | 90



REMARKS REFERENCE

19.16 Provide capabilities to encrypt communication between the system and user’s computer through standard web encryption (SSL) Encryption algorithm used must be based on the latest Advanced Encryption Standard (AES)

20 Administration

20.1 The system shall support web-based administration module for the complete management of system.

20.2 The Admin module shall support Users/ Groups/ Role definition and granting Access Rights to them and set password expiries

20.3 The Admin module shall provide easy to use interface for Index structure definition, that can be used by different users

20.4 The Admin module shall provide interface for purging old audit trail and do selective logging i.e. select the system or application features for, which the audit trails have to be generated.

20.5 The Admin module shall provide facility to take complete and incremental backups and shall be able to integrate with third party backup solutions.

20.6 Document Delivery and Distribution. The System shall support multiple document delivery methodologies i.e. The system shall allow users to download documents through HTTP or HTTPS depending upon the access rights



Page | 91



REMARKS REFERENCE

20.7 The system shall support for Print/Mail/Fax of documents

21 Reports and Audit Trails Features

21.1 The system must ensure that audit trail data cannot be modified in any way, or any part of the data be deleted by any user, including a system administrator. The audit trail may, however, be subject to re-organisation and/or copying to off-line storage if required by, for example, database software, as long as its integrity remains intact.

21.2 The System shall support extensive Reports and audit trails and shall also provide data points and facility to design new reports

21.3 The system shall support Extensive Audit-trails at user, Folder and Cabinet levels

21.4 The system shall provide facility to generate Audit trails on separate actions, and between specific date/times

21.5 The system shall support extensive reporting facility at document, folder and user level. Please specify all inbuilt reports available in the system and also provide effort estimates for new Custom reports to be designed

21.6 The System shall have audit trail to maintain history of all transactions performed on the system.

21.7 The system shall give flexibility to administrator to do selective logging i.e. suspend and resume



Page | 92



REMARKS REFERENCE

audit trail generation for specific system and user activities.

21.8 The application shall log all the actions done by individual users with user name, date and time and the administrator shall be able to generate detailed audit logs and history of the process instance.

21.9 The system shall provide ability to configure new reports

21.10 The system should allow system administrators to produce periodic reports (daily, weekly, monthly) and to specify ad hoc reports.

21.11 The system should include features for printing reports, viewing them on screen and storing them in an electronic form.

21.12 The system should include features for sorting and selecting the information included in reports.

21.13 Audit Trail Of All Logon - All activities at admin console should have an audit trail of all logon attempts and operations. Logs should be tamper proof

21.14 System should have capability to audit the print taken from the system.

21.15 Document Lifecycle Statuses - The solution needs to provide reports for document lifecycle statuses

22 Reminders and Alarms



Page | 93



REMARKS REFERENCE

22.1 The system should have the capability to set automatic reminders and alarms to concerned users.

23 Monitoring and Tracking

23.1 The System shall be able to keep track of the status, the date/time the jobs are started and ended, the creation and archival date of the documents.

23.2 The system should have inbuilt monitoring and diagnostic tool for monitoring of logs, versions and important services

24 Custom Human to Human interfaces

24.1 The system shall support Rapid Application Development component that enables development of User friendly and customizable user Interface.

24.2 The desktop shall support inbuilt Imaging capabilities and shall support complete and automatic integration of every step of the approval workflow with the underlying DMS for the purpose of document retrieving and processing. There shall be no need for integrating individual steps of a workflow to DMS separately.

24.3 The system shall be Unicode compliant for supporting different languages

24.4 System shall have a support for Hindi language GUI & data entry Screens



Page | 94



REMARKS REFERENCE

24.5 Support for other regional languages

Integration and Web Services

24.6 The System shall provide support to invocation of external programs to perform activities of a process like launching core application screen for data entry.

24.7 The system shall enable the external clients to send the messages to the system to perform operations like creating, saving and completing work items.

24.8 The System shall provide the option of invoking its integration components (adapters) either synchronously or asynchronously.

24.9 The System shall allow users to define adapters for the system.

24.10 The System shall support integration based on standards such as XML

24.11 The System shall support message-based collaboration based on protocols such as HTTP, FTP and SMTP.

24.12 The System shall support integration with existing Email Servers (MS Exchange 2010).

24.13 The System shall support email-steps to be fully integrated, not just for notification but also to initiate or complete a work step.

24.14 The System shall provide fully functional APIs for Integration.



Page | 95



REMARKS REFERENCE

24.15 The System shall provide presentation level API to customize user task interfaces.

24.16 The System shall support Web services.

24.17 The System shall enable the work items to access the Web methods of a remotely deployed web service

24.19 The system shall allow support of both synchronous as well as asynchronous mode to invoke Web methods

24.20 The System shall support Web based interfaces.

24.21 The System may have its own front-end or launch any application.

24.22 Evaluation and fine-tuning of the performance of the implemented systems: The bidder shall guarantee that with the proposed configuration/ specifications, the required response time of not more than ten seconds shall be complied with. The required response time shall be maintained throughout the warranty period. Shall the implemented solutions not meet the required response time or in the event of performance degradation that shall require upgrades in the Software, the corresponding cost shall be taken by the winning bidder.

25 Workflow System

25.1 Supply, deployment and implementation of a Workflow Management System. The proposed solution shall be capable of an automated



Page | 96



REMARKS REFERENCE

electronic processing of data and documents that allows for the integration of Business Rules. It must adhere to the thin client open standards and must not require any proprietary software to be installed on client machines. It shall be able to deal with exceptions when these occur by changing business rules or even the entire processes in real time to respond to business conditions. It shall enable the efficient and accurate tracking of the entire cycle of each major business process and provide means of generating reports for management as well as for statistical purposes. It shall interface seamlessly to the Document Management System and capable of retrieving and attaching documents and archiving the processed documents with metadata in the specified folder structure. The Workflow Management System shall be capable of the following minimum technical and functional specifications.

25.2 Core Business Process and Rules Engine of work flow. The system shall have a workflow engine to support different types of document routing mechanism including:



Page | 97



REMARKS REFERENCE

25.3 Sequential routing –Tasks are to be performed one after the other in a sequence

25.4 Parallel routing – Tasks can be performed in parallel by splitting the tasks among multiple users and then merging as single composite work item. The system shall support conditional merging of multiple parallel activities i.e Response from mandatory parallel work stages before it can be forwarded to next stage

25.5 Rule based routing - One or another task is to be performed, depending on predefined rules

25.6 Ad-hoc routing - Changing the routing sequence by authorised personnel

25.7 Process Designing – The system should support process designing functionality in such a way that change or additional process in the document workflow process do not involve code level changes or system administrator level intervention and could be done through dash board

26 Graphical Route Designer

26.1 The workflow management system shall support Inbuilt Graphical route designer for modelling complex Business Processes using drag and drop facilities.

26.2 The workflow management system shall enable users to model off-line/disconnected from the system.



Page | 98



REMARKS REFERENCE

26.3 The system shall allow process designers to define multiple automatic system defined stages, where no human intervention is required.

26.4 The Process designer shall provide intuitive interface for designing complex rules and conditions for workflow routing.

26.5 The interface shall be easy to use so that Process owners can change the business process as and when required without any programming knowledge.

26.6 The system shall enable process designers to design multiple sub-processes. This includes mapping of the existing process instance to the newly created process instance as per mapping defined in the route.

26.7 The workflow management system development environment shall provide easy navigation to choose sub processes as required to be invoked from within a process.

26.8 Facility to copy and paste work stages along with all its properties.

26.9 Facility to define documents viewed and to be attached at individual stages.

26.10 The Process designer shall support multiple Introduction stages for introducing different document types from different acquisition sources

26.11 Facility to define multiple archive stages for archive selected documents and indexes in



Page | 99



REMARKS REFERENCE

underlying Document management system at any stage of workflow process.

26.12 The system shall provide facility to define hold stages so that a particular instance or the workflow can be kept on hold for specified interval on the basis of pre-defined condition. The system shall also provide facility to define conditions for resuming the instance from hold stage.

26.13 The system shall allow process designers to design properties for each workstage like default document view, form view or Exception view etc.

26.14 The system shall allow users to define entry-level settings like Increase of priority or sending an email trigger on the basis of pre-defined conditions or setting up particular variable or property etc.

26.15 The workflow management system shall support the definition of roles and allow many-to-many relationships between users and roles to be defined.

26.16 The workflow management system shall be capable of automatically deploying an entire business process application (including forms and adapters) to the servers from the development environment



Page | 100



REMARKS REFERENCE

27 Inbuilt Form Designer

27.1 The system shall provide inbuilt facility to design Custom forms that can be attached at one or more stages of workflow.

27.2 The Form designer interface shall support facility to define text boxes, Combo boxes, radio buttons, Drop down etc.

27.3 The system shall provide facility to define variables in the process or in external database tables, which can be linked to fields defined in the form for efficient data entry.

27.4 The system shall provide facility to define zones at forms and images, so that relevant part of the image is highlighted for Image assisted data entry.

27.5 The system shall support field level calculations at form level

27.6 Facility to use scripts for defining field level validations

28 Automatic Escalations

28.1 The system shall provide facility to define multi-level escalation procedures

28.2 The system shall provide facility to define deadlines to individual work stages and escalation to respective or group of individuals, if the instance is not processed in specified time frame.



Page | 101



REMARKS REFERENCE

28.3 The system shall provide facility to define multi-level escalations on the basis of deadlines i.e Level 1 escalation after specified time and Level 2 escalation after specified time.

28.4 Facility to raise custom triggers like Email, fax etc. for escalations.

28.5 The system shall support inbuilt calendar for defining Holidays and Working hours and the escalations and reminders shall be raised on the basis of this i.e if the escalation time is set for 2 days and there is Sunday in between then it shall not be included

29 Inbuilt Exceptions

29.1 The system shall provide facility to define exceptions at individual stages, which shall dynamically change the route on execution.

29.2 The system shall have facility to give rights to raise and clear exceptions at different stages of the process with user comments.

29.3 Facility to raise triggers on the basis of exceptions.

29.4 Facility to raise automatic exceptions on the basis of pre-defined conditions.

29.5 The system shall track all the exceptions raised in the course of process and shall maintain history of that with user name, date, time and comments.

29.6 29.6 The system shall clearly differentiate process instances with and without exception



Page | 102



REMARKS REFERENCE

30 Task Management

30.1 The system shall provide facility to define tasks for individual or group of users with deadlines.

30.2 The system shall provide facility to define check lists for individual stage with option to make particular checklist items as mandatory.

30.3 Facility to raise triggers on the basis of checklist.

30.4 The workflow management system shall have email notification to user when the user is not logged on to the workflow management system. Upon receiving the email, the user shall be able to click on the hyperlink or attachment in the email to automatically launch the Workflow management system and present the user with the task to act on.

30.5 Automatic reminders to concerned users for delegated tasks.

30.6 The system shall allow definition of audit stages to audit work of new users. The users shall be able to define percentage of work to be audited on the basis of which, random instances shall be picked up and sent to auditing supervisor. The workflow management system shall provide user definable job filters and sorters for the outstanding tasks for viewing and work prioritization.



Page | 103



REMARKS REFERENCE

30.7 The workflow management system shall allow the users to route/re-route the jobs to one or more other users by job and by users (e.g. on long leave, resignation). This can also be achieved by integration with Identity Management.

30.8 The workflow management system shall allow automatic temporary re-routing of jobs to one or more other users (e.g. temporary covering of duties).

31 Inbuilt Triggers

31.1 The system shall provide facility to define custom triggers like Emails, Word template or launching executable etc. on predefined conditions

31.2 The system shall provide facility to define custom templates for the triggers with static and dynamic data.

31.3 The system shall provide facility to generate event based triggers for automatically sending mails/ fax, generating responses, invoking data form for data entry, communicating from external systems.

31.4 The workflow management system shall have email notification to user when the user is not logged on to the workflow management system. Upon receiving the email, the user shall be able to click on the URL in the email to automatically launch the Workflow management system and present the user with the task to act on.



Page | 104



REMARKS REFERENCE

32 Multiple Initiation Methodologies

32.1 The Workflow management system shall support multiple Initiation methodologies for different user groups or document types.

32.2 The Workflow management system shall support automatic initiation of incoming faxes as separate instance with the fax document as an attachment.

32.3 The system shall support automatic initiation on the basis of incoming emails with email as an attachment.

32.4 The desktop shall support inbuilt Imaging capabilities and shall support complete and automatic integration of every step of the workflow with the underlying DMS for the purpose of document retrieving and processing. There shall be no need for integrating individual steps of a workflow to DMS separately.

34 Architecture and Technology of work flow

34.1 The workflow management system shall be based on an N-tier, open, scalable architecture.

34.2 The workflow management system shall support thin client architecture.

34.3 The workflow management system shall support Web based interfaces.

34.4 The workflow management system shall support XML messaging and SOA Architecture.

34.5 The workflow management system shall have the ability to integrate through messaging.



Page | 105



REMARKS REFERENCE

34.6 The workflow management system shall have the ability to integrate through APIs.

34.7 The workflow management system architecture must be scalable and can support increasing number of users and concurrent transactions.

34.8 The workflow management system shall run in a clustered environment.

34.9 The workflow management system shall be scalable through both horizontal clustering (multiple channels) and vertical clustering (multiple instances per machine).

34.10 The Workflow management system must be Unicode compliant and shall also support customising the interface in Local language.

35 Process Management

35.1 The workflow management system shall be able to support complete administration through a web browser interface.

35.2 The workflow management system shall allow administrators to manage users, groups, Roles and other document management operations.

35.3 The workflow management system shall allow administrators to suspend, resume and control various processes from the same interface

35.4 The workflow management system shall have audit trail to maintain history of all transactions performed on the system.



Page | 106



REMARKS REFERENCE

35.5 The system shall give flexibility to administrator to do selective logging i.e suspend and resume audit trail generation for specific system and user activities.

35.6 The workflow system shall give a facility to define turnaround time for the complete process and also for the individual work stages for efficient monitoring

35.7 The workflow system shall give a facility to set Audit percentage for multiple users at different stages, so that the specified percentage of work randomly goes for work audit.

35.8 The workflow system shall give a facility to review the audit done by different auditors.

35.9 The workflow system shall display all the queues corresponding to particular process and add and remove multiple users to particular queue.

35.10 The workflow system shall allow administrator to set properties of particular queue i.e FIFO, Dynamic etc.

35.11 The system shall support Load balancing of work items in case of Dynamic Queues i.e if more than one user is associated with particular queue , work items shall be assigned on the basis of current load.

35.12 The Workflow system shall support the concept of Shared and Personal Queues, so that work items can either be permanently assigned to user’s



Page | 107



REMARKS REFERENCE

Personal queue or can be routed to shared pool of users.

35.13 The workflow management system shall allow administrator to add new queues and associate multiple work steps with them.

35.14 The workflow system shall give a facility to set diversions for particular users so that all the incoming work items are routed to assigned person or group of users.

36 Application Access Control

36.1 The workflow management system shall provide comprehensive access control mechanism.

36.2 All users of the workflow management system shall be able to access to their own work queues and other work queues with access granted by the workflow administrator. They shall not be able to delete assigned tasks from the work queues.

36.3 Process Owners or workflow administrator shall be able to intervene the flow of work items and reassign to specific user and shall also support ad-hoc routing to specific stage in case of delays or bottleneck.

36.4 The application shall log all the actions done by individual users with user name, date and time and the administrator shall be able to generate detailed audit logs and history of the process instance.



Page | 108



REMARKS REFERENCE

36.5 The application shall support field level access so that only authorised users can edit them.

36.6 The workflow management system shall allow process owners to track the following status: Task Status, Types of actions required (i.e. for approval, for acknowledgment, for further dissemination, for reply, etc). For a task in progress or a completed task on Name of Officer, Start Date, End Date, Duration

37 Process Monitoring and Reporting

37.1 The workflow management system shall be able to keep track of the work item status, the date/time the jobs are started and ended, the creation and archival date of the documents.

37.2 The workflow management system shall provide graphical and tabular tools to view progress of each individual process

37.3 The workflow management system shall support the generation of statistical and management reports but not limited to:

Number of cases assigned

Number of cases completed

Time taken to complete each task

Process History Report

User Performance Report

Average Process Time Report

Participant Report

Participant Processing Time Report



Page | 109



REMARKS REFERENCE

Process Definition Summary Report

Exception Details Report

Expired Work item Report

Diversion Report

Temporary Queue Assignment Report

37.4 The workflow management system shall support the generation of performance comparison reports.

37.5 The workflow management system shall support users drill down from a higher level view of business processes to lower level details.

37.6 The workflow management system shall support statistical reports like Total turnaround time and delay report for complete process or specific work stages

37.7 The workflow management system shall support definition of new customized reports based on exposed data points

37.8 The workflow management system shall also provide dashboard interface for online reporting of various processes. The interface shall give a flexibility to toggle between graphical and tabular view and tile different windows in the same interface

38 User Management and Security

38.1 The workflow management system shall support integration with Active Directory/ LDAP for domain level authentication and single sign on.



Page | 110



REMARKS REFERENCE

38.2 The workflow management system shall support integration with database-based authentication.

38.3 The workflow management system shall be capable of giving access rights to users/groups on work stages, documents, forms and also to the data fields.

38.4 The workflow management system shall support extensive password validations i.e locking of user account after specified number of unsuccessful login attempts, password history, password expiry, passwords must be alphanumeric and of minimum character length etc.

38.5 The workflow management system shall support SSL, HTTPS and session timeouts.

39 Integration and Web Services

39.1 The workflow management system shall provide support to invocation of external programs to perform activities of a process like launching core application screen for data entry.

39.2 The workflow management system shall support integration based on standards such as XML

39.3 The workflow management system shall support message-based collaboration based on protocols such as HTTP, FTP and SMTP.

39.4 The workflow management system shall support actions to be taken on business processes based on messaging.



Page | 111



REMARKS REFERENCE

39.5 The workflow management system shall allow documents used in processes to come from inbuilt proposed Document Management System.

39.6 The workflow management system shall support integration with Email Servers such as MS Exchange 2010.

39.7 The workflow management system shall support email steps to be fully integrated into business processes, not just for notification but also to initiate or complete a work step.

39.8 The workflow management system shall provide fully functional APIs for Process, Rules and Integration engines.

39.9 The workflow management system shall support Web services.

40 Professional Service

40.1 Project Management – This covers the management of the whole project from kick-off to hand-over. The winning bidder is required to deliver a Project Management Plan at the start of the project. Client reserves the right to review and approve the plan. This plan will be used to track and manage the project. The winning bidder is required to submit weekly status reports showing progress against plan. The proposal must indicate the delivery of this plan.

40.2 The proposal must also include a detailed resource plan that describes the Project



Page | 112



REMARKS REFERENCE

Management and identify Implementation Teams’ composition. It shall define the roles and responsibilities of each member and the number of man-days that will be required of each member.

40.3 Business Process Reengineering – The bidder shall include the impact of the new system to the operations of Client. If applicable, the bidder shall recommend changes to the existing processes that would benefit Client.

40.4 System Development – This covers all activities that are needed in the development/customization of the system. These activities may sometimes vary depending on the methodology/model used.

40.5 The winning bidder must supply, deliver, install, configure, and test all hardware and software components.

40.6 Technical trainings of personnel on the proposed solutions/ systems and training of the users on the systems to be implemented

40.7 The Bidder must provide adequate and appropriate training to personnel (Users and IT personnel) for an efficient operation of the system. A detailed training plan with specifications for training courses, number of participants, schedules, site and requirements must be defined.



Page | 113



REMARKS REFERENCE

40.8 The Bidder must provide the following training and clearly specify the commercials related to training program: Admin Training – maximum of 5 participants End user Training– maximum of 500 participants

40.9 Training on the System for users to be conducted/provided by the Principal/s of the proposed systems –maximum of 25 participants per training session

40.10 Complete users manual and system documentation (soft and hard copies) of the proposed solutions

40.11 The Bidder must provide a complete set of the following documentation: User’s Manuals, Operator’s Manuals and Source Programs (for locally developed applications) and API manuals. The Bidder shall provide/turn-over all system documentation (Technical and Functional Specifications, etc.), if applicable.

40.12 The Bidder must also provide upgrades to manuals during the warranty period.

41 Records Management

41.1 Provides the ability to declare records automatically (from Office suit etc.) based on a document lifecycle.

41.2 System should be certified against DOD 5015.2 standard, which is a records management



Page | 114



REMARKS REFERENCE

standard. DOD 5015.2 defines minimum necessary requirements for a credible electronic records management system that reliably and authentically archives electronic records

41.3 Solution should provide – electronic as well as physical records management

41.4 System should support physical Records management. System should tell documents are stored in which bin, bay, shelf, warehouse where documents are stored in single content management system. The content management system should be capable of tracking both physical and digitized documents.

41.5 Provide capability to organize and classify both electronic and non-electronic information within the same structured file plan- including but not limited to the ability to share metadata requirements, access controls, and retention policies between these different types of records

Note:- 1. Any other functionality which the bidder feels will enhance the functioning of the system should be brought out in the pre-bid meeting. 2. Bidders are required to submit the complete API tool kit used for any of the sub systems/ system with the technical response.



Page | 115

Annexure II of Appendix ‘C’ (Refers to Para 4 of Appendix ‘C’)

VENDOR SELECTION CRITERIA

The bidder must possess the requisite experience, strength and capabilities in

providing the services necessary to meet the requirements, as described in the tender documents. The bidder must also possess the technical know-how and the financial wherewithal that would be required to successfully provide the Paperless Office solution for Indian Navy and support services sought by the Indian Navy, for the entire period of the contract. The bids must be complete in all respect and should cover the entire scope of work as stipulated in the RFP. The invitation to proposal is open to all bidders who qualify the eligibility criteria as given below:- Criteria for SI

Sl Criteria Documents to be provided by SI vendors

Documents to be provided by SI vendors

Compliance to RFP

Specification –

whether Yes/No

In case of noncompli

ance, deviation from RFP

to be specified

in unambiguous terms

1. The bidder should be a company registered under the Companies Act, 1956. The Bidder should be operating in India for at least 5 years. The Bidder shall be wholly and severely liable for the project and shall be single point of contact for this project.

Certificate of Incorporation, and self certification of being in business for last 5 years, latest valid TIN/ ITCC and sales tax registration.

2. SI should have ISO 9001:2008 certification for the enterprise-wide business

Valid ISO certificate needs to be attached.

3. SI should be certified for ISO 20000/ BS 15000 Information Technology Service Management.

Valid certificate needs to be attached.



Page | 116



Compliance to RFP

Specification –

whether Yes/No



to be specified


4. The bidder should have supplied in at least one IT / e-Governance Project in Government with any State/ Central Government(s), PSU or Defence services in India during the last five (5) years for an order value of not less than Rs 3 crores. Or should have executed at least 3 similar projects of at least 1 Crores each in India

Copy of work order / client’s certificates

5. Bidder should have a turnover of at least Rs. 20 Crores from Imaging/ Scanning and Document management solution related business for each of the last 3 years.

Provide the copy of last three years audited balance sheet of the company, and/ or a self-certificate signed by the Company Secy

6. Should have at least 5 reference sites in India for Electronic document management solution and at least one site should be in Govt / PSU/ Defence.

Provide documentary evidence

7. The Bidder should have positive net worth with a turnover of more than Rs. 50 crores for over last three Financial Years

Copy of the audited profit and loss account of the company showing turnover of the company for last three years



Page | 117



Compliance to RFP

Specification –

whether Yes/No



to be specified


before the year ending on 31.03.2015 for IT related activity

8. The bidder should furnish, as part of its proposal, an Earnest Money Deposit (EMD) of the ₹.10,00,000/- (Rs Ten Lakhs only).

Attach original EMD as per Para 12 of Part I of RFP

9. The bidder should submit valid authorisation letter from each of the OEMs of System Software, and Application Software confirming following:-

Authorization for bidder

Confirm that the products meet the technical & functional requirements & Products quoted are latest version / specification and not the end of life

OEM Undertakes that the support including updates, patches, security patches, fixes, bug fixes, for the quoted products

OEM’s confirmatory letters to be enclosed



Page | 118



Compliance to RFP

Specification –

whether Yes/No



to be specified


8. The bidder should have a local office in Delhi NCR region.

Letter of Undertaking

9. The bidder should produce documentary evidence from OEM of having agreed to provide back-to-back warranty and Technical Support for its supplied products and related services on the terms contained in RFP.

Give documentary evidence/ self attested certificate should be enclosed.

10. SI (Bidder or the group company) must have CMMi 5 certification in software development.

Supporting documents.

11. Software solution provider/ OEM should be in Business Process Management (BPM) and EDMS business for minimum of 05 years.

Give documentary evidence/ self-attested certificate should be enclosed.

12. Software solution should be based on open standards and Interoperable

Documentary evidence to be provided on at least 3 platforms. (Undertaking from OEM is required. During technical evaluation, this needs to be demonstrated.)

13. SI must have ISO/IEC 27001:2005 Information Security Management Systems certification in SW development.

Supporting documents.



Page | 119



Compliance to RFP

Specification –

whether Yes/No



to be specified


14. SI will be completely responsible for the execution of the project as a single point solution provider and the sole prime contractor for the entire project.

Undertaking certificate from SI.

15. SI should be able to provide certified training on the software application either directly or through SW OEM training team

Undertaking certificate from SI and/or SW OEM.

16. SI should provide source code of all exclusively developed software/ customisations done for the project. This will however not include source code of standard COTS applications used by the SI.


17. SI should guarantee scalability & flexibility of the solution and its capability to integrate with other applications subsequently, which includes but is not limited to PKI, Identity & Access Management and RMS




Page | 120

Criteria for SW OEMs (if Applicable)

Sl

Criteria Documents to be provided

by SI vendors

Documents to be provided by SW OEM

Compliance

to RFP Specificati

on – whether

Yes/No


ance, deviation

from RFP to be specified

in unambigu

ous terms

1. OEM must have ISO 9001:2008 or equivalent certification

Supporting document.

2.

OEM should be a leading IT software product company registered in India with existence for at least last five years in India. The average turnover for last three financial years ending 31.03.2015 should be Rupees Fifty Crores only

Certificate of incorporation, balance sheet, P&L statement of last three financial years.

3.

OEM’s server software products should support Windows Server 2012 R2/R1, Red Hat, Sues ES, AIX, Solaris etc.


4. OEM’s software products should support open standards.


5.

OEM should have a good local support base in India for last five years and full post sales support facilities.


6. OEM should support the product for minimum 7 years

Commitment letter from OEM to SI regarding provision of offline



Page | 121

Sl

Criteria Documents to be provided

by SI vendors

Documents to be provided by SW OEM

Compliance

to RFP Specificati

on – whether

Yes/No


ance, deviation

from RFP to be specified

in unambigu

ous terms

updates and patches/ upgrades for 7 years.

7.

Packaged software product being offered by OEM should have at least 3 successful working installations in India.

Customer references and case studies.

8. OEM to have ownership of intellectual property for the software applications.


9.

OEM to have a roadmap of product support and development for atleast next 5 years


10. OEM should have at least one R&D centre in India.



Page | 122

Appendix ‘D’ (Refers to Para 1(c) of Part-II of RFP)

UNDERTAKING FOR HANDING OVER INTELLECTUAL

PROPERTY RIGHTS (IPR) TO THE INDIAN NAVY

I, ____________________, the authorised signatory for M/s _____________________, hereby declare that development carried out for developing of Automation Software Package for automation of Integrated Headquarters Ministry of Defence (Navy) shall not constitute a violation of IPR, and that Indian Navy shall not be held responsible for legal fallout, if any in this context. I also understand that all software, documentation and support material produced for Automation Software Package shall become the exclusive property of the Indian Navy after final acceptance by the Automation of Indian Navy. Indian Navy reserves the right to prepare any number of copies of Automation Software Package for distribution, and freely use/ reproduce/ modify source code in any other project. The same applies to all documentation, WBTs, User Manuals and training material connected to Automation.

Sd/-

Official stamp & Seal Name ________________________ Designation ___________________ Firm Name ____________________ Dated ____________________



Page | 123

Appendix ‘E’ (Refers to Para 1(d) of Part-II of RFP)

CERTIFICATE: TERMS AND CONDITIONS

We have studied the Tender Enquiry documents for Developing of Software

Package for Automation of Integrated Headquarters Ministry of Defence (Navy) and clarified all doubts on the same. There is no ambiguity in any aspect of the Tender Enquiry.

It is also certified that all terms and conditions as laid out in the Tender Enquiry documents, appendices and annexure thereto are acceptable to the Company and we abide by them in letter and spirit. It is also certified that no additional costs incurred to complete the project shall be passed on to the customer. Company Seal (Authorised Signatory) Company Name: Name: Place: Designation: Date:



Page | 124

Appendix ‘F’ (Refers to Para 1(e) of Part-II of RFP)

CONFIDENTIALITY CERTIFICATE

It is certified that the Company, its employees or any representative of the

Company or agents authorised by them will not disclose any information gained by them or their representatives or agents, while interacting with the personnel of DIT or any other Directorate of Integrated Headquarters Ministry of Defence (Navy) or through any documents prepared in connection with the Software Package for Automation of Integrated Headquarters Ministry of Defence (Navy) or any documents received by them or any study carried out by them directly or indirectly to any person or company or institution or the media.

Company Seal (Authorised Signatory) Company Name : Name : Place : Designation : Date :



Page | 125

Appendix ‘G’ (Refers to Para 1(f) of Part-II of RFP)

CERTIFICATE OF COMPLIANCE TO DECISIONS BY TEC & PNC

I, the authorised signatory for M/s __________________________________________, hereby agree to unconditionally comply and abide by all decisions taken by the Technical Evaluation Committee (TEC) and Price Negotiation Committee (PNC) constituted for the purpose of evaluating the bids for developing of Software Package for Automation of Integrated Headquarters Ministry of Defence (Navy). I also agree that M/s______________________________________________ shall not challenge any decision/ decisions taken by the above TEC and PNC in any Court of Law in India or abroad even if the same may be against the interests of my company. Place: Signature :_______________________ Date : Name :_________________________ Company Seal Designation:______________________

Stamp :_________________________



Page | 126

Appendix ‘H’ (Refers to Para 1(g) of Part-II of RFP)

GUIDELINES FOR ATP OF APPLICATION SOFTWARE

1. A board will be formed for carrying out Acceptance Testing Procedure (ATP) consisting of two members nominated by the Buyer and the Vendor. ATP i.e., functional testing (Black Box testing), will be carried out on “AS DELIVERED SOFTWARE’’ by the board. Development Agency will certify prior to ATP that the following has been carried out by them: -

(a) Unit testing (b) Integration testing (c) System Testing

2. Continuity of the members of ATP board for the complete duration of the project is to be ensured. Data for carrying out ATP is to be collected as early as possible, preferably along with design stage. 3. The base line for functional testing is the SRS document, as updated in final build. Test cases along with all the relevant output documents will be made available to ATP. 4. Expected and achieved results are to be recorded in the Test Results. 5. ATP along with functional testing will test the component for performance response time. 6. Observations/ shortfalls/ errors detected by the board will be noted and the Software will be handed over back to the Development Agency for incorporating changes as approved by PIT. 7. On acceptance of the software, a certificate will be signed by the PIT as per Annexure I to Appendix ‘H’. On successful acceptance, the package will be rolled out in other locations. 8. Final version of User Manual would also be tested for its correctness by the ATP board.



Page | 127

Annexure I to Appendix ‘H’ (Refers to Para 7 of Appendix ‘H’)

CERTIFICATE ON SUCCESSFUL COMPLETION OF ATP

Certified that Software Package for Automation of Indian Navy was tested for its

compliance with the SRS covering functional and non functional requirements and found to be satisfactory.

OIC PIT

COUNTERSIGNED Designation : Date :



Page | 128

Appendix ‘J’ (Refers to Para 1(h) of Part-II of RFP)

SERVICE LEVEL AGREEMENT FOR SUPPORT

1. Scope. This Service provides users with online, telephone and on-site support, and other deliverables as described below. Tasks and Deliverables 2. Maintenance Assistance Support. Online and telephone support for Covered System malfunctions (defined below) eight (8) hours per day, five (5) days per week, excluding holidays. Users can request support by accessing the Support Centre online or by telephone or email. The system should allow for remote online support to cover the most common user requests. Onsite support should be resorted to only for requests that cannot be handled remotely. This support will work along with the Helpdesk already existing for AMC of computer systems, network and other infrastructure. 3. On-Site Support. On-site support for Priority 1, Priority 2, and Priority 3 Covered System malfunctions (defined below) is provided eight (8) hours per day, five (5) days per week, excluding holidays. 4. Customer-Defined Urgency and Response. Users may request support and assign support priorities in accordance with the following guidelines:-

(a) Priority 1 - System Down. Covered System is not operational. Priority 1 calls may include, but are not limited to:-

(i) System hangs (unable to save work in progress). (ii) System functionality failure causes data losses or renders system unusable. (iii) Functionality failure renders system ineffective. (iv) System malfunction causes mission-critical applications to restart, hang, or suspend. (v) Security breach vulnerability is identified.

(b) Priority 1 – Response. User's request for support will be transferred to the first available engineer and, if the engineer solely determines on-site support is appropriate, an engineer will normally arrive on site within one (1) hour.



Page | 129

(c) Priority 2 - System Impaired. Covered System is not operating with full capability but is still operational. Some examples of Priority 2 calls may include but are not limited to:-

(i) Impaired or broken functionality with significant impact to applications. (ii) Frequent application failure, but no data loss. (iii) Serious but predictable management system failure. (iv) Significant system performance degradation.

(d) Priority 2 – Response. An engineer will respond to User's request for support within one (1) hour of receiving the request and if the engineer solely determines on-site support is appropriate, an engineer will normally arrive on site within four (4) hours.

(e) Priority 3 - System Operation Normal. Covered System is up and running with limited or no significant impacts. Some examples of Priority 3 calls may include but are not limited to:-

(i) Bugs which cause limited or no direct impact to performance and functionality. (ii) Request to replace a bug workaround. (iii) Limited impact defective functionality. (iv) System performance support questions.

(f) Priority 3 – Response. An engineer can be expected to respond to User's request for support within four (4) hours of receiving the request and if the engineer solely determines on-site support is appropriate, an engineer will normally arrive on site at a later, mutually convenient time.

NOTE. Priority 1, Priority 2, and Priority 3 on-site response times apply to a Covered System located within a one [1] kilometre radius of Sena Bhavan. Add one (1) hour to onsite response time for each additional ten [10] kilometres. This service may not be available or may include additional charges for Covered Systems located more than fifty [50] kilometres from Sena Bhavan. All response times are subject to conditions beyond control.

5. Replacement Hardware Parts. In the event it is determined that the replacement of a hardware part is necessary or the issue requires involvement of service engineers



Page | 130

for hardware or other software, the support team will work alongside the AMC Helpdesk to resolve the issue at the earliest. 6. Mission Critical Escalation Support. For selected Covered Systems mutually agreed between Indian Navy and OEM (the "Mission Critical Systems"), OEM will provide Mission Critical Escalation Support. For purposes of this Service Listing, "Mission Critical Escalation Support" means that OEM personnel will be notified and engaged with IHQ MoD(N)/ DIT in cooperative management of technical resources, action plans and time frames supporting resolution of Priority 1 malfunctions for the Mission Critical Systems. 7. Connected Services. Users will receive access to applicable resources from the OEM Support Centre for the benefit of the Covered System only. Such access will allow Users to perform multiple functions via the web, for example:-

(a) Submit a support request.

(b) View the status of an existing support request.

(c) Maintain support contract contacts. (d) Obtain selected firmware updates.

8. Online Program. Users shall be granted 24x7 access to the online program for the benefit of Covered Systems. The Online program shall includes the following:-

(a) Access to information for the benefit of the Covered System. (b) Access to the OEMs System Handbook, which provides the latest support information about system products.

9. Services and Support Notifications. Users will receive periodic services and support notifications from OEM via electronic means. Information may be provided in English or Hindi. 10. Remote Diagnostic Analysis. This solution being run over an air gapped network, no remote diagnostic involving Internet connection is possible. 11. Self-Monitoring. User will be given access to a web-based monitoring, configuration, patch collection, and reporting tool to assist User in the management of systems. 12. Learning Services. OEM will provide Users access to select Information Technology modules for training. All available training modules should be made available at a central website on the Naval NEWN network.



Page | 131

13. Remedial Actions. User will promptly implement any remedial actions suggested by OEM. Any issues arising out of User's failure to implement remedial actions may result in additional time and materials charges for resolution. 14. Implementation Files and Documentation. User will provide OEM with complete and properly structured implementation files and documentation. 15. Warranty. Warranty will include entire Software Package for Automation of Integrated Headquarters Ministry of Defence (Navy) which will commence from the day of final acceptance. The vendor shall provide:-

(a) Help desk/ telephonic support for entire warranty period. (b) Will entertain IHQ MOD (N) personnel regarding their problem related to data or clarification on any module. (c) Carryout refinement/ minor modification which improves functionality of any modules. (d) Carryout effort estimation of major enhancement suggested by user including database changes, technology changes and so on, if inescapable.



Page | 132

Appendix ‘K’ (Refers to Para 2 of Part-V of RFP)

PRICE BID FORMAT

1. Deliverables cost

S No Description Qty Unit

Rate (₹) Total (₹)

Software

(a) Application Software Unlimited deployment

NA NA

(b) Application Software license (per concurrent user) Or Per named user licences

400 2000

(c) Scanning solution for departments (2 lakh documents per quarter)

2 Lakhs NA (covered below)

Training

(d) Training cost for admin (5 users) 1 batch

(e) Training cost for users (500 users in batches of 25)

20 batches

Implementation

(f) System Study, Development, Integration and customisation effort

NA

(g) Hand holding period of six months including scanning service for 2 lakh documents per quarter (total 2 Qtrs)

NA

(h) Warranty period including onsite support at New Delhi for 3 years (for about 90 Directorates and Units at New Delhi) including scanning service for 2 lakh documents per quarter (total 12 Qtrs)

NA

(j) Vulnerability Assessment (VA) by CERT-IN empanelled vendor

NA

Documentation

(k) Supply of all documents as per RFP

NA



Page | 133

AMC

(m) AMC cost for 3 years post completion of Warranty of 3 years. This will include scanning service for 2 lakh documents per quarter (total 12 Qtrs)

3 Years

GRAND TOTAL --

2. Is Excise Duty extra? If yes, mention the following:- (a) Total value of items on which Excise Duty is leviable.

(b) Rate of Excise duty (item-wise if different ED is applicable). (c) Surcharge on Excise duty, if applicable. (d) Total value of excise duty payable:

3. Is Excise Duty Exemption (EDE) required? If yes, then mention and enclose the Excise notification number under which EDE can be given. 4. Is VAT extra? If yes, then mention the following:-

(a) Total value on which VAT is leviable. (b) Rate of VAT. (c) Total value of VAT leviable.

5. Is Service Tax extra? If yes, then mention the following:-

(a) Total value of Services on which Service Tax is leviable. (b) Rate of Service Tax leviable. (c) Total value of Service Tax leviable.

6. Is Custom Duty Exemption (CDE) required? If yes, then mention the following:-

(a) Custom notification number under which CDE can be given(Enclose a copy). (b) CIF value of stores to be imported. (c) Rate of Customs Duty payable. (d) Total amount of Customs Duty payable.

7. Octroi / Entry taxes, if any. 8. Any other Taxes / Duties / Overheads / Other costs. 9. Grand Total (₹):



Page | 134

Please note the following: 1. All applicable taxes and duties prevailing on the date of proposal submission should be mentioned. 2. Since the price proposal is in INR (₹), Indian Navy shall not consider any upward variation/ fluctuation on account of any foreign exchange at any time during the currency of the contract. 3. Hand holding will commence from the date of UAT for complete solution. 4. The project is to be supported for a minimum period of 7 years (six months hand holding + 3 years warranty + 3 years AMC) from the date of UAT. The decision to engage AMC will rest solely with the Indian Navy. 5. AMC cost will be used to determine L1. However, contracting for AMC will be at the sole discretion of the Indian Navy. 6. From the above list, the documents that may be required depend upon the peculiarities of the procurement being undertaken.