Part-II Of Tender For FOIS EDW Solution

Part-II Of Tender For FOIS EDW Solution 2013 Centre for Railway Information Systems, ChanakyaPuri, New Delhi-110021 IT Wing of Indian Railways

Table of Content Chapter Title Page 1 Key Dates 5 2 Project Background 6 2.1 About Indian Railways 6 2.2 About CRIS 6 2.3 Background of FOIS 6 2.3.1 Functionalities of Projects 6 2.3.2 Integration of other application with FOIS 8 2.4 Current Reporting System in FOIS and other Projects 8 2.5 Objective of EDW Solution 8 3.0 Instructions to Bidder 9 3.1 Tender Questions and Clarifications 9 3.2 Tender Response Format 10 3.2.1 Consortium 10 3.2.2 General Instruction to Bidder 11 3.2.3 Financial Information 11 3.3 Proposal Submission 11 3.3.1 Proposal Submission for Stage 1 11 3.3.2 Proposal Submission for Stage 2 12 3.4 Proposal Evaluation for Stage 1 12 3.4.1 Details of Screening of bids (Step I of Stage 1) 12 3.4.2 Detailed Technical Evaluation (Step II of Stage 1) 13 3.4.3 Final Performance Benchmark and Invitation for Stage 2 14 3.5 Proposal Evaluation for Stage 2 14 3.6 Notification of Award 15 3.7 References 15 4.0 Scope and Description of Work 16 4.1 Scope of Work 16 4.1.1 Solution provider should keep the following requirement while designing the solution to match the above scope 16 4.2 Location of Work 18 4.3 Tentative Project Plan 18 4.4 Participation of CRIS Team 19 4.5 Hardware and Operating System 19 4.6 System Performance, Monitoring and Availability 20 4.7 System Security and Audit 21 4.8 Backups and Recovery 21 4.9 Training Plan 22 Page 2 of 70

4.10 Patches and Updates 23 4.11 Network Design 23 4.12 Testing Tool 24 4.13 Description of Data Warehouse Workloads and Sizing 24 4.14 Development Setup 24 4.15 Software License 25 4.16 Acceptance Criteria 25 4.17 Offer Validity 26 4.18 Requirement of Near Real Time Data Integration/CDC 26 4.19 Existing Source Infrastructure and Standards 26 4.20 Bank Guarantee 27 4.21 Payment Schedule 27 4.22 Warranty and Support Period 28 4.23 Terms and Conditions for Penalties 28 5.0 Solution Development Support and Consultancy 29 5.0.1 Intellectual Property 30 5.1 POC Verification Procedure 30 6.0 Bid Forms Stage - 1 32 7.0 Bid Forms Stage - 2 34 Annexure-I Bidder Selection Criteria 35 Annexure-II Proposed Solution And Approach 37 Annexure-III Features Compliance Matrix 38 Annexure-IV POC 53 Annexure-V Non-Disclosure Agreement for Use of Data for POC 66 Annexure-VI Mandatory Items 67 Annexure-VII Schedule of Rates 69 Page 3 of 70

List of Tables Table 1 Key Dates 5 Table 2 Eligibility for bidding 9 Table 3 Marks for Green Solution 13 Table 4 Marks for Feature Compliance Matrix 13 Table 5 Customer Reference 15 Table 6 Tentative Project Plan 18 Table 7 SAN Switch & Tape Library Detail 21 Table 8 Training Requirement 22 Table 9 Near Real Time Data Integration/CDC Requirement 26 Table 10 Configuration of FOIS Source Database & Hardware 26 Table 11 Configuration of ICMS Source Database & Hardware 26 Table 12 Configuration of COA Source Database & Hardware 27 Table 13 Configuration of CMS Source Database & Hardware 27 Table 14 Payment Schedule 27 Table 15 Support required in man days for various components 29 Table 16 Questionnaire Format for Technical Bid 33 Table 17 Bidder Selection Criteria 35 Table 18 Marking Criteria for Essential Features 39 Table 19 Marking Criteria for Important Features 39 Table 20 Marking Criteria for Good To Have Features 40 Table 21 Compliance Matrix for General, OLAP and Data Mining 41 Features Table 22 Compliance Matrix for BI features 43 Table 23 Compliance Matrix for EDW database features 48 Table 24 Compliance Matrix for ETL & Near Real Time Data 50 Integration/CDC features Table 25 EDW solution Performance POC Response Sheet 62 Table 26 Feature Demonstration POC Response Sheet 65 Page 4 of 70

1. Key Dates Table 1 Key Dates Date of Publishing of Tender Tender NO: Last date of receipt of queries on Tender 31-12-2013 2013/CRIS/940 10-01-2014 The queries may be addressed in writing to : Dy. Manager/Purchase, CRIS, Chanakyapuri, New Delhi Date & venue of Pre-bid Conference 16-01-2014 at 15.00 hrs. in Conference Room CRIS, Chanakyapuri, New Delhi, Pin- 110021 Last date for submission and opening of bid (only technical) for Stage 1 28-02-2014 at 15.00 hrs. The bids to be addressed to : Dy. Manager/Purchase, CRIS, Chanakyapuri, New Delhi Date & Venue of Invitation for Stage 2 Last date for submission and opening of bid (techno-commercial) for Stage 2 EMD Amount 11-04-2014 at 11.00 hrs and Venue is:- Conference Room CRIS, Chanakyapuri, New Delhi 05-05-2014 at 15.00 hrs. The bids to be addressed to : Dy. Manager/Purchase, CRIS, Chanakyapuri, New Delhi Pin- 110021 10 Lakhs Cost of the Tender Rs. 10000/- Page 5 of 70

2. Project Background 2.1 About Indian Railways Indian Railways are amongst the largest Railway networks in the world, providing a significant part of the country s transportation needs, both in the passenger and freight segment. Indian Railways are divided into 16 Zonal Railways, each headed by a General Manager. The General Managers of the 16 Zonal Railways and the 6 Production Units report to the Railway Board. Each Zonal Railway is further divided into Divisions. There are 68 Divisions in the Indian Railways at present. 2.2 About CRIS Ministry of Railways established Centre for Railway Information Systems (CRIS) in 1986 as the umbrella organization for all IT activities for Indian Railways (IR). CRIS has developed the Freight Operations Information System and acts as the sole repository of all effects accruing from the project, including know-how, design and drawings, documentation, software packages and equipment on behalf of the Indian Railway. 2.3 Background of FOIS The Freight Operations Information System (FOIS) is used for logistic management of freight traffic and it s accountal. This system is currently accessible to the users from different zones/divisions of Indian Railway that are connected to the dedicated network of Railways. FOIS has users at different levels like Railway Board, Zonal, Divisional and Station. All these users have a definite scope to see the data. 2.3.1 Functionality of Projects FOIS Commercial functions of FOIS provide Acceptance, Booking and Delivery of Consignments, Collection of Freight, RR generation and Transmission, Station Accounting. Collection of RR through E-Payment with B2B Integration with different Banks is also available with the system. Commercial transactions for freight loading and unloading are reported from over 1500 locations throughout the country. Operational functions of FOIS provide facility of acceptance of customer s order, Supply of Rakes/Wagons, Movement and Delivery at destination and Consignment Tracking. Page 6 of 70

COA ICMS CMS Train operations on the Indian Railways are controlled and monitored by the Control Rooms in each of the seventy seven divisional offices. The Control Room is the nerve centre of the division. The fluidity of train movements over the jurisdiction of the division is dependent on the efficiency of the Control Room operations. The Control office, by its very nature never shuts down and works all hours of the day and every day of the week. The Control Office Application has changed the way the trains are monitored as train movements are captured in real time and movement of scheduled and unscheduled trains planned and controlled through the computer aided interface. Along with Freight Operations Information System (FOIS), COA has led to all information on train operations being computer generated. It is this application that feeds the National Train Enquiry System (NTES) that provides passengers up to date information on train running. The objective of the Indian Railways is to further improve the operations by using technological aids that enable quicker data capture and intelligent applications that provide better planning and forecasting tools. Millions of passengers book their journeys everyday with the confidence that when their train rolls up on the appointed day, it would bring a coach which has place for them. To meet this expectation day in day out, Indian Railways need to track over 50 thousand coaches. By efficiently deploying the fleet, railways are able to run more services for the benefit of their passengers, while minimizing any chances of disruption and disappointment. IR also must ensure that these assets receive timely servicing and maintenance. Depending upon the need, the system can deliver historical records from past years in printed reports, or up-to-the-minute information on an official s cell phone. The Integrated Coach Management System does exactly all this and more. There are three modules that give a comprehensive view to the managers and facilitate quick identification of available resources and their allocation as per the requirements. "Indian Railways have more than 600 lobbies. CMS application started since 2007.A significant number of lobbies is part of Crew Management System (CMS) - the tool to manage crew movement. The CMS application has been developed in house and aims to optimize the crew booked on trains. CMS has a database covering more than 1,00,000 crew members and over 45,000 crew members are being booked daily. It allows us to supervise and analyze crew operations for express, passenger, and freight trains. The Crew Management system (CMS) application is a web based application developed based on rational application development tool and DB2 Database. The CMS application is being accessed through a browser. The application development has been done using MVC software architecture. The browser based CMS application is developed using J2EE 1.4 technology. The Clients are thin Clients connected over IP based wide area network linked to Central Server at CRIS." Page 7 of 70

2.3.2 Integration of other applications with FOIS FOIS is currently integrated with ICMS (Integrated Coach Management System), COA (Control Office Application), RBS (Rate Branch System), CMS (Crew Management System), LMS (Loco Management System), FMM (Freight Maintenance Management) and Parcel Management System (PMS). 2.4 Current Reporting System in FOIS and other Projects FOIS, CMS, ICMS and COA projects currently provide a number of MIS reports to Railway Board, Zones, Divisions and Stations which contains operational details and/or commercial information. These reports are currently being provided mainly through following two functionalities: - Dynamic reports are accessible to user through desktop application as well as through browser, both on Intranet ( FOIS network) and Internet. These reports are mainly form-based reports. Static reports are pixel perfect and are published through a web-based application. There are thousands of static reports. These reports mostly include daily/weekly/monthly reports for Railway Board, Zones & Divisions on different parameters and performance indices. 2.5 Objectives of EDW Solution The proposed EDW solution will function as an MIS repository for FOIS, CMS, ICMS and CO A. The EDW solutions shall also provide additional functionalities like drill (up/down/through), selective printing etc. In addition, Indian Railways increasingly require complex analysis to support their business. The advanced analytical capability can be provided only with a dedicated decision support system. The EDW solution is also expected to play this role in addition to functioning as an MIS repository. CRIS therefore envisages the implementation of EDW solution to meet the following major objectives: An integrated, centralized and detailed repository of historical and transactional data from different data sources. Create an information infrastructure that can be leveraged for consistent data access across Indian Railways and which will form the basis for advanced analytical solutions. Enable faster decision-making by supporting Ad-hoc queries, data analysis queries across organizational hierarchies and functional boundaries. Transfer Query Load from transactional (OLTP) system to EDW. Enable information elaboration using data drills and ad-hoc queries, dashboards, alerts, SMSs, emails and any other related methods. Standardize information modeling and reporting. Page 8 of 70

Setup of Testing/Development Environment. All the web-based and other reports of FOIS shall be covered under the scope of the EDW, and shall be provided as part of the present work. The EDW shall also be extendable to cover the information requirements of the other applications that would interchange information with FOIS in future. 3.0 Instructions to Bidders Bidder proposals in response to this Tender will be accepted by CRIS as indicated in the Key Dates section of this document. Bidder must use the product (at least warehouse DB, ETL & BI) which lies in Gartner Leaders Magic Quadrant as of 2013, the proof of same must be enclosed with the bid. The proposal should be techno-commercial and should be in the format mentioned below. The proposal should be signed by a person or persons (authorized signatory) duly authorized to bind the bidder to contracts. The bidder shall also sign all pages of the original bid document and submit the same along with the technical proposal. The bidders shall be required to submit the following for being eligible Table 2 Eligibility for bidding 1. Payment for Vendor should make supply of data for POC payment of Rs 1,00,000/- and bring a 1TB of HDD to get the data from CRIS. The payment shall be in form of demand draft in favor of CRIS, New Delhi. 2 Earnest Money Deposit The bidder shall submit Earnest Money Deposit with the tender, as prescribed. Bids of only such bidders who have made this payment shall be eligible for evaluation. Interested bidders should take the data within one month from issue date of tender. The bidder shall sign a Nondisclosure agreement for the data supplied to them for the POC as per Annexure - V. Rs 10 Lakhs (Rs.10,00,000/-) All financial information submitted by the Bidder will be used for evaluation purposes only and will be held in confidence. 3.1 Tender Questions and Clarifications A pre-bid conference shall be held with all prospective bidders as indicated in the Key Dates section of this document to clarify any doubts or concerns. The bidders must submit their queries in writing by the date indicated in the Key Dates section of this document. No modifications to the tender document or assumptions be drawn Page 9 of 70

by the bidder (other than what is stated in the tender document) while bidding. All clarifications/questions must refer to the appropriate Tender page and section number. Bidders must inquire in writing as to any ambiguity, conflict, discrepancy, exclusionary specification, omission or other error in this Tender prior to submitting the proposal. If a Bidder fails to notify CRIS of any error, ambiguity, conflict, discrepancy, exclusionary specification or omission, the Bidder shall submit the proposal at its own risk and, if awarded the contract, shall have waived any claim that the Tender and contract were ambiguous and shall not contest CRIS s interpretation. If no error or ambiguity is reported by the deadline for submitting written questions, the Bidder shall not be entitled to additional compensation, relief or time by reason of the error or its later correction. CRIS will post answers on its website to all written questions received by the deadline for submitting written questions. CRIS reserves the right to amend answers prior to the proposal submission deadline. Reply/Clarification given by CRIS shall be treated as final. Once clarifications are issued, the bidder should submit a bid which adheres to Tender requirements. Corrigendum or addendum regarding this Tender, if any, will be published on the CRIS website http://www.cris.org.in. 3.2 Tender Response Format Bidders must address all information specified as per section 6.0, scope of work and all annexure of this document. All questions must be answered completely. CRIS reserves the right to verify any information contained in the Bidder's Tender response, and to request additional information after the Tender response has been received. The response to the clarifications asked by CRIS must be submitted within a week. Marketing brochures included as part of the main body of the bid response shall not be considered. Such material must be submitted only as attachments and must not be used as a substitute for written responses. In case of any conflict between the content in the attachments and a Bidder's answers in the body of the proposal, the latter will prevail. 3.2.1 Consortium In case of consortium, bids submitted by a Consortium would be bound by the following additional stipulations: a) Members of the Consortium shall nominate one member as the Lead Member. He shall be referred to as the Bidder. b) The above mentioned lead member ( Bidder ) of the consortium can submit the bid on behalf of the consortium. c) The bidder shall fulfill all the selection criteria as indicated in Annexure-I (Bidder Selection Criterion). d) Number of members in a consortium should be limited to 3. e) The bidder or any member of the consortium should have bought the data for POC from CRIS and have the certificate for the same. f) The Bid should contain the information of all members of the consortium. g) In case of consortium, CRIS will interact only will the lead member of the consortium, also referred to as the bidder. Page 10 of 70

3.2.2 General Instruction to Bidder:- In this tender, either the System Integrator on behalf of the Principal/OEM or Principal/OEM itself can bid but both cannot bid simultaneously for the same item/product. If a System Integrator submits bid on behalf of the Principal/OEM, the same System Integrator shall not submit a bid on behalf of another Principal/OEM in this tender for the same item/product. The support of hardware & software will be directly provided by their respective OEM, not by the System Integrator or any third party. The contract declaration agreement of the OEM for the same must be enclosed in the bid in original. The support escalation matrix of each OEM for hardware & software support must be placed in the bid. The system integrator must have a back-to-back agreement with all the participating OEMs for each component/deliverable envisaged to be provided as part of bid. 3.2.3 Financial Information The Bidder shall provide a complete set of audited financial statements for the past three financial years. All financial statements should be adhered to generally accepted accounting principles. Each Bidder should note that CRIS reserves the right to purchase credit reports and additional financial information, as it deems necessary. 3.3 Bid Submission A two stage bidding process is being followed for this tender, details of which are given below:- Stage 1: The bidders shall submit only their technical bid. The technical bids will be evaluated by CRIS and final performance benchmarks will be shared after clarification meeting. Based on the mentioned benchmarks bidders shall be requested to submit their revised technical proposal and commercial bid. Stage 2: Submission and Evaluation of techno-commercial bids. 3.3.1 Bid Submission for Stage 1 As part of stage 1 the bidder shall submit his technical bid in a sealed envelope. The envelope shall contain 3 sets of document as given below: 1. Bidder Selection Criteria Annexure-I also called screening document 2. Technical proposal Consisting of Proposed Solution and Approach Annexure-II, Feature Compliance Matrix Annexure-III and Unpriced Bill of Material. 3. POC results as given in Annexure-IV Page 11 of 70

The envelope should be labelled as Response to Tender for FOIS EDW Solution: Technical Bid (Stage-1). A duplicate hard copy and a soft copy of the proposal should be submitted in the form of CD/DVD in their respective sealed envelope and all versions should be properly checked. General response should be limited to a maximum of three paragraphs and should address every point as directly and factually as possible. Supplementary information may be attached as an addendum to the proposal. Lengthy narratives should not be inserted into the body of a direct response, and template or "boilerplate" information is discouraged. CRIS will be the sole judge of the qualifications of all prospective candidates and reserves the right to reject any or all submittals without assigning any reason. All communication should be documented and done in written mode only. The evaluation process for stage 1 is given at section 3.4 3.3.2 Bid Submission for Stage 2 In stage 2, Bidders must address all information specified as per section 7.0 and the offer shall contain 2 sealed envelopes consisting of a Revised Technical Packet and a Financial Packet (Annexure - VII) separately, which will be put into single large sealed envelope and should be boldly marked Response to Tender for FOIS EDW Solution: Stage-2. The revised technical proposal packet shall contain updated Proposed Solution and Approach as per Annexure-II and Comparison of revised and previous Unpriced Bill of Material. The evaluation process for stage 2 is given at section 3.5 3.4 Bid Evaluation for Stage 1 The technical evaluation would be done in two steps, as described below. Step I Screening of Bids (compliance of Annexure I) Step II Technical Bid Evaluation (compliance of Annexure II, III and IV) The bids that fail to clear any step shall not be evaluated further. 3.4.1 Details of Screening of bids (Step I of Stage 1) A preliminary examination for screening of bids to determine substantial capabilities of the bidder will be evaluated as per Annexure-I (Bidder Selection Criterion). CRIS will examine the bids to determine whether they are complete, that the documents have been properly signed, and that they are generally in order. Page 12 of 70

3.4.2 Details of Technical Evaluation (Step-II of Stage 1) Evaluation at this step shall be done as mentioned below: 1) Proposed Solution and Approach (Annexure-II) The bidder is expected to give a detailed description of the proposed solution keeping in mind the scope of work, the size of the database system, other source systems which would contribute to the data warehouse and concurrent users (BI and DB) as mentioned in this document. The solution should thus indicate the architecture, design and network details of all H/W and S/W and other relevant information to be used in the proposed solution. An evaluation of the solution based on feedback to Annexure-II shall be done. Bidder needs to submit supporting documents. There is no minimum qualifying marks for any bidder, however bidder are required to complete all the requirement of annexure-ii. Further bidder will be given points/relative points proportional to the lower number of racks proposed, lower levels of noise emission and low power consumption. The result of the same will be populated in table 3 given below:- Table 3 - Marks for Green Solution Subject Maximum Marks 1. Number of Racks 1 1 mark for 2 or lower number 2. Noise in Db (decibel) 2 of racks and 0 for 3 or more number of racks. The marking 3. Power in KVA 2 for power and noise shall be done relatively. Total 5 No minimum qualifying marks 2) Feature Compliance Matrix (Annexure-III) Technical merits and features will be reviewed against the requirements identified in the Feature Compliance Matrix sections as indicated in Annexure-III of this document. The grades given by the bidder in the Feature Compliance Matrix will be used to populate table 4 given below (method adopted for scaling given grades is explained in Annexure - III), which will be part of the final Technical score. Bids that receive minimum qualifying marks in each sub-heads will only be considered for POC verification. Table 4 - Marks for Feature Compliance Matrix Subject Table 21 - General, OLAP and Data Mining Features Maximum Marks 20 Page 13 of 70

Table 22 - BI features 25 Table 23 - EDW database features 30 Table 24 - ETL & Near Real Time Data Integration/CDC features 20 Total 95 Total Technical Score The total technical score shall be obtained by adding up the marks as obtained in table 3 & 4 as given above. The bidder is required to achieve a minimum aggregate score of 80% of total technical score, to qualify for POC verification. 3) Proof of Concept (POC Annexure-IV) The results of the POC use cases shall be submitted as part of the technical bid document in a separate sealed envelope. The instructions and use cases of POC are mentioned in Annexure IV. The POC result verification will be done by the CRIS technical team at the indicated site (in BSC) by the bidder in India as per the process given in Section 5.1. 3.4.3 Final Performance Benchmark and Invitation for Stage 2 Based on the performance POC verification results of the technically qualified bidders, a standardized performance benchmark will be established by CRIS. The final standardized performance benchmark will be shared in the clarification meeting with technically qualified bidders of stage 1 and these qualified bidders will be invited for the Stage 2 of the tender process. Against this standardized performance benchmark the bidder will be asked to submit their revised technical proposal, revised bill of material and their financial bid. The bidder has to scale up or scale down the bill of material within the same technology. All versions and releases of hardware and software proposed in the solution must be latest and proof of the same should be enclosed duly signed by OEM and prime bidder. 3.5 Bid Evaluation for Stage 2 1. At this stage the qualified bidder will have to submit: 1) Revised technical proposal (Annexure II to be submitted afresh) 2) Confirmation by the bidder that the revised technical proposal now conforms to the performance benchmark standards as given by CRIS while inviting bids to stage 2. 3) Comparison of revised and previous Unpriced Bill of Material. 2. Financial bid with respect to revised bill of material should be submitted by the bidder (Annexure VII). Financial bid will be opened in the presence of authorized representative of concerned bidders who may wish to remain Page 14 of 70

present. The date and venue of opening of Financial Bid will be conveyed to qualified bidders. Financial bids will be evaluated to determine the lowest financial bid. Financial bids with any counter conditions or ambiguous remarks are liable to be rejected. CRIS reserves the right to re-check/evaluate the revised performance results (through POC verification) given by successful bidder in same way as he has demonstrated earlier or ask for any clarification if required. The bidder has to demonstrate the same to the satisfaction of CRIS before issue of Purchase Order. Thus both the technical and financial offers of each qualified bidder shall be examined at this stage. 3.6 Notification of Award The contract will be awarded to the Bidder whose bid is found to be technically suitable and having the lowest financial quote. 3.7 References The Bidder should provide details of at least two customers for reference preferably in India as indicated in Annexure I item 4. References should preferably be from customers who have implemented data warehouse solutions. The references should be submitted in following format. Table 5 Customer Reference Customer Reference Reference 1 Reference 2 Customer Name Country Line of business Total raw data stored in the warehouse Total disk space No. of concurrent users ETL tool Logical Data Model Production Database Production Server OLAP Tool Analytical Applications (if any) Other information Contact details Page 15 of 70

4.0 Scope and Description of Work 4.1 Scope of Work The development of the data warehouse solution shall be done by CRIS team with the technical support and consultation provided by OEM as mentioned in section 5.0. The bidder shall provide a complete end to end integrated EDW solution (keeping the requirement of FOIS, COA, ICMS and CMS projects) covering the following aspects:- A detailed approach and methodology for design and implementation of the entire solution. Supply, installation and commissioning of all proposed hardware and software for production & development setup. The various components for the above mentioned scope thus should broadly cover the following, but are not limited to these: EDW database Data Modelling Tools ETL Near Real Time Data Integration/CDC ODS Metadata management All BI layer components Data Mining Tool IDE's at each layer for development, testing and deployment All hosting, development and deployment servers at each layer Version Control Mechanism Management Tools Auditing tools OEM training of all the components used to make the solution must be provided, so that end to end development, management and application hosting can be done by CRIS technical team. The details of training requirement is provided at section 4.9 CRIS will do the development work of warehouse by itself, therefore technical support during the development phase of data warehouse solution shall be provided from respective OEM as per section 5.0 Bidders may note that scope mentioned in 4.0 (including all sub sections) is for both production and development setup. 4.1.1 Solution provider should keep the following requirement while designing the solution to match the above scope:- 4.1.1.1 Each product (hardware, operating system & other software) proposed in the solution must have clear roadmap for upgrade, update, patches and support for next 5 years from the bid submission date. Page 16 of 70

4.1.1.2 All components used to build the solution should be configured in active-active and fault tolerant with 24x7 high availability and must provide load balancing at each component level. 4.1.1.3 Bidder has to mention the situations when planned down time of source systems shall be required, during initial configuration of the solution keeping in mind that the maximum outage time of production system for a single day should not exceed 2 hours. 4.1.1.4 All hardware and software must be licensed to CRIS and the System Integrator/OEM must undertake to stand by their recommended products through indemnification. 4.1.1.5 Bidder must provide a standard LDM tool to design the LDM for the solution which should have ability to support the single view of the business lines scalability to extend subject areas. 4.1.1.6 The solution should be capable of catering to all reporting needs like MIS, Operational, Analytical, Ad-hoc, KPI s on dashboards and canned reports etc. 4.1.1.7 In EDW solution, all current static and dynamic reports will have functionalities like drill (up/down/through), selective printing, sending any report to separate mailbox of any user at scheduled activities with standard predefined values of parameters in pixel perfect format ready for printing on some standard page size like A4/A3/Fanfold, etc. 4.1.1.8 Provision of across mart/schema query must be available in the proposed solution. 4.1.1.9 All the functionalities of BI tool must be provided from the single interface i.e. there should not be any separate view for pixel perfect reports. 4.1.1.10 BI tool should have capability to handle event notifications and alerts (on email and mobile) based on pre-defined business rules in the solution to enhance decision-making. 4.1.1.11 Since all OLTP system under ambit of this proposal are 24x7, proposed data extraction process should be easy to implement and minimize overhead on OLTP system and during extraction, and there should not be any downtime. 4.1.1.12 The EDW solution must be implemented to fulfill the reporting, Dashboard, Ad-hoc query, data integration etc. requirements of FOIS, COA, ICMS, CMS and other associated applications. 4.1.1.13 Impact analysis should be end to end starting from Source System to ETL to BI layer, and should cover impacts at Report level, Report attribute / metric level, Table level, Field / Column level. The solution should support impact analysis and data lineage features. The ETL tool should support bi-directional lineage at table and field level. Bidder should include any tool required to provide the above feature. 4.1.1.14 ETL tool provided by the bidder must have capability to be used as ELT also. Therefore bidders may note that ETL mentioned in this tender document must always be considered as ETL tool with ELT capability. Page 17 of 70

4.1.1.15 The solution should provide metadata management. It should collect and unify metadata from different tools and sources into a single repository, which provides a better view of metadata relationships across layers. 4.1.1.16 Each EDW components should have web based interface for the monitoring, management, administration, tuning, performance and diagnosis. 4.1.1.17 The response must include escalation matrix for hardware and software support of all components from their respective OEM. 4.1.1.18 The solution should support extendable design for future enhancements in EDW infrastructure, data model, reporting, Dashboard, Ad-hoc query, data integration etc. as and when required for warehouse as well as future requirements. 4.2 Location of Work Services provided as part of the awarded Bidder s solution must be performed at CRIS, Chanakyapuri, New Delhi-110021 unless otherwise indicated by CRIS. 4.3 Tentative Project Plan Table 6 Tentative Project Plan Deliverables Delivery of all Hardware & software components Verification of Bill of Material (Production and Development) Expected Duration Within 8 weeks after issue of PO 1 Week Responsibility Bidder + OEM Bidder + CRIS Hardware and Software installation and setup of EDW (Prod. & Dev) Solution in CRIS premises. 3 Weeks Bidder + OEM + CRIS Developer Training as per training plan In parallel after release of PO Bidder + OEM + CRIS Design of Logical Data Model (LDM) 4 Weeks CRIS with the help of OEM Implementing LDM in Physical model 2 Weeks CRIS with the help of OEM Implementation of ETL processes 3 Weeks CRIS with the help of OEM Page 18 of 70

Loading of current and archival data in warehouse 1 week CRIS with the help of OEM System Admin Level Training as per plan. After successful installation of h/w Bidder + OEM + CRIS Development & Implementation of selected reports, Dashboards, Ad-hoc queries and decision-making alerts as desired. (Phase-I) 3 months CRIS with the help of OEM 4.4 Participation of CRIS Team The development of the data warehouse solution shall be done by CRIS team with the technical support and consultation provided by OEM as mentioned in section 5.0. OEM will review the development progress done by CRIS team as and when required by CRIS. 4.5 Hardware and Operating System 4.5.1 Bidder must provide the solution in minimum number of racks and should not exceed 4 numbers of racks. Also the rack used should not be more than 42U. 4.5.2 The total of maximum rated power requirement of actual populated hardware installed in of one rack should not exceed 6KVA. 4.5.3 The database component provided should be a standard Enterprise Data Warehouse appliance. All the components within the appliance must be configured in active - active, no active - passive configuration is allowed. 4.5.4 The hardware, other than database appliance must be configured in blade architecture (where other software will be installed). 4.5.5 Blade chassis and servers must be in redundancy and configured in HA (active-active) across chassis. 4.5.6 Each software (other than database appliance) of EDW solution must be configured in cluster (Active-Active) and across blade chassis. Servers can be electronically partitioned within chassis. 4.5.7 Operating system should preferably be a proprietary operating system of the hardware OEM or any industry leading enterprise class operating system. In both the cases the operating system must i. be of 64 bit ii. have core based or perpetual license iii. be easy to manage iv. be highly secure and on-line serviceability v. have feature of power fail recovery vi. allow the best balance between data availability and performance vii. support IPV4 and IPV6 protocols 4.5.8 Hardware used to configure each system software component/tool (like ETL, Near Real Time Data Integration/CDC, BI, management tool, audit, Page 19 of 70

etc.) of EDW solution, must have operating system and system software in cluster and configured in active-active. 4.5.9 In case of Linux operating system, the L1 & L2 support must be directly provided by the hardware OEM and in case of L3 & L4 support the hardware OEM is solely responsible to communicate with operating system s technical support to resolve any issue. In both (Proprietary or Linux) cases, the hardware OEM vendor is solely responsible for providing on-site support as and when required by CRIS during the support period. 4.5.10 Whenever operating system support expires the hardware OEM vendor will be responsible for renewing the operating system support or renewal of Linux subscription. Note: - Each hardware and software must have support (levels like L1, L2, L3 or L4) from its respective OEM. No free or unlicensed or unsupported software can be used in EDW solution desired by CRIS. A consolidated support and escalation matrix is to be provided with bid document in Stage-1. 4.6 System Performance, Monitoring and Availability The desired solution should have the following capabilities in addition to the above: 4.6.1 In case of idle situation (i.e. no user load) of the solution, the CPU and memory utilization of each hardware component of the entire EDW solution should never cross the 30% threshold value. 4.6.2 In case of user load situation (not in failover condition) after go live (i.e. Phase 1 as given in tentative plan as per section 4.3) the CPU and memory utilization of each hardware component of the entire EDW solution should never cross 60% threshold value. 4.6.3 All EDW components should have web based interface for monitoring, management, administration, tuning, performance and diagnosis. 4.6.4 Architecture should be in active-active design for maximum performance & load balancing in addition to availability. 4.6.5 Each component (hardware and software) of complete solution must be configured in High Availability (Active-Active), Fault Tolerance and Load Balancing mode. 4.6.6 Each tool should have capability to send event notifications and alerts (on email and mobile) based on pre-defined rules. 4.6.7 Annual uptime of the EDW solution/setup must be 99.50% Note: In the solution designed by the bidder, if any of the system crosses the said performance benchmark or any component is found in nonredundant mode or not comply with the said requirement, the bidder has to procure the h/w & s/w (including licenses if required) at its own cost to meet the same. CRIS will not bear any additional cost liability associated with such procurement. Page 20 of 70

4.7 System Security and Audit Security: 4.7.1.5 Role based access at various levels have to be implemented across the data repositories, BI and analytics tools. 4.7.1.6 The solution should provide security features at the database, presentation and application layer level. 4.7.1.7 Encryption of the sensitive data is required. 4.7.1.8 Ability to define separate security rules for various environments (production and development) 4.7.1.9 Information travelled between BI and end user must be secure using SSL. The same must be provided with the solution. Audit: The solution should provide an auditing and logging facility that should contain at least the following features:- 4.7.2.1 Deter unauthorized user behavior at each layer (ETL, BI, Database, etc.) 4.7.2.2 The audit logs/data must be kept separately from the production or development environment. 4.7.2.3 Audit should include a review of access and authorization procedure, physical security control, backup and recovery procedures, security controls and program change controls. 4.7.2.4 Audit tool should generate a report to safe guard against threats and hazards to the confidentiality, integrity and availability of data. 4.8 Backups and Recovery FOIS has its own Tape Library. The bidder has to build, implement and demonstrate a solution which is capable of taking the backup of the solution into the existing Tape Library. The detail of the SAN switch and Tape Library is as follows:- Table 7 SAN Switch & Tape Library Detail San Switch Model Port Speed Free Port Quantity HP Storageworks 4/32B 4Gbps 12 2 Tape Library Model Backup Software Tape Supported MSL G3 4048 Data Protector Ulterium 4 The software used to build the solution by the bidder must have following capabilities:- 4.8.1 The proposed backup setup must have the capability to backup the data of each component (database, application data, application codes, operating system, etc.) and metadata across all the sub systems on to the mentioned device. 4.8.2 The proposed solution should provide mechanism for incremental and full Page 21 of 70

database backups with zero down time. 4.8.3 The proposed solution should provide monthly validation of database backup. Service includes restoration of database from backup and validation that all database components are present and not defective. An electronic report of the results is provided at completion of validation. 4.8.4 The data transfer from all servers and database to backup device must use the FCIP/SAN as mentioned. The load of backup should not come on network. 4.8.5 The backup solution must able to take backup of each machine s operating system and use the same for restoration (in case of crash). 4.8.6 If the requirement of free port is more than what is mentioned above (in table 8), then bidder has to make a provision for a new appropriate SAN switches and Trunking with existing SAN s to provide connectivity with the backup device. 4.8.7 Each software component used to build the solution must have the capability to take backup of respective software component to the tape library. 4.9 Training Plan Training as per plan given below, should be provided by OEM (not by any other third party) at training centers located in Delhi/NCR only. Training shall be provided to CRIS technical team on all the software/hardware technologies used in the proposed EDW solution. The training must be provided for all software and hardware components like EDW, ETL, BI tools, data modeling & optimization, database administration (basic, advance & tuning), system administration, any special tools used in the solution etc... The purpose of the training is primarily to strengthen the CRIS technical team to develop, maintain and deploy the solution. Training shall include both hands-on and classroom activities. All training should be based on a training needs analysis as given below:- Table 8 Training Requirement Team Training (No of persons) Component Developer's Training Admin Training LDM Designing (Only Experts) 14 Data Warehouse Database 23 23 OLAP/Star Schema designing 25 23 ETL 23 27 Near Real Time Data Integration/CDC 17 BI layer 46 23 OS 27 Any other tool Provided by Bidder 27 23 The training as indicated above should take care of the following basic requirements: Page 22 of 70

Each training batch should be of 8 to 10 persons Hands-on training via a classroom/pc lab. Each trainee should be provided a separate PC. Bidder has to submit the training plan and also submit the details about the training material. Hard copy of training material must be provided to each trainee. 4.10 Patches and Updates 4.10.1 There should not be any extra cost during the entire support period for any new version, update, upgrade and patches of operating system, all the software provided within EDW solution, hardware components and firmware. 4.10.2 As and when required by CRIS, the support for any new version, update, upgrade and patches as mentioned above will be provided on-site by respective OEM. 4.10.3 Respective OEM should be responsible for all hardware and software support including proactive services like firmware upgrades, system health check services, and assessment services etc. 4.10.4 Bidder must provide an authorization letter duly signed by signatory authority from OEM for providing the support as mentioned. 4.10.5 Bidder must provide a clear road map for 5 years of all the hardware and software (from their respective OEM) used in the EDW solution duly signed by a signatory authority of OEM. 4.10.6 All the hardware supplied for this tender should not have a declared end of sale of the product within 1 year of submission of stage 2 bid, else the next upgraded version of the same product has to delivered by the bidder to meet the scope of work and other tender condition without any financial liability to CRIS. 4.11 Network Design 4.11.1 Bidder has to provide the network architecture for EDW solution connecting their servers and storage along with the connectivity to the source systems. 4.11.2 The SAN and network speed within the solution must be at least of 10Gbps or above. 4.11.3 To make this setup, all communication switches (L2 or L3) as required must be provided by the bidder. Moreover, two additional 48 port (fully populated) network switches of 10Gbps in redundant mode must be provided with the solution to communicate outside the solution with source system used for ETL, Near Real Time Data Integration/CDC and public network in CRIS. 4.11.4 Speed of SAN and network switches mentioned in bid should be disclosed and same setup must be provided in CRIS. 4.11.5 All network devices (Network switch and SAN switches/ib switch) and connection to each warehouse component (ETL/DATABASE/BI etc.) server must be in HA (active-active) & failover. 4.11.6 All the server and database used in EDW solution will be in MZ, except BI Page 23 of 70

servers which fall in DMZ. Both the network must be segregated in such a way that server falling in different zone will communicate through firewall only and not within switch. Switch module in blade chassis should be used for cluster heart beat or internal communication. 4.11.7 Requirement of FCIP, network port and IP s for each server kept in MZ and DMZ should be mentioned separately in the proposal. 4.12 Testing tool The Bidder should provide standard functional and load testing tool for EDW solution. 4.13 Description of the Data Warehouse Workloads and Sizing The specified size of the database is the total amount of source system extracted data, defined as all data contained in the database, including all data warehouse design-specific structures (such as indexes, cubes/stars schema and summary tables). Source system extracted data is the actual row/byte count of data that is reconfigured and loaded into the warehouse, without regard to optimization techniques implemented to meet the requirements of EDW. The data warehouse size of FOIS and other projects is estimated to be around 40TB (usable size) in next 4-5 years on production system considering the current growth pattern. Also, data size to implement ODS for decision support can be considered as 1.5TB for production and 500GB for development setup. In addition around 2TB data space is required for development setup. Hence the total minimum required usable space in EDW database is 44TB excluding any overheads like database basic requirement, spool files, dictionary tables, temp space, database logs etc. Any server other than warehouse DB in production setup should have a usable space of 1TB and configured in RAID1. It is to be noted that the data warehouse solution would have a maximum of 400 concurrent users at BI layer and 400 active queries at database layer. Also the maximum connected users at BI layer would be around 5000. The proposed solution should cater for the above requirements. Also the rpm of the hard disk used to build solution should be equal or more than 10k. 4.14 Development Setup Bidder must consider following points while designing the Development Setup for EDW:- 4.14.1 Bidder must provision the hardware of development setup in HA (activeactive) 4.14.2 Bidder must provision a database sizing of 2 TB (usable and configured in RAID 1) for storage of development data. 4.14.3 Any server, other than warehouse database should have available usable space of 500GB usable and configured in RAID1. Page 24 of 70

4.14.4 Data size to implement ODS for decision support can be considered as 500GB for development setup. 4.14.5 Bidder must consider similar software setup as proposed on production for development setup. 4.14.6 Development setup hardware must have enough sizing to handle at least 10% load (40 concurrent users) of production setup. 4.15 Software License 4.15.1 For both production and development setup ETL, Database, BI and other software licenses shall be free of project specific restrictions. The same setup may be used to meet requirements of other projects, as long as additional resources are not required. 4.15.2 The EDW solution may be integrated with applications beyond those mentioned in scope of work (section 4.1) in due course. The offered license terms should not restrict such integration as and when CRIS plans to do the same and there should not be any additional cost liability associated with such integrations. 4.15.3 Bidder has to mention clearly and separately the unit cost of supplied software and hardware including licenses. The bidder has to keep on hold the said unit price for 3 Years for any additional requirement considered necessary by CRIS for future enhancement of the project. 4.15.4 All the software licenses must be perpetual and should not be user based for any tool. No of users mentioned in tender document must only be used for sizing and not for licensing purpose. Note: For any new version, update and patch management of any software (ETL, Database, BI, Operating System, etc.) within the solution there should not be any extra cost during the support period (The support period could be additional 5 years after initial 3 year warranty period provided, if CRIS agrees to the additional period). 4.16 Acceptance Criteria Preliminary Acceptance Criteria Physical verification of equipment/components as per the Bill of Material (BoM). Physical inspection of the equipment/components for any physical damage 72 hours Power on self test of hardware. Physical verification of software media, licenses and documentation (which shall also include Installation and warranty certificates from OEM) as per tender. Delivery, installation & commissioning of hardware & software. No open issues left w.r.t. hardware, software and licences. Idle utilization of hardware is as per the standards mentioned in this document at section 4.6, else bidder has to make provision to increase the resources to meet the same at his own cost including hardware and software licenses. Preliminary Acceptance Certificate to be signed jointly by CRIS and the bidder. Page 25 of 70

The date of issue of Preliminary Acceptance Certificate shall be termed as date of Preliminary Acceptance. Final Acceptance Criteria All the training modules must be completed. Software support services must be started. Three month after go live of EDW solution and utilization of hardware is as per the standards mentioned in this document at section 4.6 under user load condition, else bidder has to provision to increase the resources to meet the same at his own cost including hardware and software licenses. Go live will be the date on which CRIS completes its phase-i development. At this time the version and patches of all software, firmware & OS must be latest and proof of the same should be submitted by the bidder. No single point of failure. Final acceptance test certificate to be signed jointly by CRIS and the bidder. 4.17 Offer Validity The offer should remain valid for a period of at least 180 days from the date of the submission of offer. 4.18 Requirement of Near Real Time Data Integration/CDC Table 9 - Near Real Time Data Integration/CDC Requirement S/N Application Database Type Near Real Time Data Integration/CDC Delay to reflect in EDW 1 FOIS Oracle Database Yes Less than 3 min 4.19 Existing Source Infrastructure and Standards Server (Type & Model) HP RX6600 HP RX6600 Server (Type & Model) Table 10 - Configuration of FOIS Source Database & Hardware Number of Servers Memory in GB No. of Cores Processor Type Operating System 1 (Active) 32 4 Itanium HP Ux 11i V3 1 (Active) 32 4 Itanium HP Ux 11i V3 Table 11 - Configuration of ICMS Source Database & Hardware Number of Memory in No. of Processor Operating Servers GB/Server Cores Type System PA-RISC, Model- 9000/800/rp 4410 2 16 (may increase to 32GB/ Server) 4 (may increase to 8 shortly) Itanium HP-UX 11.23i Database Oracle Oracle Database Oracle Page 26 of 70

Server (Type & Model) Rack Mountable Server HP Proliant DL385 Table 12 - Configuration of COA Source Database & Hardware Number of Memory in No. of Processor Servers GB/Server Cores Type 2 database server per division 4 GB/ server Dual Core AMD Opteron 2.2 GHz Operating System Windows server 2003 R2 Database Oracle Table 13 - Configuration of CMS Source Database & Hardware Server (Type & Model) Number of Servers Memory in GB/Server No. of Cores Processor Type Operating System Database IBM P5 550 1 (Active) 32 GB 4 RISC AIX DB2 IBM P5 550 1 (Passive) 32 GB 4 RISC AIX DB2 4.20 Bank Guarantee The selected Bidder is required to submit a bank guarantee, which should be 10% of the Total Bid Amount of the tender within 14 days from issue of letter of acceptance. PO will be issued after submission of performance Bank Guarantee from a scheduled bank. The submitted Bank guarantee will be released by CRIS three months after the end of warranty period (3 Years from the date of issue of PO, therefore the validity of the BG should also comply the same duration). 4.21 Payment Schedule Table 14 Payment Schedule Sr. Schedule Description Terms & Conditions No. 1. First Installment 80% of contract value This installment will be (except cost of man days paid on submission of the for Solution Development performance bank Support) guarantee for 10% of tender value and after preliminary acceptance (as per section 4.16). 2 Second Installment 20% of contract value (except cost of man days for Solution Development Support) This will be released after final acceptance (as per section 4.16). Page 27 of 70

3 Solution Development Support Payment Quarterly (at quarter end) As per actual consumption of man days as accepted by CRIS. 4.22 Warranty and Support Period 4.22.1 The selected bidder must quote the complete comprehensive warranty cost of each component for 3 years (cost which has been included in the bid value) and yearly warranty cost for next 5 years as given in schedule of rates (option to enter warranty after 3 years shall rest with CRIS, who shall also have the right to negotiate the indicated rates if required). 4.22.2 The support as mentioned above should not be fall in the extended support period for any component. 4.22.3 All support must be directly from OEM. The back to back arrangement agreement for the same must be enclosed and signed by signatory authority of bidder and OEM. 4.22.4 Each participating OEM in the bid must have or create technical staff located in NCR. The proof of the same should be submitted duly signed by signatory. 4.22.5 The hardware warranty, operating system and other software support must start from the date of preliminary acceptance. 4.22.6 Clear road map for at least 5 years of each component of hardware and software must be submitted by the respective OEM duly signed by their signatory authority. 4.22.7 The onsite support of hardware, for each component must be on 6 Hour CTR (call to repair) basis. 4.22.8 The support provided of hardware and software must be for 24 X 7 by their respective OEM. 4.22.9 Proactive support on regular interval for any new version, update, upgrade and patches mentioned above will be provided on-site by respective OEM. 4.22.10 All OEM of hardware and software must have local presence in Delhi/NCR. The proof of the same must be submitted by the bidder duly signed by the signatory authority of respective OEM. 4.22.11 In case of consortium, prime bidder must furnish the letter of authorization (signed by signatory authority of respective OEM) and clear defined roles and responsibilities for the warranty and support from all respective OEM of the EDW components as stated. Also the prime bidder shall nominate a single point of contact for the project. 4.23 Terms and Conditions for Penalties 4.23.1 If the hardware failure support breaches 6Hrs CTR (call to repair), then a penalty will be charged on hourly basis and the cost of penalty per hour will be 0.02% of the contract value per year against each registered case for each component. Page 28 of 70

4.23.2 Total annual uptime of the solution (hardware and system software for production setup only) should be more than 99.50% per year, else a penalty of 1% of the contract value per year will be enforced on the bidder. This penalty will be applicable only on hardware and system software after logging the case to the respective OEM. Penalty will not be applicable on the downtime due to the application developed by CRIS. 4.23.3 All penalties will be deducted from the bidder bills. In case the penalty cost raised by CRIS is not paid by bidder in due time than CRIS has the right to deduct it from the bank guarantee amount. 4.23.4 In case the total penalty exceeds 10% of contract value, CRIS reserve the right to terminate the contract and forfeit the Bank Guarantee. 4.23.5 If any of the machine/server crosses the performance benchmark (as mentioned in section 4.6) or any component is found in non-redundant mode, the SI has to procure the h/w & s/w (including licenses if required) to meet the same, else the desired augmentation will be done by CRIS and the cost of the same will be deducted from the bidder bills. 4.23.6 Penalties will be enforced only on unplanned downtimes. 5.0 Solution Development Support and Consultancy CRIS will develop the EDW solution through collaborative development with OEM support team. To enable the same, selected bidder shall provide the support from respective OEM for following developments: LDM Designing ETL Layer Near Real Time Data Integration/CDC implementation Warehouse database OLAP/ Star Schema designing BI and Data Mining Layer Table 15 - Support required in man days for various components Data Warehouse ETL LDM Near Real Time BI Man Designing OLAP/Cubes ETL Database Data layer Days designing Jobs Integration/CDC 100 130 140 90 30 210 700 All technical support must be provided by their respective OEM as and when required by CRIS. CRIS will reserve the right to ask for support for above developments stages as required. CRIS may call resources in parallel for different support at the same time. One man day will be counted for 8 hours of support irrespective of day or night. CRIS will intimate for any planned activity of man power support 15 days in advance, and for any unplanned activity (emergency support) CRIS has the right to Page 29 of 70

call support person anytime. As above requirement are indicative, so it is possible that few days less or more is required against each indicated activity. It is expected that bidder will able to adjust these requirements within the total man days which may be deemed to be fixed. Bidder must provide a standard man power cost for each component. The above man power support will be valid for 3 Years from the date of issue of purchase order. The support resource must have minimum 5 years of relevant experience in the area of expertise with relevant qualification and should have worked on 2 EDW projects of at least 20 TB each. The resource should have capability for coding, design, debugging, optimization and tuning for each respective component/tool. The experience and qualification of the technical resource should be shared with CRIS before commencement of development support. CRIS reserves the right to request for change of the resource if found unsuitable for a particular development support component. Once the resource is accepted by CRIS, than change in deputed resource will only be allowed after taking permission from GM/FOIS. Note: The above support will not be part of hardware and software installation and commissioning. 5.0.1 Intellectual Property It may be noted that the intellectual property right of the data warehouse software solution developed by CRIS as part of this tender will reside with India Railways. 5.1 POC Verification Procedure 5.1.1 Bidder has to be ready for POC verification after submission of the bid. The schedule for the same will be intimated to each bidder at least one week prior to visit by CRIS team. 5.1.2 As POC is a part of technical evaluation, CRIS team will verify the POC results at the premises with in INDIA only as mentioned in Bidder Selection Criteria. 5.1.3 The bidder needs to showcase the POC results on exactly the same stack/hardware of EDW solution proposed by the bidder including the network configuration within the solution. 5.1.4 The hardware setup for demonstration of POC cases can be setup within India or outside India. If the bidder is demonstrating the POC remotely in India using a physical setup outside India then the bidder also has to make arrangements for a site visit within India of a live data warehouse setup. 5.1.5 CRIS team may ask for the verification of hardware configuration as per the unpriced bill of material submitted by Bidder. Page 30 of 70

5.1.6 Bidder has to verify the POC result within 5 days. 5.1.7 All use cases are to be performed in sequence as mentioned in tender document. 5.1.8 Query should not be in cache before execution of any use case. 5.1.9 During POC demonstration, the system resource utilization should not cross as mentioned in section 4.6. 5.1.10 The POC results, along with the infrastructure (hardware, software etc.) should be included in the technical proposal. 5.1.11 Basic configurations of system has to be verified to CRIS team at start of each day using a script made by the bidder. 5.1.12 Bidder has to provide minimum three network connection for CRIS team to connect their laptops with internet facility. 5.1.13 Speed of SAN and network switches used while demonstration and mentioned in bid should be disclosed and same SAN setup must be provided in proposed solution. 5.1.14 Detail logs of all the script and command executed during POC verification process must be captured and submitted to the technical team. 5.1.15 All POC results shall be signed by both CRIS and bidders team. Important: Improvements in the POC results at the time of verification are accepted, Degradation of result during POC verification beyond specified limits (up-to 20% degradation in case of query performance and up-to 10% degradation in all other case) will be viewed seriously and could lead to even disqualification of the bidder from the bidding process. Note: Except basic courtesy, no extra hospitality (boarding, lodging etc.) will be accepted by CRIS team during POC verification process. Page 31 of 70

6.0 Bid Forms Stage - 1 To, <Contact Person>, CRIS, Chanakya Puri, New Delhi, Pin- 110021 Dear Sir, Tender Submission Form Stage 1 SUBJECT: TENDER FOR FOIS ENTERPRISE DATA WAREHOUSE SOLUTION FOR CENTRE OF RAILWAYS INFORMATION SYSTEM (CRIS) With reference to your subject tender, we confirm having carefully read, studied and understood various conditions/documents supplied with the tender and submit them duly signed and stamped as having accepted the same in entirety. We submit herewith our proposal, duly signed, in sealed envelope as per details given hereunder: COVER ENVELOP CONTAINING (A) Power of Attorney for the Authorized Signatory (B) Earnest Money Deposit (EMD) (C) Technical Bid Packet (B) Unpriced Bill of Material (BOM) Thanking You Yours faithfully Signature of Bidders Authorized Signatory With Designation and Stamp. Page 32 of 70

Questionnaire Format for Technical Bid Table 16 Questionnaire Format for Technical Bid S. Criteria No 1 Name of the Bidder 2 Nature of Bidder s Organization 3 Contact Details 4 Name and designation of the person authorized to make commitments to CRIS. 5 Certificate showing firm/agency registered in India Information Needed Copies of Citations, Certificates and/or declarations etc. as proof for all of the above must be enclosed in all relevant cases. Page 33 of 70

7.0 Bid Form Stage - 2 Tender Submission Form Stage 2 To, <Contact Person>, CRIS, Chanakya Puri, New Delhi, Pin- 110021 Dear Sir, SUBJECT: TENDER FOR FOIS ENTERPRISE DATA WAREHOUSE SOLUTION FOR CENTRE OF RAILWAYS INFORMATION SYSTEM (CRIS) With reference to your subject tender, we confirm having carefully read, studied and understood various conditions/documents supplied with the tender and submit them duly signed and stamped as having accepted the same in entirety. We submit herewith our proposal, duly signed, in sealed envelope as per details given hereunder: COVER ENVELOP CONTAINING (A) Power of Attorney for the Authorized Signatory (B) Revised Technical Bid Packet (C) Comparative Sheet of Old and Revised BOM (D) Financial Bid Packet (Annexure VII) Thanking You Yours faithfully Signature of Bidders Authorized Signatory With Designation and Stamp. Page 34 of 70

Annexure I Bidder Selection Criterion The bidder can be an OEM (the solution provider) or the Systems Integrator (the entity that shall be responsible for implementing the recommended solution, including supply of infrastructure) or lead bidder of consortium. The names of the OEM and the Systems Integrator shall be clearly stated in the Technical proposals, along with clarification on who would be the Prime Bidder. For all the criteria below, bidder must fill in the form given below and relevant documents must be submitted. Sr. No. Table 17 Bidder Selection Criteria Criteria 1 The bidder must have presence in India. 2 The Bidder must have been in operation in India at least for 10 years as on the date of bidding. 3 The bidder must have experience of at least 5 years in successful consultancy of end-to-end EDW solution with hardware, software, BI tools, services etc. as well as project management within last 10 years. 4 The bidder must have implemented at least 2 EDW solutions in the last 10 years and bidder shall provide the proof of the same. 5 In case a System Integrator is the Prime Bidder, it should have an annual turnover exceeding Rs 1000 crores for past 3 financial years. 6 Bidder must use the product (at least warehouse DB, ETL & BI) which lies in Gartner Leaders Magic Quadrant as of 2013, proof of the same must be enclosed with the bid. Response of bidder Remarks of bidder/references of proof submitted Page 35 of 70

7 The bidder should ensure that each participating OEM in the bid must have technical staff located in NCR or be willing to create the required facility in NCR. The proof/willingness of the same should be submitted duly signed by signatory authority. 8 Bidder must furnish undertaking from OEM on OEM s letter head for entire services as per tender requirement including acceptance criteria, support, services and warranty. The proof of the same should be submitted duly signed by signatory authority. 9 POC verification location with complete address within India to be given by the bidder. 10 In case of remote demonstration of POC, address of customer s site visit is to be provided. Page 36 of 70

Annexure - II Proposed Solution and Approach General Bidder shall provide details of the solution being proposed as given below. Bidders are requested to be concise in their response: 1. Proposed Solution Architecture A description of the framework, design, data flow and details of individual components. An overview of how the system will meet the functional and technical requirements. A description of the programming languages, engines and automated tools proposed to be used. A detailed description of the ETL approach and methodology. A detailed description of the data warehouse database approach and Methodology. A detailed description of the BI approach and methodology. A detailed description of the metadata management plan. Number of racks 2. Un-priced Bill of Material including all hardware, software components including any other third party tools that may be required and licensing policies. 3. Training Details 4. Product Support and Service warranty Bidder should describe the support offerings available for EDW solution and associated products, including pricing options. In addition, Bidder should provide a copy and description of all warranties associated with the proposed tools. 5. Network Management Plan Bidder has to provide strategy and plan for Network Connectivity between the different components of EDW Solution and with source system and end use. 6. Power Management Plan Bidder should provide power requirement plan for EDW solution. Bidder should provide cooling requirements plan for the EDW system. Bidder should provide noise level of proposed H/W. 7. Security Plan The Bidder shall provide a detail plan of how the whole system in EDW will be secured from any external/internal threats. The Bidder should also mention the authentication policy plan. Page 37 of 70

Annexure III Features Compliance Matrix This questionnaire will be used to determine the Bidder's technical score. It is imperative that Bidders answer the questions in accordance with the guidelines provided below. Failure by a Bidder to provide correct responses will be grounds for disqualification from the Tender process. Bidders are cautioned not to indicate functionality as "included in standard offering" when in fact that particular feature is in development. If a feature/functionality is under development then the Bidders should give the appropriate date as applicable and give details in the remarks/reference column of the "Feature Compliance Matrix" and indicate the expected date that such a feature will be made available. The score achieved (sum of Basic Features and Good To Have Features) for each table i.e. Table 21 to Table 24, will be scaled down to Marks as indicated in table 4 against each matrix upto two decimal using the following formula: - Final Table Score = (Score Achieved for the Table) X (Max. Marks of matrix) (Maximum Score of Table) For example: If a bidder scores 47 in a table, this will translate to (47 x 25)/50 = 23.50 (assuming that the maximum marks of matrix is 25 and maximum score of table is 50) using the above formulae. The individual table score will be used to fill Table 4 (Feature Compliance Matrix). Technical feature are divided into the following categories Out-Of-The-Box Features All the features under this category listed in the questionnaire must be Out-of-the-Box. Absence of any of these features will result in disqualification of bidder. Bidders can choose from Two Grades to indicate their compliance with each requirement and complete the feature compliance matrix given below: Note: Out-of-the-box features shall be checked during POC verification process. Page 38 of 70

Table 18 Marking Criteria for Out-Of-The-Box No Yes Functionality not provided (when functionality Not included as Out-of-the-Box) Functionality provided Out-of-the-Box (No customizing or work around is required.) Basic Features All the features under this category listed in the questionnaire must be present. Bidder will be required to mark from 1 to 4 against these features according to the capability of the system. Non provision of any of the basic features will lead to disqualification of the bid. For Basic Features in the Compliance Matrix, Bidders can choose from four Grades as given below to indicate their compliance with each requirement: Table 19 Marking Criteria for Basic Features 1 Functionality provided; requires customized integration with third party (Bidder has established a relationship with a business partner to provide this functionality, but it needs customizing or working around using third-party tool) 2 Functionality provided by the Bidder, but requires customization (The functionality can be accomplished with the Bidder's products, but some customizing or working around is required without using any third-party tool) 3 Functionality provided seamlessly by third-party product (The Bidder has established a relationship (for example, as an OEM) with a business partner to provide this functionality integrated within its solution, and no customizing or work around is needed.) 4 Functionality provided Out-of-the-Box (No customizing or work around is required.) Note: Grades given by the bidder will be verified through documents submitted by the bidder. However if additional clarification is required for the remarks given by the bidder then the same will be sought by CRIS. CRIS could also ask the bidder to demonstration the feature during POC verification if required. After due verification if it is found that the information provided by the bidder with regard to a feature is incorrect then the marks given shall be reduced accordingly. However if verification proves the absence of a feature then the bidder shall be disqualified. Page 39 of 70

Good to Have Features Bidder will mark each questionnaire 0 or 1 according to capability of system. A Zero (0) mark will not lead to disqualification of the bidder. For Good to Have Features in the Compliance Matrix, Bidders can choose from two Grades to indicate their compliance with each requirement: Table 20 Marking Criteria for Good To Have Features 0 Functionality not provided 1 Functionality provided (The Bidder provides the functionality either out-of-the-box or from third party tool or through customization) Technical evaluation criteria table 4 at section 3.4.2 will be populated by taking sum of Marks of Basic Features and Marks of Good to have features for each matrix. Note: Kindly add three columns mentioning Grades, Remarks/Reference (if any) and Supporting Document respectively in the Feature Compliance Matrix table given below to put your Grades and Comments respectively. A Sample table is given below: Sr. No. Features Description of features Grades Remarks/ Reference Supporting Document (with reference in the bid) The bidder should add supporting documents to support the indicated feature. After verification if CRIS find that the supporting document proof submitted is not satisfactory then bidder has to demonstrate the same features during POC verification (CRIS will intimate in advance about the features to be demonstrated). If bidder is using any third party tool or customizing the product, the information of the same should be mentioned in the remark column against the respective feature. Page 40 of 70

FEATURES COMPLIANCE MATRIX Table 21 Compliance Matrix for General, OLAP and Data Mining Features Basic Features (Mark 1/2/3/4) Sr. No Features Description of features GSB.01 Capability for Web Based It should be possible for management of EDW management/administration/tuning of all the Solution components of EDW solution through a Web based monitoring interface. GSB.02 Support of different testing Environment GSB.03 Centralized metadata Repository and administration GSB.04 Integration of metadata repository from EDW, ETL and BI The solution should support different testing environments such as load testing, regression testing, and performance testing. The Solution should support centralized metadata Repository and administration. The Solution should support Integration of metadata repository from EDW, ETL and BI. GSB.05 CWM/XML/Open Metadata Metadata exchange should be done through Common Warehouse Metadata Model (CWM) or Open metadata or XML. GSB.06 GUI interface for data lineage and impact analysis GSB.07 Change Tracking Capabilities on ETL jobs and related objects. The EDW solution should have GUI interface for user friendly view of data lineage and impact analysis. The EDW solution should support Change Tracking Capabilities on ETL jobs and related objects. GSB.08 Error messages Handling The solution should provide the option to translate system error messages into predefined formats and made available as standard configurable messages in the response. Good To Have Features (Mark 0/1) Sr. No Features Description of features GSG.01 End-to-end Data Lineage from ETL End to end data lineage should be accessed from within ETL tool. GSG.02 Single Web Based Single web based monitoring interface for the Monitoring Interface management/administration /tuning of full stack of EDW solution (including DB, ETL, BI and other components) OLAP Basic Features (Mark 1/2/3/4) Sr. No Features Description of features Page 41 of 70

OLB.01 Multidimensional Storage Capability The EDW platform should provide native multidimensional storage capability either at warehouse database or at BI tool. OLB.02 ROLAP The tool should be able to perform multidimensional analysis against relational data with good performance without relying on pre-defined aggregates. OLB.03 HOLAP The aggregates or granular data reside in cube/star schema structure should be made available for drill through. Data Mining Basic features (Mark 1/2/3/4) Sr. No Features Description of features DMB.01 Integration with warehouse database The tool should support integration with proposed warehouse database to extract data to build a data mining model. DMB.02 Model Export/Import capability DMB.03 Capability for exportation of rules The tool should have the capability of export/import scoring models to some standard model like PMML. The tool should provide facility for rules to be exported in user defined file formats. DMB.04 GUI capability The tool should provide a GUI which allows interaction with data by selecting a region of a graph and see the selected information in a table. DMB.05 Analysis of data The platform should allow users to analyze forecast and actual data together in interactive dashboards. DMB.06 Sequence Analysis The tool should determine likely sequences for objects/event. DMB.07 Text Mining The tool should parse unstructured content to create structured data objects (i.e. columns) that can be combined with other structured data and used for predictive modeling. Data Mining Good To Have Features (Mark 0/1) Sr. No Features Description of features DMG.01 Offline Analysis The tool should provide facility for users to perform offline analysis on data extracted from the database. Page 42 of 70

Table 22 Compliance Matrix for BI features Out-Of-The-Box Features (Mark Yes/No) Sr. No Features Description of features BIO.01 Creation of Reports The BI platform should have the capability to create flexible, highly formatted, pixel-perfect and feature-rich operational reports, with maximum control for report designer. It should cater to any report formatting scenario and report formatting can be based on templates (like template in MS word etc.). The BI platform should allow creation of canned reports that can be run on regular basis. BIO.02 Creation Of Canned reports BIO.03 Drilling capabilities The BI platform should allow the users to perform drill down, drill up and drill across on any graph or table or crosstab to view the detail information on any value. BIO.04 Passing Parameters reports to BIO.05 Multilingual Support BIO.06 Publishing of reports BIO.07 Sending Alerts to user BIO.08 Total and Subtotal Definition BIO.09 Highlight/Format columns BIO.10 Highlighting Data element based on user defined criteria BIO.11 Running of reports as Scheduled Batch BIO.12 Fetching data from database and displaying in Office Interface Basic Features (Mark 1/2/3/4) Sr. No Features Description of features The BI platform should have ability to pass parameters across reports, ad-hoc reports and dashboards e.g. Date range. BI must support the English, Hindi and all other Indian languages. The BI platform should allow publishing of reports on internet / intranet through BI portal. The BI platform should able to send alerts to user based on pre-defined condition/business rule. The BI platform should allow users to define total and subtotal. The BI platform should provide flexibility to users to define criteria to highlight/format columns within a table. The BI platform should allow users to configure data elements to be highlighted (via font, colour, weight, etc.) based on user-defined criteria. The BI platform should allow the reports to be run as scheduled batch and store the report instance onto file repository. The BI platform should allow the users with the ability to access BI platform and create excel spreadsheets and word documents, which can directly fetch data from database using BI platform and display in office interface without any compromise on security. Page 43 of 70

BIB.01 Propagation capability The tool should propagate changes made in the metadata repository to all the reports and applications that make use of the metadata objects. BIB.02 Search in Metadata There should be facility to search metadata repository to find the appropriate report. BIB.03 User defined The BI platform should support custom user defined Calculation at meta data layer calculations to be defined at metadata layer, which can be used in reports. BIB.04 GUI interface for report Metadata Layer BIB.05 Ability to create single view to combine charts, 3D graphs The BI platform provide GUI interface to design report metadata layer with zero need for SQL statements or MDX (MDX used for querying from MOLAP) programming. The BI platform should allow a single view to combine charts, 3D graphs coming from multiple data sources without any need of configuration and coding. BIB.06 Auditing Usage The tool should offer the ability to monitor ad-hoc query usage. BIB.07 Analysis on The BI platform should provide ability to do analysis on Operational and both operational data (OLTP systems) and historical data Historical Data (Data Warehouse systems). BIB.08 Analytics on segment of report BIB.09 Filtering and Selection BIB.10 Customization on Report based on business rule The BI platform should allow the user to do analysis of segment of report data. The BI platform should allow filtering / selection should happen at report level without touching the database. The BI platform should have ability to set alerts on reports to colour one cell, column on the basis of value from other column, or colour the entire row. Users should be able to highlight numbers based on threshold settings during the course of analysis. BIB.11 Sharing of Reports The BI platform should allow sharing of reports (information) with individual users or to groups of users. BIB.12 Pivot and The BI platform should allow the user to pivot and transformation of transform the reports. It should support compound reports document layout (graphs and tables on the same page) and full pivot capabilities for tables. BIB.13 Combination of reports to generate New report BIB.14 Handle NULL or missing data Points The BI platform support the combination reports that combine multiple existing reports in one layout. The BI platform should allow users to handle missing or NULL data points. Users must have the option of supplying their own text alternative. Page 44 of 70

BIB.15 Organization and formatting of reports into tabs, section etc. BIB.16 Business Logic base report generation BIB.17 Capturing and Storing Audit information BIB.18 Representation of Indian Currency formats BIB.19 Backup of Repository and File System Each Report must have the ability to organize information into tabs (similar to sheets in excel). Each tab can be organized into sections and subsections to organize the breakdown of summary to detail. The BI platform should support automatically e-mail /Fax on some business condition. The BI Platform should allow capturing and storing audit information. The solution must provide the administrators the ability to capture user activities, user login attempts, report requests and other activities. The BI platform should support Indian representation of thousand, lakh, crores etc. in numbers / currency. The BI platform should provide backup of repository and file system. BIB.20 Report Bursting The BI platform allow administrator to configure user profiles for report bursting i.e. to send a section of report to a particular group of users. BIB.21 Customization of reports in case No Data is Available BIB.22 BIB.23 Single Sign On and Directory Services for authorization. Caching and Page rendering Feature BIB.24 Refresh Office / Excel BIB.25 Customize view of parts of a predefined report BIB.26 Support for Intuitive Graphics The BI platform should have feature of Customizing Report in case no data is available for the same. The BI platform should support single sign on and directory services for authorization. The BI platform should have proper Caching mechanism and page rendering feature implemented at the BI server end. The tool should have the ability to embed queries and refresh them from an Office/Excel document. The BI platform should be able to extract parts of a predefined report into their documents from within any MS Office application, while preserving the existing formatting of report. The BI platform should allow the dashboard model to display the results in very intuitive graphics like 2D/3D charts, speedometers, indicators, progress bars, slider bars, dials, scorecards etc. without programming. Page 45 of 70

BIB.27 Presentation and Exploration The library should be rich to include presentation like geographical maps, speedometers, traffic lights, thermometer, barometer, charts (bar, line, stacked bar, Pareto, trend, pie, bubble, radar) and The BI platforms for exploration (frequency, curve fitting, probability, regression, lag plot and moving average). BIB.28 User Management There should be common location to add/delete users and modify settings. BIB.29 Design Time Error The BI platform should support design time error handling Handling And and debugging. Debugging BIB.30 Security level The BI platform should have User, group, object, and folder level security. BIB.31 Slicing/Dicing ability Ability to slice and dice the data as per end user's requirements BIB.32 Single Interface for ad-hoc reporting The BI platform should allow the user to create ad-hoc reports, using a single interface. BIB.33 Drag and Drop Ad-hoc reporting should support drag and drop capability. BIB.34 What if Analysis The BI platform should provide the ability to perform online what if analysis. BIB.35 Conversion Able to seamlessly convert one visual representation into another e.g. bar chart to pie chart. BIB.36 Multi-Data Sources Able to integrate multiple data sets in one dashboard including both relational and multidimensional data. BIB.37 Unicode support The BI platform should support Unicode. BIB.38 SOA The BI platform should support services-oriented architecture (SOA) for flexibility and extensibility. BIB.39 Versioning Provides central repository with check in/checkout, versioning within the development, testing environment. BIB.40 WYSIWIG Developers should see live data in WYSIWIG format. BIB.41 Alerting on mobiles Devices The BI platform should allow alerting on mobile devices or e-mail, providing notifications when a new report has been scheduled. BIB.42 Widgets Support The BI platform should have a Widget Framework, that Delivers at-a-glance intelligence to everyone right on their desktop. BIB.43 BIB.44 Selective print/export Server side & client side Java support The BI platform should allow the users to print/export the reports on selected rows and columns. User must able to Export the selective print/report to multiple formats including PDF, MS excel, MS Word, RTF and HTML and XML. The BI platform should support JAVA and Javascript for server side and client side scripting. Page 46 of 70

Good To Have Features (Mark 0/1) Sr. No Features Description of Features BIG.01 Offline Analysis The BI platform should support off-line analysis as well as modification of the report layout right from their desktop. Data synchronization should be seamless so that no manual updates are required. BIG.02 Stemming of words The BI platform should understand stemming in words (e.g. match geographic to geography) as well as suggest for alternatives to cater for spelling mistakes (e.g. sales by geography à do you mean sales by geography). BIG.03 Rank the search results on the order of relevance BIG.04 Refinement of Search Criteria By grouping The BI platform should able to rank the search results on the order of relevance and searched words must be highlighted. The BI platform should have the capability to help the user to refine their search criteria by grouping the results into topics. BIG.05 Extended search The BI platform should provide capability at search engine, to leverage on the Metadata layer and suggests new queries to pull fresh information from the database when no results are found. BIG.06 BIG.07 Copy /Paste of BI Objects in MS Office Ability to represent performance drivers in a geographical map, GIS. The BI platform should allow the users to copy / paste BI objects in MS office applications with all the functionality enabled. The BI platform should have the ability to represent performance drivers in a geographical map, GIS. BIG.08 Ad-hoc to standard Ad-hoc reports should be turned into standard reports without the need for programming. BIG.09 Use of data on Local machine for Ad-hoc Analysis BIG.10 BIG.11 Capability to define the information about the Report Lifecycle Management The BI platform able to use data on local machine like text, excel, XML files, transactional database etc. as personal data provider, in ad-hoc analysis with other data coming from BI system. The BI platform should have the capability to define the information about the report (encyclopedia), so that other users in the community can understand what kind of business questions the report answers, the meaning of the business terms used and the link to other related reports. Provides Lifecycle Management stages including: development, and production. test, Page 47 of 70

BIG.12 Insert page break with new Subtotal The BI platform should have capability to generate the report on new page i.e. insert page breaks, with new subtotal wherever a new value of given column is encountered. Table 23 Compliance Matrix for EDW database features Out-Of-The-Box Features (Mark Yes/No) Sr. No Features Description of Features EDO.01 MPP (Massively Parallel Processing)/MPA EDW database must be MPP/MPA (Massively Parallel Processing/Architecture) platform. Specify (Massively parallel the type of MPP/MPA. Architecture) EDO.02 Single management tool EDW database must have single tools for monitoring, diagnosis and tuning. EDO.03 Performance and workload dashboards The EDW database should support performance and workload dashboards/graphs of CPU Usage, Cache Hit Ratio, I/O Usage and Query performance. EDO.04 EDW Free Space The EDW database should have ability to perform Management Free Space Management. EDO.05 Semi-structured and unstructured data The database should have the ability to access semi-structured and unstructured data, such as e- mail, office productivity tools, content repositories and rich media (audio, video) Basic Features (Mark 1/2/3/4) Sr. No Features Description of Features EDB.01 Query and index advisor The EDW database should have query, stats collection and index advisor feature. EDB.02 EDB.03 Support for ANSI SQL-92 compliance or higher Manageability Dependency The database in EDW platform must support ANSI SQL-92 compliance or higher. Management of EDW platform should not be dependent on availability of any particular node in the system and management / administration should continue in the event of failures in CPU/unit. EDB.04 DBA authorization DBA should be prevented from seeing application data in the databases. EDB.05 CLI & GUI for data There should be Command Line Interface as well definition language (DDL) as Graphical User Interface for DDL and DCL. and data control language (DCL). Page 48 of 70

EDB.06 Structured Query Language (SQL) procedures The EDW database should support any form of SQL for procedures. EDB.07 Roles Based Privileges The Database should support Roles Based and Authentication Privileges & Authentication. EDB.08 Audit Capability The EDW database should support option of centrally managed audit database system. The audit warehouse should support all databases and operating system log collection. The system should be able to capture transaction, privileged user audits, raise alerts on suspicious activity through some tool/dashboard. EDB.09 Backup and Recovery The EDW database should support built-in parallelism, online backup (base and incremental) & recovery feature. EDB.10 Query prioritization and tuning The EDW database support control mechanisms to regulate/prioritize/tune query execution. EDB.11 Linear Scalability The EDW database support linear scalability (and not diminishing performance) across growing volumes of data, users, queries, complexity of queries, database administration, etc. This linear scalability applies to hardware infrastructure including software (RDBMS & OS). EDB.12 Workload management The EDW platform should have the ability to automatically perform Workload Management. EDB.13 Inter mart/schema query EDW database should have provision of across mart/schema query. EDB.14 Unicode Support The EDW database should support Unicode Good To Have Features (Mark 0/1) Sr. No Features Description of Features EDG.01 Data warehouse modeling tools EDW database should have tools to assist the data modelers in schema creation. EDG.02 Support for Data Model The EDW platform should be data model agnostic and support for 3rd Normal Form as well as dimensional modeling. EDG.03 Parallelism Query processing The EDW should support in-built capability for Parallelism in Query processing (Proper resource Usage). Page 49 of 70

Table 24 Compliance Matrix for ETL & Near Real Time Data Integration/CDC features Out-Of-The-Box Features (Mark Yes/No) Sr. No Features Description of Features ETO.01 Parallel extraction The tool should support parallel extraction from multiple from multiple heterogeneous sources (like Oracle, DB2, and Sybase etc.). heterogeneous sources ETO.02 Single monitoring and control interface for administration jobs ETO.03 Near Real Time Data Integration/CDC ETO.04 Near Real Time Data Integration/CDC from database Logs ETO.05 Preview data from the sources Sr. No ETB.01 Logging of rejected records ETB.02 Syncing of multiple targets ETB.03 Web service ETB.04 Connectivity to message queues ETB.05 Built Transformations in The tool should support for a single monitoring and control interface for administration jobs. The tool should support Near Real Time Data Integration/CDC Capabilities from OLTP systems. There should not be any direct access to the source database systems. Data extraction from these systems should extract data from transactional logs instead of directly from databases. This would ensure that any operational processing is not affected by EDW data capture on operational systems. The tool should allow the developer to preview data from the sources. Basic Features (Mark 1/2/3/4) Description of Features The tool should support notification and logging of rejected records on account of DB constraints. The tool should have ability to ensure that multiple targets being loaded by one job are in sync for normal loads and for failures. The tool should support connectivity through Web Services [WS] Connectivity to message queues, including those provided by application integration middleware products and standards-based architectures (such as JMS or MSMQ) The tool should support extensive library of built in transformations (such as data-type conversions, string manipulations, simple calculations, lookup and replace operations, aggregations, summarizations, deterministic matching and management of slowly changing dimensions etc.) should be provided so as to minimize writing of code. List of such libraries should be provided. Page 50 of 70

ETB.06 Joining heterogeneous data sources ETB.07 SQL execution of ETB.08 Re-usability of the code ETB.09 Handle duplicate rows ETB.10 Copy & paste of sections of ETL code ETB.11 Debugging ETB.12 Generation of DDL from ETL ETB.13 Team based development ETB.14 Centralized repository ETB.15 Backup of repository / metadata ETB.16 Import of Metadata ETB.17 Data profiling ETB.18 Metadata Security ETB.19 Accessibility Meta data of ETB.20 Automatic generation of central metadata ETB.21 Concurrent, multiuser development environment ETB.22 Deployment The tool should be able to join heterogeneous data from multiple sources with/without staging. The tool should have ability to support SQL execution within any stage in the ETL flow. The tool should have ability to support re-usability of the code by making transformation reusable. The tool should have ability to Handle duplicate rows The tool should have ability to copy & paste sections of ETL code, ETL jobs. The tool should have ability to easily and interactively debug transformation logic across all product modules. The tool should have ability to generate database specific DDL from ETL GUI. The tool should support team-based development capabilities such as version control and collaboration The tool should support Single centralized repository for Source data definitions, Target data Models, Transformation rules and derived computations. The tool should have ability to perform database independent backup of repository / metadata. The tool should import of Metadata from any RDBMS. The tool should support data profiling of RDBMS metadata objects. The tool should have ability to secure metadata for different user level and access rights Metadata repository should consist of both business and technical definitions, and should be easily browsed by end users and power users via client/server and/or Web connections. Automatic generation of central metadata, including source data definitions, transformation objects, target data models, and operational statistics. The tool should support concurrent, multi-user development environment. The tool should support easy deployment in centralized or distributed deployment strategies and support for complete release management. Page 51 of 70

ETB.23 Security rules for various environments ETB.24 Event driven job initiation / triggering ETB.25 Support of SOA ETB.26 Deployment web service as ETB.27 Loading of multiple heterogeneous targets ETB.28 Incremental loading of tables. ETB.29 Keying of fact tables to dimensions ETB.30 Template driven development ETB.31 Slowly Changing Dimensions (SCD) - Type 1, 2 and 3. ETB.32 Scheduling ETB.33 Resume from Last point ETB.34 Logging and Error report The tool should have ability to define separate security rules for various environments (Dev, QA and Production). The tool should support event driven job initiation / triggering. The tool should support SOA Architecture and Functionality for management of the publication and testing of data services. The tool should have ability to deploy/expose all aspects of runtime job as data services (for example, deployed functionality can be called via a Web services interface) The tool should have ability to load multiple heterogeneous targets at the same time. The tool should support for incremental loading of tables. The tool should have built-in support to ensure keying of fact tables to dimensions during the load. The tool should support template driven development, i.e. Reusability of Code/Workflows/Job/Parts of Job The tool should support for Slowly Changing Dimensions (SCD) - Type 1, 2 and 3. The tool should support for time based and event based scheduling. In case of system/network failure, the proposed capture system should be able to resume from where it left. The tool should support job logging and error reporting. Page 52 of 70

POC Requirements and Use Case OVERVIEW Annexure IV POC The Objective of POC is to prove the key System capabilities stated in the Bid, through a series of unit, concurrent and end-to-end scenarios described in the use cases given below. Bidder should conduct the POC to show the end-to-end capability of ETL, database and BI (reporting & analysis). POC will be divided in two parts as follows: 1. EDW solution Performance POC 2. Feature Demonstration POC INSTRUCTIONS FOR POC 1. CRIS will provide the sample data for conducting POC to the bidders who fulfils the condition as mentioned in Table 2 - Eligibility for bidding as mentioned in section 3.0. Along with the sample data CRIS will also give extrapolation logic, five SQL queries (Q1, Q2, Q3, Q4, and Q5) in ANSI format and instructions to execute POC. 2. The Bidder receiving sample data for POC shall sign a non-disclosure agreement as mentioned in Annexure - V. 3. The queries should be executed against the base tables (i.e. without using any summary tables, index, materialized views or without using any hints to influence the performance of the database or query). 4. Any Change in query logic and data format change in terms of I/P and O/P is not allowed. All queries must be executed on non-indexed data. Bidder will not optimize the query and will not change any parameter in database to fasten the query execution. 5. The bidder is allowed to partition the data and Key used for partitioning will be the SQNCNUMB (the extra column added to all tables for extrapolation of data). Syntax change and changes for similar functionality (without changing the order of filters) with respect to EDW database is allowed only in case the query cannot be executed in the given format on proposed DB. Any such change in syntax need to be mentioned with submitted POC result (if CRIS finds that the query can be executed without such change the result submitted by bidder will not be considered for evaluation). 6. The query must not be in system cache before executing each use case. 7. The decision taken by CRIS shall be binding to both parties. Page 53 of 70

POC REPORT BY BIDDER Bidder has to submit the POC results in the POC response sheet (table 25 & 26) provided below against each use case. Bidder has to provide the system configuration logs and use case execution logs at the time of bid submission. Under any circumstance if any additional step is taken apart from the defined scope then it should be disclosed in the results. PREPARATION OF SOURCE AND TARGET SYSTEMS The bidder is advised to conduct the POC at their own premises using exactly the same hardware and software configuration that is proposed in the bid. Also bidder has to simulate source systems with configurations as provided in RFP document for performing given use-cases. Bidder will load the data from oracle dump (provided by CRIS) to the oracle source prepared by Bidder. Bidder will extrapolate the data N=65 for making data up to 20 TB times (N is number that many times data is duplicated by extrapolation script given by CRIS) as per the extrapolated logic given to bidder. Bidder will load all the extrapolated data to target system. After populating target system bidder will remove the extrapolated copies with SQNCNUMB >= 14. Bidder will execute use Case 1.1 & 1.2 on data 4 TB (approx) and after finishing the use case 1.2, bidder will remove the extrapolated data from source system and source will keep only one copy of original data with SQNCNUMB = N + 1 (for rest of all use cases). So before executing each use case the source and target will have the data as mentioned below: - Size Before Execution of Use cases Use case Source System Target System Use case 1.1 (N/5) Times (N) Times Use case 1.2 (N/5) Times All Data available at end of Use Case 1.1 (more than N Times) Use case 1.3 1 copy of Data with All Data available at end of Use Case SQNCNUMB = (N+1) 1.2 (more than N Times) Use case 1.4 1 copy of Data with All Data available at end of Use Case SQNCNUMB = (N+2) 1.3 (more than N + 1 Times) Use case 1.5 1 copy of Data with All Data available at end of Use Case SQNCNUMB = (N+2) 1.4 (more than N + 2 Times) Use case 1.6 1 copy of Data with All Data available at end of Use Case SQNCNUMB = (N+2) 1.5 (more than N + 2 Times) Use case 1.7 N/A All Data available at end of Use Case 1.6 (more than N + 2 Times) Use case 1.8 N/A All Data available at end of Use Case 1.7 (more than N + 2 Times) Page 54 of 70

Use case 1.9 N/A All Data available at end of Use Case 1.8 (more than N + 2 Times) Use case 1.10 N/A All Data available at end of Use Case 1.9 (more than N + 2 Times) Page 55 of 70

EDW SOLUTION PERFORMANCE POC: USE CASE 1.1 Transformation capabilities of ETL Purpose: a) Source system should have extrapolated data (N/5 times of the given data) and Target system should have extrapolated data (N times of the given data). b) Accuracy of Data Transformation between Source and Target System. c) Efficiency of Data Loading between Source and Target System. Pre-Condition: a) CRIS will provide table level or attribute level mapping between Source and Target Database. b) CRIS will provide a query to be transformed through ETL tool. Result of use case: This use case will give the time taken by ETL tool to populate the target system. USE CASE 1.2 Transformation capabilities of ETL to populate Facts and dimensions Purpose: a) Source system should have extrapolated data (N/5 times of the given data) and target system should have data available at end of use case 1.1 (more than N times). b) Accuracy of facts population. c) Efficiency of population of facts and dimensions. Pre-Condition - CRIS will provide the following: a) CRIS will provide table level or attribute level mapping between Source and Target Database. b) Required information to populate dimensions. c) CRIS will provide query to be transformed along with facts and Dimension definition. Bidder has to create job for population based on query given. Result of use case: This use case will give the time taken to populate the facts and Dimension by ETL tool on target system. USE CASE 1.3 Bulk Load of data through ETL Purpose: a) Efficiency of Data Loading between Source and Target System. Pre-Condition: Page 56 of 70

a) Source should have only one copy of data with SQNCNUMB = N + 1 and Target System should have data available at end of use case 1.2 (more than N times). b) Bidder will load the data from source (one copy of given data) to target only through ETL tool. General Clarifications: - CRIS is looking for Source Database to Target Database bulk loading through ETL tool. Even if Flat file approach is being adopted by BIDDER to load data, CRIS is looking for complete time to extract data from the source to load data in target Database using ETL (i.e. in this case total time will be sum of time to create flat file and time to load it to target DB). Additionally it would be better to provide load rate from flat file data to Target database. Bidder can create multiple parallel processes to load different tables but is not allowed to split single table over two processes. Result of use case: This use case will give the bulk data loading rate in GB/Hour. USE CASE 1.4 Bulk Load of data through ETL in Mixed workload Environment Purpose: a) Efficiency of Data Loading between Source and Target System. b) Efficiency of queries (average response time) separately for each query. c) Efficiency of ETL Transformation Job to populate facts and Dimensions. Pre-Condition: a) Source should have only one copy of data with SQNCNUMB = N + 2 and Target System should have data available at end of use case 1.3 (more than N + 1 time). b) Bidder will load the data from source (one copy of given data) to target only through ETL tool. c) After 5 minutes bidder will start total 50 concurrent query sessions (10 of each query) in parallel for Q1, Q2, Q3, Q4 and Q5. d) After completion of all sessions of Queries fired in above point(c) bidder will wait for 15 minutes and start execution of ETL transformation job to populate Facts and Dimensions along with total 50 concurrent query sessions (10 of each query) in parallel for Q1, Q2, Q3, Q4 and Q5. (if the bulk load from source to target got completed by this time, bidder will restart the bulk load job). e) CRIS will provide query to be transformed along with facts and Dimension definition. Result of use case: 1. Bidder has to submit the Data loading rate in GB/Hour. Page 57 of 70

2. Bidder has to submit the average running time of each query at the time of loading is in process before start of ETL transaction job. 3. Bidder has to submit the Completion Time of ETL transformation job to populate Facts and Dimensions. 4. Bidder has to submit the average running time of each query at the time of loading is in process after start of transaction job. Here maximum of 5% deviation is permitted in the average running time of each query with respect to average running time of each query before start of ETL transaction job. USE CASE 1.5 Bulk Load of heterogeneous data through ETL Purpose: a) Efficiency of heterogeneous Data Loading between Source machine and Target System. Pre-Condition: a) Source should have only one copy of data with SQNCNUMB = N + 2 and Target System should have data available at end of use case 1.4 (more than N + 2 time). b) 50 GB of Video, 25 GB of Images, 5 GB of pdf, 5 GB of XML data. Bidder will arrange required data himself. Result of use case: This use case will give the Loading Rate in GB/Hr through ETL tool. USE CASE 1.6 CDC performance test cases of source system Purpose: a) Accuracy of Data capture between Source and Target System. b) Load on source system due to CDC agent. Pre-Condition: a) Source should have only one copy of data with SQNCNUMB = N + 2 and Target System should have data available at end of use case 1.5 (more than N + 2 time). b) CRIS will provide a table structure and data. c) CRIS will provide DML statements to change the source system data. Result of use case: 1. CPU utilization Factor (MAX and AVG) on the source system. 2. Increase in memory utilization on source system which is the difference of maximum memory utilization during CDC to memory utilization of ideal system before CDC. Page 58 of 70

USE CASE 1.7 Query performance and Control mechanism Purpose: a) Accuracy in execution & subsequently final result set. b) Efficiency in execution of queries on warehouse DB. Pre-Condition: a) Target System should have data available at end of use case 1.6 (more than N + 2 time). b) Queries need to be executed independently, i.e. no other job or activity running on system. Result of use case: Bidder has to submit response time of each given queries (Q1 to Q5) in Seconds. USE CASE 1.8 To assess the Query Concurrency of the proposed solution Purpose: a) Judge the efficiency of system while concurrency in terms of query running time. Pre-Condition: a) Target System should have data available at end of use case 1.7 (more than N + 2 time). b) For this use case bidder will use only sample query Q4. Bidder will execute the use case three times as mentioned under Evaluation parameter. Result of use case: This use case will give the average response time of concurrent sessions in seconds. USE CASE 1.9 Data Compression and Query Performance Purpose: a) Data Compression ratio. b) Query performance on compressed data Pre-Condition: a) Target System should have data available at end of use case 1.8 (more than N + 2 time). b) There should not be any manual intervention to query on compressed data. c) Tables used in Query Q4 along with REH_WGON will be selected for the compression of data. d) Bidder will use sample query Q4 only for this use case. Page 59 of 70

Result of use case: 1. Data Compression Ratio. 2. Response time of query Q4 in seconds. USE CASE 1.10 Stress Testing at BI Layer Purpose: a) Demonstration of BI layer stress testing in terms of time required to generate the report. Pre-Condition a) Target System should have data available at end of use case 1.9 (more than N + 2 time). b) Bidder has to demonstrate this use case on Sample report provided by CRIS. Bidder has to make the report to accept two input parameters Zone and Date from the specified domain as given in instructions. c) Bidder will perform this use case using some standard load test tool for concurrent sessions as mentioned in RFP for the concurrent users of BI. Result of use case: Bidder has to reply in Average report generation time is seconds. Page 60 of 70

FEATURES DEMONSTRATION POC: Bidders may note that the features which are to be demonstrated in this POC are mandatory and compliance for the same has been given by the bidder in the Feature Compliance Matrix. USE CASE 2.1 Connectivity with Heterogeneous data sources Purpose: a) Connectivity with ORACLE, SYBASE ASE, SYBASE IQ, DB2, and Flat file. Pre-Condition: a) Configuration of systems to simulate Source is provided in RFP. Result of use case: Bidder has to reply as number (0/1/2/3) based on the way functionality is provided as mentioned under evaluation parameter against each data base for which connectivity supported. USE CASE 2.2 Report Tests and BI Functionalities Purpose: a) Demonstration of Sample report to showcase all the listed BI features as follows: 1. Generation of Pixel Perfect Report 2. Totals and Subtotals Definition 3. Highlight/Format of columns and partial data in columns 4. Scheduling of Reports 5. Multilingual Support (for demonstration English and Hindi Only 6. Selective print and export to PDF/DOC/EXCEL etc. 7. Widgets Support 8. Demonstration of Office compatibility (live data) 9. Drill Down and Drill Up and Drill Through 10. Alerts to user (to mobile or to mail or to client) Pre-Condition a) Bidder will demonstrate the above features through samples report and POC instructions provide by CRIS. Result of use case: Bidder has to reply in Yes against each feature supported otherwise No. Page 61 of 70

Table 25 EDW solution Performance POC Response Sheet EDW solution Performance POC Use Cases Response sheet Parameters for Use Case Result type Result Remarks USE CASE 1.1 Transformation capabilities of ETL Response Time Time taken by ETL job to execute (in seconds) USE CASE 1.2 Transformation capabilities of ETL to populate Facts and dimensions Response Time Time taken by ETL to populate the facts and Dimension. (in seconds) USE CASE 1.3 Bulk Load of data through ETL Normal Loading Loading Rate (GB/Hour) USE CASE 1.4 Bulk Load of data through ETL in Mixed workload Environment Loading Rate Loading Rate (GB/Hour) Query performance in Running Time of Q1 Mixed Workload query session (in Environment before seconds) Transformation Job. Running Time of Q2 query session (in seconds) Running Time of Q3 query session (in seconds) Running Time of Q4 query session (in seconds) Running Time of Q5 query session (in Completion Time of ETL transformation job to populate Facts and Dimensions. Query performance in Mixed Workload Environment with Transformation Job. seconds) Time taken by ETL to populate the facts and Dimension. (in seconds) Running Time of Q1 query session (in seconds) Running Time of Q2 query session (in Page 62 of 70

seconds) Running Time of Q3 query session (in seconds) Running Time of Q4 query session (in seconds) Running Time of Q5 query session (in seconds) USE CASE 1.5 Bulk Load of heterogeneous data through ETL Heterogeneous Data Loading Rate Loading (GB/Hour) USE CASE 1.6 CDC performance test cases of source system CPU utilization Factor (MAX Average CPU and Average on the source system) Utilization (In %) Maximum CPU Utilization (In %) Memory utilization Factor Increase in memory on Source system utilization on source system which is the difference of maximum memory utilization during CDC to memory utilization of ideal system before CDC. USE CASE 1.7 Query performance and Control mechanism Execution of Q1 Query Response time (in seconds) Execution of Q2 Query Response time (in seconds) Execution of Q3 Query Response time (in seconds) Execution of Q4 Query Response time (in seconds) Execution of Q5 Query Response time (in Seconds) USE CASE 1.8 To assess the Query Concurrency of the proposed solution One fourth (1/4) of the Average Response concurrent sessions of Q4 time (in seconds) as required in RFP Page 63 of 70

Half (1/2) of the concurrent sessions of Q4 as required in RFP Average Response time (in seconds) Equal to the concurrent sessions of Q4 as required in RFP Average Response time (in seconds) USE CASE 1.9 Data Compression and Query Performance Data compression ratio In % Query performance on compressed data Response time (in seconds) USE CASE 1.10 Stress Testing at BI Layer Average Report generation Average report time on BI with concurrent generation time in sessions equal to as seconds mentioned in RFP Page 64 of 70

Table 26 Feature Demonstration POC Response Sheet Feature Demonstration POC Use Cases Response sheet Parameters for Use Case Result type Result Remarks USE CASE 2.1 Connectivity with Heterogeneous data sources Connectivity with Oracle Bidder has to reply as number (0/1/2/3) based Connectivity with Sybase on the way functionality ASE is provided as Connectivity with Sybase IQ mentioned under evaluation parameter. Connectivity with DB2 Connectivity with Flat file USE CASE 2.2 Report Tests and BI Functionalities Generation of Pixel Perfect Y/N Report Totals and Subtotals Y/N Definition Highlight/Format of columns Y/N and partial data in columns Scheduling of Reports Multilingual Support (for demonstration English and Hindi Only) Selective print and export to PDF/DOC/EXCEL Widgets Support Demonstration of Office compatibility (live data) Drill Down and Drill Up and Drill Through Alerts to user (to mobile or to mail or to client) Y/N Y/N Y/N Y/N Y/N Y/N Y/N Page 65 of 70

Annexure - V Non-Disclosure Agreement for Use of Data for POC I, <Name and Designation> signatory authority on behalf of <Prime Bidder s Company Name> with registered Indian office address at <Prime Bidder s address> declares the following: - It is understood and agreed to that the discloser of confidential information may provide certain information that is and must be kept confidential. To ensure the protection of such information and to preserve any confidentiality necessary, it is agreed based on following conditions. 1. Data provided by CRIS will not be sold and only be used to perform POC for tender FOIS EDW Solution and not to be used for any other purposes. 2. I agree not to disclose/share the information and derived information obtained from the CRIS to anyone. Name and Address: Signature: Date: Location: Page 66 of 70

Annexure - VI Mandatory Items The items mentioned below are mandatory and must be provided by the bidder, failure in doing so will lead to rejection of the bid. Bidder should note that the scope of work is as given in section 4.0 of the tender document and not in any way limited to the mandatory items indicated below: Sr. No. Items 1 Each product (hardware, operating system & other software) proposed in the solution must have clear roadmap for upgrade, update, patches and support for next 5 years from the bid submission date. References of tender document 4.1.1.1 2 Escalation matrix for hardware and software 4.1.1.17 3 Number of Rack not exceeding 4 (four) 4.5.1 4 Maximum rated power per rack is not more than 6 KVA 4.5.2 5 The database component provided should be a standard Enterprise Data Warehouse appliance. All the components within the appliance must be configured in active - active, no active - passive configuration is allowed. 6 The hardware, other than database appliance must be configured in blade architecture 7 Blade chassis and servers must be in redundancy and configured in HA across chassis. 8 Each software (other than database appliance) of EDW solution must be configured in cluster (Active-Active) and across blade chassis. 9 Operating system should preferably be a proprietary operating system of the hardware OEM or any industry leading enterprise class Linux operating system. 10 In case of Linux operating system, the L1 & L2 support must be directly provided by the hardware OEM and in case of L3 & L4 support the hardware OEM is solely responsible to communicate with operating system s technical support to resolve any issue. 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.9 Compliance from bidder Page 67 of 70

11 In case of idle situation (i.e. no user load) of the solution, the CPU and memory utilization of each hardware component of the entire EDW solution should never cross the 30% threshold value. 12 In case of user load situation (not in failover condition) after go live (i.e. Phase 1 as given in tentative plan as per section 4.3) the CPU and memory utilization of each hardware component of the entire EDW solution should never cross 60% threshold value. 13 The proposed backup setup must have the capability to backup the data of each component (database, application data, application codes, operating system, etc.) and metadata across all the sub systems on to the mentioned device. 14 The proposed solution should provide mechanism for incremental and full database backups with zero down time. 15 The SAN and network speed within the solution must be at least of 10Gbps or above. 16 Bidder has to mention clearly and separately the unit cost of supplied software and hardware including licenses. The bidder has to keep on hold the said unit price for 3 Years for any additional requirement considered necessary by CRIS for future enhancement of the project 17 All the software licenses must be perpetual and should not be user based for any tool. No of users mentioned in tender document must only be used for sizing and not for licensing purpose 18 All support must be directly from OEM. The back to back arrangement agreement for the same must be enclosed and signed by signatory authority of bidder and OEM 4.6.1 4.6.2 4.8.1 4.8.2 4.11.2 4.15.3 4.15.4 4.22.3 Page 68 of 70

Annexure - VII Schedule of Rates The price bid should be submitted in a separate envelope duly signed and sealed. Bids received with price bids in envelopes, which are not properly sealed and/or merely stapled are liable to be rejected. Details of Schedule Of Rates Schedule Of Rates Sr. No. Item Hardware Cost Qty Product offered (Model/ Make/Version) Unit Cost Taxes as amount Unit Cost with Tax Total Cost (A) (B) (C) (D) (A*D) Total Value of Hardware Offer(X) Software License Cost Total Value of Software Offer (Y) Professional Services Consultancy for 1 software development support (as per Form 1) 2 Training (as per Form 2) Total Value of Professional Services Offer (Z) Total Value of The Offer (X+Y+Z) Support Charges for the 4 th Year Support Charges for the 5 th Year Note: The schedule of rates are divided into broad heads, the bidders are supposed to make their own list based on the actual items that is being proposed in the solution and is to be supplied under these main heads. Also Support charges for 4 th & 5 th year will not be taken for financial evaluation. Page 69 of 70

Form 1: Solution Development Support Charges as per Section 5.0 Name of the OEM/product OEM Solution Development Support Charges Cost of Technical Number of Total Resource per Engineers Base day Provided Rate Taxes Total Cost Form 2: Training Charges as per Section 4.9 Component LDM Designing (Only Experts) Data Warehouse Database OLAP/Star Schema designing ETL Near Real Time Data Integration/CDC BI layer OS Any other tool Provided by Bidder Total One Person Price (A) Total number of persons (B) Total Cost (A*B) Page 70 of 70