REQUEST FOR PROPOSAL (RFP) FOR SELECTION OF
SYSTEM INTEGRATOR
TO
PROCURE, DESIGN, DEVELOP, INTEGRATE, MAINTAIN AND ENHANCE APPLICATION & SERVICES ON UNIFIED TICKETING SOLUTION FOR TICKETING AND ALLIED ACTIVITIES UNDER BOOT (BUILD, OWN, OPERATE, TRANSFER) MODEL
in APSRTC
February,2021 Tendering Agency APSRTC, GoAP 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 013
Page 1 of 223 Intentionally Left Blank
Page 2 of 223 Proprietary & Confidential
No part of this document can be reproduced in any form or by any means, disclosed or distributed to any person without the prior consent of the APSRTC except to the extent required for submitting a proposal and no more.
Page 3 of 223 Request for Proposal (RFP) Structure
This Request for Proposal (RFP) is meant to invite proposals from interested system integrators (SI) capable of delivering the services described herein. The content of this RFP has been acknowledged in Single volume explained in following document.
Page 4 of 223 OFFICE OF THE VC & MD, APSRTC NOTICE
ANDHRA PRADESH STATE ROAD TRANSPORT CORPORATION
Request for Proposal - Call Notice for “Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Ticketing Solution for Ticketing and other Allied activities under BOOT model in APSRTC, Government of Andhra Pradesh”
Time schedule of various Proposal related events:
Release of Request for Proposal (RFP) 26.02.2021, 11: 00 Hrs
Last date for submission of online questions 03.03.2021, 16: Hrs by bidders
Pre-Bid Conference 08.03.2021, 11:00 Hrs
Date of Issue of Clarifications 15.03.2021, 16:00 Hrs
Start date for Submission of bids 24.03.2021, 11:00 Hrs
Last date for Submission of bids 25.03.2021, 16:00 Hrs
Last date for Submission of Hard Copy of bids 25.03.2021, 16:00 Hrs at APSRTC HO in Sealed covers.
Pre-Qualification Bid Opening Date 26.03.2021, 11:00 Hrs
Technical-Bid Evaluation Bid opening date will be communicated to qualified bidders Commercial-Bid Opening Date
RFP Document Cost Rs. 20,000 (Twenty Thousand only) + 18% GST
Contact points from APSRTC Mr K Madhava Trinadh
[email protected], [email protected] Contact Details of POC Mob. +91-9959224312
For further details please visit https://apsrtc.ap.gov.in/Other%20Contract%20Works.php
Chief Engineer (IT), Andhra Pradesh State Road Transport Corporation, 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 013, India Page 5 of 223 Note: The document will be made available in APSRTC website for download. The fee for RFP shall be remitted in the form of a Demand Draft/Banker's cheque in favour of “FA&CAO, APSRTC” Payable at Vijayawada, before the stipulated time and date of bid submission
The document fee may also be paid into the current account number of FA & CAO of APSRTC through NEFT / RTGS only at least 24 hrs. in advance. The details of account 1.Name of the Account FA & CAO 2.Current Account Number 62472413226 3.IFSC Code SBIN0020169 4.Name of the Bank State Bank of India The details with UTR number shall be mailed to [email protected] and [email protected]
.
Page 6 of 223 Notice Inviting Proposal (NIP)
Name of work – Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Ticketing Solutions for Ticketing and other Allied activities under BOOT model in APSRTC, Government of Andhra Pradesh.
On behalf of the Public Transport Department, Government of Andhra Pradesh (“GoAP”), the VC & MD, APSRTC, Government of Andhra Pradesh, invites eligible and competent Proposers to submit their qualification, technical and commercial proposals for the selection to Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Ticketing Solutions for Ticketing and other Allied activities under BOOT model in APSRTC, in accordance with conditions and manner prescribed in this Request for Proposal (RFP) and other Proposal Documents issued by APSRTC, GoAP, which is available on its website https://apsrtc.ap.gov.in/Other%20Contract%20Works.php ).
VC & MD, APSRTC reserves the right to cancel any or all proposals without assigning any reason at any time during the tendering process.
Sd/- VC & MD, APSRTC
Page 7 of 223 Procedure to Submit proposal on MSTC e-commerce Platform:
Procedure for Bid Submission
The Bidder shall submit their response through document submission process on e-Procurement platform at https://www.mstcecommerce.com by following the procedure given below:
The Proposer would be required to register on the e-procurement platform https://www.mstcecommerce.com and submit their proposals online.
The Proposers shall submit their necessary documents for proposal online in e-Procurement web site. The Proposers shall upload the scanned copies of all the relevant certificates, documents, etc., in support of their Pre-Qualification and other certificates/documents with clear readability, in the e-Procurement web site. The Proposer should sign on all the statements, documents, certificates uploaded in the e-Procurement website, owning responsibility for their correctness/authenticity.
In case any Proposer is not able to upload the entire set of documents on https://www.mstcecommerce.com platform either due to space/size constraint or any other technical hitches, only in such cases, the relevant hard copies of the left over documents which could not be uploaded https://www.mstcecommerce.com platform may be submitted in sealed covers in APSRTC office located at 1st Floor, NTR Administrative Block, Pandit Nehru Bus Station, NH-65, Vijayawada, Andhra Pradesh, before the stipulated closure time of proposal submission. A self-certificate from the Proposer in this regard detailing the reasons for submitting the hard copies, if any, duly bringing out issues faced in uploading them on e-procurement platform, if any, shall also be submitted. The uploaded documents on the e-procurement platform and the hard copies submitted in sealed covers, if any, together will be treated as a single set of documents under a proposal and will be evaluated accordingly.
Registration with e-Procurement platform: For registration and online proposal submission Proposers may contact HELP DESK on https:// www.mstcecommerce.com or
MSTC LIMITED, 4th Floor “JEEVAN SAMRIDDHI”, D. No. 42-1-45/1/1, New Investment Building, Thikkana Road Floor, Visakhapatnam - 530 004. [email protected] e-mail id: [email protected], Ph No. 0891-2701066 e-mail id: [email protected] Ph No. 9989719979
GSTN No: 37AAGFA3527J2ZF (APSRTC) and GSTN No: 37AACCM0021E1Z6 (MSTC)
Page 8 of 223 Terms of use of Services for Vendors:
1. MSTC Limited shall be hereinafter referred to as "MSTC" or Administrator/Application Service Provider. The participating parties or individuals shall be hereinafter referred to as vendors. 2. The organisation (APSRTC) who is the purchaser of goods, works or services through the e- Procurement system shall be hereinafter referred to as Buyers. 3. The e-Procurement system may invite bids from vendors through the process of e-tender, Reverser e- Auction, Reverse e-Auction with quantity cum price bid or any other mode. 4. This set of terms and conditions is general in nature and is a part and parcel of the terms and conditions of use of e-Procurement services. 5. Vendors have to fulfil all contractual liabilities arising out of the bids submitted by them on this e- procurement system. All procurement contracts subsequent to use of the e-Procurement system shall be entered into between the Buyers and the Vendors and MSTC shall not be a party in any such contract. 6. Only registered vendors shall be eligible to participate in any e-procurement event conducted on MSTC’s e-procurement system. 7. Vendors are required to register with MSTC portal online as per proforma followed by submission of documents and/or fees to the buyer for whom such registration has been sought. The buyer shall decide the list of documents and the fees and shall be intimated to the vendors as soon as the vendors submit the on-line registration form. The vendors would generate their own user ID and password. Such vendors will be listed as registered vendors. No vendors without registration with MSTC portal will be able to bid for e-Procurement. 8. Mere registration will not confer any right upon the vendors to participate in the e-Procurement. 9. Depending on the type of the e-procurement (Open/Global/Limited), a participation of vendors will be restricted. For Open type, all registered and activated vendors shall be eligible to participate in the bidding whereas for Limited type events, only such vendors will have access who will be pre-qualified by the Buyer. 10. The details of the e-procurement event shall be available to vendors through their logins in the form of NIT or Corrigendum. Un-registered vendors shall be able to download the NIT/corrigendum by submitting some details. 11. Vendors are required to have their own and valid Digital Signature Certificates (DSCs). Each vendor shall need his signing type DSC to sign and log in. During saving his bid in e-tender before final submission, a vendor shall need to have his encryption type DSC. 12. Vendors are required to note that only one DSC will be allowed to be used with a user id. DSCs are non-transferable. 13. By registering with MSTC’s e-procurement website, Vendors agree not to use, display, upload, modify, publish, transmit, update, share or store any information that i. Belongs to another person, ii. Is harmful, threatening, abusive, harassing, blasphemous, objectionable, defamatory, vulgar, obscene, pornographic, paedophilic, libellous, invasive of another’s privacy, hateful, or racially, ethically or otherwise objectionable, disparaging, relating or encouraging money laundering or gambling, or otherwise unlawful in any manner whatsoever; iii. Harm minors in any way, iv. Infringes any patent, trademark, copyright or other proprietary rights; v. Violates any law for the time being in force;
Page 9 of 223 vi. Discloses sensitive personal information of other person or to which the user does not have any right to; vii.Causes annoyance or inconvenience or deceives or misleads the addressee about the origin of such messages or communicates any information which is grossly offensive or menacing in nature; viii.Impersonate another person; ix. Contains software viruses or any other computer code, files or programs designed to interrupt, destroy or limit the functionality of any computer source; x. Threatens the unity, integrity, defence, security or sovereignty of India, friendly relations with foreign states, or public order or causes incitement to the commission of any cognizable offence or prevents investigation of any offence or is insulting to any other nation. 14.Vendors agree that MSTC shall be at liberty to de-register or suspend the registration of any Vendor due to their misusing of the facilities provided or due to any non-compliance of statutory guidelines / above instructions or due to any infringement which is not as per the extent law of the land. 15.Vendors agree that MSTC has taken all possible measures to safeguard the business interest of vendors and MSTC does not discriminate between vendors. 16.Vendors agree to keep MSTC indemnified against any loss incurred by them due to non-functioning or malfunctioning of MSTC’s e-procurement system owing to technical reason beyond the control of MSTC. 17.The vendor acknowledges and agrees that wherever applicable, the content, including but not limited to text, software, music, sound photographs, graphics, video, or other material contained in website, including advertisements or information is protected by domestic and international copyrights, trademarks, service marks, patents, or other proprietary right and laws. The vendors is permitted to utilise this material and information only for intended use, and shall not copy, reproduce, transmit, distribute, or create derivative works of such content or information without express authorisation. MSTC/buyer shall not be held liable for any misuse or infringement of any trademark or copyright by the vendor, and the vendor shall be solely liable for any damages, claims, actions etc. for infringement or violation of the same. MSTC/buyer reserves the right at its sole discretion to terminate the access of the vendor to the website, if the vendor violates the provisions of this clause. 18.Only the Courts at Vijayawada or the High Court of Andhra Pradesh, shall have the exclusive jurisdiction to entertain any dispute or any other matter or claim arising out of or in connection with the E- procurement. 19.FORCE MAJEURE: For any delay in performance due to any reason/cause beyond their control including fires, floods, go-slow, lockout, closure, pestilence, dispute with staff, dislocation of normal working condition, war, riots, epidemics, political upheavals, government action, civil commotion, breakdown of machinery including technical failures, shortage of labour, acts demands or otherwise or any other cause or conditions beyond the control of aforesaid cause or not and the existence of such cause or consequence MSTC / Buyer may extend the time of performance by such period as may be necessary to enable MSTC/Buyer to effect performance after such cause of delay will have ceased to exist. The provisions aforesaid shall not be limited or abrogated by any other terms of the contract whether printed or written. 20.Vendors agree not to test the e-procurement system with false bids. The risk and consequence of any such false bids lies exclusively with the Vendor and MSTC/Buyer will be at liberty to take penal action against such Vendor as deemed fit. 21.By registering with MSTC’s e-procurement system, Vendors agree to pay transaction charges to MSTC on event basis. Such payment can be made by the Vendors either on-line or off-line as notified from time to time. The Vendor further agrees that if he fails to pay the transaction fee to MSTC before bidding in the e-procurement system, he should pay the same to MSTC forthwith on receipt of demand from MSTC. Failure to pay the transaction fee even after receipt of demand by MSTC, the Vendor’s user account in the e-procurement system may be suspended or cancelled by MSTC. Page 10 of 223 22.Vendors agree that the terms and conditions of events as notified in the NIT / Corrigendum by the Buyer shall be read in conjunction with these terms and conditions. In case of any clash in the meaning / interpretation of the terms and conditions, the terms and conditions mentioned in the NIT / Corrigendum shall prevail. 23.MSTC reserves the right to modify these terms and conditions from time to time. Vendors are requested to periodically check these terms and conditions for updates.
For obtaining Digital Signature Certificate, you may contact:
https://www.mstcecommerce.com
Hard copies:
All the Proposers shall submit the hardcopies of the payment receipts towards the proposal processing fee in APSRTC office at Vijayawada before proposal due date. All the Proposers shall invariably upload the scanned copies of payment receipts in e-Procurement system and this will be the primary requirement to consider the proposal responsive.
1. APSRTC shall carry out the technical evaluation solely based on the uploaded certificates/documents, payment receipts towards EMD (if applicable) in the e-Procurement system and open the price proposals of the responsive and technically qualified Proposers only. 2. APSRTC will notify the successful Proposer for submission of original hardcopies of all the uploaded documents and payment receipts towards EMD (if applicable) prior to entering into the agreement. 3. The successful Proposer shall invariably furnish the original payment receipts towards EMD (if applicable); Certificates/Documents of the uploaded scanned copies to the RFP Inviting Authority before entering into agreement, either personally or through courier or post and the receipt of the same within the stipulated date shall be the responsibility of the successful Proposer. APSRTC will not take any responsibility for any delay in receipt/non-receipt of original payment receipts towards EMD (if applicable), Certificates/Documents from the successful Proposer before the stipulated date and time. 4. On receipt of documents, APSRTC shall ensure the genuineness of the payment receipts towards EMD (if applicable) and all other certificates/documents uploaded by the Proposer in e-Procurement system in support of the qualification criteria before concluding the agreement.
Deactivation of Bidders at MSTC e-Procurement platform
If any successful Proposer fails to submit the original hard copies of uploaded certificates/documents within stipulated time or if any variation is noticed between the uploaded documents and the hardcopies submitted by the Proposer, the successful Proposer will be suspended from participating in the RFPs on e-Procurement platform for a period of 3 years. The e-Procurement system would deactivate the user ID of such defaulting Proposer based on the trigger/recommendation by the RFP Inviting Authority in the system. Besides this, APSRTC shall invoke all processes of law including criminal prosecution of such defaulting Proposer as an act of extreme deterrence to avoid delays in the RFP process for execution of the development schemes taken up by the government. Other conditions as per RFP document are applicable.
Page 11 of 223 MSTC’s e-Procurement Portal Guidelines for Bidders:
Detailed guidelines and process may be obtained from MSTSC portal. Bidders are advised to keep checking the latest guidelines from the website to keep themselves updated. They may also contact the offices of MSTC to seek clarification on any point. MSTC shall not be responsible for any mistake committed by any bidder or for any consequent loss to the bidder due to misunderstanding anything written in the Annexure B. The Proposer is requested to get a confirmed acknowledgement from the RFP Inviting Authority as a proof of Hardcopies submission to avoid any discrepancy.
RFP Document:
The Proposer is requested to download the RFP document and read all the terms and conditions mentioned in the RFP Document and seek clarifications if any from the RFP Inviting Authority. Any offline proposal submission clause in the RFP document could be neglected.
The Proposer has to keep track of any changes by viewing the Addendum/Corrigenda issued by the RFP Inviting Authority from time-to-time in the e-Procurement platform. The Department calling for RFPs shall not be responsible for any claims/issues arising out of this.
Bid Submission Acknowledgement:
The Proposer shall complete all the processes and steps required for Bid submission. The system will generate an acknowledgement with a unique proposal submission number after completing all the prescribed steps and processes by the Proposer. Users may also note that the proposals for which an acknowledgement is not generated by the e-procurement system are treated as invalid or not saved in the system. Such invalid proposals are not made available to the RFP Inviting Authority for processing the proposals. The APSRTC and Government of AP are not responsible for incomplete proposal submission by users.
1. The Proposers may contact APSRTC for any further information / clarifications on e-procurement. 2. The Proposers need to register on the electronic procurement market place i.e., https:// www.mstcecommerce.com. On registration in the e-procurement market place they will be provided with a user ID and password by the system using which they can submit their proposals on line. 3. While registering on the e-procurement market place, the Proposers need to scan and upload the required documents as per the RFP requirements on to their profile. The e-procurement market place provides an online self-service registration facility to all such Contractors who are already registered with respective participating departments for supply of specified goods and services. 4. All the Proposers shall invariably upload the scanned copies of RTGS/NEFT in e-Procurement system and this will be the primary requirement to consider the proposal as responsive. The Department shall carry out the Technical proposal evaluation solely based on the uploaded certificates/documents, RTGS/NEFT towards EMD (if applicable) in the e-procurement system and open the price proposal of only the technically eligible and responsive Proposers. The Department will notify the successful Proposer for submission of original hard copies of all uploaded documents and RTGS/NEFT towards EMD (if applicable) prior to entering into agreement. 5. The Proposers shall furnish a declaration in online stating that the soft copies uploaded by them are genuine. Any incorrectness/deviation noticed will be viewed seriously and apart from cancelling the work duly forfeiting the EMD (if applicable), criminal action will be initiated including suspension of business. Page 12 of 223 Table of Contents
Intentionally Left Blank 2
Proprietary & Confidential 3
Request for Proposal (RFP) Structure 4
NOTICE 5
Notice Inviting Proposal (NIP) 7
Procedure to Submit proposal on MSTC e-commerce Platform: 8
Terms of use of Services for Vendors: 9
Table of Contents 13
Definitions 20
Disclaimer 26
Preamble 28
1. Purpose of the RFP 29
2. Schedule of Events 30
Tentative Calendar of Events 30
3. Introduction to APSRTC 31
3.1. Profile 31
3.2. Vision of APSRTC 31
3.3. Corporate Philosophy: 31
3.4. Guiding Principles of APSRTC 31
3.5. IT Initiatives in APSRTC: 32
3.6. Hierarchy of the Stake Holders 36
3.7. Project Awarding Committee: 36
3.8. Conflict Resolution Matrix 37
4. Introduction to Unified Ticketing Solution 38
4.1. Vision 38
4.2. Objectives 38
Page 13 of 223 4.3. Strategies 38
4.4. Thrust Areas 38
5. Functional Scope of the RFP 39
5.1. Overview 39
5.2. Online Passenger Reservation System (OPRS) 39
5.3. Automatic Fare Collection System (AFCS) 62
5.4. Pass Automation and Accountal System (PAAS) 67
5.5. Automatic Vehicle Location System (AVLS) 68
5.6. Passenger Information System (PIS) 72
5.7. Command Control Centre (CCC) 73
5.8. Cargo and Courier Management System 76
5.9. Multi-purpose integrated Mobile app for mTicketing and PIS 79
5.10. Web Portal 81
5.11. Dashboards 82
5.12. Reports 83
5.13. IT Infrastructure 95
5.14. Information and Infrastructure Standards 96
5.15. Requirements Gatherings Standards: 98
5.16. Design Standards 98
5.17. Integrations 99
5.18. Network and Security 99
5.19. Non-Functional Requirements 101
5.20. Capacity Building and Change Management 102
5.21. Documentation 103
5.22. Development Strategy 103
5.23. Change Request 103
5.24.Testing 104
5.25. Go Live Requirements 107
Page 14 of 223 5.26. Operations and Maintenance Requirements 107
6. Payment Terms 111
6.1. Method of Payment 111
6.2. Details of Transactions 111
6.3. Chargeable Transactions 111
6.4. Payment Cycle 113
6.5. Income Tax Rule Compliance 113
6.6. Liquidated Damages 113
6.7. Payment Schedules and Milestones 113
6.7.1. Payment Milestones 114
6.8. Assumptions for Counting of days for all the SLA and Timelines 115
7. Acceptance Criteria 116
7.1. Acceptance Criteria Definition 116
7.2. Acceptance Criteria Template 116
7.3. Acceptance Criteria for SI 116
7.4. Go Live Requirements 117
7.5. Code Review Checklist Template for Review 118
8. Service Level Agreement 119
8.1. Service Level Agreements 119
8.2. Definitions 119
8.3. Planned Down Time 120
8.4. Support Team Availability 120
8.5. Help Desk Team Availability 120
8.6. General 121
8.7. SLA Metrics 121
9. Terms and conditions 127
9.1. Contract Terms 127
9.2. Pre-Bid Conference 131
Page 15 of 223 9.3. Bidder Inquiries and APSRTC responses 132
9.4. Supplementary Information/Corrigendum/Amendment to the RFP 133
9.5. Proposal Preparation Costs 133
9.6. Right to terminate the process of RFP by APSRTC 133
9.7. Acceptance of part / whole bid / modification – Rights thereof 134
9.8. Authentication of Bids 134
9.9. Interlineations in Bids 134
9.10. Consortium Bids 134
9.11. Venue & Deadline for submission of proposals 135
9.12. Late Bids 135
9.13. Conditions under which this RFP is issued 135
9.14. Rights to the Content of the Proposal 135
9.15. Modification and Withdrawal of Proposals: 136
9.16. Non-Exclusivity 136
9.17. Legal Heir 136
9.18. Non-Conforming Proposals 136
9.19. Acknowledgement of Understanding of Terms 137
9.20. Offer Validity period 137
9.21. Language of Proposals 137
9.22. Termination of Contract 137
9.23. Exit from the project: 137
9.24. Non-Disclosure of Confidential Information 138
9.25. Criteria for Eligibility 141
1. Pre-Qualification Criteria 141
2. Pre-Qualification Documents 143
3. Technical Qualifications 145
4. Technical Qualification Documents 147
5. Commercial Proposal 148
Page 16 of 223 9.26. Performance Bank Guarantee (PBG/BG) 149
10. Bid Opening and Evaluation Process 150
10.1. Bid Opening 150
10.2. Bid Evaluation Process 150
1. Preliminary Scrutiny 150
2. Evaluation of Pre-Qualification Criteria 150
3. Evaluation of Technical Bids 150
4. Criteria for Technical Evaluation 151
5. Detailed Technical Evaluation Criteria 151
6. Technical Presentation 154
10.3. Commercial Bid Opening and Bid Evaluation 155
1. Bid Opening 155
2. Announcement of Bids 155
3. Clarification of Bids 155
4. Evaluation of Commercial Bids 155
11. Bid Submission Forms and Undertakings 159
11.1. Forms for Submission of Pre-Qualification 159
P1: Application Form 159
P2: Authorisation Letter 161
P3: Details of the Bidder 162
P4: Certificate of Incorporation 163
P5: Format for Self-Declaration on Blacklisting 164
P6: Pending Litigation 165
P7: Self-Declaration/Self- Certification (Conflict of Interest) 166
P8: Financial Strength Details: 167
P9: Project Experience Information Sheet 168
P10: Certification of the Organisations 169
P11: Proof of Bid Document Fee/Purchase 170
Page 17 of 223 P12: Proof of EMD Deposit 171
P13: Letter of Understanding and Commitment 172
P14: Additional Criteria on Public Procurement 173
P15: Details of Local Presence 174
P16: Copy of GST Certificate and TAN/TIN if available 175
P17: Copy of PAN 176
P18: MoU or Letter of Association between Bidder and Consortium Member 177
P19: Certifications ISO 9001:2008 or CMMi Level 3 or higher. 178
P20: Any other Documents 179
11.2 Technical Forms Evaluation Format 180
T1:Letter of Technical Proposal 180
(Company Letter head) 180
T2: Relevant Proposed Product Experience in Government Sector (PSU) 181
T3: Proposed Solution: 182
T4: Declaration for Bill of Material 183
T5: Project Management Framework, Proposed Approach and Methodology for the solution proposed. 185
T6: Work Plan and Resource allocation 186
Team Composition 186
T7: Data Migration/Extraction and Infrastructure Plan 187
T8: Takeover and Exit Management 188
T9: Help Desk, Support and Training Plan 189
T10: Workflow with Screenshots for Online Ticketing Solution 190
T11: Workflow with Screenshots of Operation Module Management 191
T12: Workflow with screenshots of Dynamic/Flexi fare System 192
T13: Workflow with Screenshots of Multi-Level Fare Structure System 193
T14: Workflow with Screenshots of Mobile App ticketing 194
T15: Workflow with Screenshots of Bus Pass Module. 195
Page 18 of 223 T16: Workflow with Screenshots of AVLS & PIS Mobile app. 196
T17: Workflow with Screenshots of Logistics Booking 197
T18: Workflow with Screenshots of Payment Modes and Integrations. 198
T19: Workflow with Screenshots of eWallet. 199
T20: Certificate on Average Tickets sold per day from all eligible projects. 200
T21: DC Tier-III or above or its equivalent certification. 201
T22: DR Tier-III or above or its equivalent certification. 202
11.3 Commercial Submission Forms 203
C1: Financial Proposal Submission Form 203
C2 (a) Product and its summary of components with IT infrastructure 204
C2 (b) Product and its summary of components (without Infrastructure) 205
C3 Product & its related Software 206
C4 Proposed Software Development Cost 207
C5 Data Migration/Extraction 208
C6 Capacity Building and Change Management 209
C7 Proposed Infrastructure (Hardware) for DC and DR 210
C8 Operations & Maintenance 211
C9 Additional Manpower Cost 212
12. Compliance Requirements: 213
Pre-Qualification Compliance: 213
Technical Compliance: 214
13. Additional Information: Average Transactions in FY 2018-19 and 2019-20 215
14. Additional Information: Average Transactions during Nov’20 to Jan’21 216
15. Sample Dashboards with actionable insights 217
16. Hardware Specifications: 220
Proposed Android ePOS/eTIM: 220
Proposed Mobile Phone Specifications: 221
Proposed LED Display Panel Specifications 222
Page 19 of 223 Definitions
Definitions
SNo Acronym Description 1 AFCS Automatic Fare Collection System 2 AIS Automotive Industry Standard 3 AP Andhra Pradesh State Road Transport Corporation 4 APCSOC Andhra Pradesh Cyber Security Operations Centre 5 API Application Program Interface 6 APN Access Point Name 7 APSRTC Andhra Pradesh State Road Transport Corporation 8 ATB Authorised Ticket Booking 9 AVLS Automatic Vehicle Locating System 10 B2C Business to Citizen 11 BAR Backup, Archive and Restore 12 BCP Business Continuity Plan 13 BG/PBG Bank Guarantee 14 BoM Bill of Materials 15 BQB Bluetooth Qualification Body 16 BRD Business Requirements Document 17 BSNL Bharat Sanchar Nigam Limited 18 CAD Computer Aided Design 19 CAPEX Capital Expenditure 20 CCMS Cargo & Courier Management System 21 CIS Centralised Integrated Solution 22 CM&CB Change Management & Capacity Building 23 CMC Common Mobility Card 24 CMMI Capability Maturity Model Integration 25 COBOL Common Business Oriented Language 26 DB Database 27 DC Data Centre
Page 20 of 223 SNo Acronym Description 28 DD Demand Draft 29 DDoS Distributed Denial of Service 30 DMZ Demilitarised Zone 31 DR Disaster Recovery Centre 32 DSC Digital Signature Certificate 33 DVD Digital Versatile Disk 34 EMD Earnest Money Deposit 35 EMS Enterprise Messaging System 36 EMV Europay, Mastercard and Visa 37 EoD End of the Day 38 ESI Employee State Insurance 39 ETA Estimated Time of Arrival 40 ETD Estimated Time of Departure 41 ETIMs Electronic Ticket Issue Machines 42 FA&CAO Financial Advisor & Chief Accounts Officer 43 FIPS Federal Information Processing Standards 44 FY Financial Year 45 GB Giga Byte 46 GIS Geographic Information System 47 GLONASS Global Navigation Satellite System 48 GoAP Government of Andhra Pradesh 49 GPRS General Packet Radio Service 50 GPS Global Positioning System 51 GSM Global System for Mobile Communication 52 GST Goods & Services Tax 53 GTS GSM Technical Specifications 54 HTML Hypertext Markup Language 55 HTTPS Hypertext Transfer Protocol Secure 56 IDAM Identify and Access Management 57 IEEE Institute of Electrical and Electronic Engineers
Page 21 of 223 SNo Acronym Description 58 IFSC Indian Financial System Code 59 INR Indian Rupee 60 IP Internet Protocol 61 ISO International Organisation for Standardisation 62 IT Information Technology 63 ITS Intelligent Transportation System 64 KMs KiloMetres 65 LAN Local Area Network 66 LDAP Lightweight Directory Access Protocol 67 LED Light Emitting Diode 68 LLP Limited Liability Partnership 69 LOI Letter of Intent 70 MAF Manufacturers Authorisation Form 71 mAh milli Ampere Hour 72 MDM Master Data Management 73 MIS Management Information System 74 MoUD Ministry of Urban Development 75 MSTC Metal Scrap Trade Corporation Limited 76 NEFT National Electronic Fund Transfer 77 NIP Notice Inviting Proposal 78 NIT Notice Inviting Tenders 79 NSR-RTD Nizam State Railways - Road Transport Division 80 O&M Operations & Maintenance 81 OCR Optical Character Recognition 82 OEM Original Equipment Manufacturer 83 OP Out Patient 84 OPEX Operating Expense 85 OPRS Online Passenger Reservation System 86 OS Operating System 87 OTA Over The Air
Page 22 of 223 SNo Acronym Description 88 OTP One Time Password 89 PAAS Pass Automation & Accountal System 90 PAN Permanent Account Number 91 PBG/BG Performance Bank Guarantee 92 PC Personal Computer 93 PCI Payment Card Industry 94 PF Provident Fund 95 PIN Personal Identification Number 96 PIS Passenger Information System 97 PMA Project Monitoring Agency 98 PoA Power of Attorney 99 PoC Point of Contact 100 PoS Point of Sales 101 PTS PIN Transaction Security 102 QA Qualitative Analysis 103 QR CODE Quick Response Code 104 RAM Random Access Memory 105 RBI Reserve Bank of India 106 RDBMS Relational DataBase Management System 107 REST Representational State Transfer 108 RFID Radio Frequency Identification 109 RFP Request For Proposal 110 RPO Recovery Point Objective 111 RTGS Real Time Gross Settlement 112 RTO Recovery Time Objective 113 SAM Security Access Module 114 SAN Storage Area Network 115 SD Secure Digital 116 SDC State Data Center 117 SI System Integrator
Page 23 of 223 SNo Acronym Description 118 SIM Subscriber Identity Module 119 SIT System Integration Testing 120 SLA Service Level Agreement 121 SME Small and Medium Enterprise 122 SMS Short Message Service 123 SoW Scope of Work 124 SPoC Single Point of Contact 125 SSL Secure Socket Layer 126 SSO Single Sign-On 127 STAAD Structural Analysis and Design 128 STAR Statistical and Ticket Accountal Record 129 TAYL Travel As You Like 130 TB Tera Byte 131 TCP Transmission Control Protocol 132 TDS Tax Deduction at Source 133 TIM Ticket Issue Machine 134 TTD Tirumala Tirupati Devasthanam 135 TTI Travel Ticket Inspector 136 TV Television 137 UAT User Acceptance Testing 138 UOM Units of Measurement 139 UPI Unified Payment Interface 140 USB Universal Serial Bus 141 UTR Unique Transaction Reference 142 VC&MD Vice Chairman and Managing Director 143 VMU Vehicle Monitoring Unit 144 VT&PIS Vehicle Tracking & Passenger Information System 145 VTS Vehicle Tracking System 146 VTU Vehicle Tracking Unit 147 WACS Weighted Average Commercial Score
Page 24 of 223 SNo Acronym Description 148 WAN Wide Area Network 149 WBS Work Breakdown Structure
Page 25 of 223 Disclaimer
The information contained in this Request for Proposal (the “RFP”) or subsequently provided to Proposers (System Integrators), whether orally or in documentary or any other form by or on behalf of the VC & MD, APSRTC or any of its employees or advisors, is provided to Proposers on the terms and conditions set out in this RFP and such other terms and conditions subject to which such information is provided.
The nature of this RFP Tender is Open Tender cum Reverse Auction. This RFP is not an agreement and is neither an offer nor invitation by the APSRTC to the prospective Proposers or any other person. The purpose of this RFP is to provide interested parties with information that may be useful to them in preparing and submitting their Proposals. This RFP includes statements, which reflect various assumptions and assessments arrived at by the APSRTC in relation to the Project. Such assumptions, assessments and statements do not purport to contain all the information that each Proposer may require. This RFP may not be appropriate for all persons, and it is not possible for the APSRTC, their respective employees or advisors to consider the investment objectives, financial situation and needs of each person who reads or uses this RFP. The assumptions, assessments, statements and information provided in this RFP Documents may not be complete, accurate, adequate or correct. Each Proposer should, therefore, conduct its own investigations and analysis and should check the accuracy, adequacy, correctness, reliability and completeness of the assumptions, assessments, statements and information contained in this RFP and obtain independent advice from appropriate sources.
Information provided in and pursuant to this RFP to the Proposer is on a wide range of matters, some of which may depend upon the interpretation of the law. The information given is not intended to be an exhaustive account of statutory requirements and should not be regarded as a complete or authoritative statement of law. The APSRTC and GoAP accept no responsibility for the accuracy or otherwise of any interpretation or opinion of law expressed herein.
The APSRTC and GoAP, their respective employees and advisors make no representation or warranty and shall have no liability to any person, including any Proposer under any law, statute, rules or regulations or tort, principles of restitution or unjust enrichment or otherwise for any loss, damages, cost or expense which may arise from or be incurred or suffered on account of anything contained in this RFP or otherwise, including the accuracy, adequacy, correctness, completeness or reliability of the RFP Documents and/or any assessment, assumption, statement or information contained in or deemed to form part of this RFP Documents or arising in any way in connection with participation in the Proposal Submission process in respect to the Project.
The APSRTC and GoAP accept no liability of any nature whether resulting from negligence or otherwise howsoever caused arising from the reliance of any Proposer upon the statements contained in this RFP Documents.
The APSRTC may in its absolute discretion, but without being under any obligation to do so, update, amend or supplement the information, assessment or assumptions contained in this RFP Documents.
The issue of this RFP Documents does not imply that the APSRTC is bound to evaluate a Proposer or to appoint the successful Proposer for the Project and APSRTC reserves the right to reject all or any of the Proposers or Proposals without assigning any reason whatsoever anytime during the tendering process.
Page 26 of 223 The Proposer shall bear all costs associated with or relating to the preparation and submission of its Proposal including but not limited to preparation, copying, postage, delivery fees, expenses associated with any demonstrations or presentations which may be required by the APSRTC or any other costs incurred in connection with or relating to its Proposal. All such costs and expenses will be to the account of the Proposer, and the APSRTC shall not be liable in any manner whatsoever for the same or for any other costs or other expenses incurred by a Proposer in connection with preparation or submission of the Proposal, regardless of the conduct or outcome of the Proposal Submission process.
Page 27 of 223 Preamble
The Government of Andhra Pradesh, under the aegis of the Hon’ble Chief Minister, Sri YS Jagan Mohan Reddy Garu, has envisioned to bring sustainable and transformational change in APSRTC and to bring the benefits of technology to all the Citizens with a focus of Customer Empowerment approach. The following objectives are set be achieved in this drive. a. Understand the needs and pain points of commuters in Public Transport. b. Address it through Business Process Re-engineering and leveraging technology. c. Adopt business processes that are easy to understand and follow d. Build the solution on technology platforms that have gained the trust and popularity with the citizen. e. Restructure the activity matrix in public transit that is Citizen Centric in tone tenor and hue. f. Digitise the reengineered citizen-centric business process. g. Develop an inclusive, customer friendly ecosystem for digital payment in public transit. h. Design an ecosystem that empowers the citizen to independently plan and undertake the intended journey. i. Provide all necessary information to the citizen with accuracy and in a timely manner. j. Keep every transaction transparent and traceable.
Page 28 of 223 1. Purpose of the RFP
The purpose of this RFP is to enable APSRTC to select a System Integrators to Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Ticketing Solution for Ticketing and other Allied activities under BOOT model in APSRTC, Government of Andhra Pradesh The requirements mentioned in these documents may change during the execution period, based on the interaction among APSRTC and System Integrator, and all these changes have to be recorded and submitted to “Project Awarding Committee” for approval, System Integrator will be responsible for gathering and documenting these changes.
The RFP is not an offer by APSRTC but an invitation to receive proposals from eligible and interested bidders in respect of the above-mentioned project from System Integrators. The RFP does not commit APSRTC to enter into a binding agreement in respect of the project with the potential bidders.
Page 29 of 223 2. Schedule of Events
This RFP is issued by APSRTC to the bidders and is intended to procure Ticketing Solution.
SNo Item Description Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Ticketing Solution for 1 Project Title Ticketing and other Allied activities under BOOT model in APSRTC, Government of Andhra Pradesh 2 Project Initiator/RFP Issuer Details APSRTC, GoAP
3 Contact Point Name from APSRTC Mr. K Madhava Trinadh, [email protected], [email protected], 4 Contact Details of POC Mob. +91-9959224312 APSRTC Address for the purpose of Bid 1st Floor, RTC House, 5 Submission and all other NTR Administrative Block, Pandit Nehru Bus Station, communications Vijayawada - 520013 6 Correspondence to VC & MD, APSRTC 7 Official Website https://apsrtc.ap.gov.in 8 EMD Rs 25,00,000/- (Rs Twenty Five Lakhs in words) 9 PBG Rs 2,00,00,000/- (Rs Two Crores in words)
Tentative Calendar of Events The following table enlists important milestones and timelines for completion of bidding activities:
Release of Request for Proposal (RFP) 26.02.2021, 11: 00 Hrs
Last date for submission of online 03.03.2021, 16: Hrs questions by bidders
Pre-Bid Conference 08.03.2021, 11:00 Hrs
Date of Issue of Clarifications 15.03.2021, 16:00 Hrs
Start date for Submission of bids 24.03.2021, 11:00 Hrs
Last date for Submission of bids 25.03.2021, 16:00 Hrs
Last date for Submission of Hard Copy of 25.03.2021, 16:00 Hrs bids at APSRTC HO in Sealed covers.
Pre-Qualification Bid Opening Date 26.03.2021, 11:00 Hrs
Technical-Bid Evaluation Bid opening date will be communicated to qualified bidders Commercial-Bid Opening Date
Contact points from APSRTC Mr K Madhava Trinadh.
Page 30 of 223 3. Introduction to APSRTC
3.1. Profile
The legacy of APSRTC dates back to June 1932, when the State run Bus Public Transport was first established with 27 buses and 166 employees as NSR-RTD (Nizam State Rail & Road Transport Department), a wing of Nizam State Railway in the erstwhile Hyderabad State. The past 79 years of its colourful history has witnessed its 27 to 22,000 buses in the united Andhra Pradesh State setting and surpassing bench marks in every area of operations and maintenance of Public Transport winning numerous National and International accolades including the Guinness Book of World Records.
After the separation of the geographical area of Telangana into a separate state, APSRTC is currently operating 12,000 buses, with 129 depots, 423 bus stations, 692 bus shelters and about 55,000 committed and competent manpower.
The APSRTC buses cover 42 Lakhs KMs and carry 62 Lakhs people to their destination every day. They connect 14,123 villages to all towns and cities in Andhra Pradesh thus providing safe and economical bus transport facility to about 95% of the citizens of Andhra Pradesh. APSRTC operates in both city and Mofussil areas. in all kinds of terrain, The APSRTC buses also ply to important towns and cities in the neighbouring states of Telangana, Tamilnadu, Karnataka, Odisha and Chattisgarh.
3.2. Vision of APSRTC
APSRTC is committed to provide consistently high quality of services and to continuously improve the services through a process of Kaizen for the utmost satisfaction of the passengers and to attain a position of pre-eminence in the Bus Public Transport sector.
3.3. Corporate Philosophy:
3.3.1.To provide safe, clean, comfortable, punctual and courteous commuter service at an economic fare. 3.3.2.To provide employee satisfaction in financial and humanistic terms. 3.3.3.To strive towards financial self-reliance in regard to performance and growth. 3.3.4.To attain a position of reputation and respect in the society.
3.4. Guiding Principles of APSRTC
3.4.1.To provide efficient, effective, ethical management of the business. 3.4.2.To assist the State administration in attaining good governance. 3.4.3.To treat the customer, i.e., passenger, as a central concern of the Corporation's business and provide the best possible service. 3.4.4.To explore and exploit technological, financial and managerial opportunities and developments and render the business cost effective at all times.
Page 31 of 223 3.4.5.To regularly and constantly improve the capabilities of employees for higher productivity. 3.4.6.To focus on service conditions and welfare of the employees and their families consistent with their worth to the Corporation. 3.4.7.To fulfil its obligation to the State and Central governments by optimising return on investment. 3.4.8.To emphasise environmental and community concerns in the form of reducing air and noise pollution. 3.4.9.To consciously conform to the policy guidelines of the State in its business operations and reach a position of pre-eminence in bus transport business.
3.5. IT Initiatives in APSRTC:
Andhra Pradesh State Road Transport Corporation has been in the forefront of utilising Information Technology (IT) for effective delivery of citizen services and day to day operations. 3.5.1.To Provide better services to passengers. 3.5.2.To Reduce passenger’s waiting time at the time of ticketing & issue of bus passes. 3.5.3.For Effective managerial controls. 3.5.4.To Reduce waiting time of conductors at the counters. 3.5.5.For Effective maintenance management of vehicles. 3.5.6.For Faster dissemination of information. 3.5.7.For Better inventory control. 3.5.8.Standardisation and simplification. 3.5.9.Digitisation of employee welfare schemes management.
Following are the customised applications developed and operational forming the ITMS framework of APSRTC.
3.5.9.1.Online Passenger Reservation System (OPRS):
Multi-mode Booking facility which facilitates the passengers to book tickets in advance on “Anywhere to Anywhere basis”. i. Multi-Mode booking — eTicketing, Mobile Application, Bus station counter, Authorized Ticket Booking Agents, B2C Channels etc., ii. Tickets can be booked/cancelled/preponed/postponed by the passengers though OPRS. iii. Wide network of about 2500+ ATB agents. iv. Waitlisting Option in all reserved buses. v. Paper less Travel – Passengers can travel showing the SMS/email received. vi. eWallet with multiple benefits. vii. Value added services: TTD Dharshan Link tickets, Flexi Fare system. viii. Link Tickets – Last mile connectivity with unreserved services ix. Ticket Transfer x. Multi Payment Channels – Accepts Credit Card, Debit Card, Net Banking, UPI, PoS, QR Code and cash.
Page 32 of 223 3.5.9.2.Pass Automation and Accounting System (PAAS): An online solution which simplifies the process of issue of free and concessional Bus Passes to different categories of eligible Citizens as per the welfare policies of the government of AP. This project is developed in three tier architecture which enables to issue 64 types of passes through more than 120+ counters across the state. i. To provide concessional bus passes and hassle-free services to differently abled citizens, Freedom Fighters, Journalists, Students etc., ii. To dispense manual issue of bus pass system iii. To enhance citizen experience. iv. To have better visibility and control over issue of Bus Pass issue system. v. Accurate and easy accounting system for revenue and subsidy calculation.
3.5.9.3.Vehicle Tracking & Passenger Information System (VT&PIS)
A solution with indigenous core components, bringing together diversified GPS, GIS module, GSM/GPRS and other technologies to provide: i. An Automatic Vehicle Location/Tracking System ii. Real-time passenger information system on Mobile App, Web and SMS. iii. An interface to disseminate public transport information through a variety of systems and communication media like internet, SMS, Display systems in the Bus Stops/Terminals. iv. Incident and Emergency Management System v. Centralised Smart Schedule Management vi. Auto Announcement System at Bus stations and Bus shelters. vii. Enquiry application with Live Bus location and ETAs. viii. Increased accuracy and efficiency of operations.
3.5.9.4.Ticket Issuing Machines (TIMs)
Ticket Issuing Machines (TIM’s) were introduced into APSRTC in May ,2000. The main aim of introducing TIMs is to issue reduce the ticket issue time, to issue tickets even after completion of ground booking and to pick up more number of passengers en-route. Also, with a view the management can derive information of various aspects of operations like punctuality analysis, travel patterns of the public, economic viability of service, saving of stationery and generate MIS reports from the database. Similarly, the crew will be benefited by issuing a single ticket to a group of passengers, avoiding of ticket punching, STAR closing and instantaneous remittance of reports. At present, all the services in APSRTC (100%) operations are using 15,847 TIMs and completely dispensing the manual ticket system.
3.5.9.5.Centralised Integrated Solutions (CIS) APSRTC introduced in-house standalone IT applications mostly in COBOL on Linus Platform beginning from 1987. These applications were functioning as independent silos across 308 locations. APSRTC initiated the process of migration & integration of all its existing IT applications to contemporary technologies, duly automating the non-computerised core areas as well. APSRTC launched Centralised Integrated Solutions (CIS) in April, 2012 to: Page 33 of 223 i. Overcome current system’s inability to operate on the latest technology and address the security issues, which the earlier systems could not handle. ii. Establish Single Source of Truth – Eliminate redundancy and duplication of the data. iii. Data Integrity iv. Data Management v. Data availability and Data Standardisation. vi. For Sustained Application development vii. Optimum Manpower utilisation and viii. Paperless Office
Page 34 of 223 High Level Centralised Integrated Solutions Architecture
3.5.9.6.Other IT initiatives
i. 100% computerisation of Payrolls and PF accounting for all employees. ii. Design of bus body designs using CAD workstations. iii. Design of Civil Engineering infrastructure using CAD and STAAD software packages. iv. Computerised vehicle testing machine in use to check effectiveness of braking, steering, lighting and exhaust systems. v. Operating 24*7*365 days Toll free Central Call Centre to address the passenger needs, grievances etc., vi. Computerised Hospital Management System which includes OP Module, Pharmacy, Clinical Module, Lab, Blood bank, Operation Theatre, Radiology and Maternity ward. vii. Pilot Project of RFID based eTIMs and cashless payments using Smart Cards at Vijayawada City. viii. Pilot Project on mTicketing and mPass at Vijayawada City. ix. Aadhaar based biometric attendance in offices. x. 100% online tendering for procurement and disposal. xi. 100% file movement and correspondence through e-office system of NIC. xii. Digitisation of Crew Duty Charts.
Page 35 of 223 3.6. Hierarchy of the Stake Holders
APSRTC is the sole owner of the project. IT department will complete the due process necessary for on-boarding the winning system integrator and initiate a handshake between system integrator and Operations department.
Once the System Integrator is identified, there will be mutual responsibility of the Operations department and IT department to initiate the business process re-engineering from an improvement and smart ticketing solutions perspective.
This will include a final definition of the problem statement, requirements and minimum acceptable criteria, etc. IT department will extend necessary support for the implementation of the project.
System Integrator is responsible to host all required IT infrastructure for the deployed resources and shall be responsible for their maintenance & management including insurance of manpower and equipment.
Roles and Responsibilities of each and every Stake Holder will be detailed out in subsequent sections.
3.7. Project Awarding Committee:
3.7.1.The Project awarding Committee is empowered to review, approve and suggest amendments if any:
1. To the Project Scope of Work 2. To the Project detailed Functional and non-Functional requirements. 3. To the proposed technical architecture of the project
Page 36 of 223 4. To the proposed solution of the project 5. To the estimated budget and 6. To Suggest procedural amendments.
3.7.2.Members of the project Awarding Committee:
1. Chief Engineer IT Member 2. Chief Finance Manager Member 3. Dy CTM Marketing Member 4. Representative from ITE&C, GoAP Member
3.8. Conflict Resolution Matrix
In case of conflicts of any nature following matrix will be used for resolution:
SNo Nature of Confict Level SPoC (single Point of Contact)
First Level APSRTC Core Team Project Related 1 Second Level Dy Chief Engineer IT Concerns Final Chief Engineer IT
First Level Dy Chief Engineer IT
2 APSRTC Related Second Level Chief Engineer IT
Final Executive Director A
First Level Chief Engineer IT
3 Policy Related & Others Second Level Executive Director A
Final VC & MD, APSRTC
Page 37 of 223 4. Introduction to Unified Ticketing Solution
4.1. Vision
To implement 360o ITS Solution for ticketing and allied activities of APSRTC.
4.2. Objectives
The System Integrator shall prepare a Blueprint document that server the following objectives: 4.2.1.To increase the adoption and usage of public transport. 4.2.2.To migrate to cashless/digital ticketing and payments in buses and logistics. 4.2.3.To leverage technology to increase operational performance. 4.2.4.To enhance the user experience. 4.2.5.To establish single source of truth. 4.2.6.To Empower the commuter towards self-reliance in purchasing services from APSRTC. 4.2.7.To equip the organisation to access and analyse clean and real time data seamlessly for initiating and monitoring business strategy interventions.
4.3. Strategies
4.3.1. Leverage the all-pervading android platform by providing an App based solution. 4.3.2. Acceptance of payments through all digital media like Credit/Debit Cards, Customised Close Loop Cards, NCMC, UPI, QR Code and APSRTC wallet. 4.3.3. Campaign for creating wallets for all customers based on mobile number or any unique ID of customers. 4.3.4.Support the passengers in decision making by providing real time passenger information system
4.4. Thrust Areas
4.4.1.Penetration of the e-wallet, UPI and mobile ticket. 4.4.2.Active and aggressive involvement of System Integrator for achieving the above. 4.4.3.Encouraged and educate the customer for adopting digital payments for transit. 4.4.4.Payment system to be compatible with NCMC protocol.
Page 38 of 223 5. Functional Scope of the RFP
5.1. Overview
It is desired to design, develop, deploy, host and maintain a hybrid ticketing solution compatible with both Android POS machines and Mobile Phones + Bluetooth Printers. APSRTC shall supply the necessary POS machines and/or Mobile Phones to its staff as required for this project. As per the requirement of APSRTC, the System Integrator shall deploy a hybrid model i.e., the SI may need to deploy both Android POS solution and Android Mobile Solution for issuing tickets. In case of, Android Mobile Phone, APSRTC shall supply the Bluetooth printer for ticket issuing. In case of, Android Mobile phone or POS supplied by APSRTC, the SI shall use the inbuilt GPS of POS or Mobile for fetching GPS location of buses. Base Functionality of Android Mobile App developed for POS or Mobile Phone shall remain same as traditional ETIM. ETIM/POS/Mobile Phone is referred interchangeably in the document as applicable. APSRTC shall provide the payment gateway for integration with Online Ticketing Portal and for collecting Cashless payments from Customers. SI shall provide the necessary maps licenses or open maps as required for VTS, AVLS and PIS. APSRTC shall provide the SMS gateway as required for sending the SMS to passengers. All other software licenses (DB, Web Servers, EMS etc), Data Center Hosting etc as required for the project shall be procured by the SI. At a high-level, services are divided into following modules as given below, followed by detailed description of services under each module.
1. Online Passenger Reservation System (OPRS) 2. Automatic Fare Collection System (AFCS) - Electronic Ticketing through Android ePOS app 3. Pass Automation and Accounting System (PAAS) 4. Automatic Vehicle Location System (AVLS) 5. Passenger Information System (PIS) 6. Central Command Control 7. Cargo and Courier Management System 8. Multi-purpose Integrated Mobile App. 9. Web Portal for stakeholders 10.Dashboards and Reports 11.IT Infrastructure
5.2. Online Passenger Reservation System (OPRS)
5.2.1.Scope
1. Web and mobile interface to enable reservation of bus seats for both advance reservation and current booking across various APSRTC routes from anywhere and anytime. 2. Web-based reservation portal for the passengers to access information and book tickets. 3. RTC Operator Booking - This module is used by the booking clerks at the depots/bus stations for the booking of tickets for various routes and services 4. ATB Agents - Authorised Ticket Booking agents to book tickets for passengers.
Page 39 of 223 5. B2C Agents - Integration with online travel ticket portals to book tickets for passengers. 6. Mobile Ticketing and service tracking through app on Android and iOS platforms for customers. 7. To deploy appropriate ticket validation mechanisms on the Android POS to ensure validation/ checking of the ticket 8. Integration with payment gateway provider to allow passenger to make payments across all available online payment modes. 9. Integration with AFCS system for reporting and reconciliation of tickets booked. 10. Integration with APSRTC-ERP (CIS).
5.2.2.Functional Requirements:
1. All the facilities related to bus booking/cancellation of the APSRTC buses online. 2. Passengers can purchase any form of tickets available through the Self-Service Web Portal, Mobile App, B2C Portals or through the Assisted mode with RTC Operators and ATB agents, etc., for single journey, or return journey tickets or concession (special category) passes, multi-journey tickets and subscription model of ticketing may be added later as well. 3. OPRS Application shall be developed to all types of buses including pallevelugu services 4. Synchronising and updating real time data across all ticketing interfaces viz. (eTicketing, RTC operator, ATB agent, B2C channels, Android app) 5. Origin-Destination (OD) based open ticket booking system with fixed time slot-based ticket validity. 6. Tickets once purchased should be stored in such a manner that they can be presented for validation / authentication even if the user’s phone is offline without a data connection. 7. Multiple passengers may ride using one ticket on one phone as long as the correct number of tickets or rides have been validated. 8. Mobile Number as Payment Method: Introduction of new payment instrument with robustness to enable passengers with recharge option at bus station counters and ATB agents, Online for all Mobile Users. 9. OPRS must support completely digital user authentication such as Aadhaar-based authentication or other such authentication frameworks. 10. Cashless Payments: Enabling collection of payments by Drivers/Bus Station Counters/Ground Booking points through QR Code via UPI or APSRTC wallet system. 11. Facility to book tickets under concessional schemes and amenities. 12. Web Browser based facility for computerised reservation of Non-Stop services, current, advance tickets with/without concessions. 13. Reservation of concession tickets with / without physical tickets. 14. To facilitate ticket issue on “travel anywhere” basis. 15. Enabling Blocking, Return Journey reservation with/without concession route wise, service wise, cancellation, pre/postponement of tickets anywhere. 16. Automatic releasing of predefined quota seats based on configurable time, place or condition. 17. Facility of payment through Credit cards/Debit cards, Net banking, NCMC payments, on-line payment through third party Payment Gateway services. 18. Centralised control of fares, concessions, cancellation slabs, reports, etc., and the application software.
Page 40 of 223 19. Agent wise commissions, agent wise cancellations, cancellations before and after departure, universal stock account etc, and Agents cash remittance through prepaid and postpaid in configurable methods. 20. Integration and accessibility to various service delivery points such as ATB agents, Sub agents, e- Seva, AP Gram Sachivalayam/Ward Secretariat, Mobile based advance reservation, Android POS/ Mobile App based ticket issuing machine and necessary accountal of tickets and revenues. 21. Reconciliation of Inter Bus Station/Depots transactions based on issue date or journey date. 22. Anywhere to anywhere Bus Station wise transaction reports daily, weekly, fortnightly, monthly and yearly to be generated. 23. The system would facilitate display of departure /arrival timings as well as the facility to drill down to view the arrival /departure timings en-route. 24. Facility for wait listing and allotment against cancellations. 25. There shall be provision for implementing EQ /quota system service wise, station wise, issue point wise. 26. Tickets to be printed in bilingual mode English and Telugu as per the design approved by APSRTC. 27. Multi-level user authorisation and authentication with appropriate User Profiles, Rules and Roles, etc. 28. All Operational, MIS and Revenue reports for a specified period Bus Station wise, Service wise, Operator wise, other agents and e-ticketing, payment gate way wise, etc., to be generated. 29. Finest granularity in data dashboards shall be facilitated for Macro and Micro analysis of data with selective drill down and cross referencing. 30. It shall provide facility for reconciliation report or tool between RTC vs agents, RTC vs Payment Gateways, similarly RTC vs other channel providers. 31. Main unit of application is Service, it shall be extended or shrunk either side. Majority of parameters are based on the service wise configurable. 32. Ladies seats to be earmarked in PINK colour and facility for blocking these for ladies only. Special blocking for MLA/MPs, etc., to be provided. Blocking seats release time to be configurable. 33. Dynamic configuration provision of earmarked seats like Senior Citizens, PHC, etc., quota seats in a service. 34. Facility to capture Passenger biographic data such as Name, Gender, age, etc., and to deduce patterns on travels related to frequency and branded services. 35. Maintenance of passenger profile to facilitate integration with CRM. 36. The Reservation and cancellation facility should be made available through mobile, ticketing issuing machines, SMS, ticket vending machines, Kiosks. 37. The System should have an option to provide refunds to passengers according to the up gradation and down gradation of service/class. 38. The System should have an option to provide refunds automatically to passengers in case of service cancellation or breakdown, etc. 39. Service cancellation information and refunds shall be triggered automatically to all online, B2C tickets, etc. 40. Seat wise concessions, Service wise concessions, type wise concessions, sector wise concessions, group concessions, and seasonal concessions, etc., to be provided. 41. Multi Concession booking in single transaction should be provided. 42. The System will have a facility for seat vacancy position sector wise and API provision for automatic Platform Announcement system. Page 41 of 223 43. The system shall have the facility of Out Depot cash remittance module. 44. Facility to provide information and alerts on timings, fare, service cancellations, payment gateway transactions, e-ticketing booking and cancellation, late arrivals and departures to passengers on mobile phones through voice calls or SMS, web notification, e-mails etc., 45. After creation and implementation of a Service in the application, for every modification of critical data (like Master data) Route wise, Service wise, user wise, fare changes, Kilometres changes, stage changes shall be intimated to the Chief Admin and Admin roles through mail and pop ups immediately. 46. Error pop up must be generated with correct relative messages wherever required to be popped up. 47. Facility of dynamic fare changes across the board throughout the computerised Bus Stations centrally. 48. Dynamic MIS for effective decision making. 49. Based on the above data the software will generate various reports on daily, fortnightly, monthly and yearly basis and resolve individual queries as may be put up the individual APSRTC, etc., from the time to time. 50. Accommodation and other value added services to be incorporated in the ticket for services where applicable with or without concession. 51. The administrative interface shall support web enabled, browser based interface and standalone interfaces. 52. The OPRS system administration shall facilitate generation of various kinds of reports — text and graphical. The reports will be of use to various stakeholders such as the Corporation, Identified Management Officials and Service Access, network, payment gateway, authentication, back office and other service providers. Such reports could be planned in advance, the system should provide for creation of additional reports online. 53. The solution must enhance the overall management of security, by providing Authorisation Officers of APSRTC an easy way to manage users and their corresponding profile information; while also maintaining the ability to manage at the application level. The centralised control should allow for the web-based maintenance of organisational level controls such as user management, role management and overall administration control. 54. The solution must provide scalable access services to the System / Solution, including scalability in terms of number of users, user groups, concurrent users, resources, and access control policies. In addition, it must be scalable to legacy and future applications /resources that are attached to the portal. The ability to transport this solution for all future web-enabled services with minimal effort reduces future implementation costs and ensures a structured / proven security environment. 55. The System should be able to capture IP addresses of the customer logged in. 56. The System should provide log reports of login and logout of various users at the specified intervals of time. 57. The solution must provide a robust and customisable security solution that meets the application requirements of Anytime Anywhere Booking. It is hard to anticipate all present and future requirements. An open, extensible architecture and documented Application Programming Interfaces (APIs), Web services enable site developers to customise an access control system to their specific requirements. A platform that will grow with additional application deployment and scales as user traffic grows, while providing the highest level of reliability is required. 58. The security solution must be capable of comprehensive logging of the traffic through the network and applications under its control. It should be capable of logging unauthorised access attempts in to the network and the System internal resources, and attempts to login that fail. It should also be capable of notifying appropriate parties including the organisation users/department users/System Security Administrators etc of suspicious activity. Page 42 of 223 59. The vendor has to provide security certification for security check in the application throughout the project period. 60. There shall be provision for issue of e-ticketing through a minimum of four payment gateway service providers. 61. System shall facilitate booking entire bus for use of group of passengers, tourist /Corporate or any other citizens with or without concession. The information like vehicle type, hire charges and other terms and conditions shall be provided on line and the system shall facilitate online booking of entire bus. 62. The provision to enter the number of passengers travelled stage wise in the bus should be made available at the destination /origin bus station and a report to be provided for this purpose. 63. Capturing passenger information wherever necessary shall be facilitated on all platforms. 64. The data relating to passengers shall be held securely and inaccessible to any hacking attempts. 65. System should facilitate payment for ticket booked through Credit Card, Debit Card, Cash deposits, Bulk payments in cash / cheque / Demand Draft in authorized banks and inputting data from such receipts / challans into the system, Special coupons or any other payment mechanism as and when introduced. The system shall have necessary interfaces in conformance with the standards and protocols specified by such third party payment gateway service providers. 66. Such payments received will provide appropriate interfaces for the backend accounting and financial systems to access the payment collection data. 67. In case of high demand for tickets, APSRTC as part of its business development policy may offer reservation facility on mobile, POS/Mobile App, Vending machines, Kiosks. The access to the reservation will have to support wireless interface to the system through an ISP or any other relevant technology. 68. The system should support printing, using any type of printer – Laser, Inkjet and on pre-printed or plain paper through any browser. 69. Pre-printed tickets may be made available to the bus station counters/franchisees and other travel agents including ISPs as per policies of APSRTC, who will have to maintain inventory and submit requests online for replenishments from APSRTC. 70. The System shall also provide to send the details of the generated ticket to the e-ticket user through mail, SMS and WhatsApp. 71. The system shall facilitate capturing feedback from users of APSRTC services and provide an option for APSRTC management to get alerts on feedback posted on the site for immediate attention and action. 72. The system shall provide user management services and service enrolment features to enable the user to register with the portal. It should also provide secured mechanism for user identification, transaction integrity, security and non-repudiation. 73. The system should support booking of luggage and parcel at bus stations and franchisee counters in respect of accompanied or unaccompanied baggage. 74. Facility to sell and account stock with or without face value, date value like Couple Gift Card, Bus Pass Renewal, etc., and validating the concession tickets validating with the CAT and Couple Gift Card, etc. 75. Issue of Journalist Pass, Retired Employees Pass, etc., through OPRS application and validation of such pass during issue of tickets to the pass holders at all counters of the Corporation. This facility is to be configurable. 76. The system shall display the ticketing activity to the passenger who is at the counter through slave monitor with selective information. As such the passenger will select his required seat/type of service for his journey. Page 43 of 223 77. The system should have Mobile App deployed on the Mobile POS or Mobile Phone based Ticket Issuing Machines (TIMs) for issue and accountal of tickets and revenue. The TIM App should be able to get seats availability, fare matrix from the Central Server and should be able to issue tickets through the TIM and update the Central Server. The communication with the TIM to the Central Server will be through GPRS, GSM or other communication media. 78. The Onboard Bus Ticketing Mobile App deployed on Mobile POS should work in offline / online mode with zero revenue loss to the corporation by ensuring the 100% data sync with the central server. 79. Integration with UPI, NCMC and mobile eWallets for paper less journey. 80. The Mobile POS app should be able to board the passenger by validating and the authenticating the travel in offline/online. 81. To incorporate advertisements in the home page and where ever changes made by APSRTC to be modified immediately. However, the vendor shall have no rights to claim the revenue realised, if any, on the advertisements and his scope is limited to uploading the ads only. 82. The vendor has to maintain and change the website homepage periodically incorporating contemporary design elements from time to time to add appeal. 83. The Bus Station wise and Type wise Time Table to be provided in the Home page. 84. Flash messages, SMS and e-mails to be generated automatically, whenever a service is cancelled or introduced, modification of schedule time and pickup point, etc., immediately in the application. 85. To provide Credit card/Debit card payment facility across all the counters including ATB agents. 86. To provide bus station wise quota seats in all services. 87. Systems should check valid parameters defined by APSRTC such as current booking time, cancellation timings, minimum travelling distance, and concessions, etc., for booking of ticket in a service. 88. The vendor has to deploy manpower 24 X 7 with sufficient team of Software Engineers, Database Administrators, Network Administrator, etc., at Data Center/Disaster Recovery Center to design, development, implementation, migration with necessary equipment & tools and to attend day to day problems immediately, without any interruption. 89. Additional and final requirements will be finalised during the preparation of the System Requirement Specifications. 90. APSRTC is looking for an end to end solution for software design, development and deployment for UTS, deploy Data Center (Cloud based) to handle 50,000 hits/sec, installation, migration, setting up and running of Disaster Recovery Center (with minimum 50% capacity of DC) including providing of required Internet Band width, leased lines between DRC and DC, MPLS VPN connections to 12 major Bus Stations and providing the manpower for Data center and Disaster Recovery Center on a 24 x 7 basis. 91. The system should be able to withstand occasional spurt in traffic beyond the 50,000 concurrent users limit and continue to provide seamless and undiminished user experience. 92. The firm should setup Data Center, installation and set up the Disaster Recovery Center including the Hardware, Networking equipment, Air Conditioners, UPS, Batteries (maintenance free) and maintain the DC and DRC, providing of IBW, leased lines and MPLS VPN connections to major bus stations and Application during the contract period 93. Users should have a facility to Print/SMS/ email Ticket. 94. Passengers should be able to cancel, prepone and postpone their journey as per the business rules of the Corporation. 95. Passengers should be able to track their refund status via PNR Number or Mobile number. 96. Dynamic searching (today, tomorrow and next 30 days seat status with fare). Page 44 of 223 97. Integration with NCMC and mobile eWallets for paper less journey 98. Web enquiry for seats availability, fare, routes, en-route stops, Arrival and Departure time, etc. 99. Integration with EMV contactless bank card for frequent travellers (card can be used as a fare media for customer identification). 100. Advance Booking, Full/Partial Cancellation of tickets, and advancement and postponement of journeys. 101. Cancellations, Pre/Postponements shall be allowed at all Bus stations. 102. To provide accurate and easy accounting system for Inter Depot Transactions and e-ticketing. 103. Solution shall be flexible and able to adopt the future needs of APSRTC such as inclusion of Non- stop services and short distance services etc into OPRS platform. 104. Role based dashboards shall be provided. 105. Audit trail must be maintained for all data updates/amendments and deletions for security audit. 106. It is expected that as a part of development of OPRS System, the system integrator will study the existing Software used for reservation, cancellation, pre-ponement and postponement, e-ticketing and payment gateways, etc., and suggest appropriate changes and obtain sign off from various concerned departments within APSRTC.
5.2.3.Special Hire Bus Module
1. Special Bus Hire is used to provide online inventory for passengers to book the whole bus. 2. Module should have an option to configure depot wise bus inventory available for full bus booking. 3. Passengers will have an option to search for buses available from a nearest depot based. The search will be based on the place searched on maps and based on the nearest depot and inventory available in that depot. 4. System should be having the capability to configure bus type based per kilometre fare, levies, interstate taxes, etc. 5. The final fare calculation collected is based on the route (multiple points) selected by passenger on the map. 6. The system should allow to collect security deposit for each trip from the passenger. 7. The fare will be based on the kms travelled, travel time slabs, interstate route taken, etc. All these calculations should be done by the system automatically. 8. System should be able to accept payment from passenger through payment gateway and generate invoice online. 9. System should allow cancellation based on the rules defined and process refunds automatically. 10. On acceptance of the payment, system should be able to map the booking to depot inventory and able to send the necessary alerts to respective depot managers, control room, etc. 11. On completion of the trip and on bus reaching the depot, the system should be able to calculate the final invoice and automatically process refund of security deposit to passenger post any applicable deductions.
5.2.4.Open Ticket Booking Module
1. System should allow booking of tickets for bus services based on the origin-destination, time slot and bus type.
Page 45 of 223 2. System should have business configurational parameters where in the number of booking per bus type, role wise and per slot shall be configured. Based on the services already created in the system, the system should allow booking only to the extent of the cap set per role, bus type and per time slot. This capping may vary based on route, bus time and slot time. 3. Tickets should be issued online, POS, Bus Station Counter, Ground Booking Points, Agents and through ATM Kiosks. 4. All tickets booked should be recorded in the system. 5. Passengers will bring these tickets for boarding the buses. 6. All tickets should be carrying QR code and/or unique PNR number. 7. Tickets bought to the buses should be validated both online/offline. 8. Offline validation of tickets should be carried out in case of non-availability of internet connectivity. 9. Once ticket is validated the same ticket should not be allowed for boarding in other buses. 10. Tickets might be booked for roundtrip or oneway. Both tickets should be issued through all modes and validation of each ticket is mandatory before boarding the bus. 11. System should be able to restrict booking based on the number of passengers defined per slot. 12. MIS reports should be generated against the bookings made, no of passengers booked for a journey date, no of passengers boarded, etc. 13. Dashboards needs to be created as per APSRTC requirements
5.2.5.Payment Gateway
1. APSRTC will provide Payment Gateway service providers. 2. SI shall integrate all the Payment Gateways provided to web portal, ePOS etc to accept digital payments. 3. SI shall integrate with payment gateways up to payment method. 4. The SI shall provide dynamic switching of Payment Gateway to the user. 5. The user shall not be provided with selection of payment gateway (Like ICICI, Ingenico, HDFC, Razorpay etc.,). 6. The user shall be provided with selection of payment method only (CC, DC, Net banking, UPI Wallets etc.,). 7. After the selection of payment method, the user shall be directed to a single payment gateway based on the success ratio/response received to UTS platform. 8. If multiple gateways are available for same payment method, randomisation shall be used to direct the user for making payment. 9. This feature helps the load on Payment Gateway service provider and improves the user experience. 10. Due to dynamic switching, this feature reduces the rate of failure transactions. 11. In case, the user failed to make payment successfully using a selected payment gateway, the user transaction state shall be saved and provide necessary facility to make payment using another payment gateway after the stipulated period, subject to availability of the same seats in the service. 12. In case, UTS platform observes poor success ratio from a specific payment method, UTS platform shall disable the respective payment method to the live users for a stipulated period of time, till the payment gateway resolves such issues. 13. Under any circumstances, turnaround time for response from Payment Gateway shall be configurable and shall not be more than 5 mins.
Page 46 of 223 5.2.6.Indicative Working example of OPRS System
1. Route Master Creation
Each Route shall be created in the system by mapping a list of Bus Station in the order of actual bus travel on that route. Distance between adjacent Stations and toll details shall be entered in the route creation module. The same route creation module shall be compatible for stage wise route creation.
2. Fare Chart Master Creation
Each Bus type and each State Transport shall have different per KMs/Stage fare. The fare calculation shall be based on the no of kms/stages being operated in a state multiplied by per KM fare applicable for that bus type and state transport unit. The base fare calculations are arrived based on calculation based on Per KM based – Bus Type. This base module evolved to multiple modules and levels of fare calculation based on the ever-growing requirement and needs of APSRTC. Today, these fare modules have reached to a stage where the fare can be varied in real time at central server level based on business rules and the same fare can be used across various ticket selling platforms including counters/online/conductors/b2c channels/ETMs/POS. Following are the details of each module/levels involved in fare calculation. The hierarchical sequence of steps involved in fare calculation are listed below: a. Fare based on per KM and Bus Type. Per KM based fare is defined based on each state wise KMs operated in a state. This module helps achieve the bilateral fare rules agreed between different states. The state in which the bus route is operating should follow the per KM fare of that state’s STU. b. Fare calculation is based on the KMs between Boarding and Dropping Point. c. Stage Wise Fare calculated based on No. of stages between two points and Bus Type. d. Rate Masters are used to manually edit/correct route wise fare calculated in first two modules. e. Fare variation based on month of year and Bus Type. Ex: Summer AC buses are charged higher. Rainy season may be charged lower than normal. f. Flexi Fare module is used for variation at bus service level or route — bus type level. g. Seat Wise Fare is for Bus Type – Seat Wise based fare variation. Premium seats are charged higher. Ex: First three rows are charged higher; Window seats are charged higher. Last Row seats are charged lower. h. Dynamic Fare module helps STUs to improve revenues based on the demand on a route/service for a given day. Ex: Increase the fare by 10% if the occupancy ratio of the bus is 50% one week prior to the journey date. Decrease fare by 5% if occupancy ratio of the bus is 30% two weeks prior to journey date. i. Weekday fare roaster used to vary fare based on the day of operation of a bus. Ex: Buses operated on Friday and Sunday are charged higher. Bus operated on Tuesday are charged lower. j. Fare capping module helps cap the variation between a range of the base fare. Ex: Fare variation can be 25% higher or 10% lower than normal calculated fare. k. The fare calculation done in the above steps can be used in real-time across ticket selling platforms. This gives leverage to APSRTC to maximise the revenue by varying the fares automatically based on the peak demand/supply of bus inventory on a route.
Page 47 of 223 3. Trip Details Master Creation
a. Each Bus Schedule will comprise of multiple trips. b. Each schedule shall have a Schedule No (DCP Number) defined and this is unique across APSRTC. c. Each DCP No will have multiple trips assigned. d. Driver/Conductor goes to the bus depot and takes duty allotment in the CIS system of APSRTC. e. CIS system shall communicate the Schedule details to OPRS. f. Each trip/service is created in OPRS system shall have a Depot Schedule Code. g. Each trip/service shall have the bus running timing, fare, business rule flags to allow advance booking, current booking, Bus seat layout and other operational parameters like weekly service, daily service, alternate day service, etc. h. Once the Schedule is assigned in CIS, the information shall be passed on to OPRS. i. Type of Bus: The above-mentioned master bus seat layouts are made available in OPRS portal for use. j. Time of Schedule Departure at origin k. OPRS Service/Schedule-Trip Number l. Stage wise Arrival and Departure Timings m. Classification of stages as – Boarding and Alighting. n. Fare Matrix of the Trip o. Days of operation. p. Waybill Closure points
4. Current Bookings at all stages
a. Current booking shall be enabled till LS-1 stages (where LS is Last Stage). The ticket booking in the ground stages, online and in bus will continue to happen even when the bus starts from the origin point. b. This shall be available on all OPRS platforms including Driver/Conductor Mobile App and Ground Booking Mobile App. c. After generation of waybill, current booking shall be available from at CS+1 stage till LS-1 Stage only. (Where CS is Driver App Current Stage)
5. Android app for Bus On-board driver/conductor ticketing
a. Conductor/Driver login based on Employee ID and password b. Schedule and trip information based on duty allotment in CIS c. Fetch fare matrix details of the assigned route / service / DCP no.s. d. From the assigned schedules, start trip in chronological order. e. Fetch all the Advanced reserved passengers’ information in waybill to the App display by boarding point wise. f. Board passengers using, PNR, Mobile, Passenger Name, QR-Code, unique PIN (passenger identification number) both in offline and online. g. Option to call passengers. Page 48 of 223 h. Display boarding point wise available/ boarded / not boarded summary. Real time seat availability, revenue summary to know current available seats in the bus. i. Display seats availability with or without Bus Layout j. Enable Standee ticket issuing k. Current Booking l. Stage update m. Acceptance of Digital Payments such as QR Code (UPI), NCMC card enabled payments, APSRTC Mobile Wallet and optionally Cash. These payments modes are enabled / disabled by route, bus type and / or user type. n. Issue tickets for General Public, Concession Tickets and Luggage tickets. o. Bus Pass journey validation. p. Issue child only ticket. q. Update seat availability in real-time with Conductor/ground booking App. r. Alerts to driver when Ground booking user issues tickets for the selected DCP No. / Trip No. s. App should work offline in case of any network issues. t. End Trip / End Duty – all the revenue generated in the driver app should be in sync with central server and the information (COB1, COB2, COB3, COB4 files) to be pushed to CIS server. u. Option to capture Toll /OD Cash. v. Option to view on board passengers / duplicate waybill details. w. Cancel Trip. x. Break Down functionality. y. Route Change. z. Advanced Booking.
6. Ground Booking App
a. Booking Staff login based on Employee ID and password b. Validated duty based on the duty assignment in CIS system. c. List all DCP codes / services that are passing thru the location at which the conductor / driver is assigned the duty to issue tickets. d. Filters by Route, DCP Code and ETA to display preferred services listing. e. Display seats availability with or without Bus Layout. f. Current Booking g. Acceptance of Digital Payments such as QR Code (UPI), NCMC card enabled payments, APSRTC Mobile Wallet and optionally Cash. These payments modes are enabled / disabled by route, bus type and / or user type. h. Alerts to driver when Ground booking user issues tickets for the selected DCP No. /Trip No. i. Option to make a device as primary to issue tickets in rapid speed. j. Wallet Registration and Top-up. k. Booking Revenue Summary Report. l. End Duty – all the revenue generated in the driver app should be in sync with central server and the information (COB1, COB2, COB3, COB4 files) to be pushed to CIS server. m. Advanced Booking.
Page 49 of 223 n. Open Ticket Booking.
7. OD based Open Ticketing
a. Currently, in OPRS, APSRTC issue tickets to passengers with more specificity i.e., date of journey, service number, boarding point time, name, age and seat number, alighting point, etc. b. In common corridors, where the frequency of operations is high, more specificity acts in a negative way for public reducing the flexibility to choose the preferred travel time, etc. c. So, in high frequency corridors, ticket booking shall be enabled with date of journey, time slot (preferably 2 hrs), boarding point, alighting point and type of bus. d. This OD based ticketing gives flexibility to passengers to board any bus within the specified time slot and perform their journey. This flexible option improves the customer experience. e. The OD based ticket shall be provided with QR code or PIN which shall be verified by Driver App to board customer.
8. Bus Passes
a. In the existing system, conductors verify bus pass using the following details: i. Photo ii. Route iii. Type of Bus permitted iv. Validity. v. In certain types if passes, in addition to the above, toll charges need to be collected from passenger, and issue a ticket. b. Bus Pass issue is manually done at the bus stations counters of select bus stations. c. Bus Pass application shall be modified and developed with following two options: d. Mofussil Services: i. During pass issue, generate QR code storing Name, Route, Type of Bus and Validity. Photo shall also be printed on the bus pass along with QR code. ii. To collect Toll charges during purchase of bus pass itself. iii. QR Code (UPI) and NCMC payment integration. iv. Enable Dynamic QR Code (UPI) and NCMC card enabled payment acceptance for each counter. v. All Driver and Ground Booking using passes shall be validated through App by scanning the Pass QR Code and photo identity shall be physically validated by driver. Offline validation should be enabled in case of no access to internet. e. City Services: i. During pass issue, generate bus pass based on route, validity, Aadhaar number etc by storing the Aadhaar card number details in APSRTC PAAS system. QR code on Aadhaar will act as a pass identifier. ii. To collect Toll charges during purchase of bus pass itself. iii. QR Code (UPI) payment and NCMC card enabled payments integration for pass issue. iv. Enable Dynamic QR Code (UPI) and NCMC card enabled payments acceptance.
Page 50 of 223 v. All Driver and Ground Booking using passes shall be validated through App by scanning the Pass QR Code and photo identity shall be physically validated by driver. Offline validation should be enabled in case of no access to internet.
9. Closed Loop APSRTC eWallet
a. Creation of eWallet linked to Mobile Number. b. Topup wallet account in online / mobile app /ATB Agents /counters. c. While booking a ticket, passenger can make payment using APSRTC eWallet account. d. To enhance the security of eWallet, dynamic OTP generation and validation shall be incorporated in the work flow. e. Transfer wallet balance to friends account in APSRTC e-wallet. f. Track transactions status and handling of failure transactions. g. Detailed transaction history. h. Necessary reconciliation reports.
5.2.7.Working illustration for Long Distance Services Sample Route – Vijayawada PNBS, Vijayawada Benz Circle, Eluru, Rajahmundry, Vizag. Service No – 1234
1. Advance Booking
a. Online Booking for service 1234 is enabled in advance as per the reservation days defined in OPRS. b. Advance Bookings accepted through APSRTC Online Portal, Bus Stations Counters, ATB agent, B2C and B2C Sub API. c. In addition to the existing payment options, revenue of fare through QR code (UPI)/NCMC payments, APSRTC Wallet (through OTP validation) shall be enabled at Bus Station Counters, ATB, Driver App and Ground Booking App. d. Advance Booking continues as per the definition in OPRS and/or until driver starts trip and downloads waybill into Driver Mobile App at Vijayawada PNBS whichever is earlier. Current booking commences as per the above criteria. e. All tickets shall be issued against a valid mobile Number. OPRS shall send e-ticket, QR ticket, SMS ticket to all tickets booked. f. Revenue details to sync with CIS on waybill generation and / or when the trip / duty ends.
2. Payment Acceptance Process
a. The following payment collection process shall be applicable for Bus Station Counters, ATB Agent counter, Driver App and Ground Booking App. This is applicable for both Current and Advance Booking process. b. Cash Payment – Passengers walks into the bus/counter/ground booking staff, tender the cash and collect the ticket. Option to issue ticket by cash is to be provided. The cash mode is configurable from the back-end system.
Page 51 of 223 c. Dynamic QR Code (UPI)payments – During the ticket booking process, upon selection of the OD, DOJ etc, a dynamic QR code is generated on the screen. The QR code is scanned by passenger through any of UPI payment enabled App. On successful payment by the passenger in their phone, the Driver/Conductor/Ground Booking app should generate ticket by direct communication to the central server. There is no manual intervention to validate the payment receipt to generate the ticket by Driver or RTC Staff. d. APSRTC wallet payment – During the ticket booking process, upon selection of the OD, DOJ etc, customer’s APSRTC wallet mobile number need to be entered for collecting the payment from customer’s wallet. An OTP code is generated and sent as SMS to the customer for confirming the transaction. Customer tenders OTP to Driver/Conductor/Ground Booking for validation by entering in the Smart Ticket Booking App. Upon confirmation of payment deduction from customer’s wallet and ticket is automatically generated. There is no manual intervention to validate the payment receipt to generate the ticket by Driver or RTC Staff. Customer registered mobile receives necessary transactional notifications based on the configurations set at the central server. e. Payments received through Cash or UPI or NCMC or APSRTC wallets are accounted as follows: i. In OPRS all revenue accounting process is based on a Bus Station and Depot to which the Bus Station is assigned. ii. Bus Station Counters and ATB agents are assigned to a bus stations (which in turn are assigned to Depots). All revenue made shall be deposited in respective bank account of Depot to which Bus Station is assigned. iii. Drivers and Ground Booking staff are assigned to Depot. All revenue made shall be deposited in respective Depot’s bank account to which the staff are assigned. iv. Revenue accounting is based on the Depot to which a Service is assigned. v. On periodic basis, IDT (Inter Depot Transfer) report generated in OPRS shall be used to make inter depot accounting adjustments of the revenue. vi. In case of ATB agent, when using UPI or NCMC APSRTC wallet payment, only commission will be credited to their account. Revenue of ticket amount shall be deposited to RTC account directly. In case of ticket cancellations, only commission amount shall be debited from agent account. The refund shall be automatically credited to customer’s UPI or NCMC or APSRTC wallet.
3. Current Booking
a. Current booking starts from 30 mins before service start time at the origin or when driver starts the trip and continues until it reaches till the last stop. b. Booking of tickets will continue for all combination of OD through APSRTC Online Portal, Bus Stations Counters, ATB agent, B2C, B2C Sub API, Ground Booking App and Driver App. c. Tickets are booked by taking customer mobile number. In current booking only SMS shall be sent to customer with details of the Service No, OD, DOJ and Bus Number. d. Driver initiates Stage Left operation if moving from the departure location. Stage Left is performed by driver before Stage Close operation. e. Stage Update Operation (Eg: Bus is moving from VJA->Benz Circle->Eluru->Rajahmundry) Performed at Vijayawada PNBS) i. Will stop booking from Vijayawada PNBS to all other destinations in all modes except through Driver App.
Page 52 of 223 ii. Booking from other stages (i.e., Vijayawada Benz Circle, Eluru, Rajahmundry) to all other enroute destinations will continue through APSRTC Online Portal, Bus Stations Counters, ATB agent, B2C, B2C Sub API and Ground Booking App. iii. Ground Booking App can issue tickets only from booking stage at which the app is deployed to enroute locations. Ex: Staff deployed at Vijayawada Benz Circle can issue tickets from Benz Circle to enroute locations but not from PNBS or Eluru or Rajahmundry to other enroute locations. iv. Stage Left operation will help Driver to cross check if all customers boarded the bus from a stage and to issue tickets to any customers who might be waiting near the bus. v. Driver performs Stage Close operation. vi. Stage Close Operation vii. Will stop booking of tickets from Vijayawada PNBS through Driver App. viii. Will enable booking of tickets from Vijayawada Benz Circle through Driver App. ix. The cycle of stage left and stage close operation will continue till the driver reaches LS (Last Stage)-1 stage i.e. Rajahmundry in this illustration. The booking disabling at each stage happens based on these operations and follows the process as defined above.
4. Validation and Authentication of Tickets
a. The ticket must withstand both digital authentication through QR codes using the Android POS or PIN based validation or a visual authentication through an animation that cannot be easily replicated. b. Ticket validation must function on both the Android POS and the passenger’s mobile phone. Once validated on passengers mobile phone, the QR code shall be defaced to avoid further validation in other buses. c. Validation logic shall work in both offline Android POS and online Android POS. d. Validation logic shall be applicable for tickets booked through APSRTC web portal, RTC operators, ATB Agents, B2C Agents etc., e. Validation logic shall stand good for OPRS service tickets, Non-OPRS Service tickets, Open tickets (Route based tickets) and Ground Booking Tickets also.
5. POS/Mobile App Booking Control Logic on Internet Connectivity
a. Every ticket booked is in sync with OPRS server in real time. b. If POS/Mobile app has internet, current booking will continue at all modes as per above. c. If POS/Mobile app has no internet connectivity, current booking will discontinue at all modes and re-enabled once POS/Mobile app is connected to OPRS servers. d. POS/Mobile app will continue issuing tickets even when internet connectivity is not available. These tickets will be auto synched with OPRS once internet is available.
6. Bus Pass Validation
a. Crew will check photo ID and scan QR Code in the bus pass using the POS/Mobile app. b. Bus Pass travel will be recorded against the waybill if the pass is valid for travel based on the route, bus type and pass expiry date combination. Page 53 of 223 c. No ticket shall be booked but seat count logic will continue to work based on the number of passes scanned. d. In case of Aadhaar based bus pass, post scanning of Aadhaar card, system shall fetch pass information from the central server for validation. e. Bus pass holder travel details are duly captured and sync with central server to generate necessary MIS reports.
7. Trip Closure and Duty Closure in POS/Mobile App
a. Trip Close will close the waybill and trip ends. No more bookings are allowed against the trip. b. Trip Close will once again sync all tickets of the trip with OPRS for reconciliation. c. Duty Close will generate report on screen showing details of waybill collection and amount to be deposit to depot cash counter by the driver. d. Duty Close will once again sync all tickets of trips with OPRS for reconciliation. e. Trip Close and Duty Close shall send the tickets and revenue information to CIS system.
8. Ground Booking App Ticketing, Cash Collection and Deposit Process
a. Ground Booking App will be able to view the list of all Bus Services which are due to travel along their booking point. Staff may choose any service and book ticket by entering the destination and no. of passengers. b. Ground Booking App will also have option to view ETA (Expected Time of Arrival) of a bus to his booking point based on the POS/Mobile app GPS (Global Positioning System). The GPS coordinates are relayed to OPRS servers so that ETA can be determined and displayed in the Ground Booking App. c. Ground Booking App login and cash deposit operations are like the process being followed in OPRS Bus Station Counters. d. Each Ground Booking staff will receive a login and this login is assigned to a Bus Station and in turn to a Depot. e. Ground Booking Staff will have a login against which all daily collections will be recorded. f. Ground Booking Staff will end the duty and deposit cash with respective Depot cash collection counter.
5.2.8.Working illustration for Short Distance Bus Services (Mofussil Services, Open Ticket and City Buses) Sample Route – Vijayawada PNBS, Vijayawada Benz Circle, Gannavaram, Hanuman Junction, Eluru. Service No – There is no service number allotted for Non-OPRS services.
1. Timetable/Service Creation in OPRS
a. Scheduled operations (planned timetable) of all Non-OPRS services shall be defined in OPRS. b. The DCP number is allotted Non-OPRS (short distance/ordinary/city bus) services with multiple trips (time slots) for the day/week/ month, along maximum no. of seats in a bus, etc. c. Enabling advance ticket booking for these services will be through Open Ticket Booking System.
Page 54 of 223 2. Open Ticket Booking
a. Passenger book Open Ticket by searching for Origin, Destination and Date of Journey combination. b. List of Non-OPRS bus services available will be shown to customer along with Bus Type by slot, in general 24 hours split into hourly slot or slots as defined by APSRTC. c. Customer may choose to book Open Ticket based on time slot and seat availability count. d. Customer needs to provide details like name, mobile no and email to book the ticket. QR ticket along with PIN will be sent to customer. The same shall be used by customer to board the bus. In case customer does not have a smart phone, physical QR ticket may be printed for ticket being issued at bus station counters/agents. e. The seat availability on a route is defined based on the business logic defined in OPRS. f. Ex: Vijayawada – Guntur. If there are total of 10 buses running between 9 AM to 11 AM with per bus capacity of 40 seats. Corporation may define a logic to sell only 50% of the available inventory through Open Ticket system. This is to ensure customers booking Online Open Tickets and directly coming to Bus Station will be able to find buses during the given time slot. If the 50% inventory against the time slot is sold, the open ticket booking against the given time slot shall not be accepted. g. Corporation may choose to enable grace period of half hour or one hour for boarding the buses during the time slot i.e., customer who booked open ticket for 9 AM to 11 AM slot may be allowed to board the bus from 8:30 AM to 11:30 AM. This is for the operational convenience and is selectively configured. h. Corporation may enable customer booked in higher category buses be allowed to travel in lower category buses. If customer booked a ticket in Super Luxury bus, he may be allowed to travel in Pallevelugu without option for difference fare refund. Vice Versa is not allowed. i. Advance Open Ticket Bookings shall continue as per the business rule definition in OPRS. Ex: Open ticket booking is allowed till two hours prior to the journey time. If customer wants to perform journey today between 9 AM to 11 AM, customer must have booked open ticket before 7 AM today. j. Booking of Advance Open Tickets based on OD, DOJ, Bus Type and Time Slot will continue for all combination of OD through APSRTC Online Portal, Bus Stations Counters, ATB agent, B2C, B2C Sub API based on the business rules defined in OPRS. k. Open Ticket shall be utilised for Short distance and City Bus Services to allow Passengers to make advance booking. l. Open Ticket boarding is validated only by QR Code / PIN with or without internet. m. If open ticket is boarded in offline, then the PIN / QR code validated revenue details are duly accounted against the service / DCP no. in which the passenger performed the journey. n. Necessary transactional/MIS reports to be generated.
3. Payment Acceptance Process
a. The following payment collection process shall be applicable for Bus Station Counters, ATB Agent counter, Driver App and Ground Booking App. This is applicable for both Current and Advance Booking process.
Page 55 of 223 b. Cash Payment – Passengers walks into the bus/counter/ground booking staff, tender the cash and collect the ticket. Option to issue ticket by cash is to be provided. The cash mode is configurable from the back-end system. c. Dynamic QR Code (UPI)payments – During the ticket booking process, upon selection of the OD, DOJ etc, a dynamic QR code is generated on the screen. The QR code is scanned by passenger through any of UPI payment enabled App. On successful payment by the passenger in their phone, the Driver/Conductor/Ground Booking app should generate ticket by direct communication to the central server. There is no manual intervention to validate the payment receipt to generate the ticket by Driver or RTC Staff. d. APSRTC wallet payment – During the ticket booking process, upon selection of the OD, DOJ etc, customer’s APSRTC wallet mobile number need to be entered for collecting the payment from customer’s wallet. An OTP code is generated and sent as SMS to the customer for confirming the transaction. Customer tenders OTP to Driver/Conductor/Ground Booking for validation by entering in the Smart Ticket Booking App. Upon confirmation of payment deduction from customer’s wallet and ticket is automatically generated. There is no manual intervention to validate the payment receipt to generate the ticket by Driver or RTC Staff. Customer registered mobile receives necessary transactional notifications based on the configurations set at the central server. e. Payments received through Cash or UPI or NCMC or APSRTC wallets are accounted as follows: i. In OPRS all collection accounting process is based on a Bus Station and Depot to which the Bus Station is assigned. ii. Bus Station Counters and ATB agents are assigned to a bus stations (which in turn are assigned to Depots). All collection made shall be deposited in respective bank account of Depot to which Bus Station is assigned. iii. Drivers and Ground Booking staff are assigned to Depot. All collection made shall be deposited in respective Depot’s bank account to which the staff are assigned. iv. Revenue accounting to a Depot is based a schedule/trip start done by Driver App login. Based on the Driver login, trips initiated are assigned to the same depot to which the driver login is attached. v. On periodic basis, IDT report generated in OPRS shall be used to make inter depot accounting adjustments of the revenue. vi. In case ATB agent when using UPI or APSRTC wallet payment, only commission will be credited to his account. Collection of ticket amount shall be deposited to RTC account directly. In case of ticket cancellations, only commission amount shall be debited from agent account. The refund shall be automatically credited to customer’s UPI or NCMC or APSRTC wallet.
4. Current Booking
a. Current booking is allowed till the bus reaches destination. b. Crew initiates trip start operation at Vijayawada PNBS. c. Customer booking ticket must provide mobile number to receive e-ticket with details of ticket no, OD, DOJ, Bus No and PIN for boarding. In case customer does not have a mobile no, booking staff will give two-or three-digit PIN which shall be told to driver for validating the boarding. d. The trip will appear for current booking for bus station counters located at Vijayawada PNBS only.
Page 56 of 223 e. Crew will also be able to issue Bus Tickets from Vijayawada PNBS to en-route points for customers who purchase ticket in the bus. Bookings through driver app may be enabled based on type of bus operation like Non-Stop Services, etc. f. Crew will also be allowed to accept Open Tickets from Customers by scanning the QR ticket using POS/Mobile app. g. Tickets booked by POS/Mobile app from Vijayawada PNBS to enroute destinations, Tickets Booked at Bus Station Counters at Vijayawada PNBS, Tickets scanned at Vijayawada PNBS and Bus Passes scanned at Vijayawada PNBS are collectively taken into consideration for the count of vacant seats available for booking. h. For Non-OPRS services, seat selection process is not mandatory. System will issue tickets without seat number allotment. i. Driver initiates Stage Left operation at Vijayawada PNBS. Stage Left action is performed by driver before Stage Close operation. j. Stage Left operation will enable current booking at CS (Driver App Current Stage) + 1 stage only in the current route. Following sample helps understand this process. k. Stage Left Operation (at Vijayawada PNBS) will stop booking from Vijayawada PNBS to all enroute destinations at all Vijayawada PNBS bus station counters/ground booking except in the POS/Mobile app. l. Booking from immediate next stage i.e., Vijayawada Benz Circle to all other enroute destinations will open. Assuming that Ground Booking App is being used at Vijayawada Benz Circle, booking for the current trip will be enabled through the App. m. Ground Booking App can issue tickets only from booking stage at which the app is deployed to enroute locations. Ex: Staff deployed at Vijayawada Benz Circle can issue tickets from Benz Circle to enroute locations but not from PNBS or Gannavaram or Hanuman Junction to en-route locations. n. Tickets issued by Ground Booking App at Benz Circle will be continuously synched with Driver App. o. Stage Left operation will help Driver to cross check if all customers boarded the bus from a stage, issue tickets to any customers who might be waiting near the bus or board the customers who might have come near the bus with Open Tickets. p. Crew performs Stage Close operation before leaving Vijayawada PNBS if ticket issuing/boarding passengers is not required at this stage. q. Stage Close Operation (at Vijayawada PNBS) i. Will stop booking of tickets from Vijayawada PNBS through POS/Mobile app. ii. Will enable booking of tickets from Vijayawada Benz Circle through POS/Mobile app. r. Stage Left Operation (at Vijayawada PNBS) i. Crew will reach Vijayawada Benz Circle and perform Stage Left Operation at the time of bus leaving from that location after boarding all the eligible passengers to travel in the bus. ii. Booking from immediate next stage i.e., Gannavaram to all other enroute destinations will open. Assuming that Ground Booking App is being used at Gannavaram, booking for the current trip will be enabled through the App. iii. Will stop booking from Vijayawada Benz Circle to all enroute destinations at Vijayawada Benz Circle Ground Booking App except through Driver App.
Page 57 of 223 iv. Crew will check the details of customers boarding the bus at Benz Circle by validating the two or three-digit PIN issued to customer by ground booking staff or validating the open tickets by way of scanning the QR code. v. Crew performs Stage Close operation before leaving Vijayawada Benz Circle. s. Stage Close Operation (at Vijayawada Benz Circle) i. Will stop booking of tickets from Vijayawada Benz Circle through POS/Mobile app. ii. Will enable booking of tickets from Gannavaram through POS/Mobile app. t. The cycle of stage left and stage close operation will continue till the crew reaches LS (Last Stage)-1 stage i.e., Hanuman Junction in this illustration. The booking disabling at each stage happens based on these operations and follows the process as defined above.
5. Open Ticket Validation
a. Crew can validate the open ticket by scanning the QR ticket using the POS/Mobile app. b. Ticket acceptance is based on the OD, Bus Type, DOJ, Time Slot for boarding. c. Ticket shall be accepted only after meeting the business logic criteria as mentioned above. d. The revenue from open ticket thus scanned will be accounted against depot to which the bus belongs to. e. Ticket booked by counters and Ground Booking App are directly linked to the DCP code / Service No. of the bus for which the current trip being performed.
6. POS/Mobile app Booking Control Logic on Internet Connectivity
a. Every ticket booked is synced with OPRS server in real time. b. If POS/Mobile app has internet, current booking will continue in bus stations counter or Ground Booking App at CS (Driver App Current Stage) + 1 stage as illustrated in above example. c. If POS/Mobile app has no internet connectivity, current booking will discontinue. d. POS/Mobile app will continue issuing tickets even when internet connectivity is not available. These tickets will be synched with OPRS once internet is available.
7. Bus Pass Validation
a. Crew will scan the bus pass using the POS/Mobile app. b. Bus Pass travel will be recorded against the waybill if the pass is valid for travel based on the route, bus type and pass expiry date combination. c. No ticket shall be booked but the seat allotment and seat count logic will continue to work based on the number of passes scanned.
8. Trip Close and Duty Close in POS/Mobile app
a. Trip Close will close the waybill and trip ends. No more bookings are allowed against the trip. b. Trip Close will once again sync all tickets of the trip with OPRS for reconciliation. c. Duty Close will generate report on screen showing details of waybill collection and amount to be deposit to depot cash counter by the driver. Page 58 of 223 d. Duty Close will once again sync all tickets of trips with OPRS for reconciliation. e. Trip Close and Duty Close shall send the tickets and revenue information to CIS system.
9. Ground Booking App Ticketing, Cash Collection and Deposit Process
a. Ground Booking App will be able to view the list of all Bus Services which are due to travel along their booking point. Staff may choose any service and book ticket by entering the destination and no. of passengers. b. Ground Booking App will also have option to view ETA (Expected Time of Arrival) of a bus to his booking point based on the Driver App GPS (Global Positioning System). The GPS coordinates are relayed to OPRS servers so that ETA can be determined and displayed in the Ground Booking App. c. Ground Booking App login and cash deposit operations are like the process being followed in OPRS Bus Station Counters. d. Each Ground Booking staff will receive a login and this login is assigned to a Bus Station and in turn to a Depot. e. Ground Booking Staff will have a login against which all daily collections will be recorded. f. Ground Booking Staff will end the duty and deposit cash with respective Depot cash collection counter. g. On duty end, OPRS shall send the tickets and revenue information to CIS system.
10. Open Ticket Booking
a. Time Slot Duration – should the time slot for open ticket should be 1 hour or 2 hours or 3 hours. b. Ticket Validity Grace Period – should we allow the customer to board the bus if customer comes 30 min prior or 30 mins after the ticket time slot period. c. Process to refund in case of not travelled or should these tickets be non-refundable. d. Ticket booked for Upper Category may be used for Lower Category. The differential fare is non- refundable. Suggested to avoid these refunds considering the problems in terms of reconciliation refund processing. e. Lower category open ticket shall not be allowed to travel in higher category bus. No differential fare option collection option as of now. f. Normalisation of Bus Station names and Depots across RTC depots and OPRS. This activity is required for both OPRS and Non-OPRS services. Unique codes provided by APSRTC shall be super imposed on the maps and lat long co-ordinates shall be attached. g. Open Booking Schedule (timetable) feeding in OPRS. h. Open Ticket capacity to be kept open for advance booking i.e., 50% or 60% of seats available in a route should be kept open or not. i. APSRTC wallet to be used for collection of fare through Bus Station Counters, ATB agents, Driver App and Ground Booking App. j. All tickets issued shall be paperless. k. SMS tickets are issued against all ticket bookings. l. Accepting QR ticket as valid document to travel. m. Accepting SMS ticket as valid document to travel.
Page 59 of 223 n. In case of customer not having mobile phone, decision to accept PIN while boarding as a ticket validation process must be decided. o. Corporation shall provide smart phone/POS to all drivers/ground booking staff for issuing of tickets
5.2.9.Payment Integration, Security and Other Integrations
1. Payment options must include RBI-approved digital payment options, including UPI, e-wallets and NCMC cards. 2. PCI-DSS standards must be followed for all card based payment functionality as well as for storage & authentication of tickets and adherence to industry standards in application security and functionality. 3. SMS gateway Integration. 4. eMail gateway Integration. 5. Adoption of NCMC cards as per Government of India guidelines. 6. Other integrations as detailed in this document and may arise from time to time as per need.
5.2.10.Targeted Users
1. Citizens i. The system should address the requirements of any traveller and should provide specific requirements of different types of commuters. ii. Students are special category of commuters who may be allowed special privileges, such as pricing, periodicity, validity of tickets etc., iii. Women citizens are special categories of commuters who may be allowed special privileges in terms of seating and ticket pricing, issue of seasonal passes etc., iv. Children citizens are special categories who may be allowed special privileges in terms of seating and pricing.
2. Special Passengers: i. The System should provide for special passengers and seat allotment and ticket pricing and cover people, such as, elected Representatives, Physically Challenged, Senior Citizens and any other Group as decided by APSRTC from time to time. These policies have to be dynamically configurable. ii. Group passengers who may be given bulk allotment of seats including hire of a Bus on Contract. iii. The System should facilitate special concessions for selective seats for a service. iv. The System should facilitate special concessions for groups of booking and for Schools and occasions like Jatharas.
3. Authorised Ticket Booking Agents i. The Agents should provide ticketing services either Current or Advance to passengers and the passengers must be able to access the reservation information and offer their services to the traveling public. ii. The System should be able to connect to Service Providers, like e-Seva, Gram/Ward Sachivalayam, MOBILE ticketing etc., to provide online ticketing services as well as secure and Page 60 of 223 accurate statement of revenue collection made on behalf of APSRTC and provision should be made to enable the System to access and integrate with other Government Departments, such as, Tourism, Endowments etc., to provide a Single Window facility for transport and accommodation etc. iii. The system should be configurable for the agents cash remittance for prepaid or postpaid method
4. Booking Clerks: i. The Booking Clerks at various Bus Stations and also at Depots should be able to access the new System to manage the services and ticketing process including viewing the service details, fare tables, cancellation, Pre-ponement, postponement both full and partial, generate Auxiliary Way Bills, Shift Revenue, etc., and also be able to do the ticketing process in full. 5. Drivers/ Conductors 6. Depot System Supervisors 7. Depot Supervisors 8. APSRTC Administrative Officers 9. Central Complaint Cell
Page 61 of 223 5.3. Automatic Fare Collection System (AFCS)
5.3.1.Scope:
1. Design, development, integration and implementation of required back-office software modules system for management of all fare media, ticket issuance and validation, revenue reporting and reconciliation. 2. Develop, Test and Deploy Android App that shall be installed on Android POS or Mobile Phone for issue of tickets through POS or Mobile Phone. 3. Provide training to all crew and staff on correct usage of Android POS app and daily reconciliation processes, including regular repeat and refresher trainings as may be needed. 4. Device level software application to be developed, maintained and upgraded to enable issuance and validation of tickets by the conductor against payment of cash, card or mobile ticket. 5. Mobile App shall be developed for the following: a. Driver/Conductor Bus Onboard Ticket issuing. b. Passengers/RTC operators /Agents booking App. c. Ticket Issuing by Ground Staff/Agents at Booking Points. d. TTI – Ticket Checking Staff App. 6. Driver/Conductor Bus Onboard Ticket issuing should support the following high-level functionalities a. Bus on Board Bus Ticket Issue b. Concession Ticket Issue c. Issue Advance Reservation Tickets for Other Bus Services d. Open Ticket Booking for Other Bus Services e. Collection of payment through Debit/Credit/UPI Payment f. Collection of payment through APSRTC Closed Loop e-Wallet g. Validation of Bus Tickets by scanning the QR ticket. h. Validation of Bus Ticket by entering the PNR i. Validation of Bus Ticket in offline mode j. Option to download ticket details of advance reserved bookings k. Option to transfer tickets to other bus in case of bus breakdown etc l. Shall have functionality to check the revenues collected. m. Shall have functionality to check the earlier trip details and collection n. Shall have functionality to send communication via SMS to advance booking Passengers regarding bus delays, etc. o. App should work in Offline Mode and issue only Cash tickets in case of loss of internet connectivity. 7. Ground Booking/Ticket Issuing should support the following high-level functionalities a. Issue Current booking tickets for the bus that are already enroute b. Concession Ticket Issue c. Services running through a bus station shall be listed by default for the Ground Staff to make the Current Booking. d. Ground Staff shall have option for saving favourite booking list in the home screen. Page 62 of 223 e. Ground Staff shall have option to search for a service based on Source/Destination combination. f. Shall have access to the ETA (Estimated Time of Arrival) of a bus at the Bus Station g. Issue Advance Reservation Tickets for Other Bus Services h. Open Ticket Booking for Other Bus Services i. Collection of payment through Debit/Credit/UPI/NCMC Payment j. Collection of payment through APSRTC Closed Loop e-Wallet k. App shall work only in Online Mode. 8. Check Staff App a. Shall support download and validation of tickets against a bus b. Shall support functionality to record the checking details on the central system c. Shall have functionality to generate reports d. App shall work only in Online Mode 9. The business logic and rules of the corporation applicable to fares shall be integrated into the solution. 10. The complete business process flow from the assignment of vehicle and crew to service, waybill generation, etc., until the closure of the service, end to end shall be integrated with the APSRTC ERP Platform.
5.3.2.Functional Requirements
5.3.2.1.Access to Android POS/eTIM/Mobile Phone app
1. The conductor and driver should be able to login to the Android POS app via a combination of username + password (ID + PIN). 2. Other roles may be required to login to the device based on varying operational needs. 3. App installed on phone needs to have activation process. On successful activation, the driver / conductor is authorized to Login to the app with provided user name / password. 4. App access has to be controlled based on the remittance of previous day collection / earnings. If previous duty collection is not remitted to the corporation then the login is not allowed to perform any transactions.
5.3.2.2.Data stored on Android POS/eTIM/Mobile Phone:
Provision to store conductor ID, driver ID, vehicle number, crew duty number and crew duty details i.e. schedule time, departure time, bus service type, stage and fare table of routes operated, concession fare charging rules, other fare rules, etc.
5.3.2.3.Ticketing functionality:
1. Provision to print conductor ID, depot name, issue date and time, fare, and sequential ticket number on each ticket. System to be flexible enough to incorporate other details at a later stage. 2. Provision to record and print various types of tickets — general ticket, group ticket (adult + child + concession), other concession tickets, differential fare ticket, various schemes tickets, luggage ticket, package ticket, etc. Page 63 of 223 3. Types of fares and tickets should be able to be created centrally and updated to Android POS devices via on-demand Over The Air (OTA) updates 4. Provision to issue refunds of fare in case of change in service type or full / partial cancellation of service or face value revision 5. Provision to view any ticket issued by the conductor 6. Provision to record the details of passengers from whom fare is not collected by the conductor — e-Ticket holders, pre-paid smart card pass holders, monthly / quarterly pass holding passengers, employee duty pass holders, etc., with a view to provide detailed route-wise analysis of usage of services by such category of passengers. Such passes and other pre-paid tickets may be in the form of paper tickets, physical cards, e-tickets or smart cards. 7. Ticketing and passenger information should be relayed in real-time upon each transaction to the Central Server, and also available in batches for reconciliation and settlement as per operational cycles e.g. for each trip, for each shift, at the end of each day, etc. 8. In the case of loss of data connection, ticketing transactions must be stored locally and then transmitted to the Central Server immediately upon re-establishment of the data network. 9. All ticketing functions must work in offline mode also in the case of loss of data connection and then be settled by batch mode in pure offline condition. 10. Tickets shall be printed in English/Telugu language as per the layout approved by APSRTC.
5.3.2.4.Ticket validation functionality:
The Android POS app must be able to validate all forms of pre-purchased tickets (e-tickets, smart card tickets, paper-based QR code tickets) in both online and offline mode and / or ticket number in online mode. These tickets could be single-journey, return and / or monthly passes or other multi-journey tickets.
5.3.2.5.Security:
1. Security of private APN network with industry-standard encryption protocols 2. Read / write facility for smart cards, confirming to ISO 14443 specifications, including the ability to modify the software to read / write / validate any existing or proposed transport mobility smart cards confirmed by the State Government / Central Government / MoUD / Metro , etc. 3. Tamper-proof software and hardware, with alerts upon detected tampering events.
5.3.2.6.Performance:
1. The System should be able to perform without any material degradation of performance over time 2. The System should have an accuracy of 99.95% for every transaction, reports generated, MIS and accounting done through the Android POS. 3. The time taken to print/generate a ticket through the Android POS/eTIM/Mobile Phone after data entry should not exceed 4 seconds per transaction where applicable. 4. Ensure availability and uptime of Android POS/eTIM/Mobile Phone app and software platform as per SLAs mentioned.
Page 64 of 223 5.3.2.7.Integration with fare media i.e. Android POS, Mobile Ticketing, NCMC:
1. Acquire and process all the transactions from all fare media at acceptance infrastructure. 2. Hold and download the fare media parameters and fare table information to Android POS devices. 3. Communicate with each device via network and process the data received to provide overall audit, statistical and operational information. 4. Generate the necessary management reports from the fare media transaction information. 5. Generate and update blacklists for all applicable fare media and download these to sales and validation equipment. 6. Dynamically refresh Mobile Ticketing application for transit products, fares and other transit parameters. 7. Generate dynamic QR code for mobile tickets.
5.3.2.8.Reconciliation:
1. Automatic generation of daily, monthly & yearly reports for revenue reconciliation using revenue data 2. Transactions, audit register and cash amount. Reports shall be generated depot wise and shift wise 3. Reconciliation report should be generated at EoD for each device. 4. Facilitate interactive report generation on select parameters, period and comparison.
5.3.2.9.Database management system:
1. Support data integration, data recovery, exception handling, validation and security 2. Parallel processing of transactions. 3. Maintain historic data for 3 years. 4. Data beyond 3 years to be archived during the agreement period.
5.3.2.10.Product configuration management:
Configure transit products with parameters such as product ID, name, expiry date /time, number of days in week, start and end time, route/stop , device type, fare, discounted fare, profile , etc.
5.3.2.11.Security management:
1. Restrict access to entire AFCS only to authorized users. 2. Create different user groups and assign different access levels / privileges.
5.3.2.12.Ticketing and revenue reports:
1. Conductor sign-on/sign-off details as on required date & time with summary containing conductors not reported back as per schedule duty, imprest amount tally report.
Page 65 of 223 2. Machine detail report indicating number of online Android POS, number of Android POS in depots and unmoved / idle Android POS in depot on at a date and time. 3. Daily cash collection report (conductor wise, route wise, depot wise, etc.) 4. Conductor-wise shortage / excess report 5. Passenger count by trip, route on a daily, weekly, monthly basis. 6. Stage wise Boarding and Alighting Matrix
5.3.3.Targeted Users:
1. Citizens 2. Drivers/ Conductors 3. Depot System Supervisors 4. Depot Supervisors 5. APSRTC Administrative Officers 6. Central Complaint Cell
Page 66 of 223 5.4. Pass Automation and Accountal System (PAAS)
5.4.1.Scope
1. Vendor has to develop Bus Pass System for registration, issue, renewal and validation system as part of UTS. 2. Bus Pass system shall provide features to issue and validate different types of passes. 3. Shall provide necessary dashboards and reports as detailed in the subsequent sections of this RFP.
5.4.2.Functional Requirements
1. Option to feed applicants details in case of Free pass applicants in student category. Other than free passes all other route and fixed passes data filling is done by students only through website in online. 2. Issue of online MR (wherever applicable), online photo grabbing and issue of bus pass identity card. 3. Renewal of bus passes online or through bus station counters should be allowed. 4. Bus Pass Stock management module in case of physical bus passes being issued at Bus Station Counters. 5. e-Bus Passes shall be issued and passengers and this will be shown on the mobile phone of the passenger. 6. Student enters his/her Aadhaar No. Child Information API will be provided by Govt. of AP. The Aadhaar No. in Child Information database shall be validated. 7. If the Aadhaar No. is found then the student enters the further details like Bus pass Type and if Route exists route will be selected. 8. After filling these details, amount will be paid through online itself. 9. Now the student will be registered for the pass. 10. While travelling, the conductor’s having the bus pass validation Application in the POS/Mobile App devices will scan the commuter’s Aadhaar Card. 11. Upon scanning the Aadhar, the pass details shall be pushed from central server to the Android App through Web API for validation and recording purpose. 12. Bus Pass data shall be integrated with OPRS for validation through Android Ticketing App. 13. Franchise module for outsourcing the application to be used by 3rd party organisations to issue bus passes on behalf of APSRTC.
5.4.3.Targeted Users:
1. Citizens 2. Drivers/ Conductors 3. Depot System Supervisors 4. Depot Supervisors 5. APSRTC Administrative Officers 6. Central Complaint Cell
Page 67 of 223 5.5. Automatic Vehicle Location System (AVLS)
AVLS shall be implemented based on the GPS location collected through the Android POS/eTIM/ Mobile Phone used for ticketing. It is intended to track the bus position and display real time data on the video wall or wall mounted screen installed in the Central Command Control. The location data gathered from the Android POS/eTIM/Mobile Phone devices will also be used to display the status of the buses on web portal and mobile app to the passengers. Proposed system shall increase the efficiency of public transport.
5.5.1.Scope:
1. Creation of GIS layers with route maps based on bus stop locations and stop sequences. 2. Design, develop, integrate, deploy software platform that enables live tracking to all stakeholders. 3. Incorporate GPS based vehicle tracking in the software solution installed in the Android POS/ eTIM/Mobile Phone used by drivers/conductors for ticket booking. 4. Provide GIS based road maps with perpetual license as may be required. 5. Supply, installation, testing and commissioning of all the required Server Hardware, Firewalls, Software (operating system software, GIS software, RDBMS, Application server software, application software, Digital maps/Google map licenses , etc.), Database, Data Storage, all required Connectivity, Networking Equipment’s, etc., required for Data Center and hosting the same in a Data Center and paying hosting charges. 6. SI shall host the entire application on reputed cloud platforms which are on par with Tier-III DC standards
5.5.2. Functional Requirements:
1. AVLS shall determine the precise location of Android POS devices and transmit the same to the central command control at defined intervals (user configurable intervals which can be as low as once in every 10 seconds) of time. 2. AVLS shall compare the actual location of the Android POS, at a given time, with its scheduled location. 3. AVLS shall calculate the time for the bus to reach all subsequent stops (ETA) along the route, factoring in the current bus speed, distance to be covered and any deviations from the schedule and dynamically updating the same every 10 seconds. 4. The geographical information system (GIS) applications shall enable display of the position of vehicles on a detailed digitised road map/Google map/customised map and linked with the communication control and reporting applications. 5. AVLS shall have ability to locate a specific bus in real time to know the position and status. 6. The system shall provide access to real time information related to Expected Time of Arrival (ETA), Estimated Time of Departure (ETD) , etc., through SMS/mobile app/web portal. 7. The application shall be able to receive emergency messages from the vehicles by generating alarms at the Central Command Centre to attract the operator’s attention. 8. AVLS should be capable of Centralised route/service management. 9. AVLS shall support dynamic trip configuration, enabling the control room to activate individual trips, provide route numbers for the UP or DOWN trips. Based on the trip number downloaded, the
Page 68 of 223 route information in terms of bus stop locations, bus stop index numbers (current and the next bus stop index), etc., shall also be downloadable to the Android POS device on board . 10. AVLS needs to integrate with other sub-systems in the overall ITS solution framework including voice announcement system , etc.. 11. AVLS to facilitate GPS based monitoring of trip and service kilometres operation against schedule. 12. Ability to receive SOS and alerts from moving / stranded buses en-route. 13. Facility to track defined versus actual movement of vehicles. 14. Map (complete Andhra Pradesh and Telangana covering the required routes) and select cities like Chennai and Bangalore. Scaling should be of minimum 1:5,000. 15. AVLS shall provide for appropriate user access and security controls. 16. Vehicle Master details, Schedule Allotments, Vehicle Assignments etc shall be done through CIS and integrated with OPRS/Android POS/eTIM/Mobile. The same information shall be utilised as part of AVLS module for all tracking purposes. 17. Full details of each of the vehicles of APSRTC or those sub-contracted shall be entered into a database to be ready when the services are launched. 18. The data elements may include vehicle description, identification, its details and other data elements as identified to be essential by Vendor and APSRTC. 19. The data shall at any point in time be easy to update with auto update facility and provide for quick click access to list of values to prevent errors in data entry during manual operations. 20. The database shall be up-to-date on the movement of vehicles along with their defined schedules and destinations and details of the drivers of the vehicles. 21. The application shall provide a graphical interface to make quick position related assessments. 22. The application software shall support facilities to zoom-in to enable close-up view (on the map) of the vehicle of interest or to zoom-out to view all the vehicles on the screen. 23. The interface of the application shall support multiple window views for an overview with capabilities to close up and enlarge a screen of interest. 24. The Depot Level interface required for feeding the route, service, stops, stop GPS co-ordinates, etc., required for the AVLS and PIS is also to be provided and system shall also be integrated with OPRS and CIS for auto capture of the details, without any manual intervention. 25. AVLS shall provide these data on real time basis at pre-determined and configurable intervals over wireless networks and shall support both the time mode (periodic updates based on time interval) and Distance Mode (periodic updates based on distance interval). 26. AVLS shall enable motion-based, scheduled or on-demand position reporting, securely over cost effective communication networks. 27. The system shall support multiple concurrent user queries/transactions (about 10,000 concurrent users) with about 12,500 vehicles. However, the system shall be scalable as required at a later point. 28. Ability to locate a bus at a given time to estimate its arrival/departure time at the next destination, based on traffic density, distance, speed, run-time information from the previous bus arrival time for the same location , etc., and displaying the ETA at relevant Bus Stations/Bus Shelters , etc. 29. Support tracking of buses that deviate from the scheduled route based on definition of permitted geographic regions of operation. 30. Facility to view vehicle movements real-time on maps. 31. Facility to generate information such as travel time estimation, average time at bus stop, density of passenger traffic at different bus stops en-route, passenger traffic at different locations, alerts on exceptions and logging of the journey details of the bus for each trip. Page 69 of 223 32. Facility for playing back the recorded details of the bus movement along the authorized route. 33. Facility for playing back the recorded details of the bus movement on the given time period basis also. 34. AVLS shall enable operational managers to very easily create locations, routes, schedules using an intuitive user interface. 35. AVLS shall also support import or export of services to facilitate commuters in looking up for services directly in maps. 36. Register a bus on unscheduled route from backend on real time basis. 37. Exception Recording/Actions (Off-route Detection, Non-Stoppage at Bus stops, Trip Cancellation). 38. Real-time Running Trip Line diagram of buses on a particular route, for headway detection. 39. AVLS application software shall support calculation of distance travelled by a vehicle on a schedule/trip and average distance travelled and time taken in a schedule for a period. 40. Information elements that needs to be captured at the minimum shall include longitude, latitude, physical location with date and time stamps, bus number, service number, contact number and crew ID and overlay this on a map. 41. The AVLS system shall have the ability to raise alerts associated with simple business rules in the context of the operations and Vehicle Tracking and Monitoring. 42. Alerts will be displayed on the monitoring console and an extract of the same will be available on the user’s dashboard for the user with their jurisdiction of operation. 43. In case of vehicles that are moving, Alerts shall be flashed at the Central Command Control room as well as the nearest two Bus stands i.e., through one that is passed and the one approaching bus stand. 44. SMS notification to concerned officials for specified schedules/vehicles regarding certain parameters like regularity, skipping stops, speed violations, etc 45. Provision to capture information pertaining to incidents like riots, natural calamities, etc., and sending alerts to required bus stand. 46. Real time / history of all trips that are more than “X” minutes late (X input at run time by the user). 47. Real time / history / Record of a particular jurisdiction in maintaining ETA. 48. Real time / history of All Trips or specific trips between two points with a feature to playback. 49. The display of vehicles on the map shall be colour coded based on parameters such as regular schedules, special services, etc., as per operational requirement of APSRTC. 50. AVLS shall enable APSRTC staff to query and visualise graphically patterns of poor on-time performance in order to take corrective actions. 51. The accuracy of the prediction of Android POS location should not vary more than +/-3 meters. 52. Android POS Tracking software should be upgradeable/configurable over the air (OTA). 53. Android POS Tracking should support the configuration of standard parameters such as Over- Speeding, Harsh Braking, Harsh Acceleration , etc., as well as other general in-vehicle parameters and generate alerts as necessary. 54. Should be able to send GPS positional data (Latitude and Longitude) to back office server at configurable periodic interval which could be as low as 10 seconds. 55. In case of loss of communication link, the Android POS should be capable to store 9000 way points (More than 24 hours data for 10 sec interval) and send them to back office server when communication link is established. This data should be intact when Android POS switched off or during power failures, wherever applicable. 56. Should support both GPRS and SMS modes of communication
Page 70 of 223 57. AVLS related Software changes as and when required by APSRTC or on need basis. 58. Depot wise Region wise Type wise Route wise services depiction on map in real time shall be provided on the CCC video panels for monitoring. 59. Route wise service bus depiction should be enables on the CCC video wall or wall mounted screen as a line graph with colour coded symbols for on time, delayed and ahead of time services for monitoring. 60. This feature should also be made available on mobile and web interface to the administration.
5.5.3.Targeted Users:
1. Citizens 2. Driver/Conductors 3. Bus Station Controllers 4. Bus Station Enquiry Staff 5. APSRTC Administrative Officers 6. Central Complaint Cell
Page 71 of 223 5.6. Passenger Information System (PIS)
5.6.1.Scope
1. Development and maintenance of the required application software for the entire contract period. 2. Develop, Deploy, Maintain and Manage Web/Mobile App based PIS system and Auto announcement system as per the detailed functional specifications of APSRTC.
5.6.2.Functional Requirements
1. The system shall provide access to real time information related to Expected Time of Arrival (ETA), Estimated Time of Departure (ETD) etc.,24*7*365 through SMS/mobile app/web portal. 2. PIS real-time data shall be made available through SMS/Web/mobile app (both for iOS and Android). 3. Using the GPS co-ordinates of the bus stations en-route, the PIS shall be capable of announcing the estimated time to next stop and the arrival of the bus to that bus station in advance. 4. Facility for citizens to access and view position / location information on GIS maps near real time through Web interface with historic data displayed on maps. 5. Successful bidder will be bound to display all advertisements/information/matter as desired by APSRTC without any additional cost on Web and Mobile interfaces. 6. There should be a provision to group services by service numbers/service class/depots/service category/routes to display on a certain PIS displays. Vendor to provide necessary API to the PIS system. 7. The data on the Web and Mobile interfaces should be refreshed automatically without refreshing the entire page / screen. 8. If required, SI shall provide an API to 3rd parties for integration with Display Boards/Screens. 9. Passenger Information System shall provide real time traffic density Information, which can be used by commuters to facilitate travellers to better plan their trips, bypass congested routes or choose to delay departure times in the event of congestion. 10. The Central Command Control room display shall be capable of switching over to displaying the transit information of any of the PIS displays for viewing the content in real time. 11. Should support SoS alerts 12. Should have ability to automatically get the schedule information from back end servers. 13. Should have ability to automatically select the trip/route start and stop as per the schedule and send the same to back office server. 14. PIS related Software changes as and when required by APSRTC or on need basis.
5.6.3.Targeted Users: 1. Citizens 2. Driver/Conductors 3. Bus Station Controllers 4. Bus Station Enquiry Staff 5. APSRTC Administrative Officers 6. Central Complaint Cell Page 72 of 223 5.7. Command Control Centre (CCC)
The bidder should setup one CCC (Phone & Mail Support) at Head Office. The dedicated phone number for the same shall be obtained by the bidder in the name of APSRTC. Integrating a support desk arrangement that is made available as per business hours of operations of APSRTC. The CCC is part of the critical infrastructure for converging all data for visual display empowering the organisation to monitor traffic trends, revenue trends, revenue leakage, incident management, direct communication with operating crew, service quality like Punctuality, conducting polls/ surveys and collecting customers feedback on the ho etc.,
5.7.1.Scope: The CCC Desk should undertake the following activities
1. System Integrator shall setup Command Control Centre at APSRTC Head Quarters. 2. Shall procure, install and maintain 8*5” Video Wall at RTC House, APSRTC. 3. Install all related hardware, softwares, furniture, air-conditioning, for multi level views of UTS components. 4. All UTS services shall be integrated to CCC and shall enable APSRTC officials for monitoring of all services of UTS. 5. CCC shall be capable to integrate with multiple data sources and display related dashboards on the Video Wall. 6. Log service requests related to IT infrastructure of APSRTC under the scope of work and give them a service request number 7. Assign severity level to each service request 8. Track each service request to resolution 9. Escalate the service requests related to usage of application software to Application support team. 10. The CCC coordinator should log all service requests and assign the service requests to engineers and ensure that service request is closed. It is the CCC Coordinator’s responsibility to generate reports using the service requests logging and reporting tool as provisioned. 11. Provide L 1 support to crew on UTS related issues. 12. Shall provide dashboards for analysis. 13. Creation of knowledge base on frequently asked questions to aid users.
5.7.2.Functional Requirements
1. CCC shall have a 10-seater space who can work 24*7*365 with phone and email support. 2. Shall provide end to end Incident Management System. 3. CCC Centre should have manpower (preferably one supervisor and 9 CCC executives per day) to be provided by the vendor round the clock for providing trouble shooting activities in shifts. 4. Staff deployed at CCS shall attend to any queries from APSRTC staff related to UTS application deployed by the vendor. 5. Vendor will train the APSRTC staff for using the system and appoint personnel for trouble shooting activities. 6. In case of Accidents- Page 73 of 223 a. Shall obtain details from crew b. Co-ordinate with local DM/AM(T)/AE(M)/SDI c. Collect Photos, FIR(RTC) etc. d. Liaison with parent depot and attending depot
7. In case of Breakdown- 1. Shall obtain details from crew. 2. Liaison with parent depot and attending depot 3. Will monitor till the vehicle attended.
8. In case of Service Cancellation- 1. Shall contact OPRS team and cancel the service. 2. Shall inform to Central Complaint Cell. 3. Shall inform the Service operating attached Bus station.
9. In case of Employee Line Sick- 1. Crew will inform the Command Control Centre. 2. Command Control Centre shall co-ordinate with parent depot and nearby depot for smooth operation of service.
10. In case of non-reporting of reserved passenger 1. Crew shall inform Command Control Centre. 2. Command Control Centre shall give suitable instruction to proceed 3. Command Control Centre shall communicate to Central Complaint Cell.
11. In case of ePOS Failure- 1. Command Control Centre shall assist the crew in trouble shooting. 2. If the issue is not resolved, Command Control Centre shall co-ordinate and arrange ePOS from nearby depot.
5.7.3. Infrastructure
1. CCC connectivity (primary) - 10 Mbps - ILL 2. CCC connectivity (secondary - 100 Mbps Broadband 3. Wi-Fi Router - As required 4. 8-port switch - 2 or 16-port switch - 1 5. Anti- Virus - 10 6. PCs/ Desktops - 10 7. Multi-function Colour Laser Jet Printers - 2 8. Air-conditioners - as required 9. Furniture - As required 10. 5 KVA UPS with Batteries
Page 74 of 223 11. All payments related to CCC (Phone & Mail support) shall be paid by the SI except monthly Electricity Bills.
5.7.4.Targeted Users: 1. Drivers and Conductors 2. Depot System Supervisors 3. Depot Supervisors 4. Bus Station Controllers and Supervisors 5. APSRTC Administrative Officers 6. Central Complaint Cell
Page 75 of 223 5.8. Cargo and Courier Management System
5.8.1. Scope
1. The Customer should be able to book parcel, courier, bulk cargo in any authorised Parcel counter or through mobile app and web portal. 2. To provide Computerisation of booking of Parcel, Cargo & Courier services at specified outlets. 3. To provide accurate and easy accounting system of pack of parcel/Courier booked. 4. Optimisation of existing processes and standardisation. 5. Design, develop and implement a custom-tailored application with both self-service portal and assisted mode to book with multiple payment options. 6. One stop shop for all logistics booking, tracking and delivery of goods and parcels. 7. Application shall suit the business needs of individuals, businessmen, institutions, industries and government departments. 8. Warehouse Management
5.8.2. Functional Requirements
1. Generic workflow of the services shall contain a. Inspection - Ensure the item is not under prohibited items list. b. KYC - Name, photo and address of the consignee and consignor. c. Consignment - Item details, description, such as weight, volume etc., d. Shipping - From and To details e. Payment - Application shall facilitate multiple payment options including NCMC and COD. f. Confirmation-LR shall be generated and application shall notify the customer and receiver with sms alerts and tracking status periodically. g. Delivery - Consignment shall be delivered as per the customers request such pick up from APSRTC counters, door delivery etc., 2. Warehouse Management with proper tracking of goods at the delivery station with token system. 3. Application shall allocate bin/token number for storing of goods at delivery station and easy retrieval during delivery. 4. Application shall support various kinds of booking: a. Self Booking b. Courier Booking c. Parcel Booking d. Bulk Booking e. To Pay Booking f. Proof of Delivery g. Pre-Paid Booking h. Door-to-Door pickup and delivery solution. i. Paper Parcels Booking j. Advertisements k. 3rd party integrations - swiggy, zomato for delivery and pickup Page 76 of 223 l. Payment Reconciliation m. Franchise module for outsourcing the application to be used by 3rd party organisations to book parcels and receive parcels on behalf of APSRTC. 5. Optimisation of fleet and operations 6. Application shall support multiple booking modes: a. Web/Mobile based Self Service Portal - where the passenger enters the details and based on the criteria, parcel or goods shall be picked up from the customer location or the customer may handover at APSRTC Logistics counter. b. RTC Operator Booking - This module is used by the booking clerks at the depots/bus stations for the booking of goods and parcels. c. Authorised Agents - Authorized agents to book goods and parcels for customers. d. B2C Agents - Integration with online goods booking portals/apps to book goods and parcels. 7. Application shall provide workflow to enter into JVs with Online Goods Booking Portals and agencies. 8. Trucks on hire Contract System. 9. Application shall provide workflows to onboard hiring of lorries and trucks for transhipment of goods and parcels. 10. Configuration of commissions to various stakeholders in handling goods and parcels. 11. Provision of automated payment system and reconciliation of payments/commissions to various stakeholders. 12. Generation and validation of hire trucks payments. 13. Mobile app on Android and iOS platforms for customers. 14. Establish last mile connectivity for pickup and delivery of goods and parcels.
5.8.3. Integrations:
1. Payment options must include RBI-approved digital payment options, including UPI, e-wallets and NCMC cards. 2. SMS gateway Integration. 3. eMail gateway Integration. 4. Village and Ward Volunteer Ecosystem for last mile connectivity 5. Online Goods and Parcels booking portals. 6. Delivery chains such as Zomato, Swiggy etc., 7. Integration with APSRTC AVLS system. 8. Integration with APSRTC ERP Platform - CIS 9. Integration with CRM and other applications maintained at Central Complaint Centre.
5.8.4. Targeted Users
1. Citizens 2. Driver/Conductors 3. Bus Station Controllers 4. Bus Station Enquiry Staff
Page 77 of 223 5. APSRTC Administrative Officers 6. Central Complaint Cell 7. Hire Truck Agencies 8. Authorised Agents 9. Online Goods and Parcel booking agencies.
Page 78 of 223 5.9. Multi-purpose integrated Mobile app for mTicketing and PIS
5.9.1.Mobile app for passengers
1. Shall be available for both Android and iOS operating systems. 2. At a high level, the App shall have the following features for various categories of users. a. Customer Ticketing b. Agent Ticketing c. Special Hire Booking for Customers d. Parcel, Cargo and Courier Booking e. Fare/Tariff acceptance through Cash f. Fare/Tariff Acceptance through Digital media viz., Mobile/Aadhar based wallets, QR code, UPI, Open and Closed loop cards, NCMC, etc. g. Bus Pass Registration and Issue h. Vehicle Location Services i. TTI - Ticket Checking functionality j. Passenger information and feedback 3. Shall facilitate users to track the services, book ticket and bus passes. 4. Users shall be able to get list of nearby Bus stops using their device location and shall list all upcoming buses to those bus stops. 5. User shall be able to search for buses that are being currently operated between two bus stations. 6. User shall be able to track a Bus by vehicle number if required. 7. User shall be able to see the live bus location on the Google Map or any licensed map or customised map and should be able to track the bus as it moves. 8. When searching for buses between two bus stops, the user should be able to filter the results based on the service types. 9. When showing the list of buses, running between two bus stops, by default it should show the upcoming buses and if required the user should be able to see the entire scheduled list of buses. 10. By default, search results shall be sorted in departure time order from the selected origin. Options shall be provided to sort based on journey time, fare, travel distance, first/last mile connectivity distance etc., 11. User should be able to view fare information from any stop to any stop where a journey is possible along the bus network. 12. The mobile application should display the total fare across an entire journey while using the journey planner using any modes of travel. Trip planner functionality with last mile connectivity shall be enabled using user device GPS, search parameters (Origin, Destination etc). 13. Wherever APSRTC operation is not available, first/last mile connectivity shall be shown as walking upto 1000 meters distance and 2W/4W if the distance is beyond 100 meters to reach APSRTC pickup point/dropping point. 14. The app should also show the live occupancy status of the bus by way of data from the AFCS Sub- System. 15. All features except live information should be available in offline mode 16. When showing the bus/service schedule, the ETA should be displayed along with the scheduled time for all the upcoming bus stops in that service. Page 79 of 223 17. In addition to the service schedule with ETA, the details like Driver name, Route, Source and destination stops information should be displayed to the user. 18. The user should be able to add his favourite routes, trips, and service numbers for quick access. 19. The user should be able to track a service with Route number. 20. The user should be able to provide the feedback directly from the app on various pre-defined categories. 21. The user should be able to send SOS signals to officials when there is an accident, breakdown or when women needs some help. 22. The user should be able to set an alarm to alert the user on reaching his destination while travelling in the bus linking with ETA. 23. The user should be able to send an emergency message with location data to any two user’s choice mobiles numbers which are pre-saved in mobile app. 24. Provision to send banners to the public app about discounts and other important information should be provided. 25. There should be an option to show messages at the service level, when there are deviations in the route. 26. User shall be able to verify the details of Bus Pass and renew it online. 27. End-to-end Automation of apply, validation/verification of certificates, collection of amount and issue of digital pass and cargo booking. 28. 3600 Profiling of passenger as per timeline — purchase of tickets, bus passes, parcel, cargo & courier booking and frequent search routes, buses etc., 29. Alerts and Reminders on renewals of Bus Passes, journey reminders, status of bus passes and cargo tracking etc., 30. Integration and display of cargo & courier tracking on map. be available for both Android and iOS operating systems
5.9.2.Targeted Users: 1. Citizens 2. APSRTC Administrative Officers 3. Central Complaint Cell
Page 80 of 223 5.10. Web Portal
5.10.1.Scope
1. Unified portal to handle all ITS operations and their sub systems. 2. Shall be configured to control all AVLS, PIS, AFCS, CCMS, Android POS and other ancillary systems 3. Shall provide necessary dashboards and reports as detailed in the subsequent sections of this RFP.
5.10.2. Functional Requirements
1. The web portal should have secure have authenticated using the username and password. 2. The admin users should be able to assign a vehicle to a service directly from the app. 3. The admin users should be able to edit the schedules whenever required based on the depot. 4. The admin staff should be able to activate or deactivate a service at anytime. 5. The admin staff should be able to cancel a service directly through the web portal. 6. The admin staff should be able to view reports of all ITS 7. All the features in mobile app should be shown in admin level. 8. The live status of the last data packet received from VMU/Mobile as applicable for every vehicle in admin portal as well as admin mobile app should be shown dynamically Zone/Region/Depot wise. 9. The hire vehicle master with contract agreement period should be shown separately with VMU/ Mobile details as applicable. 10. Web Portal shall be responsive and customisable to all form factors (PC, Tablet and Mobile).
5.10.3.Targeted Users: 1. Depot System Supervisors 2. Depot Supervisors 3. APSRTC Administrative Officers 4. Central Complaint Cell
Page 81 of 223 5.11. Dashboards
The service provider shall provide graphical dashboard and Data analytics to have visual view of all / some key reports/parameters enabling quick decision making. The System Integrator shall provide a set of dashboards that enable the APSRTC to monitor and implement ITS effectively.
5.11.1.Performance Dashboards
Crew Performance: For all pre-configured parameters such as driver behaviour, harsh acceleration/ breaking, non-stoppage at designated points, unauthorised stoppages, vehicles stopping for long duration, not meeting the ETA and ETD schedules , etc., and logged into journey details of the bus for each trip.
5.11.2.Overview Dashboards
1. Vehicle Fleet Summary Dashboard – Quick view on vehicle fleet performance. 2. Successful bidder shall provide every vehicle status like online, repair, accident, cut off, offline, battery removed, in company etc with date and should be stored in data base. The information should be shown dynamically in admin web portal. 3. Successful bidder shall display the live status of the last data packet received from VMU for every vehicle in admin portal as well as admin mobile app. 4. Depot Dashboard 5. Service Dashboard
5.11.3.Alerts
1. The system shall have ability to highlight exceptions through Alerts by monitoring of deviations such as route, arrival, over speeding, unauthorised stopping, and departure timings and non-receipt of waybill files , etc. 2. Alerts shall be generated in case of deviations from the authorized route and recorded in all cases for reporting and review. 3. AVLS shall provide drill down to the exact location of the event by clicking on the alert and see the position of event drawn over the map along with driver, vehicle and standard description of event details related to the business rules. 4. Ability to receive SOS and alerts from moving / stranded buses en-route. 5. In case of any abnormal or malfunctioning in communication is detected, ITS shall record the type of failure and issue an alert.
5.11.4.Targeted Users:
1. Depot System Supervisors 2. Depot Supervisors 3. APSRTC Administrative Officers 4. Central Complaint Cell Page 82 of 223 5.12. Reports
Reports so generated shall be interactive i.e., drilled down from macro(corporation) level to micro(trip) level. Reports shall always be generated and updated on realtime basis. Frequency of generations is realtime, daily, weekly, fortnightly and monthly reports.
UTS shall provide a system for generating and viewing online, real-time project and MIS reports for Route wise, Service-wise, department-wise, counter wise, centre-wise and e-ticketing transactions payment gateway wise, handled during a daily, weekly, fortnightly, monthly and yearly and transaction density trends during any specified periodicity. The online MIS reporting system shall be an integrated system which shall provide web-based reporting for points of access.
UTS being a multi-location, multi-user initiative, it is imperative to provide online MIS reporting capabilities tailor-made to the requirements of the various participating departments. The successful bidder should gather the requirements for online MIS reporting from the individual participating users and design the application accordingly
The system shall provide MIS reporting with multiple “Slice & Dice” options to generate reports in flexible formats based on user specific needs. The online MIS reporting requirements can be stated from the following perspectives:
5.12.1.The system shall provide MIS reporting with multiple “Slice & Dice” options to generate reports in flexible formats based on user specific needs. The online MIS reporting requirements can be stated from the following perspectives: 5.12.2.From the UTS portal perspective, the reports should present real time, historical, statistical and predictive views in addition to the daily/weekly/monthly/yearly views. 5.12.3.Portal usage statistics related to registered users, business entities, online transactions etc payment gateway wise for reconciliation. 5.12.4.Trend analysis reports detailing the user behaviour patterns providing forward-looking predictions of business user interests in UTS portal. 5.12.5.A few indicative reports which the successful bidder should consider are: a. Date Wise Transactions. b. Transactions since inception. c. User wise, counter wise, Bus Station wise transactions. d. Quality of Service Report outlining the performance of the individual front end service providers in processing the user requests in comparison with Service Level Metrics requirements. e. Total page views per category. f. For online events: peak simultaneous users, total users logged in, (average stay per user) Gateway wise reports. g. The online MIS reporting requirements for UTS Data Center activities include providing graphical views for information such as: collections for each center, statistical/trend view (rate of growth of transactions for particular department and predictive growth of transactions), historical view (collections till date).
Page 83 of 223 h. The following are indicative reporting requirements that the successful bidder should take into account while designing an appropriate solution: Hourly / Daily / Weekly / Monthly / Yearly transactions / collections by center. i. Day wise and Shift wise collection summary reports. j. User wise summary for the day reports. k. Transaction based alerts. l. All Users and all centers revenue reports. m. Service cancellation and tickets cancellation reports. n. Bus Station wise Anywhere to Anywhere transaction reports. o. Gateway wise Reconciliation statement for e-ticketing. p. Generation of service wise MTD 141. q. Inter Depot, Inter Region Transaction reports. r. Corporation summary report daily/fortnightly/monthly/yearly. s. All the reports to be generated in the form of HTML, PDF, Text and Excel statements. t. All the reports to be generated in from — to date option facility.= u. Any other reports required by the Project Manager, UTS time to time. v. The successful vendor has to generate all the transaction wise and revenue wise reports on daily, weekly, fortnightly, monthly and yearly basis. w. Any report in any format subjected to availability of data in the Database.
5.12.6.Online Passenger Reservation System (OPRS)
5.12.6.1.General Reports
1. Agent Daily Commission 2. Agent Daily TDS Collection 3. Agent Remittance Report 4. Agent Revenue Report 5. Agent CR Note Report 6. Agents Payments Report 7. Anywhere to anywhere report 8. Boarding Point Services 9. Booked Seats Summary 10. Bus Station wise Summary 11. Cancelled Services Report 12. Cancelled Tickets 13. Agent e-Ticket Cancelled 14. Cancelled POS Tickets 15. Date wise transaction summary 16. Day/Monthly Summary 17. Dinner Order Report 18. Dinner Tickets by Service
Page 84 of 223 19. Flexi Fare (API) Report 20. IDT(Issue) Depot wise details 21. IDT(Receive) Depot wise details 22. Invalid Tickets 23. Link Tickets Reports 24. Concession Ticket Sales Report 25. POS Tickets report 26. POS Tickets Summary Report 27. Remote Agent Cancellation Report 28. Seat Block & Release Log 29. Special Service Report 30. Special Services Summary Report 31. Stock Consumption Report 32. Services and Agents Report 33. Service Types Report 34. Unreported Service Report 35. Users OTP Report 36. Vacancy Seats Summary 37. Waiting List Seats Summary 38. Waybill Cancel Report 39. Waybill not Generated Report 40. Window Scroll Report 41. 141 Service Report 42. Stage-wise Alighting and Boarding Report
5.12.6.2.Online Reports
1. Bus Station wise Booked e-Tickets 2. Online Pending Transactions 3. Online Reconciliation Report 4. Online Transactions Report 5. Online Users List 6. Online Reconciliation Summary 7. Ticket Pending Refund Status 8. Failure Ticket Pending Refund Status.
5.12.6.3.Account Reports
1. ATB Agent Register 2. Accounts Header Summary Report 3. Auxiliary Waybill Summary 4. Cancellation of Tickets Page 85 of 223 5. Commission Issued Report 6. Day/Monthly Summary Settlement Report 7. e-Ticketing Summary 8. Depot wise Levy Received. 9. Depot wise Received retained Amount. 10. IDT (Issue) Station wise Summary 11. IDT(Receive) Station wise Summary 12. RTC Operator Ticket Issues 13. SRT Report 14. Waybill Commission Report 15. Day wise Fares for Service Report 16. Daily Reward Points Summary Report 17. Transaction wise Reward Points Report 18. Transaction wise Redeem details Report 19. Service wise Reward Point Transaction Details
5.12.6.4.Wallet Reports
1. Wallet Date wise Transaction Report 2. Wallet Coupon Usage Report
5.12.6.5.Other Reports
1. Active Agent wise Booked details 2. Agents Daily Balances 3. Agents Reconciliation Report 4. Auto Top up Payment Gateway Response Report 5. Booked Seats (Depot Wise) 6. Transferred Seats Report 7. Booked Seats Summary (Depot wise) 8. Bus Station wise ATB Summary 9. Bus Station wise Summary Report 10. Cancellation Alert Report 11. Cancellation Summary (Slab wise) 12. Day wise Auxiliary Waybill Summary 13. Destination wise Booked Seats 14. Depot wise Booked Seats 15. IDT(Issue) Grand Summary Report 16. IDT(Receive) Grand Summary Report 17. Month wise First and Last Booked tickets 18. Month wise TDS Summary 19. Passenger Cess Report Page 86 of 223 20. Product wise Summary 21. Route wise Product wise Summary 22. Sector wise Booked Seats 23. Service Cancel Refund Tickets 24. Service Cancellation After Journey Date 25. Service Cancelled Tickets 26. Ticket Sales (Advance Booking) 27. Target Commission Report 28. TTD Dharshan Passenger Info Report 29. Date wise TTD Dharshan Availability Report 30. Depot wise TTD tickets issued Report 31. Window Scroll (Journey based) 32. Mobile Ticket Booking 33. Ticket Block Unblock Report 34. Sector wise Booked Seats Summary 35. 141 Stage wise Seats 36. Reservation Chart with Cancellation Ticket 37. Region wise Service Count Report 38. Region wise no of services at Hotel Report 39. Region wise Schedule Hotel Timings and Duration report 40. User wise commission report 41. No of User Visits Report 42. Date wise Sub Franchisee Summary Report.
5.12.7.Android POS Reports
1. Ticket Report 2. Total Remittance Report 3. Denomination wise Report 4. Stage wise Punctuality Report 5. Passengers stage wise Boarding and Alighting Report 6. Stage wise Boarding and Alighting - Trip Sum Report 7. Stage wise Boarding and Alighting - Each Trip Report 8. TTI Checking Report 9. Daily ticket and Receiving Statement 10. Monthly Police warrant Report 11. Waybill Cancel Report 12. Monthly Time wise Report 13. Monthly Trip wise passenger boarding and earning Report 14. Monthly Toll Plaza amount Report 15. Monthly Toll Paid amount Report 16. Monthly Stage wise Passenger Boarding and Alighting Report Page 87 of 223 17. Monthly TAYL Ticket Report 18. Monthly Conductor wise TAYL ticket Report 19. Service Performance Report 20. Service Trip Performance Report 21. Monthly Average Stage wise Boarding and Alighting Report 22. Date wise Service PoS Report 23. TIM wise Report 24. Trip wise Report 25. Daily Statement 26. TIM Master Report 27. Pass Report 28. Non-Received TIMS Report 29. Trip Close Reports 30. Breakdown Reports 31. Manual Waybill Closing Report 32. Return Journey Ticket Report
5.12.8.National Common Mobility Card
5.12.8.1.All reports related to Card transactions. 5.12.8.2. Analytics on customer adoption trends 5.12.8.3. Revenue reconciliation reports.
5.12.9.Pass Automation and Accountal System (PAAS)
5.12.9.1.Transaction Reports
1. Pass Type Distance Report 2. Bus Pass Sales Statement 3. Operator wise Revenue Report 4. Invalidation Report 5. Franchise Commission 6. Stock Report 7. Exception 8. Exclusive Passes 9. Skipped Stock Report 10. Pass wise comparison between two dates 11. Free Passes Report 12. Window Scroll Report 13. Subsequent Tickets 14. NGO passes 15. Route wise Passes issues. Page 88 of 223 16. Center wise Sales 17. Day wise Revenue 18. Disabled IDs 19. Center opened Status Report 20. DC Cash not entry list 21. Day wise cash receive from franchise by DC 22. Institution/College/School wise passes issued. 23. Subsidy Claim Report 24. Invalidation detailed report 25. Scheme Report 26. Depot/Region/Zone wise Report 27. KMs wise Route Passes 28. NGO pass Holder Reports 29. PHC Pass Holder Report 30. POS Sales Report 31. Zone/Region/Depot wise POS Sales Report 32. Age wise Free passes below 18 years 33. Journalist Passes Report 34. Complimentary Passes Report 35. Center and Day wise Sales Report 36. Secretariat and Special Privilege Bus Passes Report 37. Bundle wise Skipped stock Report 38. Zone/Region/Depot Franchise Commission Report 39. Student Details Report 40. Non-Renewal/Renewal Commuters Report 41. JNNURM Passes Report 42. Route wise Passes issued Report 43. Quarterly Vs Yearly Passes Report 44. Dynamic Bus Passes Report 45. OTP Report
5.12.9.2.Master Reports
1. Pass Types 2. Fares 3. Franchises 4. Centers 5. Counters 6. Places 7. Routes 8. Depots 9. Holidays Page 89 of 223 10. Institutions/Colleges/Schools details 11. Schemes 12. Organisation Routes 13. Amount Received from Prepaid Organisation 14. Offline Officers 15. Employees 16. Main Routes
5.12.9.3.Other Reports
1. Center Information 2. Route Information 3. Student Details 4. User Information 5. Course Details Report 6. Active/Inactive Schools/Colleges/Institutions 7. Institution Vs Course Details Report 8. Main Routes sharing Report. 9. Franchise Commission Reports
5.12.10.Automatic Vehicle Location System (AVLS) Reports
5.12.10.1.MIS Reports
1. Departure Punctuality Report 2. Departure Delay Summary Report 3. Trip-wise Departure Punctuality Report 4. Service wise Departure Punctuality Report 5. Arrival Punctuality Report 6. Arrival Delay Summary Report 7. Trip-wise Arrival Punctuality Report 8. Service wise Arrival Punctuality Report 9. Trip wise Actual Running Time Report 10. Vehicle Tracking Status Report 11. Bus Stops Skipped Report 12. Route Deviation Report 13. Unauthorised Stoppage Report 14. Driver Performance Report 15. Feedback Summary Dashboard Report 16. Feedback Dashboard Report 17. Emergency Dashboard Report 18. Vehicle Multiple Assignment Report Page 90 of 223 19. Trip wise Vehicle Assignment & Tracking Status Report 20. Vehicle Assignment & Tracking Status Report 21. Trip-wise Tirumala Vehicle Assignment and Tracking Status Report 22. VMU Performance Report as applicable 23. Service Cancellation Report 24. Schedule GPS KMs Analysis Report 25. Speed in any time interval report
5.12.10.2.Summary Reports
1. Day-wise Tracking Report 2. Day-wise Punctuality Report 3. Monthly Departure Punctuality Report 4. Monthly Arrival Punctuality Report 5. Monthly Tracking Report 6. Stop wise Punctuality Report 7. Service wise Punctuality Report 8. Stop to Stop Duration Report
5.12.10.3.Headway Chart Reports
1. Headway Chart 2. Depot wise Headway Chart 3. Headway Chart All\
5.12.10.4.Auto Announcement System
1. Depot wise Services Announced Report 2. Announcement Statistics Report
5.12.10.5.Other Reports
1. Depot wise Daily Report 2. Stage wise Departure Report 3. Stage wise Arrival Report 4. Stage wise ETA Report 5. Depot wise Bus Location Report 6. Control Chart
5.12.11. Passenger Information System (PIS)
1. Auto Announcement System Page 91 of 223 2. Real time service status data on mobile APP and web portal
5.12.12. Mobile Ticketing
1. Analytics on Transactions and customer adoption trends 2. Revenue reconciliation reports
5.12.13. Logistics
5.12.13.1.General Reports
1. Mis-Route List 2. Mis-Route Manifest Report 3. Manifest Report 4. Receiving Report 5. Delivery % Report 6. Delivery Report 7. DGT Manifest Report 8. POD Report
5.12.13.2.Earnings
1. Earnings Report 2. Earnings Payment wise Report 3. Agent Booking Report 4. Route wise Booking Report 5. Route wise Receiving Report 6. Billing Report
5.12.13.3.Attendance
1. Registration List 2. Attendance Report
5.12.13.4.DC Remittance
1. DC Remittance 2. Hamali Payment
5.12.13.5.TOPAY Management
1. Contractor Wallet Report Page 92 of 223 2. Booking Report 3. Delivery Report 4. AWB TOPAY History 5. TOPAY Undelivered Report
5.12.13.6.Manual Earnings Report
1. Manual Earnings Report
5.12.13.7.Penalties
1. Penalty Report 2. My Penalties
5.12.13.8.Other Reports
1. Contractor Commission Report 2. Booking Report 3. Earnings Report 4. Agents Earnings Report 5. Agents Balance Report 6. Bulk Booking Report 7. Route Analysis 8. Product Analysis 9. TOPAY Undelivered Report 10. Agent Cash Remittance 11. Transhipment List 12. Customer Pickup Report 13. Payment Reconciliation
5.12.13.9.Stock Module Reports
1. My Stock Report 2. Stock Transfer Report 3. Stock Utilisation Report 4. Stock Skip Report
5.12.13.10.Complaint Management
1. Complaints Summary Report 2. Open Complaints Report 3. Closed Complaints Report Page 93 of 223 4. Settled Complaints Report
5.12.13.11.Head Office Reports
1. Booking Summary 2. Software Billing Report 3. Top Up Report 4. Insurance Collected report
5.12.14.Mobile App
1. Analytics on Transactions and customer adoption trends 2. Revenue reconciliation reports
5.12.15. ITS Solution
1. Analysis of customer feedback 2. SLA reports
5.12.16. Targeted Users:
1. Depot System Supervisors 2. Depot Supervisors 3. APSRTC Administrative Officers 4. Central Complaint Cell
Page 94 of 223 5.13. IT Infrastructure
1. The System Integrator shall host and maintain all Unified Digital Solutions and its sub systems, preferably in a cloud environment. 2. Solution shall be co-hosted DC-DR at Tier-III and above certified or its equivalent Cloud Services Provider only. 3. Tier-III and above or its equivalent Certification shall be submitted in the Technical Qualification forms. 4. IT infrastructure, networking, bandwidth and necessary add on components shall be maintained by the system integrator. 5. All software licenses for Unified Ticketing Solution and necessary hardware shall be procured by the system integrator on behalf of APSRTC and maintain the same during the entire contract period. 6. Successful bidder shall provide required Internet Bandwidth, Leased lines between DC & DRC, MPLS VPN connections to 12 major bus stations of APSRTC. Such internet Bandwidth, Leased lines and MPLS VPN connection charges, Telephone bills, Taxes and any other charges related to DC & DRC should be paid by successful bidder, without any default. 7. All the expenses for procurement shall be included in the commercials and no separate payment will be made to the system integrator for any softwares, hardware etc., 8. During exit management, the same shall be transferred to APSRTC at 0 value (at no additional cost to APSRTC).
Page 95 of 223 5.14. Information and Infrastructure Standards
1. ITS must meet the essential criteria of i. Availability ii. Accessibility iii. Assessment; and iv. Acceptance. 2. Government of Andhra Pradesh, IT Department defined the standards for all eGovernance Applications by a G. O. MS No-3, Dt 08.07.2020. 3. The G. O. prescribes the common standards, guidelines and compliance matrices pertaining to the IT Projects. The SI shall comply the solution to the Standards and Guidelines prescribed in the G. O. 4. SI shall adopt and comply the Open Source Policy Framework guidelines issued by Central government from time to time. 5. SI shall propose and utilise open source tools and technologies to the extent possible. 6. The proposed solution shall proactively monitor all user transactions for any web-application hosted in any latest technology compliant application server; detect failed transactions; gather evidence necessary for triage and diagnosis of problems that affect user experiences and prevent completion of critical business processes. 7. The proposed solution shall determine if the cause of performance issues is inside the application, in connected back-end systems or at the network layer. 8. The proposed solution shall provide real-time monitoring of memory usage, servlets, caches, DB connection pools etc 9. The data structure and format will confirm to standard practices adopted internationally and will have to be based on the Data Standards Definition framework widely accepted. 10.Successful bidder shall capture the data from the Android POS device and push immediately to the central server. It will be the responsibility of the bidder to ensure consolidated monthly data backup of all buses & depots at Data Center and the same should also be kept safe with themselves. The storage media in the form of SAN/External Hard Disk/DVD/Pen Drive shall be provided by the successful bidder. 11.The database shall be up-to-date on the movement of vehicles along with their defined schedules and destinations and details of the drivers of the vehicles. 12.The Central Server will communicate with Android POS devices using HTTPS or TCP/IP. The data and instructions required on the Android POS devices are communicated from the Central Server. 13.Successful Bidder shall provide complete backup of all Developed/Used Application Software (latest & updated version) and whole Database of the complete project period. 14.High Availability: All the web servers and the database servers should have a defined DR solution setup with acceptable RPO and RTO. Preferably in Tier-III and above Data Center(Standalone scalable or Cloud) 15.The application should be architected to have the appropriate redundancy build into the system, in order to maintain the application without any downtime. 16.ITS solution shall be scalable both in terms of hardware and application software. 17.Master Data Management (MDM). 18.BAR: The project shall have an in-built Backup, Archive and Restore Solutions to protect data and ensure availability.
Page 96 of 223 19.The System Integrator shall adopt Life cycle Approach in Policies, processes, practices and technologies used to manage data from source to sink.
Page 97 of 223 5.15. Requirements Gatherings Standards:
The System Integrator is responsible for gathering detailed requirements. It is proposed to deploy a team of two Sr. Business Analyst who shall be utilised for this work and adhere to following guidelines.
1. Define and agree on the scope of the project. 2. Make sure requirements are specific, measurable, agreed upon, realistic and time-based. 3. Always ask what the customer wants without assumptions. 4. Involve the users from the start. 5. Create a clear, concise and thorough requirements document and share it with the customer. 6. Avoid talking technology or solutions until the requirements are fully understood. 7. Get the requirements agreed with the stakeholders before the project starts. 8. Create a prototype, if necessary, to confirm or refine the customer's requirements.
5.16. Design Standards
The System Integrator is responsible to implement IDAM (Identity Access Management) across the project and shall enable Single Sign On (SSO) Functionality. Design of applications should be in compliance of industry standards as stated below:
1. Well-structured code, consistent in style and format. 2. Areas of the code with excessive complexity to be restructured or split. 3. Enforce naming conventions. 4. All fields to be properly initialised. 5. Ensure that most common logic statements are always tested first with proper exit for every loop. 6. Consider errors and manage exceptions cleanly 7. Connectors, Data, Functional rules to be constructed under the correct class and ruleset. 8. Use out-of-the-box rules and functions. Avoid custom HTML. 9. Design intent-driven processes with limited hand-coded java in activities. 10.Ensure to have not more than 5 connector flow actions for each assignment. 11.Create easy-to-read flows — there should be no more than 15 shapes on a page. 12. Calculate and edit declaratively, not procedurally.
Page 98 of 223 5.17. Integrations
All external systems (both existing and future) shall be integrated with the current project. It is expected to consume some APIs from already available systems and shall provide APIs to external system for integration with them. It is also planned to develop a unified web portal and mobile app for all Citizen Centric Services available across the organisation for better user experience. The system Integrator shall extend all technical support and integration APIs as and when necessary to APSRTC and other system integrators on the strength of written orders from APSRTC. The following systems shall be integrated with this project:
5.17.1.Licensed GIS Layers 5.17.2.APSRTC ERP Platform - CIS 5.17.3.Payment Gateways 5.17.4.SMS Gateway 5.17.5.eMail Gateway 5.17.6.WhatsApp Messaging Services. 5.17.7.Auto Audio Announcement System 5.17.8.Cargo and Courier Management System 5.17.9.Integration with other Internal Applications 5.17.10.APCSOC 5.17.11.Samagra Shiksha 5.17.12.Grama Ward Sachivalayam 5.17.13.TTD Dharshan 5.17.14.Other internal and external APIs as and when needed for the project. 5.17.15.Central Complaint Cell Integration.
Note: a. Licensed GIS layers/Google Maps and email Gateway shall be provided by the System Integrator. b. SMS Gateway, Payment Gateway and WhatsApp Messaging Services gateway will be provided by APSRTC. c. SI is expected to integrate multiple payment gateways to meet the needs of application users.
5.18. Network and Security
1. Successful bidder shall provide high end, high capacity server hardware (cloud is allowed), software and provide required bandwidth connectivity, etc., to all sub systems of the ITS Solution. 2. Shall use licensed software for Operating System, Database, Web application, Network software and management, Antivirus and any other required software, along with cost. 3. Access to ITS and its sub-systems shall be role based. 4. All the components in the network should be firewall protected and distributed denial of service (DDoS) attach protected. 5. The proposed project shall provide access/integrate to APCSOC to monitor cyber security threats. 6. The elements/options that could be seen by the users should be customisable. Page 99 of 223 7. The Admin web application and Mobile App should be configurable to generate OTPs 8. All the hardware components should be given dedicated IPs in a dedicated subnet. 9. Encryption at REST and encryption on wire should be configurable. 10.Should have provision to enable LDAP and integration with Single Sign On 11.Firewall should be provided to block the secured ports that are not to be exposed to the public networks 12.Load balancers should be in place before any component that gets exposed to the public network. 13.Databases/Application Servers should never be exposed to the outside network. All the communication to the application should go through the Load balancers in the DMZ. 14.All the critical changes to the master data should be audited
Page 100 of 223 5.19. Non-Functional Requirements
1. The System Integrator preferably follow the latest version of Industry Standard IEEE 830 & 1233 for drafting the Blueprint Document. 2. The System Integrator shall maintain log of all transactions that place in the project for audit and monitoring purpose. 3. Logs shall be backed up periodically to a permanent storage. The System Integrator shall ensure security and confidentiality of Log data. 4. Daily operations related to monitoring and analysing the ITS would be done by APSRTC designated officials/employees, however, required support in operations shall be provided by the successful bidder. 5. The successful bidder shall provide support in daily operations of ITS hardware, software, connectivity related problems occurring at depot/bus station level. Necessary training should be provided to designated APSRTC personnel to enable them to carry out these activities. 6. Successful Bidder shall provide adequate technical manpower for successful working of ITS. The salaries, perquisites, allowances, etc., for the employees should be borne by the Bidder only. Such manpower employed by the Bidder should not be considered as employees of APSRTC and they should not claim any job benefits in APSRTC at any point of time. 7. Successful bidder shall maintain the hire vehicle master data including agreement starting and ending dates with an alert facility to remove the ITS equipment at the end of the agreement period. 8. The successful bidder should submit documentation of every output (report) along with algorithm and regarding the logic used to develop that report. 9. The modification build given should be approved by APSRTC along with detailed release note in the chronological order. All the release notes in the chronological order should be made available on the web site for the admin users in the opted and date wise modifications with details. 10.The Service Provider shall market the proposition to public transport users with prior written approval of APSRTC to drive migration towards e-Ticketing and digital passes. 11.The Service Provider may use any and all forms of media necessary, at their own cost, to market the proposition, with prior written intimation to APSRTC. 12.Office space for CCC setup, electricity and minor civil works will be provided by APSRTC on request from System Integrator as per availability. If APSRTC could not provide the space as required by the System Integrator, alternative arrangements shall be made by the System Integrator with prior intimation to APSRTC. 13.Monthly electricity bills for CCC will be paid by APSRTC. However, phone bills for CCC shall be borne by the System Integrator.
Page 101 of 223 5.20. Capacity Building and Change Management
1. The System Integrator need to execute the change management and capacity building activity as per the change management and capacity building plan approved by APSRTC. 2. CB & CM shall be as per the transition plan prepared by System Integrator and approved by APSRTC. 3. The System Integrator has to ensure zero service disruption during transition as such the same is to be planned accordingly. 4. The successful bidder shall organise periodical training programs about the complete functioning of the ITS i.e., all operations, reporting, monitoring, etc., to the designated officials of APSRTC as and when required by APSRTC during the complete contract/project period. Deliverables of CB & CM are as follows: i. Training Plan ii. Training Manuals iii. User Guides and Materials and iv. Documented Evidence of successful User Training.
5. The system integrator shall also provide trainings to the designated participants, whenever any changes are made in the Solution. 6. The System Integrator shall conduct training at the regional offices to ensure effective outcome and number of people to be trained would be specified by APSRTC well before commencement of the training schedule. 7. Training needs to be conducted based on a requisite mix of theory & practical operational sessions. The trainings should be conducted in Telugu. 8. The System Integrator shall prepare required training material and manuals as desired. 9. The System Integrator shall submit the consolidated training and change management report after successful completion of trainings.
Page 102 of 223 5.21. Documentation
1. The successful bidder shall prepare all necessary documentation for the project. 2. During installation and post installation, the Systems Integrator shall provide documentation on As- Built components/customised components to APSRTC. 3. The documentation should consist of all the configuration details, diagrams, Test plans, administration manuals, setup guides etc., 4. Solution Architecture shall be submitted during bid submission. 5. Detailed manuals for each appropriate unit of the supplied equipment and services including certifications from OEMs. 6. The training and operational manuals should be bilingual (English & Telugu). 7. Inspection and testing procedure manuals including QA policy and procedures for the software/ hardware equipment. 8. Any other document(s) deemed necessary for implementation, operation and maintenance of the hardware and network equipment and the overall system.
5.22. Development Strategy
1. Selected System Integrator needs to work along APSRTC Core Team to capture specific and detailed requirements. 2. This may require multiple iterations to gather requirements/Data/ Demos/Sign offs. 3. Once requirements are finalised, BRD needs to be documented and shall obtain sign-off. 4. System Integrator team develops the system as per the sign-off requirements following best practices during all phases of system development. 5. System Integrator team may reuse various artefacts and documents information available with APSRTC. 6. Development of the Project should follow Agile Methodology. 7. System Integrators has to support for integration of developed services with appropriate services for Operational Purpose. 8. If System Integrator has developed any of the APIs during the project development phase, it has to ensure that these APIs are exposed and available to APSRTC for Integration and Operational Purpose.
5.23. Change Request
With technological improvements, it is expected to propose changes to the signed off solution. The system integrator shall plan for contingency to accommodate the proposed changes Change request management process at APSRTC will typically consist of following steps:
5.23.1.Request for Change Review:
The selected System Integrator and APSRTC Core Team from APSRTC will initiate a request for Change in existing scope and the same change request must be thoroughly documented. Following Components must be part of Change Request: Page 103 of 223 1. Incidents that necessitate the change 2. Description of how the change would be implemented 3. Impact that the change would have on all associated systems 4. A risk assessment 5. Contact information for everyone involved in the change 6. An outline of who will need to approve the request 7. A backup plan to follow in case the change is not successful
5.23.2.Change Planning:
Once the change request has been initiated and submitted, it will be reviewed by the Chief Engineer (IT) of APSRTC to prepare the implementation plans for changes based on available bandwidth and priorities.
5.23.3.Change Approval:
The proposed change request and planning document will be submitted to Project Awarding Committee, based on merit of the change request, Committee will approve or reject the Change Request. If the approved change request is a part of Unified Ticketing Solution or a component of its sub system, then the system integrator shall initiate development at no additional cost to APSRTC.
5.23.4.Change Implementation
Once the change request is approved by the Project Awarding Committee, Selected System Integrator will proceed with the change to complete the Change Request. Appropriate adjustments in the approved scope of the work (SoW) will be made to accommodate these Change Requests and timelines will be revised.
5.23.5.Change Closure:
The System Integrator and APSRTC, will follow this procedure and conduct when they performance testing, functionality testing, etc., after changes have been developed. When found satisfactory, changes will be moved to production environment and change request gets closed.
5.24.Testing
1. Design of test cases and test plan strategy should be completed in parallel to requirements finalisation. 2. Testing shall include all components vis-a-vis the functional, operational, performance and security requirements of the project, as envisioned in the RFP. 3. System Integrator team to ensure that the SIT/UAT test cases and test strategy documents to be reviewed and approved by APSRTC. 4. Complete responsibility lies with the system integrator in testing of the solution in all aspects. 5. The System Integrator shall preserve the test case results and make them available to APSRTC and 3rd Party Auditor for review Page 104 of 223 6. Testing will be performed for the backlog and the bugs identified during testing iterations of the earlier version are to be fixed. 7. Following Standard testing best practices to be ensured across all phases of testing. i. Unit test cases executed against Test Plan/Scripts ii. Profile to identify performance problems iii. Verify that Logs have no errors or alerts iv. Clipboard pages are managed 8. Scope of application testing shall include (but not limited to):
i. Unit and regression testing — this include functional testing of all individual modules developed under the ITS solution for APSRTC. This testing will be performed by the System Integrator.
ii. System Integration Testing (SIT) – After the entire development cycle is over, all the components shall be tested end to end. Here, System Integrator has to demonstrate the system in a controlled production environment. The System Integrator will carry out the Integration testing to ensure the integration of all the modules of ITS solution for APSRTC.
iii. Performance and Load Testing – The application software along with the associated infrastructure should successfully meet the criteria for response time for a given user load defined as a minimum concurrency of 20% of the total users of APSRTC. Number of Users may vary case to case scenario and System Integrator has to adhere to these numbers.
iv. User Acceptance testing (UAT) — 100% of all Critical defects identified as part of the UAT shall be fixed and retested before go-live. For high-priority defects, at least 90% of the defects shall be fixed before go-live. Remaining 10% will need to be fixed within 1 month of the go-live. For medium-priority defects, 80% of these should be fixed before go-live and for low-priority defects, 60% shall be fixed before go-live. All pending medium and low priority defects shall be fixed within 2 months of go-live.
9. Critical Priority: A defect that completely hampers or blocks testing of the product/feature is a Critical Priority defect. An example but not limited to this, would be in the case of UI testing where after going through a wizard, the UI just hangs at one pane or doesn’t go further to trigger the function. Or in some other cases, when the feature developed itself is missing from the build.
10. High Priority: A High Priority occurs when the functionality is functioning grossly away from the expectations or not doing what it should be doing. An example but not limited to this could be: the feature is expected to display a particular error to the user with respect to its return code. In this case, functionally the code will throw an error, but the message will need to be more relevant to the return code generated.
11. Medium Priority: A Medium Priority defect occurs when the product or application doesn't meet certain criteria or still exhibits some unnatural behaviour, however, the functionality as a whole is not impacted. For example, but not limited to this example, a particular functionality can be used only on a later version of the platform, so in order to verify this — the tester actually downgrades his system and performs the test and observes a serious functionality issue which is valid, as normally end users will be expected to have support for a higher version of platform.
Page 105 of 223 12. Low Priority: A minor bug occurs when there is almost no impact to the functionality, but it is still a valid defect that should be corrected. Examples of this could include spelling mistakes in error messages printed to user or defects to enhance the look and feel of a feature.
Page 106 of 223 5.25. Go Live Requirements
For completion of Go-Live formalities, System Integrator (SI) must submit: 1. Final UAT and Compliance Certificates from APSRTC. 2. Letter for completion of Appropriate Training to all stake holders and users on delivered product. 3. All the necessary software documentation for Delivered Product. 4. User Manual for Line Department Catalogue for Help Desk Team to resolve Line Department issues or raise Flags/Tickets. 5. Demonstrate concurrency of 50,000 hits/sec load testing on the infrastructure deployed. System integrator at its own cost may appoint third party to assess & perform the security and load testing of the deployed application. 6. It may be noted that, concurrency of 50,000 hits/sec doesn’t limit to the users available/logged into UTS platform. Live users logged into UTS platform may be 10-15 times more than concurrency. 7. On an average, ideal user completes the transaction with exactly 5 clicks (i.e., user interactions with the server).
5.26. Operations and Maintenance Requirements
The vendor shall be required to provide operational and maintenance services for all applications for the entire project including, all the connected software and integrated components. This section discusses the Operations & Maintenance services to be provided by vendor with respect to Application Software. The successful bidder shall be responsible for the overall management of the UTS application including the software and related IT Infrastructure. The successful bidder shall be responsible for the operation and maintenance of UTS solution, which includes application solution management and IT Infrastructure management including security management, network management, server management, storage management, etc. Following includes but not limited to the various activities to be performed by the successful bidder during the maintenance of the UTS application.
Operations & Maintenance (O&M) phase of the project is co-terminus with contract period. During the contract period, the System Integrator is required to undertake the following key activities:
1. Maintain the implemented software as per prescribed service levels agreement terms laid down in this RFP. 2. Integrate the application developed for this RFP, with software applications developed and deployed with APSRTC as per requirement. 3. Implement changes to software as per terms and conditions of the RFP 4. Actively monitor and manage the solution, limited to the scope of this RFP. 5. Maintain systems required for automated generation of compliance of service level requirements laid down in this RFP. 6. Extension of O&M contract will be at the discretion of APSRTC and APSRTC may continue or award the O&M post mandatory services from this RFP to other System Integrators. The System Integrator is required to conduct a parallel run for Two months with any new System Integrator identified.
Page 107 of 223 5.26.7.Application Management
a. The successful bidder provides warranty at no additional cost for UTS application software, Hardware, Network and all equipment for a period of sixty months, commencing from the date of commercial GOLIVE. The warranty should include that the solution supplied under this contract shall have no defect arising from design or workmanship or from any act or omission of the successful bidder that may develop under normal use of the supplied application. b. During the warranty period, successful bidder shall be completely responsible for defect free functionality of UTS application software and shall resolve any UTS application related issues including bug fixing etc with in duration agreed between UTS Project Manager and the successful bidder. c. Successful bidder shall provide the latest updates, patches/fixes, version upgrades relevant for the UTS application components periodically. d. Successful bidder shall be responsible for software version management, software documentation management reflecting current features and functionality of the application. Training of APSRTC personnel on latest version of software as applicable in their operations is also the responsibility of the Successful Bidder
5.26.8.Infrastructure Management This includes the design of an appropriate System Administration policy with precise definition of duties and adequate segregation of responsibilities and obtaining the approval for the same from the Project Manager, UTS. System Administration includes the following activities:
a. Overall management and administration of infrastructure solution including servers, networking & security components, storage solution etc for Data Center and Disaster Recovery Center. b. Performance tuning of the system as may be needed to comply with Service Level Metrics requirements on a continuous basis. c. Security management including monitoring security and intrusions into the application. d. Monitor and track server and network performance at Data Center and Disaster Recovery Center and take corrective actions to optimise the performance on a daily and hourly basis. e. Escalation and co-ordination with other vendors for problem resolution wherever required. f. System administration tasks such as managing the access control system, creating and managing users, etc. g. Data storage management activities including backup, restore and archival, etc. h. Attend to Department's user request for assistance related to usage and management of UTS application. i. The successful bidder undertakes to ensure that daily transaction wise back-up copies and total dump backup of UTS and related data are created and maintained safely. This backup data must be under the control of Project Manager, UTS. j. The successful bidder shall maintain the adequate stocks of spares to meet the requirements at Data Center and Disaster Recovery Center. k. The Project Manager, UTS project reserves the right to verify the stocks at any time whenever a component has to be replaced because of technical, functional, manufacturing or any other problem, it shall be replaced with a component of the same make and configuration.
Page 108 of 223 l. In case the component of same make and configuration is not available, the replacement shall conform to open standards and shall be of a higher configuration specifically approved by Project Manager, UTS. m. Other important activities at Data Center and Disaster Recovery Center shall include but not limited to: i. Daily maintenance of system configuration. ii. Implementation of system security features. iii. Overall security of the network. iv. Day-to-day disk space management. v. Tracking the servers performance and take the remedial and preventive actions in case of problems. vi. Proper upkeep of storage media for taking backups.
5.26.9.Network Management Services
Design of Network Administration Policy and getting it approved from the Project Manager, UTS for effective and efficient management of Network resources at Data Center and Disaster Recovery Center. Network Administration, consists broadly of the following activities
1. Network devices configuration, management and tuning for optimum performance. 2. Tracking the network status, availability and taking the remedial and preventive actions in case of problems. 3. Network fault isolation and resolution. 4. Monitoring of network performance and escalation of performance deterioration to concerned authorities and take remedial actions to resolve such issues. 5. Implementation/modification of network routing policies, IP addressing policy as required. 6. Real time monitoring and deployment of network security measures 24*7*365. 7. Documentation related to network configuration, routing policies, IP addressing schema , etc. 8. Bandwidth monitoring and trending for the network.
5.26.10.Information Security Services
The successful bidder is responsible for implementing measures to ensure the overall security of UTS solution and confidentiality of the UTS data is maintained. The successful bidder shall monitor production systems for events or activities, which might compromise (fraudulently or accidentally) the confidentiality, integrity or availability of the UTS application. This monitoring shall be through the security controls including:
1. Real-time intrusion detection tools. 2. Audit review tools. 3. Manual processes.
Page 109 of 223 4. Successful bidder shall develop a detailed security policy for UTS application implementation & maintenance. The security policy developed by the successful bidder shall be updated to keep the security recommendations current and the same shall be implemented for the UTS solution. 5. The successful bidder, with the co-operation of appropriate, appointed representatives of UTS organisation and the participating departments will manage the response process to security incidents. The incident response process will seek to limit damage and may include the investigation of the incident and notification of the appropriate authorities. A summary of all security incidents shall be made available to UTS Project Manager on a weekly basis. Significant security incidents will be reported on a more immediate basis. 6. The successful bidder shall produce and maintain system audit logs on the system at which point they will be archived and stored as desired by Project Manager, UTS. The successful bidder will regularly review the audit logs for relevant security exceptions. The successful bidder has to purchase and integrate the security certification for the UTS application throughout the contract period.
Page 110 of 223 6. Payment Terms
6.1. Method of Payment
Payment is made to the system integrator by NEFT/RTGS subject to submission of valid invoices The System Integrator must provide following details: 1. Name of the Beneficiary as mentioned on Bank Account. (System Integrator/ Lead Member in case of a consortium/Authorised in case of a firm/company) 2. Contact Number 3. Complete Billing Address 4. City, Postal Code 5. State and Country 6. e-mail Address 7. Aadhaar Number (if Applicable) 8. PAN Number and GST Number (if Applicable) 9. Bank Details Account Number 10.Name of Account Holder (Registered name for Corporate Account) 11.IFSC Code and Branch Name.
6.2. Details of Transactions
APSRTC has issued around 36.57 Lakh ticket per day for the past two years. Based on this data the bidder is expected to estimate the efforts actually required for providing the rates per transaction. It is informed that the projected scale of transactions may increase or decrease depending on market conditions. APSRTC doesn’t indemnify the bidder who is expected to develop solutions that are scalable to address the variations in volume of transactions.
6.3. Chargeable Transactions
6.3.1.Chargeable Transactions: Bidder will be paid only for tickets on which net seats sold across all platforms. So, if a ticket has been booked through the online reservation system, and then cancelled, SI shall not be paid for both (booked transaction and cancelled transaction) the transactions. The SI will be paid for the following transactions:
1. Net Seats sold in OPRS 2. Net ID cum Bus Pass Ticket (Annual Passes) 3. Net Bus Pass Ticket (Monthly/Quarterly) 4. Android ePOS Seats and 5. Net Parcel/ Cargo/ Courier Booking Receipts including DGT bookings 6. Special Hire Bus Booking (One net bus booking will be treated as one net transaction)
Page 111 of 223 6.3.2.Non-Chargeable Transactions: The SI will not be paid for all remaining tickets types which are but not limited to: 1. Top Punch Ticket 2. Luggage Ticket 3. Cancelled Seats 4. Employee Pass/Warrant Entry 5. Blocking of Seats for MLA, MP, MLC, Escort and other officials. 6. Transfer of Seats 7. Invalidation of Bus Pass ID 8. Invalidation of Bus Pass Ticket 9. Issue of MR receipt for Bus Pass ID/ Bus Pass Ticket 10. Validation of Bus Passes 11. Top up of eWallet 12. Top up of NCMC or any closed loop cards. 13. AVLS & PIS transactions 14. Help Desk Incident Management tickets and 15. Others
Chargeable Transactions are non-negotiable between SI and APSRTC. In case of any ambiguity on chargeable or not, a written directive may be requested from APSRTC. In this regard, decision of APSRTC is final.
6.3.3.During unforeseen circumstances or slack season, there is a need for reducing risk for the SI due to significant drop in volumes. For this purpose, minimum guarantee of 15 Lakhs net average seats per day in a calendar month, as decided by APSRTC based on their internal projections, will be made to the vendor subject to the following criteria:
1. Minimum Guarantee is applicable after Go-Live Declaration for all modules by APSRTC. 2. If the actual ticket sale is less or equal to 15 Lakhs net average seats per day in a calendar month, then the amount to be paid is 15 Lakhs per day * Transaction rate 3. In case of lockdown, strikes, acts of God and situations beyond the control of APSRTC where APSRTC has not operated any services during such period, the minimum guarantee seats of 15 lakhs net average seats per day in a calendar month will not be considered. In such cases both APSRTC and Bidder shall mutually decide and come to a conclusion on the minimum guarantee seats. The decision of VC & MD in this regard shall be final and shall be binding on both the parties. The System Integrator should not claim any compensation on account of such loss suffered during such situations due to non-operation of buses by APSRTC. 4. Minimum guarantee of 15 Lakhs net average seats per day in a calendar month is applicable after calculation of net average sold during the month. Prorata calculation will be considered for part month payments. E.G: A= Net seats sold in a month. B= No of Calendar Days in a Month C= Average Net seats per Day in a Month. C= A/B.
Page 112 of 223 5. Minimum guarantee of 15 Lakhs net average seats per day is not applicable on daily basis. For all calculation purposes, average net seats is taken on calendar month average only. 6. Average operations revenue is Rs 13.00-14.00 Crs per day. A minimum guarantee of 15 Lakhs average net seats per day in a calendar month is applicable only after realisation (80%) of the normal average operations revenue (pre-Covid) for at least 6 months continuously.
6.4. Payment Cycle The invoicing may be raised on monthly basis and payments may be made within 30 days from the invoice submission date, based on the actual deliverables/milestones achieved in the specified timeframe.
6.5. Income Tax Rule Compliance
Payments shall be subject to deductions of any amount for which the Bidder is liable under the empanelment or RFP conditions. Further, all payments shall be made subject to deduction of TDS (Tax deduction at Source) as per the Income-Tax Act Section 194C and / or any other statutory provisions.
6.6. Liquidated Damages
In the event of the Bidder's failure to submit the Guarantees and Documents and provision of the necessary deliverables as per schedule specified in this RFP, APSRTC may at its discretion withhold any payment until the completion of the contract. APSRTC may also deduct from the payment due to the Bidder as agreed, liquidated damages to the sum of agreed terms as specified in the SLA, subject to the maximum value of the Liquidated Damages being not more than 10% of the value of corresponding milestone payment of the delayed/undelivered services/monthly instalment. This right to claim any liquidated damages shall be without prejudice to other rights and remedies available to APSRTC under the contract and law. Liquidated damages shall not be imposed for the period of delay solely attributable to APSRTC, provided that APSRTC shall accept that such delay is attributable to it.
6.7. Payment Schedules and Milestones
All the payments will be done to the selected Bidder by the APSRTC after the delivery of services or milestones. It is expected from the SI to deliver the project in agile methodology. Net transaction rates will be applicable and paid as per the commercials submitted. 1. Payment for the net seats booked shall include the seats/ bus passes/ parcel transactions done through UTS during the pilot and rollout phases also. 2. Net Seat/transaction rate is applicable and payable from pilot phase as per the weightage prescribed by APSRTC. 3. Weightage's of UTS modules are as follows: 1. OPRS - 20% 2. AFCS and Android ePOS App - 40% 3. Integrated Passenger Mobile App - 05% 4. PAAS - 10% 5. AVLS & PIS - 10% Page 113 of 223 6. CCMS - 10% 7. CCC - 05% 4. Net transaction rate payable will be decided and paid proportionately as per the above weightage till Go-Live of all modules. 5. After the delivery of all modules, net transaction rate as per the commercial quote will be paid for all chargeable transactions. 6. Mobilisation advance will be paid as per Payment Milestones. 7. All milestone payments made shall be adjusted in the monthly invoices payable to the SI as per net transaction rate. E.g: If Rs 30.00 lks is paid for achieving a particular milestone, the same will be deducted in the monthly invoice payable for net transactions during that month. Balance amount will be paid to the SI. If the monthly invoice value is lesser than the milestone payment paid, the same will be adjusted in the subsequent monthly invoices. After such adjustments only next milestone payment will be released, if any. 8. Priority of Delivery of services and modules will be finalised by APSRTC. 9. No payment will be made for only delivery of non-chargeable transactions modules. However, such modules payment will be included, when chargeable transactions modules are also delivered. 9.1.Following payment milestones shall be applicable for the Bidder:
Phase Milestone Payment Monthly Invoice* (The first At the end of each Payment will be based on the actual outcome as per monthly payment will be month after the “Unit Costs” under Pricing Summary Sheet. If from Pilot Phase. satisfactory delivery the billing period less than one month, then amount of the services and will be calculated on pro-rata basis and for this acceptance of the purpose the following factors are considered. submitted invoice to APSRTC. 1. Billing Cycle is last week of every month 2. 1 month is equal to One Calendar Month 9.2.Terms and conditions
1. Next billing Cycle or monthly Payment will be based on the actual utilisation of resources to deliver the services/milestones/applications. Total monthly Payment is linked to the compliance with the SLA metrics and the actual payment is the payment due to the Service Provider after any SLA related deductions. 2. The payments shall be carried out on Pro-rata basis computed usage for the respective month.
9.3. Payment Milestones Timeline % of Total SNo Milestone (in days) Project Cost Start of Pilot Rollout at Two depots for OPRS, AFCS a T + 45 1% and POS App, eWallet 0 Start of Rollout at one depot each at Twelve regions c of APSRTC for OPRS, AFCS and POS App, Ground T0 + 75 2% Booking app, eWallet (12 depots)
d Establishment of CCC T0 + 75 1% Start of Rollout at three additional depots each at e Twelve regions of APSRTC for OPRS, AFCS and T0 + 105 2% POS App, Ground Booking app, eWallet (48 depots)
Page 114 of 223 Start of Rollout at six additional depots each at Twelve regions of APSRTC for OPRS, AFCS and f T + 135 3% POS App, Ground Booking app, eWallet (120 0 depots)
g Start of rollout at remaining depots (129 depots) T0 + 180 1% Total 180 days 10% as per h Monthly Payment as per the net transactions Every Month weightage till Go-Live As per contract rate post Go- i Monthly Payment as per the net transactions Every Month Live of all modules. NOTE: Total Project is calculated either on Form C2(a) or C2(b)
6.8. Assumptions for Counting of days for all the SLA and Timelines
The APSRTC assumes all the calendar days for the counting of SLA and timelines for deliverables. Due dates for SLA and Timelines, falling on non-working days will be extended to next working day. This extension will not result in change in project plans.
Page 115 of 223 7. Acceptance Criteria
7.1. Acceptance Criteria Definition
Acceptance Criteria defines how a particular feature could be used from an end user’s perspective. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a functional requirement and form the basis of functional requirement acceptance testing which establishes the conditions for the success of the feature.
Acceptance criteria could establish a boundary that helps to understand what’s included and what’s excluded from the scope of the development. The criterion of acceptance not only informs the product behaviour in happy path scenarios, it also guides the user experience when things don’t work as intended. It describes what would be verified by the acceptance tests.
When the system integrator verifies particular functional requirement acceptance criteria and the developed feature passes it, the development of the functional requirement is considered as a success.
7.2. Acceptance Criteria Template
Acceptance criteria describe the intent of the APSRTC, i.e., idea of what the functionality should be like. It is up to the system integrator to develop the solution to the functional requirement. To make it simple, they can divide the document into a three-part scenario: Given, When, Then – each describing an item of the criteria, like what the product is used for, what should be there and what shouldn’t be. In the format of acceptance test criteria examples:
Scenario This is the title of the condition to be acted upon.
Given (an initial The user places an item into their shopping cart. condition)
This is where the process in which the user's initial order is verified or When whether it fulfils the system requirements to process the task. If it does, (something happens) then the system can proceed to work on the order. However, if the user order does not match to the system requirements, the system will deny the task. Then Once the system is done verifying the user order, the order is then (this is the processed to produce the results which would be: the final result, input to result) the next task or a lead-on for the user to the next task.
7.3. Acceptance Criteria for SI
1. The System Integrator shall study the requirements of the project and existing systems and shall design, develop, test, and provide maintenance support in accordance with the APSRTC guidelines 2. Final acceptance of Deliverables comprising functionalities and specifications identified in the RFP and successful completion in one or more Statements of Work, i.e. outcomes of the methodology is Page 116 of 223 expressly conditioned upon completion of all applicable inspection and testing procedures to satisfy the mutual definition of “done” as prescribed in the methodology. 3. Payments shall be made upon satisfaction of the criteria of “done” set forth in each deliverable. The System Integrator shall acknowledge and agree that Deliverables agreed criteria for “done” together with a resolution process for disagreement. The System Integrator shall provide best estimate. 4. The System Integrator shall diligently engage with APSRTC in review of all Deliverables presented and all outcomes in accordance with each module. During APSRTC’s review of the final Deliverables, outcomes or other work contracted identifies errors, defects, faults, noncompliance with the required Deliverables and specifications of the RFP as set forth, the System Integrator shall provide APSRTC with a revised Deliverable timeline and/or a mutually agreed upon detailed schedule, e.g. corrective action plan, for completion of a revised Deliverable, for any objections that System Integrator and APSRTC mutually determine fall within the intended scope of the Deliverable. If the APSRTC objections are not within the scope of the Agreement, the SI may initiate a Change Order and change request process follows. 5. Final acceptance at the conclusion of the project will be complete when the all processes meet the definition of “done” and there are no objections pending. Final acceptance shall result in release of any retain-age amounts and the final payment. 6. The System Integrator shall monitor and review the Alert logs and provide remediation for the alerts generated. 7. The following parameters would be reviewed during acceptance criteria
i. Number of working functions signed off ii. Quality of deliverable including code, proof of internal review iii. Best practices followed on deliverables including code
8. The System Integrator shall establish a process to review all violations and Alerts and document the rare situations when a violation is justified. Compliance to the Alerts will result in more maintainable, performant, scalable and upgradable applications with significantly fewer defects than non-compliant applications.
7.4. Go Live Requirements
The System Integrator must submit:
1. Letter for completion of Appropriate Training to respective APSRTC Officials on delivered product. 2. All the necessary software documentation for Delivered Product 3. User Manuals for the Deliverable 4. Catalogue for Help Desk Team to resolve any issues or raise Flags/Tickets.
Note: “Go Live” sign-off document which will be jointly approved by the APSRTC, and System Integrator selected through this RFP.
Page 117 of 223 7.5. Code Review Checklist Template for Review
The System Integrator shall provide the rules list with all the rules created or changed
7.5.1.Review Fundamentals: 1. Does the code completely and correctly implement the Business Requirements? 2. Does the code completely and correctly implement the Solution Design? 3. Does the code completely and correctly implement the System Requirements? 4. Does the code completely and correctly implement the Technical Requirements?
7.5.2.Review Guidelines:
1. Code Design
i. Is the code well structured, consistent in style and consistently formatted? ii. Are there any areas of the code excessively complex, and should as a result, be structured or split? iii. Enforce naming conventions iv. Are the fields properly initialised? v. Are the most common logic statements always tested first, does every loop have an exit? vi. Consider errors and manage exceptions cleanly vii. Design intent-driven processes.
2. Rules Management & Reuse
i. All rule availability set appropriately ii. All rule changes checked in iii. Wherever possible, use parameters to make rules flexible and re-usable.
3. Documentation
i. Is the code documented with an easy to maintain and consistent commenting style? ii. All activity steps have descriptions iii. History tab populated with usage and description information for all rules iv. All rules have meaningful, natural language short descriptions v. No commented-out steps in any activities.
4. Testing & Performance
i. Unit test executed against Test plan/Scripts ii. Profile to identify performance problems iii. Verify that logs have no errors or alerts iv. Clipboard pages are managed. Page 118 of 223 8. Service Level Agreement
8.1. Service Level Agreements
The service levels SI is required to comply with are detailed in this section. Also, penalties for non- compliances associated with the different service level agreements are defined herein. The service level agreements are broadly categorised under three headings:
1. Service Level Agreements until “Go-live” of the Project: The charges to be levied on the SI for non- compliance to SLAs until “Go-live” are referred to as Liquidated damages. 2. Service Level Agreements during the O & M. Phase: The charges to be levied on the SI for non- compliance to SLAs during the O & M phase are referred to as penalties. 3. SLAs are applicable as per the Deliverable Milestones notified in the RFP. 4. During O&M phase, maximum Penalty per month may be capped at maximum of 5% of the total monthly billing. 5. SLAs are calculated on weekly/monthly basis.
8.2. Definitions
For the purpose of this SLA, the definitions and terms as specified in the contract along with the following terms shall have the meanings set forth below:
1. “Incident” refers to any event / abnormalities in the functioning of the Cloud Enablement components in Service Provider’s specified services that may lead to disruption in normal operations of the services
2. “Support" shall mean the 15x7 support which shall handle patch updates, upgrades Fault Reporting, Trouble Ticketing, and resolution of related enquiries during this contract. Interactive remote diagnostic support shall also be there, allowing technical support engineers to troubleshoot an incident securely through a browser-based remote-control feature.
3. “Availability” shall mean the time for which the services offered are available for conducting operations from the equipment / solution hosted on Cloud. Availability percentage is measured as Availability %age = {(Agreed Service Time – Down Time)/(Agreed Service time) (100%)
4. “Scheduled Maintenance Time / Scheduled downtime” shall mean the time that the System is not in service due to a scheduled work. Scheduled maintenance time is planned downtime with the prior permission of the designated officer of APSRTC.
5. "Scheduled operation time” means the scheduled operating hours of the System for the month. All scheduled maintenance time on the system would be deducted from the total operation time for the month to give the scheduled operation time. The total operation time for the systems and applications hosted on cloud will be 24x7x365. Downtime means accumulated time during which the System is totally inoperable within the Scheduled Operation Time but outside the scheduled maintenance time. Page 119 of 223 6. “Response time” is defined as the time between receipt of the incident by support team and its logging / generation of ticket on the system
7. “Resolution Time” shall mean the time taken (after the incident has been reported to the support team) till resolution. The severity parameters have been defined below:
8. The severity would be as follows:
1. Critical: In case more than 1 physical server are down threatening business continuity (Services are not accessible and not working and Multiple Clients are affected) which is attributable to the UTS Platform implemented by the Service Provider, it shall be considered as a Critical incident. 2. High: In case 1 service is down causing high impact on business operations (Services are not accessible/not working [few clients are affected) which is attributable to the e.g.,UTS Platform implemented by the Service Provider. 3. Medium: In case an essential functionality of the UTS Platform becomes unavailable which is not actually hampering the live services of the platform but may impact the services if not attended immediately will be termed as medium. 4. Low: The incidents would be termed as low, which does not have any significant impact on the UTS Platform delivery (little or no impact on business entity), e.g., i. A minor problem or question that does not affect the software function, ii. An error in software product Documentation that has no significant effect on operations; or iii. A suggestion for new features or software product enhancement.
8.3. Planned Down Time
Planned downtime shall mean any time when the cloud-based services from the service provider are unavailable because of Urgent Maintenance activities and any other scheduled maintenance or upgrade activities that may or may not be periodic. The planned downtime must be notified to APSRTC at least 48 hours in advance.
Urgent Maintenance activities are maintenance activities required by application or systems that cannot be postponed until the next available or convenient maintenance window, and may include but not limited to restarting applications, rebooting servers, applying patches or fixes, reconfiguring, reloading data, etc.
8.4. Support Team Availability
It is expected that technical support is available from 08:00 hrs to 23:00 hrs daily. During critical failures/issues, support team shall be available 24*7*365.
8.5. Help Desk Team Availability
It is expected that help desk team is available 24*7*365.
Page 120 of 223 8.6. General
1. Successful bidder shall provide required Internet Bandwidth, leased lines between DC & DRC, MPLS VPN connections to 12major bus stations as specified in the Tender. Such internet Bandwidth, leased lines and MPLS VPN connection charges, Telephone bills, Taxes and any other charges related to DC & DRC should be paid by successful bidder, without any default. In case of non-payment of such bills the amount if paid by APSRTC, the same has to be paid by bidder, to APSRTC with @ 36% of penalty per annum. This would be deducted from the monthly commission payable amount. Such three default occurrences in a year would be liable for forfeiture of the PBG/BG and invoking the Bank Guarantee. 2. A Xerox copy of payment of monthly MPLS charges to be submitted to the ATM-2(M-IT), /RTC House/Vijayawada APSRTC before due date (monthly/quarterly), failing which penalty will be imposed. 3. Bidder shall be penalised to an extent of Rs. 2,000/-per hour or part thereof for the breakdown of any Leased lines or MPLS VPN connections provided to the Bus Stations to UTS Data Center and Disaster Recovery Center. 4. In case of any delay on part of bidder, to complete the tasks before the total time quoted, a penalty of Rs. 10,000/-per week of delay or part there of shall be imposed on successful bidder. Penalties will not be levied on lapses not due to successful bidder. 5. Deployment of application without proper testing attracts recovery of manpower cost of APSRTC’s involvement plus Rs. 5,000/-penalty for each item identified and reported by APSRTC. 6. A penalty of Rs. 5,000/-will be imposed for each occasion, if any wrong or unauthorised information is communicated through home page/website. 7. APSRTC reserves the right to extend the timelines to achieve a particular milestone, if required based on the prevailing situations during project roll out phase. Under no circumstances, such extension of time period shall be permitted beyond T0+360 days.
8.7. SLA Metrics
SLA Metrics
SNo SLA Parameter Target Performance Description Damages
Installation, Installation, Fine of Rs 15,000/-per day upto Configuration and configuration of OPRS 7 Days and after Rs 30,000/-per keep ready of UTS platform should be day upto 14 Days. After that, Platform with completed for Contracting Authority will take Android POS App/ development, testing and necessary action as specified in 1 agent Ground T0 + 75 Days production environments. the Agreement/Addendum to Booking App, This includes Android terminate the contract. eWallet, Dynamic POS App/agent Ground QR Code Booking App, eWallet, Penalties shall not be levied for integration, Open Dynamic QR Code cases not related to the SI. Ticket. integration, Open Ticket Deployment of Help Fine of Rs 1,000/-per day upto Desk Team, setting up 14 Days and after Rs 2,000/-per Setting up of Help help desk infrastructure day upto 14 Days. After that, 2 Desk T0 + 75 Days and shall keep ready for Contracting Authority will take functional necessary action as specified in the Agreement.
Page 121 of 223 SNo SLA Parameter Target Performance Description Damages
Shall deploy the solution 0.5% of the monthly invoice shall be deducted per month till delivery on prorata basis till T0 + 360 Days. Go-Live of AVLS & 3 T0 + 210 Days After that, Contracting PIS Authority will take necessary action as specified in the Agreement/Addendum to terminate the contract. Shall deploy the solution 0.5% of the monthly invoice shall be deducted per month till delivery on prorata basis till T0 + 360 Days. Go-Live of Buspass 4 T0 + 240 Days After that, Contracting Module -PAAS Authority will take necessary action as specified in the Agreement/Addendum to terminate the contract. Shall deploy the solution 0.5% of the monthly invoice shall be deducted per month till delivery on prorata basis till T0 Go-Live of Cargo + 360 Days. and Courier 5 T0 + 270 Days After that, Contracting Management System Authority will take necessary CCMS action as specified in the Agreement/Addendum to terminate the contract. Shall deploy the solution 0.5% of the monthly invoice and a minimum of 10 shall be deducted per month till dashboards and two delivery on prorata basis till T0 Go-Live of analytical reports shall be + 360 Days. 6 Analytics and MIS T0 + 300 Days deployed. After that, Contracting dashboards Authority will take necessary action as specified in the Agreement/Addendum to terminate the contract. Should deploy O&M Fine of Rs 1,000/-per day upto team and shall be 14 Days and after Rs 2,000/-per Deployment of available for application day upto 14 Days. After that, 7 O&M (Support) T0 + 75 Days support. Contracting Authority will take Team necessary action as specified in the Agreement. Availability of all critical Damages will be levied as per core components shall be the follows: at least 99.95%. 1. <99.95% & >=99.0% =0.25% Availability is based on a 2. <99.0% & >=98.5% UTS Platform weekly 7 day * 24 hour =0.50% 8 Availability >= 99.95% calculation excluding 3. <98.5% & >=97.0% =1.0% schedule downtime. For each additional drop of 1% in the performance below 97.0%, 1% of the monthly payment will be additionally levied.
Page 122 of 223 SNo SLA Parameter Target Performance Description Damages
Availability of all Damages will be levied as per functionalities shall be at the follows: least 99.95%. 1. <99.95% & >=99.0% =0.25% Availability is based on a 2. <99.0% & >=98.5% =0.5% weekly 7 day * 24 hour 3. <98.5% & >=97.0% =1.0% calculation excluding Availability of all schedule downtime. For each additional drop of 1% services including in the performance below 9 services provided to >= 99.95% Monitoring software 97.0%, 1% of the monthly 3rd party based checking shall be payment will be additionally Integrations facilitated by SI. levied.
Non-availability of even one of the agreed services would amount to deviation for this purpose. Response time of For each drop of 1% in services measured at an performance below 98%, 0.5% 98% of business interval of 2 hours and of the monthly payment will be Response Time for transactions shall be averaged monthly. levied additionally. 10 all business within the limit of 5 transactions seconds Monitoring software Penalties shall not be levied for based checking shall be cases not related to SI. facilitated by SI. Schedule Measures timely 0.5% of monthly payment per Maintenance of the 100% of the schedule maintenance or each unscheduled maintenance Configured UTS maintenance should be enhancements in the counted monthly. 11 Platform and its carried out as per UTS Platform components schedule. (including apps) Measures the timely Rs 10/- per each non-tracking Non-Availability of action on Auto trip. 12 Vehicle Tracking 100% of the waybills Assignment and Vehicle Services issued. tracking for every trip of operation. Measures the timely Damages will be levied as per response from UTS the follows: platform for issue of bus 1. up to 95% = Rs 500. per passes during business occasion during business hours of a day. This is hours of a day. 100% application uptime applicable on day to day 2. <95% & >=90% = Rs 1000 13 Non-Availability of during business hours basis. per occasion during Bus Pass Services (0800 to 2000 hrs) business hours of a day.
For additional drop of 1% in performance below 90%, Rs 250 will be levied additionally
Page 123 of 223 SNo SLA Parameter Target Performance Description Damages
Measures the timely Damages will be levied as per response from UTS the follows: platform for Cargo and 1. up to 95% = Rs 500. per Courier management occasion during business not less than 100% services during business hours of a day. Non-Availability of application uptime hours of a day. This is 2. <95% & >=90% = Rs 1000 14 Cargo and Courier during 0800 to 2000 hrs applicable on day to day per occasion during Management and not less than 98% basis. business hours of a day Services uptime during other non- business hrs. For additional drop of 1% in performance below 90%, Rs 250 will be levied additionally
Measured as total Damages will be levied as per downtime minutes/total the follows: minutes in a month. For example, if there 1. <99% & >=97% =Rs 500/- were 2 hours in july 2. <97% & >=95.0% =Rs when a customer’s 750/- Help Desk >99% availability of (APSRTC) call could not 3. <95.0% & >=90.0% =Rs 15 Availability total period have been answered, 1,000 availability will be [100- {120/(31days*15 For each additional drop of 1% hours*60 minutes)}*100] in the performance below = 99.57% 90.0%, Rs 250/-of the monthly payment will be additionally levied. Measured as percentage Damages will be levied as per of calls getting connected the follows: to the help desk, averaged over the month 1. <90% & >=87% =Rs 250/- 2. <87% & >=85.0% =Rs 500/- >90% availability of 3. <85.0% & >=80.0% =Rs 16 Call Connect Rate total period 750
For each additional drop of 1% in the performance below 80.0%, Rs 250/-of the monthly payment will be additionally levied. Average time taken to Damages will be levied as per acknowledge and the follows: respond once an incident 1. <95% & >=90% = Rs 500 is logged through one of 17 Problem Response >95% within One Hour the agreed channels. This For additional drop of 1% in Time is calculated for all performance below 90%, Rs incidents reported within 250 will be levied additionally the reporting month. (15*7*365)
Page 124 of 223 SNo SLA Parameter Target Performance Description Damages
1. For critical requests Time taken to resolve the 1. <100% & >=99% = 0.25% — 100% of the resolve the problem 2. <99% & >=98.5% = 0.5% requests should be 3. <98.5% & >=97% = 1.0% resolved within 2 hours of problem For additional drop of 1% in reporting. performance below 97%, 1% 2. For high Level calls, penalty will be levied >=95% should be additionally on monthly solved within 4 payment. Time to Resolve Hours of problem 18 (Minimum time to reporting. resolve MMTR) 3. For medium Level calls, >=95% should be solved within 24 Hours of problem reporting. 4. For low Level calls, >=95% should be solved within 48 Hours of problem reporting For all incidents which Rs 1000/-for increase of every are designated resolved 1% over and above 2%. by SI, but are reopens by Percentage of the APSRTC. 19 reopened incidents <=2% This is calculated for all incidents reported within the month This is calculated during For delay in submitting RCA Submission of Root within 7 days for critical the month, SI to submit report as specified, Rs 250 for 20 Cause Analysis and high level incidents RCA Reports. every two days will be levied (RCA) reports and within 14 days for additionally beyond the medium level incidents agreeable time. SI will be responsible for Each Instance will attract a any breach occurred at penalty of 5%/of monthly infrastructure level and payment. platform level.
21 Data Privacy Breach Zero Instances In any case, SI must not use or access APSRTC data stored in UTS Platform through unauthorised channels. Any incident where in For each breach/data theft, system compromised or penalty will be levied as per any case wherein data following criteria. theft occurs (including Any security incident detected internal incidents) 5% of monthly payment.
Security breach This penalty is applicable per 22 including Data Theft/ Zero Instances incident. These penalties will Loss/Corruption not be part of overall SLA penalties cap per month. In case of serious breach of security over 3 times in a year wherein the data is stolen or corrupted, APSRTC reserves the right to terminate the contract.
Page 125 of 223 SNo SLA Parameter Target Performance Description Damages Availability of SLA Rs 500 per every day delay reports covering all parameters required (e.g., 5 working days 23 for SLA monitoring from the end of the within the defined month) time. Data Sync Periodic For each test, sync rate Failure of data sync for every 24 Report for the DC should be less than 30 test - Rs 2,500 per test failure. and DR mins. Measured during the 1% of Monthly payment per regular planned or every additional 2 (two) hours of 25 Recovery Time RTO <= 1 hours unplanned (outage) downtime Objective (RTO) changeover from DC to DR or vice versa. Measured during the 1% of Monthly payment per regular planned or every additional 2 (two) hours of 26 Recovery Point RPO <= 2 hours unplanned (outage) downtime Objective (RPO) changeover from DC to DR or vice versa.
Note: S.No 8 to SNo 26 are applicable from T0+75 days.
Page 126 of 223 9. Terms and conditions
9.1. Contract Terms
9.1.1.Eligible Bidders
Only System Integrators who are registered on MSTC platforms as vendors will be eligible for submitting their bids for this RFP.
9.1.2.Availability of the RFP Documents:
The RFP can be downloaded from the website / given under Section 4. The bidders are expected to examine all instructions, forms, terms, project requirements and other information in the RFP documents. Failure to furnish all information required as mentioned in the RFP documents or submission of a proposal not substantially responsive to the RFP documents in every respect will be at the bidder's risk and may result in rejection of the proposal and forfeiture of the bid security.
9.1.3.Mode of Submission
Procedure for Bid Submission: The Bidder shall submit their response through document submission process on e-Procurement platform at www.mstcecommerce.com by following the procedure given below: The Proposer would be required to register on the e-procurement platform
www.mstcecommerce.com
and submit their proposals online and a hardcopy of entire proposed documents shall be submitted by stipulated bid closing date and time.
In case any Proposer is not able to upload the entire set of documents on e-procurement platform either due to space/size constraint or any other technical hitches, only in such cases, the relevant hard copies of the left over documents which could not be uploaded on e-procurement platform may be submitted in sealed covers in the office of CE(IT)/APSRTC located at 1st Floor, NTR Administrative Block, Pandit Nehru Bus Station, NH-65, Vijayawada, Andhra Pradesh, before the stipulated closure time of proposal submission. A self-certificate from the Proposer in this regard detailing the reasons for submitting the hard copies, if any, duly bringing out issues faced in uploading them on e- procurement platform, if any, shall also be submitted. The uploaded documents on the e-procurement platform and the hard copies submitted in sealed covers, if any, together will be treated as a single set of documents under a proposal and will be evaluated accordingly.
The Proposers shall submit their necessary documents online in e-Procurement web site. The Proposers shall upload the scanned copies of all the relevant certificates, documents, etc., in support of their Pre-Qualification and other certificates/documents with clear readability, in the e-Procurement web site. The Proposer should sign on all the statements, documents, certificates uploaded in the e- Procurement website, owning responsibility for their correctness/authenticity. Page 127 of 223 9.1.4.Earnest Money Deposit:
1. Bidders shall submit, along with their bids, EMD for an amount as specified in the RFP in APSRTC account as per the details given in the RFP. EMD in any other form shall not be entertained. 2. The EMD shall be denominated in Indian Rupees only. 3. No interest will be payable to the bidder on the amount of the EMD. 4. In general, unsuccessful bidder’s EMD will be discharged/returned as promptly as possible, but not later than 30 days after the award of the contract to the selected implementation agency. 5. Scanned copy of the payment receipt for document and EMD should be uploaded through eprocurement process. 6. The physical copies of EMD fee shall be submitted to the concerned as per the details mentioned in the data sheet. Bids submitted without adequate EMD will be liable for rejection. 7. The EMD of successful bidder shall be adjusted against the Performance Bank Guarantee (PBG) to be remitted before entering into agreement. 8. No interest is payable on EMD and PBG to the SI. 9. The EMD may be forfeited: i. If a bidder withdraws his bid or increases his quoted prices during the period of bid validity or its extended period, if any; or ii. In the case of a successful bidder if the bidder fails to sign the contract for any reason not attributable to the APSRTC or not furnish Performance Bank Guarantee (PBG) within specified time in accordance with the format given in the RFP. iii. Bids Submitted with EMD not valid in the specified period will also be rejected iv. During the bid process, if any information is found wrong / manipulated / hidden in the bid. The decision of APSRTC regarding forfeiture of the EMD and rejection of bid shall be final & shall not be called upon question under any circumstances.
9.1.5.Payment of Transaction Fee:
1. For submission of Techno Commercial bid, the bidder has to remit a non-refundable administrative entry fee to APSRTC at the rate of Rs 20,000 + 18% GST (Rupees Twenty-Thousand only plus GST @ 18%) i.e. 23,600/-(Twenty Three Thousand Six hundred only) in advance. 2. The Bidder shall also arrange to remit an amount of Rs.25,00,000/- (Rupees Twenty-five lakhs only) to APSRTC as caution deposit (EMD) (refundable) in advance. 3. The entry fee and caution deposit shall be paid into the current account number of FA &CAO of APSRTC through NEFT / RTGS only at least 24 hrs. in advance. The details of account i. Name of the Account FA & CAO ii. Current Account Number 62472413226 iii. IFSC Code SBIN0020169 iv. Name of the Bank State Bank of India 5. The details with UTR number shall be mailed to [email protected] and [email protected].
Page 128 of 223 Name Mobile Lot Number Administrative Vendor Bank Caution Bank UTR Number Fee Paid Rs Account Deposit IFSC Code Number Number Paid Rs
6. During the Techno Commercial bid process, the bidder will be required to pay user charges to the MSTC at the rate of 0.03% of bid value plus 18% GST or Rs 10,000/-plus18% GST whichever is less.
9.1.6.Allotment and Letter of Award
1. The successful bidder shall be decided based on the lowest bid after completing the reverse auction. However, the corporation reserves the right to reject any bid or cancel the tendering process without assigning any reason at any stage. 2. The successful bidder (Prime Bidder only) will have to enter into an agreement within 15 days from the date of receipt of Letter of Intent, duly submitting Bank Guarantee for the prescribed amount, towards PBG. The EMD of unsuccessful bidder will be refunded after the bidding except for L 2. EMD of the L 2 will be refunded after the LOI acceptance by L 1 bidder. The date of implementation of the project will be decided by Chief Engineer IT, Head office, APSRTC.
9.1.7.General Terms and Conditions
1. The response to the tender has to be submitted in accordance with the Terms and Conditions mentioned in this document. 2. The specifications and requirements mentioned in the tender are subject to revision and changes as and when required. 3. APSRTC reserves the right to cancel the tendering process at any stage and can invite fresh tender without assigning any reasons. 4. If any dispute arises out of the contract with regard to the interpretation, meaning and breach of the terms of the contract, the matter shall be referred to, by the Parties, to the Vice Chairman & Managing Director, APSRTC. 5. The Bidder/Consortium Partner should have a local support office at Vijayawada and provide the supporting documents in technical bid. If the bidder does not have any local support office at the time of bidding, then he must submit an undertaking on his letter head that if selected then he shall open a local support office at Vijayawada within two months from the date of award of contract. 6. The application software developed for this project should be provided with perpetual licenses for APSRTC use. APSRTC will have all Intellectual Property Rights on all customisations carried out to suit APSRTC operations & reporting requirements, etc. The application software to the extent of customisations to APSRTC should not be used, or handled by any individual, outside agency, firm, organisation, state transport undertaking except APSRTC. Any violation or breach of this condition will entitle the Corporation to claim damages. 7. Consortium is allowed and bidders are permitted to add maximum one consortium member for the purpose of this project up to the submission of the tender. The successful bidder will not be allowed to drop any consortium member till the completion of the project. The successful bidder will be liable to fresh scrutiny/disqualification in case of dropout of any consortium member post award of contract and till completion of the project at the discretion of APSRTC. One consortium partner cannot be the member of any other consortium for this project. Consortium agreement has to be
Page 129 of 223 submitted along with the Techno Commercial bid duly signed by all the consortium partners stating the name of lead bidder and roles and responsibilities of all the consortium partners. 8. APSRTC reserves the right to reject any software supplied against the order, if found not working satisfactorily or not able to render the proposed solution at the time of installation at sites. The rejected software, if any, shall have to be taken back and replaced as per requirement of Corporation forthwith at the cost of the bidder. No payment will be made for the rejected software. 9. The prime/lead bidder should submit any representation regarding any financial matters/ transactions, with the signatures of all the consortium members. 10. The Vice Chairman & Managing Director of APSRTC, Vijayawada, reserves the right to cancel the tenders at any stage and can invite fresh tenders without assigning any reason(s). 11. The decision of APSRTC is final in allotment of the contract. 12. The Techno Commercial bids submitted are not permitted to be withdrawn at any stage of process and APSRTC will not be responsible for any delay in finalising the tenders for reasons beyond its control. 13. Legal disputes, if any, should be settled only in the courts having jurisdiction in Vijayawada and High Courts of AP State. 14. Bidders shall fill up the required information as prescribed in the tender form. Incomplete forms without full information are liable for rejection. 15. The rate will be applicable for the whole contract period and will not be subject to any upward revision for any reasons whatsoever. The rate shall be quoted exclusive of GST. 16. Vendor has to submit quotes for the bid parameter “ Rate per 100 net transactions”: a. With IT Infrastructure b. Without IT Infrastructure c. Reverse auction will be conducted based on i. Rate per 100 net Transactions rate with IT Infrastructure - G1 and ii. Rate per 100 net Transactions rate without IT Infrastructure - G2 17. Quote G1 and G2 shall be quoted in paise only. 18. Reverse auction will be conducted either on G1 or G2 only with a minimum decremental value of 10 paise. 19. The period of contract is for five (5) years from Go-Live Declaration date (excluding pilot period) with the successful bidder. 20. The individual/Firm/Company shall furnish the IT Returns, Audited P&L account and balance sheet for 2017-2018, 2018-19 and 2019-20 along with the tender form. 21. All the Municipal/Statutory levies, taxes, etc., imposed by State and Central Government/Service taxes, etc., should be borne by the successful bidder to carry out the business. 22. The personnel engaged by the vendor for commencing the business are not entitled for a job in APSRTC, either at present or anytime in future. 23. GST, as per the provisions of GST Act will be reimbursed as per the procedure in vogue. 24. Any advertisements, print material by the Vendor for improvement of his business, etc., shall be at his own cost and the content should be approved by APSRTC authorities before publication. 25. No conveyance/bus pass shall be provided to any employee engaged by the Vendor nor any sort of compensation be paid by APSRTC. 26. In case of any disputes regarding interpretation of Terms and Conditions of this agreement, decision of Vice Chairman & Managing Director, APSRTC, Vijayawada is final.
Page 130 of 223 27. The successful vendor shall not disclose to any other party about the knowledge of system on the possession of material and information given to the successful vendor under this agreed contract or any information which has been generated during the running of the project. The successful vendor should hold such material and information in strict confidence, not to make use of them other than for the performance of this contract, except release it only to designated employees requiring such information for operation, maintenance, control and inspection of the systems. During the execution of the contract and thereafter the above information should not be released to any other parties. 28. If any untoward incidents occur while maintenance of ITS and its sub systems or any other works, they shall be handled by the vendor. Further, if any damage occurs during such incidents to the property / personnel of the vendor, APSRTC has no responsibility and is not liable to pay any compensation. 29. The bidder should provide the deployment plan of man power at regions to maintain and manage the ITS equipment, Android POS in all the depots of the corporation. 30. The persons engaged by the successful bidder, to carry out work shall be paid minimum wages as fixed by the Commissioner of Labour. PF, ESI, etc., as per statutory obligations has to be paid to the workers/employees from time to time and a proof to that extent may be produced to APSRTC, every month for record purpose. 31. The successful bidder shall remit PF/EDLIF/ESI etc. amount in respect of the persons engaged by them, to the Regional Provident Fund Commissioner or concerned Authorities on the PF number obtained by them and produce proof of the same every month to APSRTC for office record. Noncompliance of the same will be viewed seriously and it may be considered as breach of terms and conditions of the agreement. 32. The successful bidder shall indemnify APSRTC from all the claims, damages and compensations under the provisions of all Laws and Acts pertaining to the persons engaged by them. 33. The successful vendor should submit documentation of every output (report) along with algorithm and regarding the logic used to develop that report. The modification build given, should be approved by APSRTC along with detailed release note in the chronological order. All the release notes in the chronological order should be made available on the web site for the admin users in the opted and date wise modifications with details.
9.2. Pre-Bid Conference
1. The APSRTC will host a Pre-Bid Conference, tentatively scheduled as per the schedule given in Section 2 above. The representatives of the interested organisations may attend the pre-bid conference at their own cost. The purpose of the pre-bid conference is to provide bidders with information regarding the RFP and the proposed requirements in reference to the particular RFP. It will also provide each bidder with an opportunity to seek clarifications regarding any aspect of the RFP and the project. 2. Clarify and discuss issues with respect to the Project and the RFP, APSRTC may hold Pre-Proposal meeting(s). APSRTC will endeavour to hold the Pre-Proposal meeting as per bidding schedule specified in Section 2 above in both off-line and online mode. Details of virtual (online) connect will be published at APSRTC official website with at least 24 hrs in advance to the pre-bid meeting. 3. The date, time and venue of the Pre-Proposal Meeting (pre-bid meeting) shall be: Date : 08.03.2021 Time : 11:00 Hrs Venue : Mini Conference Hall, Page 131 of 223 O/o The APSRTC, GoAP 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 013 4. Prior to the Pre-Proposal meeting(s), the Bidders may submit a list of queries and propose deviations, if any, to the Project requirements and/or the Services Agreement. Bidders must formulate their queries and forward the same to APSRTC as per the time schedule set out in Clause 4 above. APSRTC may, at its sole discretion or based on inputs provided by Bidders that it considers acceptable, amend the RFP. 5. Bidders may note that APSRTC will not entertain any deviations to the RFP at the time of submission of the Proposal or thereafter. The Proposal to be submitted by the Bidders would have to be unconditional and unqualified and the Bidders would be deemed to have accepted the terms and conditions of the Bidding Documents with all its contents including the draft Services Agreement. Any conditional Proposal shall be regarded as non-responsive and would be liable for rejection. 6. Attendance of the Bidders at the Pre-Proposal meeting is not mandatory. 7. All correspondence / enquiries shall be submitted to the officer mentioned below, in writing by facsimile/registered post/courier or by email: Kind Attention: VC & MD, APSRTC Address: APSRTC, GoAP 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 013 Email: [email protected], [email protected] 8. APSRTC shall make available its responses, including a description of the enquiry, but without identifying its source, on the e-procurement website and/or its website. In addition, APSRTC may choose to send to all Bidders, written copies of such responses to all the Bidders. No interpretation, revision, or other communication from APSRTC regarding this solicitation is valid unless it is in writing and is signed by a person not less than the rank of the VC & MD, APSRTC. 9. The period of contract is for five (5) years from the date of Go-Live Declaration with the successful bidder.
9.3. Bidder Inquiries and APSRTC responses
1. All enquiries from the prospective bidders relating to this RFP must be submitted in writing exclusively to the contact person notified by APSRTC as above in the format specified below as Request for Clarification Format. A copy of the bidder enquiries should also be emailed to the bid issuer’s email address provided in the Section 4. The mode of delivering written questions would be through post or email. It can also be presented in writing by the authorized representative of the prospective bidders during pre-bid conference. In no event will APSRTC be responsible for ensuring that bidders’ inquiries have been received by them. Telephone calls or any other mode of communication other than prescribed herein will not be accepted for the queries. 2. After the RFP is issued to the bidder, APSRTC shall accept written questions/inquiries from the bidders. APSRTC will endeavour to provide a complete, accurate, and timely response to all questions to all the bidders. However, APSRTC makes no representation or warranty as to the completeness or accuracy of any response, nor does APSRTC undertake to answer all the queries that have been posed by the bidders. All responses given by APSRTC will be published on the website given under Section
Page 132 of 223 4. All responses given by APSRTC will be available to all the bidders. Any email communications sent by bidders to APSRTC must be sent to the email address provided in Section 4. 3. APSRTC will not be bound to clarify any query after the pre-bid meeting. 4. The queries should be submitted in following format:
SNo Bidder Section Clause Page Clause/ Query APSRTC Response Name Name No No. Statement
9.4. Supplementary Information/Corrigendum/Amendment to the RFP
1. If APSRTC deems it appropriate to revise any part of this RFP or to issue additional data to clarify an interpretation of the provisions of this RFP, it may issue supplements to this RFP. Such supplemental information, including but not limited to, any additional conditions, clarifications, minutes of meeting, and official communication over email/post will be communicated to all the bidders by publishing on APSRTC official website. Any such supplement shall be deemed to be incorporated by this reference into this RFP. 2. The letters seeking clarifications sent either to all the bidders or to specific bidder as the case may be pertaining to pre-bid conference shall also be deemed to be incorporated by this reference in this RFP, as the case may be. 3. At any time prior to the deadline (or as extended by APSRTC) for submission of bids, APSRTC, for any reason, whether at its own initiative or in response to clarifications requested by prospective bidder, may modify the RFP document by issuing amendment(s). All such amendments will be published on APSRTC official website. All such amendment(s) will be binding on all the bidders. 4. In order to allow bidders a reasonable time to take the amendment(s) into account in preparing their bids, APSRTC, at its discretion, may extend the deadline for the submission of bids.
9.5. Proposal Preparation Costs
The bidder is responsible for all costs incurred in connection with participation in this process, including, but not limited to, costs incurred in conduct of informative and other diligence activities, participation in meetings/discussions/presentations, preparation of proposal in providing any additional information required by APSRTC to facilitate the evaluation process, and in negotiating a definitive Service Agreement and all such activities related to the bid process. This RFP does not commit APSRTC to award a contract or to engage in negotiations. Further, no reimbursable cost may be incurred in anticipation of award of the contract for implementation of the project.
9.6. Right to terminate the process of RFP by APSRTC
1. APSRTC may terminate the RFP process at any time without assigning any reason. APSRTC makes no commitments, explicit or implicit, that this process will result in a business transaction with anyone.
Page 133 of 223 2. This RFP does not constitute an offer by APSRTC. The bidder’s participation in this process may result in APSRTC selecting the bidder to engage in further discussions and negotiations towards execution of a contract. The commencement of such negotiations does not, however, signify a commitment by APSRTC to execute a contract or to continue negotiations. 3. APSRTC has the right to terminate this discussions and negotiations process without assigning any reason and no costs will be reimbursed to the participating bidders.
9.7. Acceptance of part / whole bid / modification – Rights thereof
APSRTC reserves the right to modify the specifications / quantities / requirements / tenure mentioned in this RFP including addition / deletion of any of the item or part thereof after pre-bid and the right to accept or reject wholly or partly bid offer, or, without assigning any reason whatsoever. No correspondence in this regard shall be entertained. APSRTC also reserves the unconditional right to place order on wholly or partly bid quantity to successful bidder. 9.8. Authentication of Bids
The original and all copies of the bid shall be typed or written in indelible ink and signed by the Bidder or a person duly authorized to bind the Bidder to the Contract. A certified true copy of the corporate sanctions/approvals/board resolution authorising its authorized representative to sign/act/ execute documents forming part of this proposal including various RFP documents and binding contract shall accompany the bid. All pages of the bid, except for un-amended printed literature, shall be initialed and stamped by the person or persons signing the bid.
9.9. Interlineations in Bids
The bid shall contain no interlineations, erasures or overwriting except as necessary to correct errors made by the Bidder, in which case such corrections shall be initialled by the person or persons signing the bid.
9.10. Consortium Bids
1. Consortium of Bids is allowed with one partner. However, such consortium member shall be from IT/ ITES services organisation only. The Prime Bidder will be the single point of contact under this contract and the responsibility for implementing and commissioning the complete solution shall lie with the Prime Bidder. 2. In case of any delays from the partner, Prime Bidder shall be liable and should take complete ownership for execution of contract. 3. Memorandum of Understanding (MOU)/agreement of the Prime Bidder with the Consortium Member signed by the Authorized Signatories of the individual organisations should be submitted along with pre-qualification bid. The MoU /agreements shall clearly specify the roles and responsibilities of the prime bidder and the consortium member w.r.to. the project.
Page 134 of 223 9.11. Venue & Deadline for submission of proposals
1. Proposals, in its complete form in all respects as specified in the RFP, must be submitted online at address specified. 2. Last Date & Time of submission: Before the date and time stipulated in schedule given. 3. APSRTC may, in exceptional circumstances and at its discretion, extend the deadline for submission of proposals by issuing an addendum. All such addendums will be published on the website given under Section 1 Clause 1. In such a case of extension, all rights and obligations of APSRTC and the bidders previously subject to the original deadline will thereafter be subject to the deadline as extended.
9.12. Late Bids
Bids received after the due date and the specified time (including the extended period if any) for any reason whatsoever, shall not be entertained and shall be returned unopened.
9.13. Conditions under which this RFP is issued
1. This RFP is not an offer and is issued with no commitment. APSRTC reserves the right to withdraw the RFP and change or vary any part thereof at any stage. APSRTC also reserves the right to disqualify any bidder, should it be so necessary at any stage for any reason whatsoever. 2. Timing and sequence of events resulting from this RFP shall ultimately be determined by APSRTC. 3. No oral conversations or agreements with any official, agent, or employee of APSRTC shall affect or modify any terms of this RFP and any alleged oral agreement or arrangement made by a bidder with any department, agency, official or employee of APSRTC shall be superseded by the definitive agreement that results from this RFP process. Oral communications by APSRTC to bidders shall not be considered binding on APSRTC, nor shall any written materials have provided by any person other than APSRTC. 4. Neither the bidder nor any of the bidder’s representatives shall have any claims whatsoever against APSRTC or any of their respective officials, agents, or employees arising out of, or relating to this RFP or these procedures (other than those arising under a definitive service agreement with the bidder in accordance with the terms thereof). 5. The information contained in this document is only disclosed for the purposes of enabling bidders to submit a proposal to APSRTC. No part of this document including the Annexure's can be reproduced in any form or by any means, disclosed or distributed to any party not involved in the bid process without the prior consent of APSRTC except to the extent required for submitting bid. This document should not therefore be used for any other purpose.
9.14. Rights to the Content of the Proposal
All the bids and accompanying documentation submitted as bids against this RFP will become the property of APSRTC and will not be returned after opening of the proposals. APSRTC is not restricted in its rights to use or disclose any or all of the information contained in the proposal and can do so without compensation to the bidders. APSRTC shall not be bound by any language in the proposal indicating the confidentiality of the proposal or any other restriction on its use or disclosure. APSRTC Page 135 of 223 has the right to use the services of external experts to evaluate the proposal by the bidders and share the content of the proposal either partially or completely with the experts for evaluation with adequate protection of the confidentiality information of the bidder.
9.15. Modification and Withdrawal of Proposals:
1. No Bid shall be modified, substituted or withdrawn by the Bidder on or after the Bid Due Date. Entire bid security shall be forfeited if any of the bidders modify or withdraw their bid during the bid validity period. 2. Any alteration/modification in the Bid or additional information supplied subsequent to the Bid Due Date, unless the same has been expressly sought for by the APSRTC, shall be disregarded. 3. The RFP/bid submission process is according to the e-Procurement process. The procedure for modification, substitution and withdrawal of bids shall be as specified in the e-Procurement website mentioned in the Section 4 of this RFP. Hence, bidders are advised to go through such procedures stated in the online procurement portal of APSRTC. 4. The Bidder may modify, substitute or withdraw its Bid after submission, provided the same is done before the last date of bid submission or that written notice of the modification, substitution or withdrawal is received by the APSRTC prior to the last date and time for submission of Bid. However, after the last date of bid submission modification, substitution or withdrawal of bid will not be permitted and such modified/substituted bid will not be considered for evaluation.
9.16. Non-Exclusivity
APSRTC has the right to allot similar natured contract to any other firm for a similar activity, if needed, in any region/zone or entire state/corporation, during the subsistence of the contract period and the successful bidder shall not have any right to object to the same and the decision of APSRTC in this regard shall be binding.
9.17. Legal Heir
In the event of death of the authorised signatory/ Director of the successful bidder, during the subsistence of the contract period, APSRTC may permit the legal heir of the successful bidder, as decided by its board of directors, to run the business on the same terms and conditions for the remaining period of the contract, duly entering into a supplementary agreement on Rs 100/- non- judicial stamp paper purchased at the cost of the successful bidder, subject to the condition that necessary proof of such legal heir, as required, shall be submitted to APSRTC. Failing the same will lead to termination of the contract.
9.18. Non-Conforming Proposals
A proposal may be construed as a non-conforming proposal and ineligible for consideration:
1. If it does not comply with the requirements of this RFP.
Page 136 of 223 2. If a proposal appears to be “canned” presentations of promotional materials that do not follow the format requested in this RFP or do not appear to address the particular requirements of the proposed solution, and any such bidders may also be disqualified.
9.19. Acknowledgement of Understanding of Terms
By submitting a proposal, each bidder shall be deemed to acknowledge that they have carefully read all sections of this RFP, including all forms, schedules and Annexure hereto, and has fully informed themselves as to all existing conditions and limitations.
9.20. Offer Validity period
The offer should remain valid for a period of 180 days from the date of the submission of offer. A proposal valid for a shorter period may be rejected as non-responsive. On completion of the validity period, unless the bidder withdraws his proposal in writing, it will be deemed to be valid until such time that the bidder formally (in writing) withdraws his proposal. In exceptional circumstances, at its discretion, APSRTC may solicit the bidder's consent for an extension of the validity period. The request and the responses thereto shall be made in writing or by fax or email.
9.21. Language of Proposals
The proposal and all correspondence and documents shall be written in English.
9.22. Termination of Contract 1. The SI shall be obliged to fulfil all terms and condition of the UTS platform. 2. Termination of contract comes in to force during non-performance of the SI only. 3. Failure to comply any of the conditions or scope of work, APSRTC may issue written notice to the SI to fulfil the contractual obligations within 60 days from the date of receipt of the notice. 4. Failure to comply the contractual obligations may be treated as breach of contract and any violation or breach of terms and conditions of the contract including unsatisfactory performance by the SI during the subsistence of the agreement, shall render the contract liable for termination with advance notice. In such a case, the security deposit/Performance Bank Guarantee/ Bank Guarantee held by APSRTC will be invoked in favour of APSRTC. 5. APSRTC has the right to terminate the contract without assigning any reason at any time during the subsistence of the contract period, with an advance notice of 60 days, in such cases the security deposit/Performance Bank Guarantee/ Bank Guarantee held by APSRTC will be refunded after adjusting the dues, if any. 6. SI shall comply and complete and procedures in similar to exit management during termination as well. 7. SI reserves no right to terminate/withdraw the contract under any circumstances. Detailed contractual conditions will be laid in Master Services Agreement.
9.23. Exit from the project: Under ordinary circumstances, SI reserves no right to exit from the project. APSRTC reserves full rights to exit. However, under extra ordinary circumstances, if the SI unlikely to maintain contractual Page 137 of 223 obligations due to changes in the organisation may serve a written notice to APSRTC duly stating the reasons.
If APSRTC is satisfied with the reasons stated, APSRTC may permit the SI to exit from the project subject to completion of minimum contract period of three (03) years from Go-Live Declaration date. The SI shall serve notice with minimum six (06) months in advance, after completion of minimum contract period of three (03) years from Go-Live declaration date..
Advance Notice for exit from the project shall be given in writing to Chief Engineer (IT), APSRTC. If the SI desires to withdraw from the contract before completion of minimum contract period of three (03) years from Go-Live Declaration date,PBG/BG/SD will be forfeited.
9.24. Non-Disclosure of Confidential Information
The Bidder shall maintain the security, non-disclosure and confidentiality of all information in accordance with the following clauses in performance of its activities under the Contract. Bidder shall ensure that its personnel, agents, officers and other resources, if any, are fully aware of the obligations arising under this Exhibit and shall take all commercially reasonable steps to ensure compliance. The Contract may be terminated by the APSRTC for cause for a material breach of this Exhibit.
9.24.1.Security Procedures:
Bidder warrants, covenants and represents that it shall comply fully with all security procedures and policies of APSRTC, which procedures and policies are communicated to the Bidder by the APSRTC during the performance of the Contract. Bidder shall hold the APSRTC harmless from any loss or damage to the APSRTC resulting from the violation of such security procedures or policies by the Bidder, its officers, agents, employees, and other resources.
The Bidder shall comply with the following specific security procedures:
1. Data Access – The Bidder must ensure that all data related to this project is stored in a controlled access environment to ensure data security and integrity. All facilities proposed for use must have adequate security systems in place to protect against the unauthorised access to the facilities and data stored therein. Adequate security systems must be in place to control access into the facilities. Access into and within the facilities must be restricted through an access control system that requires positive identification of authorized individuals as well as maintains a log of all accesses (e.g., date, time, who). The Bidder shall have a formal procedure in place for granting computer system access to the data and to track access by its own employees. Access for projects outside of those approved by the APSRTC is strictly prohibited.
2. Location of Data – Unless otherwise noted in the contract, all the APSRTC data exchanged with the Bidder must be stored, housed, processed, backed-up, archived and otherwise retained on systems physically located in India or designated online systems provided by the APSRTC. This requirement extends to any human resources deployed by the Bidder to handle data storage service.
3. Data Exchange – Except as otherwise stipulated in the contract, Bidder shall make arrangements to receive or exchange all the APSRTC supplied or designated electronic information via the Page 138 of 223 APSRTC's systems of record. APSRTC information in other formats must be exchanged via an official contact identified in the contract.
4. Physical Transport of Data – The Bidder shall use reputable means to transport data. Deliveries must be made either via hand delivery by an employee of the Bidder or by restricted delivery via courier (e.g., FedEx, India Post, DHL, Blue dart) with shipment tracking and receipt confirmation. This applies to transport between the Bidder’s offices, and APSRTC.
5. Electronic Transport of Data – The Bidder shall use reliable means of electronically transferring data between APSRTC and Bidder’s devices, offices and facilities. Such means must assure the confidentiality and integrity of the data while in transit.
6. Data Protection – The Bidder shall use appropriate means to preserve and protect APSRTC data. This includes, but is not limited to, use of stable storage media, regular data backups and archiving, password protection of volumes, and data encryption. The Bidder shall encrypt data identified by APSRTC, as requiring encryption and it shall use encryption methods that have Federal Information Processing Standard (FIPS) 140 validation.
7. Data Destruction – At the end of this contract, the Bidder shall employ the technical measures necessary to assure the secure, irreversible erasure or destruction of all data storage formats to eliminate any and all data collected or generated by the Bidder and/or provided by APSRTC unless explicit provisions for the retention of some data sets have been stipulated in the contract. The destruction process must receive written approval by APSRTC.
8. Return of Data – Upon written request of APSRTC at any time during the term and upon expiration or termination of the contract, the Bidder shall promptly return to APSRTC, in the format and on the media requested by APSRTC, all or any part of APSRTC data collected during the term of the contract.
9. Data Breach Notification-below, Bidder agrees that it shall immediately report to APSRTC the discovery of any unauthorised use or unauthorised disclosure of such Confidential Information [See Section B: Nondisclosure and Confidentiality] directly to the APSRTC.
The terms of this section shall apply equally to Bidder, its agents and other human resources, if any. Bidder agrees that all resources, if any, and agents shall be made aware of and shall be made contractually bound to the terms of this section.
Upon request by APSRTC, Bidder may be asked to provide a recent independent audit report on security controls. APSRTC shall have the right to send its officers and employees into the offices of the Bidder for inspection of the facilities and operations used in the performance of any work under the Contract. On the basis of such inspection, specific measures may be required in cases where the Bidder is found to be non-compliant with Contract safeguards.
Page 139 of 223 9.24.2.Nondisclosure and Confidentiality
Except as may be required by applicable law or a court of competent jurisdiction, the Bidder, its officers, agents, employees, and other human resources, if any, shall maintain strict confidence with respect to any Confidential Information to which the Bidder, its officers, agents, employees, and other human resources, if any, have access. This representation shall survive termination of the Contract. For purposes of the Contract, all APSRTC information of which Bidder, its officers, agents, employees, and other human resources, if any, becomes aware during the course of performing Services for APSRTC shall be deemed to be Confidential Information (oral, visual or written, in paper, electronic or any other format). Notwithstanding the foregoing, information that falls into any of the following categories shall not be considered Confidential Information:
1. Information that is previously rightfully known to the receiving party without restriction on disclosure; 2. Information that becomes, from no act or failure to act on the part of the receiving party, generally known in the relevant industry or is in the public domain; and 3. Information that is independently developed by Bidder without use of Confidential Information of APSRTC. Bidder shall hold APSRTC harmless, without limitation, from any loss or damage to APSRTC resulting from the disclosure by the Bidder, its officers, agents, employees, and resources of such Confidential Information.
9.24.3.Central or State Requirements
In the event that it becomes necessary for Bidder to receive Confidential Information, which Central or State statute or regulation prohibits from disclosure, Bidder hereby agrees to return or destroy all such Confidential Information that has been received from APSRTC when the purpose that necessitated its receipt by Bidder has been completed. In addition, Bidder agrees not to retain any Confidential Information which Central or State statute or regulation prohibits from disclosure after termination of the Contract.
Notwithstanding the foregoing, if the return or destruction of the Confidential Information is not feasible, Bidder agrees to extend the protections of the Contract for as long as necessary to protect the Confidential Information and to limit any further use of disclosure of that Confidential Information. If Bidder elects to destroy Confidential Information, it shall use reasonable efforts to achieve the same and notify APSRTC accordingly. Bidder agrees that it will use all appropriate safeguards to prevent any unauthorised use or unauthorised disclosure of Confidential Information, which Central or State statute or regulation prohibits from disclosure.
Bidder agrees that it shall immediately report to APSRTC the discovery of any unauthorised use or unauthorised disclosure of such Confidential Information directly to APSRTC. The terms of this section shall apply equally to Bidder, its agents and resources, if any. Bidder agrees that all resources, if any, and agents shall be made aware of and shall be bound contractually to the terms of this section.
Page 140 of 223 9.25. Criteria for Eligibility
1. Pre-Qualification Criteria
SNo Particulars/ Parameters Documents to be submitted
Power of Attorney (PoA) or Board Resolution authorising the person signing the proposal to sign on behalf of the Letter of authorisation to be 1 frm or Letter of Authorisation issued by Competent submitted Authority of the bidder.
Legal Entity
The Bidder should be a company registered under the Indian Companies Act, 1956 and shall be primarily in the business of providing Information Technology Software Certifcate of Incorporation of the 2 Development or System Integration or IT Solution Prime Bidder to be enclosed. Implementation Services (IT/ITES). The Company should have been in business for at least fve years as on 31st March 2020.
Consortium partner being an entity, it shall either be a Certifcate of Incorporation (for Company or a Partnership (including LLP) under the Companies or LLP) or copy of Indian Companies Act or Partnership Act, respectively. 3 Partnership Deed (for Partnership) to Such entity or entities as the case may be, should have be enclosed where Consortium been in the business at least for 3 years as on 31st partner is an entity. March 2020.
L e t t e r o f a s s o c i a t i o n f r o m consortium partner to be submitted along with the proposal. Letter of Association should clearly indicate The Prime Bidder (System Integrator) has the option of the roles and responsibilities of each 4 partnering with one entity as consortium partner. of the consortium members for this project along with estimated eforts that shall be put for this project and also their equity shareholding pattern.
Blacklisting
The Bidder and Consortium Member declared blacklisted/ineligible/debarred by any State/central Self-Declaration from the Bidder and Government or PSU or has been found to have been consortium member as per proforma 5 engaged in activities or practices which are corrupt, enclosed in the RFP from authorised fraudulent, Non-satisfactory work or any other unethical signatory. business practices, as on date of bid submission, shall not be eligible.
Financial Criteria
Page 141 of 223 SNo Particulars/ Parameters Documents to be submitted
The average minimum annual turnover per year should be at least Rs 25.0 Crs and proft making for the last The bidder and consortium member three years for Prime Bidder including Consortium should submit audited fnancial member. The revenues should have been accrued from statements and a certifcate of software development/software implementation (IT/ITES) 6 revenue composition for each of /system Integration and associated services. three years as per proforma by the auditor for FY 17-18, FY 18-19 and Associated services shall mean the services such as FY 19-20 Cloud Services/Operations and Maintenance of IT System/Training for IT applications.
Prior Experience
The Bidder should have prior experience in implementation of Online Ticketing Solutions with Contract Value of Single Project - 7.5 Crores Details of Experience of responding Two Projects - 5 Crores each frms/project citation for projects as 7 Three Projects - 4 Crore each which have gone live in per Proforma supported with Work the past fve years (FY 15-16, FY 16-17, FY 17-18, FY Order and Proof of Go-Live/Project 18-19 and FY 19-20). completion certifcates from client.
This may be met by any one of the consortium members.
8 Proof of Bid Document Purchase Declaration to be submitted
Confict of Interest
Bidder and consortium member shall furnish an afrmative statement as to the absence of, actual or potential The Bidder and consortium member shall not possess confict of interest on the part of the any confict of interest with the project that would 9 System Integrator or any prospective adversely impact the ability of the Bidder to complete sub-contractor due to prior, current, the requirements as given in the RFP o r p r o p o s e d c o n t r a c t s , engagements, or afliations with APSRTC.
Additional Criteria
As per Government of India (GoI), Ministry of Finance has issued the Public Procurement directive amending the General Financial Rules 2017 vide notifcation dated 23rd July 2020, All Organisations / Bidders / Companies with FDI from neighbouring countries need to be 10 registered with registration committee constituted by the As applicable. Department for Promotion of Industry and Internal Trade (DPIIT). The registration & clearance documents from GoI need to be attached / furnished mandatorily by these said Bidders as and when sought by APSRTC prior to start of tender evaluation process.
The Bidder (or Any bidder in case of a consortium) should have a valid minimum Copy of a Valid Certifcate which is 11 a. ISO 9001:2008 certifcate for software development or self-attested by the authorized b. CMMI Level 3 or higher as on last date of submission signatory. of the bid.
Page 142 of 223 2. Definitions:
1. Bidder: Bidder/Bidder shall be the SI. Bidder shall be responsible for discharging the responsibilities as per contractual obligations. Bidder shall submit the bid which is complete in all aspects. Payments will be released to the Bidder only.
2. Development Center in AP: The bidder should have a development center in AP or establish within 60 days from the date of award of contract.
3. Billing: The Bidder shall raise the bills from his office/development center in AP only.
3. Note: As per G.O. MS No 12 , dated 08.06.2016 , AP Procurement Policy for e-Governance 1. Bidders can submit their bids with self-declarations in respect of the pre-qualification criteria prescribed in the RFP 2. The procuring agency shall evaluate the bids based on the self-declaration and select the successful bidder 3. The successful bidder should submit the documents to prove their pre-qualification as specified in the RFP, within 5 working days from the date of declaration of successful bidder 4. APSRTC will receive support documentations, verify the compliance with the requirements of the RFP and if they are in order, issue the award notification 5. Failure to submit all support documents by the successful bidder within specified time or non- compliance with the self-declaration or non-fulfilment of the pre-qualification criteria specified in the RFP, upon their verification, shall entail forfeiting the EMD and Blacklisting of such bidder for a period of two years. In such cases, APSRTC may proceed further with the next-ranked bid. 6. However, Prime Bidder should submit the following support documents mandatorily as part of the bid response 7. Power of Attorney (PoA) or Board Resolution authorising the person signing the proposal to sign on behalf of the firm or Letter of Authorisation issued by Competent Authority of the bidder. 8. Self-declaration confirming the truth of the data or information furnished by the bidder. 9. The SI can engage other product vendors/OEMs/SMEs/Startups outside the Bidding participation to help them execute the solution with back to back agreements (maximum of 2 such entities will be allowed and should be referred in the proposal).Their experience will not be considered for pre- qualification and technical evaluation they will not be signatories of the contract or covered by the same. 10. In case if the bidder is not having office in any one of the 13 districts of Andhra Pradesh (AP), the prime bidder should furnish an undertaking that the same would be established within 60 days of signing the contract. 11. In case of prior projects referenced as part of the citations by the Prime bidder, executed and declared in foreign currency, the exchange rate as on the date of floating RFP would be considered for evaluation.
4. Pre-Qualification Documents
Page 143 of 223 1. The following documents shall be submitted as Pre-Qualification Compliance requirements as per format given in this document 2. P1 - Application form as prescribed in RFP. 3. P2 - Authorisation Letter for Bid Submission. 4. P3 - Bidder Information form (details of the Bidder) as prescribed. 5. P4 - Certificate of Incorporation under Indian Companies Act, 1956 for both bidder and Consortium member. 6. P5 - Self-declaration on blacklisting form as prescribed. 7. P6 - Pending Litigation form as prescribed. 8. P7 - Self-declaration on Conflict of Interest form as prescribed. 9. P8 - Financial strength details as prescribed. 10. P9 - Relevant general experience for form as prescribed. 11. P10 - Certifications of the Organisation. 12. P11 - Proof of Bid Document Purchase. 13. P12 - Proof of EMD Deposit. 14. P13 - Letter of Understanding and Commitment. 15. P14 - Additional Criteria on Public Procurement. 16. P15 - Details of Local Presence. 17. P16 - Copy of GST Certificate and TAN/TIN if available. 18. P17 - Copy of PAN. 19. P18 - MoU or Letter of Association between Bidder and Consortium Member. 20. P19 - Certifications ISO 9001:2008 or CMMi Level 3 or higher. 21. P20 - Other documents as may be deemed fit by the bidder for proving their eligibility
Page 144 of 223 5. Technical Qualifications
1. The Technical Bid will comprise of a cover letter, documents/Annexure as proof against technical evaluation criteria, details of Product & maintenance facilities, project staffing plan, undertaking (as given in RFP). Please note that no price information should be indicated in the Technical Bid and shall only be quoted in the Commercial Bid. Failure to comply with the same may result in the rejection of the Bid. In submitting additional information, please mark it as ‘Supplemental’ to the required response. If the bidder wishes to propose additional services (or enhanced levels of services) beyond the scope of this RFP, the proposal must include a description of such services as a separate attachment to the proposal. 2. APSRTC may seek clarifications from the Bidder on the technical proposal. Any clarifications by the bidder on the technical proposal should not have any commercial implications. 3. Demo, approach, methodology and work plan are key components of the technical proposal. Bidders shall present their technical proposal containing:
Max SNo Evaluation Criteria Score Past Experience and Proposed Relevant Implementation in Govt Sector (STUs in 10 I India) Implementation & Maintenance of Online Ticket Reservation system projects in State a Transport Units in India during last three years with relevant documents (Agreement / Contract / Work Order and Go-Live sign-off from customer). II Proposed Technical Solution Offered 10 a Proposed Technical Solution Offered, Approach and implementation methodology. III Project Management and Work Plan 10 a Project Management Framework IV Product Demonstration 70
a Online Ticketing Solution 8
b Operations Module Online Ticketing solution 8
c Dynamic / Flexi Fare System 5
d Multi-Level Fare structure system 5
e Mobile App based Driver / Conductor Booking 19
f Bus Pass issue Module 4
g Mobile App based VT & PIS 4
h Logistics Booking 5
i Integrations to accept Wallet, UPI, QR Code & Card based payments 3
j Mobile Number based e-wallet 3
k Special Bus Hire 6 Total (I+II+III+IV) 100
Page 145 of 223 1. Technical Demo: Demo as per the requirements matrix
2. Understanding of Project: This section shall contain a clear and concise understanding of project requirements along with activities to be performed and deliverables to be provided based on the scope of work.
3. Technical Approach and Methodology: In this part, bidders should explain their understanding of the objectives of the assignment, approach to the assignment, proposed solution, proposes technology methodologies for carrying out activities and obtaining the expected outputs, and the degree of detail of such output. Bidders should also explain the proposed methodologies and highlight the compatibility of those methodologies to the proposed approach and the needs of the project. Applicant shall also include the risk management, business continuity plan and quality assurance plans as a part of approach and methodology, Work methodology Work Plan: In this part the applicant should propose the main activities of the assignment, their content and duration, phasing and interrelations, meetings, milestones (including interim approvals by the client), and delivery dates of the reports/documents. The proposed work plan should be consistent with the technical approach and methodology, showing understanding of the scope of work and ability to translate them into a feasible working plan. A list of the final documents, including reports to be delivered as final output, should be included here. The work plan should be consistent with the work schedule, milestones, deliverables, meetings and presentations shall be clearly mentioned
4. Organisation and staffing: In this part the applicant should propose the structure and composition of team for the main disciplines of the assignment, the key expert/firm responsible, and proposed technical and support staff may be provided. In case of a consortium, applicant shall also explain the roles and responsibilities of the partner firms and the solution that they will implement and the arrangements made thereof, Capacity building: Bidder should submit a brief approach note on training of APSRTC staff during implementation and post-implementation. Bidder should provide hands on training before requesting for acceptance and completion of implementation. Training and manual details should be provided to all the users.
5. Approach for Project implementation: Detailed approach for carrying out the project implementation along with the support and maintenance during the contract. Bidders should submit a detailed approach for both first and second phase implementation. Bidders need to give detailed approach how they would implement complete project with integration plan.
6. Company profile: Details of the point of contact along with brief work profile of the prime bidder as well as other partner firms including relevant experiences of executing similar projects. Bidder may include relevant case studies and attested copies of completion certificates from clients in support of the case studies.
7. Innovation: If any, on the RFP to improve performance in carrying out the project. Innovativeness in terms of proposing the functional services that can be taken up by the APSRTC beyond what is already provided in the RFP shall be appreciated.
8. Other Information: Any other information relevant to the solution as preferred by the bidder can also be placed in the document.
Page 146 of 223 6. Technical Qualification Documents
1. The following documents shall be submitted as Technical-Qualification Compliance requirements as per format given in this document. 2. T1 : Letter of Technical Proposal. 3. T2 : Relevant proposed Product Experience in Government Sector (PSU). 4. T3 : Proposed Solution 5. T4 : Declaration for Bill of Material – Software, Hardware and others. 6. T5 : Project Management Framework, Approach and Methodology for the solution proposed, Work Plan and Resource Allocation. 7. T6: Go-Live & Operational Plan and Team Deployment Structure. 8. T7 : Data Migration/Extraction Strategy and Infrastructure Plan. 9. T8 : Take Over and Exit Management Plan 10. T9 : Help Desk, Support and Training Plan 11. T10 : Workflow with Screenshots for Online Ticketing Solution. 12. T11 : Workflow with Screenshots of Operation Module Management 13. T12 : Workflow with screenshots of Dynamic/Flexi fare System 14. T13 : Workflow with Screenshots of Multi-Level Fare Structure System 15. T14 : Workflow with Screenshots of Mobile App ticketing 16. T15 : Workflow with Screenshots of Bus Pass Module. 17. T16 : Workflow with Screenshots of VT&PIS Mobile app 18. T17 : Workflow with Screenshots of Logistics Booking 19. T18 : Workflow with Screenshots of Payment Modes and Integrations. 20. T19 : Workflow with Screenshots of eWallet. 21. T20 : Certificate on Average Tickets sold per day from all eligible projects. 22. T21 : DC Tier-III or above or its equivalent certification. 23. T22 : DR Tier-III or above or its equivalent certification.
Page 147 of 223 7. Commercial Proposal
1. Bidder must submit through e-procurement mode only, in absence of which the proposals will be rejected. 2. The following documents shall be submitted as Technical-Qualification Compliance requirements as per format given in this document.
i. C1 - Commercials Proposal Form ii. C2 - Summary of all components iii. C3 - Product & its related software’s Licenses Cost as per BoM proposed in Technical Qualification (for each module as per the SoW) iv. C4 - Software development cost (for each module as per the SoW). v. C5 - Data Migration/Extraction (for each module as per the SoW). vi. C6 - Training and Change Management Cost (for each module as per the SoW). vii. C7 - Proposed Infrastructure and other components for DC and DR (for each module as per the SoW). viii. C8 - Operations and Maintenance. (for each module as per the SoW). ix. C9 - Application Maintenance and Operational Expenses (for each module as per the SoW)
3. Bidder shall clearly mention unit rates and total amount for each component. Any discrepancy between words and figures noted against each item of the RFP and between unit rates and total amount, the decision of APSRTC will be final and binding on the proposals (in case of discrepancy, the amount in words will be considered as final). 4. Prices quoted by the Bidder shall be final (exclusive of all taxes). No variation in prices will be allowed under any circumstances during the entire period of project. No Conditional and open ended bid shall be evaluated and the same is liable for rejection. 5. The commercial proposal submitted by the bidder should be inclusive of all the items in the technical proposal and should incorporate all the clarifications provided by the bidder on the technical proposal during the evaluation of the technical proposal. 6. Prices shall be quoted in Indian Rupees (INR) only. 7. The bidder shall quote the price for all the components, the services of the solution to meet the requirements of ITS as listed in this RFP. 8. Bids with price adjustment shall be rejected. 9. The price quoted in the commercial proposal and finalised by the tender evaluation committee shall be the only payment, payable by APSRTC to the successful prime bidder for completion of the contractual obligations by the successful Bidder under the Contract, subject to the terms of payment specified as in the proposed commercial bid or the one agreed between APSRTC and the Prime Bidder. 10. The prices, once offered, must remain fixed and must not be subject to escalation for any reason whatsoever within the period of the validity of the proposal (i.e., during the sudsistence of the contract) for successful bidder. A proposal submitted with an adjustable price quotation or conditional proposal may be rejected as non-responsive. 11. Bidder should provide all prices, quantities as per the prescribed format given in this RFP. bidder should not leave any field blank. In case the field is not applicable, Bidder must indicate “0” (zero) in all such fields.
Page 148 of 223 12. It is mandatory to provide breakup of all taxes, duties and levies wherever applicable and/or payable. All the taxes of any nature whatsoever shall be borne by the Prime Bidder. 13. APSRTC reserves the right to ask the Bidder to submit proof of payment against any of the taxes, duties, levies indicated within specified time frames. 14. Price Commitment and Validity: As a part of the technical proposal, the Bidder will be asked to provide a complete Bill of Materials (along with the complete technical specifications for each of the individual items) for the procurement of the components required for APSRTC and for their maintenance as specified in this RFP. In the Commercial bid, the Prime Bidder will be asked to provide pricing for the same. VC&MD, APSRTC reserves the right to procure (by itself) the proposed components from the Prime Bidder at rates not exceeding the rates proposed by the Bidder as part of their Commercial Proposal.
9.26. Performance Bank Guarantee (PBG/BG)
1. The successful bidder should Deposit the Rs 2.00 Crs amount, towards PBG. The Earnest Money Deposit of Rs 25 Lakhs of the successful bidders will be converted as PBG. The balance PBG Rs 1.75 Crs shall be furnished in the form of a Bank Guarantee in favour of Financial Adviser & Chief Accounts Officer, APSRTC, Vijayawada, before entering into an Agreement. The Bank Guarantee should be valid throughout the contract period from the date of Agreement. Any delay in submission of PBG and entering into Agreement would result in forfeiture of EMD. The proforma of the Bank Guarantee should be as prescribed by APSRTC. The PBG shall not carry any interest. 2. In case the contract is extended on mutual consent, the Bank Guarantee shall have to be extended for further period as desired by APSRTC. In general BG has to be valid for a period of six months over and above the agreement/contract period. 3. The Performance Bank Guarantee shall have validity up to 73 months from the date of the agreement.
Page 149 of 223 10. Bid Opening and Evaluation Process
10.1. Bid Opening
APSRTC will open all the bids submitted online, in the presence of bidders’ representatives who choose to attend the Bid opening as per the RFP. Bid opening will be performed at three stages as per the dates specified in RFP data sheet
1. Pre-Qualification Bid 2. Technical Bid and 3. Commercial Bid
10.2. Bid Evaluation Process
1. Preliminary Scrutiny
The APSRTC will examine the bids to determine whether they are complete, whether any computational errors have been made, whether required sureties have been furnished, whether the documents have been properly signed, and whether the bids are generally in order.
The tenders that do not conform to the tender conditions and tenders from the firms without EMD, Bid document fee shall be straight away rejected.
Subsequent to the preliminary scrutiny and identification of qualified bidders, further evaluation of the bids will be done in three stages and at the end of every stage short listed bidders will be informed of the result to have a fair and healthy competition. The following is the procedure for evaluation.
2. Evaluation of Pre-Qualification Criteria
The evaluation committee will evaluate all pre-qualification bids to determine if they are responsive and meeting all the pre-qualification requirements of the RFP. APSRTC will prepare a list of firms based on the compliance to the pre-qualification criteria. The tenders that do not conform to the tender conditions and tenders from firms without adequate capabilities as per pre-qualification criteria of this RFP shall be straight away rejected. All eligible tenders will be considered for further evaluation. The decision of APSRTC will be final in this regard.
3. Evaluation of Technical Bids
The evaluation of the Technical bids will be carried out in the following manner:
i. The technical bid will be examined by an evaluation committee, based on the evaluation criteria and the points system specified in the RFP.
Page 150 of 223 ii. The bidders, who score an aggregate technical score of 75, will qualify for the evaluation of the commercial bid. iii. Non Compliance of any technical specification in the proposal from the RFP requirements, the proposal shall be summarily rejected.
4. Criteria for Technical Evaluation
The Evaluation Committee feels that the following parameters are critical for the success of the project and expects the bidders to provide accurate and precise information in their responses.
Technical proposal of the bidders will be opened and evaluated who meets all the pre-qualification criteria. The evaluation committee will evaluate the Technical Proposals on the basis of the technical evaluation criterion as provided below. The bidder has to follow the structure as per the Forms provided against each criterion. The bidder should attain a qualifying score of 75.
It may be noted that only Bidders who have been qualified in the Pre-Qualification stage, shall be intimated to demonstrate their Software solution including all functionalities through LIVE functionally working environment.
No PowerPoint presentations allowed for Technical Product Demonstration, as part of the Technical evaluation process. Bidders shall be given one-week time to prepare and come for the Technical demonstration to the selection committee.
5. Detailed Technical Evaluation Criteria
Max SNo Evaluation Criteria Point System Score Past Experience and Proposed Relevant Implementation in Govt Sector (STUs in 10 I India) Implementation & Maintenance of 1. 5 & above projects =10 points Online Ticket Reservation system 2. 4 projects = 7 Points projects in State Transport Units in 3. 3 projects = 5 points a India during last five years with 4. <3 projects = 0 points relevant documents (Agreement / Contract / Work Order and Go-Live sign-off from customer). II Proposed Technical Solution Offered, Approach and implementation methodology. 10 Proposed Solution 1. Understanding of the requirement = 1 Point 2. Solution architecture conceptualised for this project = 3 Point 3. Security architecture = 1 Point 4. Detailed plan for scalability & connectivity = 2 Point a 5. Application deployment and testing Strategy =2 Points 6. Proposed Approach for implementation = 1 Point 7. Integration approach with existing APSRTC system = 1 Points Page 151 of 223 Max SNo Evaluation Criteria Point System Score III Project Management and Work Plan 10 Project Management Framework 1. Project Management Framework – 1 Points 2. Go-Live and Operational Plan – 2 Points 3. Infrastructure Plan – 2 Points a 4. Take over and Exit Management - 2 Points 5. Training – Schedule, Training of Trainers, Manuals - 3 Points IV Product Demonstration 70 Online Ticketing Solution 1. Ticket Booking, Cancellation, Pre- postponement, Waiting List Tickets-1 Point 2. Book Multi-concession ticket in single transaction (e-Ticket, App, ATB Agents, RTC Counters) - 1 Point a 3. Open Ticket Booking and Validation - 2 Points 8 4. Instant / Automated refunds - 1 Point 5. Link Ticket - 2 Points 6. Track Ticket Status: By PNR, Status, OB Ref. No., or email, mobile no. - 1 Point
Operations Module Online Ticketing 1. Masters Configuration (Roles, Users, Bus Type, solution Concessions, crew, Concession by Role, Concession by User, Lock / Unlock the Sessions, MAC/PhoneID based authentication, Base Rate per Km/Stage, Layout master, Quota Seats by Layout, Route, Link Places) - 1 Point 2. Agent Online Topup, Percentage Based Commissions, User wise commission / incentives, Reward Points - 1 Point 3. Service Configuration (Depot, Category, Route, Schedules, Rest Hops, Authorisations are configurable in advance / advance planning) - 1 Points b 8 4. Service Cancellation, Bulk Refunds - Service Cancellation, Service Close-1 Point 5. Stock Management (Inventory, Issue Stock, Transfer, Skip, Reports) - 1 Point 6. Block / Release Seats, Reservation Chart, Waybill, Invalidate, Track Ticket, Refunds, Lock Ticket, Transfer Seats - 1 Point 7. Multiple trips service configuration - 1 Point 8. News Module, Value Added Services such as - Accommodation Tickets, TTD Dharshan Integration, Alerts (Journey Reminder, Delayed Service Alerts, Refunds, etc), Disable Booking - 1 Point Dynamic / Flexi Fare System 1. Date Wise, Seat Wise Fare increase / decrease by Percent / Fixed - 2 Points 2. Flexi Fare by Route, Bus Type, Service - 2 c 5 Points 3. Fare Increase / decrease based on Occupancy, Adv. Reserve days - 1 Points
Page 152 of 223 Max SNo Evaluation Criteria Point System Score Multi Level Fare structure system 1. Fare definition by per Kms / Stages, Bus Type, Route, Peak / Slack Fare Roster - 2 Points d 2. Seat Wise fare rounding - 1 Point 5 3. Global, User Wise, Bus Type wise Commissions - 2 Points Mobile App based Driver / 1. Login, List assigned duty details (trips) - 1 Point Conductor Booking 2. Boarding Point wise passenger details (waybill info.) - 1 Point 3. Issue Adult / Child only tickets - 1 Point 4. Bus Pass Validation through QR Code - 1 Point 5. Board Passengers by PNR, Name, Mobile No, QR Code, PIN - 1 Point 6. Concession Ticket - 2 Points 7. Issue Tickets Online / Offline, Real-time sync of e Ground Booking Tickets with Driver - 2 Points 19 8. Trip/Duty Collection Summary - 1 Point 9. Cancel Trip/Route Change - 1 Point 10. Trip/Duty Start/End - 1 Point 11. Luggage Tickets - 1 Point 12. Ticket Checking Inspector Module - 2 Points 13. Bus Breakdown/Transfer Seats Module - 2 Points 14. Advance Ticket Booking for Other Buses - 2 Points Bus Pass issue Module 1. Issue of ID cum Ticket – 1 Point 2. Issue of ID and Ticket separately – 1 Point f 4 3. Configuration of Concessions – 1 Point 4. Stock Management – 1 Point Mobile App based VT & PIS 1. Mobile App based ETA - 1 Point 2. Track by Service Number – 1 Point g 4 3. Track by Vehicle Number – 1 Point 4. Time Table – 1 Point Cargo and Courier Booking 1. Configure the fare er KM rate of parcel based on L8W*H/ Weight of Parcel - 1 Point 2. Parcel Booking, Parcel Cancellation, Parcel Delivery and Tracking, Alerts to customers - 1 h Point 5 3. Parcel Loading and Unloading module for every luggage at transhipment points - 1 Point 4. Multiple Transhipment Points and Parcel Tracking - 2 Points Integrations to accept Wallet, UPI, 1. e-Wallet payments - 1 Point i QR Code & Card based payments 2. UPI/QR Code Based Payments - 1 Point 3 3. Cash/Card Payments - 1 Point Mobile Number based e-wallet 1. Register e-Wallet with mobile no. - 1 Point j 2. Add Cash/Transaction history - 1 Point 3 3. Transfer to Friend - 1 Point
Page 153 of 223 Max SNo Evaluation Criteria Point System Score Special Hire Booking 1. Configuration Module - Per KM fare, Bus Type, Depot wise inventory, Levies, Inter State fare etc. - 1 Point 2. Provide list of buses of nearest available depot based on search information - 2 Points 3. Final fare calculation shall be based on the route points selected by the passenger. The KMs shall be calculated dynamically using open maps/ k Google maps or equivalent Systems. Total fare 6 with security amount should be collected during booking - 2 Points 4. On trip completion, final invoice calculation based on final KMs reading, trip hours etc should be calculated. Final invoice should be sent to passenger and difference of security amount should be automatically refunded - 1 Point Total (I+II+III+IV) 100
Note:
1. SI shall provide work order/testimonial/project completion certificate from the client for all the stated project experience. 2. The value of the projects considered in the above criterion would be based on the Purchase Order or the LoI issued to the responding firm. In absence of the supporting documents, the projects would not be considered for evaluation.
6. Technical Presentation
Bidder has to make presentations and demo at APSRTC premises to facilitate the procurement committee in understanding the bidder’s capabilities to execute the project. The date for presentation will be communicated in advance. Bidders are expected to communicate the requirements (if any) for conducting this exercise 2 days in advance to APSRTC. Bidder shall ensure that the representative carries a valid photo ID and authorisation letter from the bidder. The presentations should cover cases of installations of the software in an environment similar to APSRTC requirements. The objective of the presentation is to: i. Understand software solution’s features in greater detail ii. Approach and Methodology iii. Project plan iv. Technical solution proposed in the technical bid v. Innovative services proposed in the technical proposal vi. Other important components of the proposal
Page 154 of 223 10.3. Commercial Bid Opening and Bid Evaluation
1. Bid Opening
Commercial bids will be opened and compared after the technical evaluation has been completed for those bidders who are technically qualified with the 75 qualifying marks.
2. Announcement of Bids
The commercial bids will be opened, in the online/ presence of bidders or their representatives who choose to attend the commercial bid opening on the date and time to be communicated to all the technically qualified bidders. In the event of the specified date of bid opening being declared a holiday for APSRTC, the bids shall be opened at the appointed time and location on the next working day.
The Bidders/Bidder’s representatives present at the commercial bid opening shall sign a register evidencing their attendance.
3. Clarification of Bids
To assist in the evaluation, comparison and an examination of bids, APSRTC may, at its sole discretion, ask the bidder for a clarification of its bid including breakdown of unit rates. The request for clarification and the response shall be in writing. If the response to the clarification is not received before the expiration of deadline prescribed in the request, APSRTC reserves the right to make its own reasonable assumptions at the total risk and cost of the bidder.
4. Evaluation of Commercial Bids
4.1. Change in the Quantities
The Contracting authority reserves it right to alter the scope (increase quantity / remove certain items) up to approximate (±10 %) units.
4.2. Commercial Evaluation Process
The Commercial Bids of the Bidders who qualify in the First Stage will only be evaluated as per the Evaluation Criteria mentioned below:
1. The prices should be all exclusive of taxes but inclusive of all Out-of-Pocket Expenses (OPEs.) 2. All expenses related to travel, boarding, lodging, etc., would be inclusive and no separate claims on any account would be entertained. 3. The cost of the necessary commute or any other expenses incurred during the project execution for requirements gathering, UAT and any other work, will be the sole responsibility of the System Integrator and should be accounted while submitting a quote for this proposal 4. The total value of the price bid shall be arrived based on the total value quoted by the bidder for Capital expenditure and Operational expenditure Page 155 of 223 5. The Commercial Bids of the Bidders who qualify in the Technical Stage will be evaluated as per the Evaluation Criteria mentioned below: 6. Government of Andhra Pradesh is proposed to build a new State Data Centre(SDC) for all departments IT infrastructure needs. ITE&C department has given mandate to all departments to migrate all existing and proposed applications to SDC. 7. Subject to priority and allocation of IT Infrastructure at SDC, the SI is requested to submit the quotes for separately for UTS platform a. With IT infrastructure b. Without IT infrastructure. 8. Keeping in view of GoAP proposal, C2 form is designed to submit bid details as C2(a) and C2(b). 9. All the bids will be compared on the basis of reverse auction and as per format given commercial forms 10. Arithmetical Errors in Commercial Proposals - If there is a discrepancy between the unit price and the total price that is obtained by multiplying the unit price and quantity, the unit price shall prevail and the total price shall be corrected. If there is a discrepancy between the rates in words and figures, the rate in words will govern. If the bidder does not accept the correction of errors, the bid will be rejected and EMD may be forfeited. Bidder is advised to exercise adequate care in quoting the prices. No excuse for corrections in the quoted figures will be entertained after the commercial proposals are received by APSRTC.
4.3. Total Bid Valuation
The Commercial Bids of the Bidders who qualify in the Technical Stage will be evaluated as per the Evaluation Criteria mentioned below: 1. Bidder who qualify during the Technical Stage shall be considered for commercial evaluation. 2. For convenience of reverse auction, a quote shall be given for 100 net chargeable transactions with IT Infrastructure and without IT Infrastructure. a. Form C2 (a) with IT Infrastructure = Single net Transaction rate in ps (F1) b. Form C2 (b) without IT Infrastructure-= Single net Transaction rate in ps (F2) c. Quote for 100 transactions with IT Infrastructure = F1*100 = G1 in paise d. Quote for 100 transactions without IT Infrastructure = F2*100 = G2 in paise 3. Unit of quote shall be in paise only and SI has to submit quotes G1 and G2. Illustration as follows: a. If F1 is 5 ps and F2 is 3 ps as per commercial forms C2 (a) and C2(b), then i. Form C2 (a) with IT Infrastructure, F = Rs 0.05 ps (INR) ii. Form C2 (a) with IT Infrastructure, F1 - F*100 = 5 ps (In paise) iii. Form C2 (a) with IT Infrastructure, G1 - F1*100 = 500 ps (In paise) iv. Form C2 (b) without IT Infrastructure, F = Rs 0.03 ps (INR) v. Form C2 (b) without IT Infrastructure, F2 - F*100 = 3 ps (In paise) vi. Form C2 (b) with IT Infrastructure, G2 - F2*100 = 300 ps (In paise) b. Quote for 100 transactions with IT Infrastructure = F1*100 = G1 in paise = 500 ps c. Quote for 100 transactions without IT Infrastructure = F2*100 = G2 in paise = 300 ps d. Decremental value is 10 paise. e. Reverse auction will only be conducted on either G1 or G2 only.
Page 156 of 223 4. During the reverse auction, quote shall be revised and decremented only on G1/G2 (i.e., on 100 net chargeable transactions). 5. Minimum decremental value during reverse auction is fixed as ten paise (10 ps) from the quote fixed by APSRTC. 6. Lowest bidder (L1) post reverse auction amongst the technically qualified bidder shall be awarded the contract.
4.4. Notification of Award:
Prior to the expiration of the bid validity period, APSRTC will notify the successful bidder in writing or by fax or email, to be confirmed in writing by letter, that its proposal has been accepted. The notification of award will constitute the formation of the contract. Upon the successful bidder's furnishing of performance bank guarantee, APSRTC will promptly notify each unsuccessful bidder and return their bid security.
10.4 Delivery Schedule
The Prime bidder shall sign the contract with the VC&MD, APSRTC GoAP covering all the required services. Milestones and their timelines for each item are as follows:
SNo Milestone Timeline I Planning and Inception Phase 10 Days from issue of a Signing of the Master Services Agreement with Prime Bidder LoI of Award =T0
b Detailed Project Plan T0 + 7 Days
c Comprehensive Project Risk Management Plan T0 + 7 Days II Design Phase
a Existing System Study & Submission of Blue Print Documents T0 + 15 Days
b Functional Requirements Document T0 + 15 Days
c Data Extraction and Data Migration Strategy Document T0 + 15 Days
d Application Integration Strategy Document T0 + 15 Days
e Quality Assurance Plan T0 + 15 Days III Solution Architecture Phase
a Submission of Solution Architecture Documents T0 + 25 Days Solution Design Document for all applications, modules and b T + 25 Days sub-modules 0
c Technical Design Document T0 + 25 Days IV Implementation Phase 3rd Party Integration with APSRTC Systems and Payment a T + 40 Days Gateway 0
Page 157 of 223 b Development, Testing and Performance Testing T0 + 40 Days
c Deployment T0 + 40 Days V Change Management & Capacity Building
a Submission of Change Management Plan T0 + 45 Days
b Training Manuals, and Completion of User Training T0 + 45 Days VI Deployment Phase Start of Pilot Rollout at two depots for OPRS, AFCS and ePOS a T + 45 Days app and eWallet (2 depots) 0
b Deployment of Help Desk and CCS T0 + 75 Days
c Deployment of SLA Monitoring Tool T0 + 75 Days Start of Rollout at one depot each at 12 regions of APSRTC for d OPRS, AFCS, Driver App, Conductor / agent Ground Booking T0 + 75 Days App, eWallet (12 depots) Start of Rollout at three additional depots each at 12 regions of e APSRTC for OPRS, AFCS, Driver App, Conductor / agent T0 + 105 Days Ground Booking App, eWallet (48 depots) Start of Rollout at six additional depots each at 12 regions of f APSRTC for OPRS, AFCS, Driver App, Conductor / agent T0 + 135 Days Ground Booking App, eWallet (120 depots) Declaration of Go-Live for OPRS, AFCS, Agent Ground g T + 180 Days = D Booking app 0 1
e Declaration of Go-Live for Vehicle Tracking (AVLS & PIS) T0 + 210 Days
f Declaration of Go-Live for Bus Pass Module T0 + 240 Days Declaration of Go-Live for Courier & Cargo and Courier g T + 270 Days Booking 0
h Analytics T0 + 300 Days VII Operations & Maintenance
a Operations & Maintenance T0 + 75 Days VIII Exit Management Exit Management, Knowledge Transfer and Acceptance by the a D + 60 Months Department 1
b Transfer of the assets at “0” value in working condition D1 + 64 Months
Page 158 of 223 11. Bid Submission Forms and Undertakings
11.1. Forms for Submission of Pre-Qualification
P1: Application Form
(Company Letterhead) (On the Letterhead of the Bidder)
Date: [●]
To,
The VC&MD, APSRTC,, RTC House 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001
Re: Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Digital Solutions for Ticketing and other Allied activities under BOOT model in APSRTC, Government of Andhra Pradesh.
Dear Sir,
We, the Undersigned apply to be pre-qualified for the above referred project and declare the following: 1. We have examined and have no reservations to the RFP Document.
Having examined the Bidding Documents, we, the undersigned, offer to provide the services specified as per the RFP for the sum (here in after called total bid price) as quoted in commercial bid or such other sums as may be determined in accordance with the terms and conditions of the contract. We undertake, if our bid is accepted, to commence work as per the schedule and to achieve the effectiveness of the contract within the respective timelines stated in the Bidding Documents.
2. Construction of the Contract
a. We have read the provisions of bid and confirm that these are acceptable to us. b. We further declare that bid is unconditional. c. We undertake, if our bid is accepted, to commence the work as per the schedule immediately upon your Notification of Award to us, and to achieve Completion within the time stated in the Bidding Documents.
Page 159 of 223 d. If our bid is accepted, we undertake to provide an Implementation cum Performance Security in the form and amounts, and within the timelines specified in the Bidding Documents. e. We undertake that, in competing for (and, if the award is made to us, in executing) the above contract, we will strictly observe the laws against fraud and corruption in force in India. f. We, hereby, declare that only the persons or firms interested in this proposal as principals are named here and that no other persons or firms other than those mentioned herein have any interest in this proposal or in the Contract to be entered into, that this proposal is made without any connection with any other person, firm or party likewise submitting a proposal, that this proposal is in all respects in good faith, without collusion or fraud g. We agree to abide by this bid, which consists of this letter, EMD with technical bid, commercial bid, Pre bid meeting addendum if any and other attachments (specify the attachments) as per the bid document.
3. We or suppliers for any part of the contract(s) resulting from this pre-qualification, do not have any conflict of interest in accordance with Data sheet 4. We are entity (Public/Private/Government)
We understand that you may cancel the pre-qualification process at any time and that you are not bound either to accept any application that you may receive or to invite the pre-qualified bidders to bid for the contract(s) subject of this pre-qualification, without incurring any liability to the Bidders, in accordance with Data Sheet.
Thanking you,
Sincerely,
[Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date
Attachment: Board Resolution/Authorisation form from the competent authority for bid submission.
Page 160 of 223 P2: Authorisation Letter
Page 161 of 223 P3: Details of the Bidder
SNo Description Details to be flled by the Bidder
1 Name of the Organisation
Nature of the Organisation 2 Government/Public/Private/Partnership/Proprietorship
Year of Establishment (Enclose any of the following for proof of establishment) 3 a. Certifcate of Incorporation b. Audited Balance Sheets c. Registered Partnership deed if any Registered Ofce Postal Address with Phone & Fax 4 Number
Ofce Postal Address with Phone & Fax in Andhra 5 Pradesh
Contact person with Phone, Mobile Number & email 6 Address
7 GST Registration Number and TAN/TIN if available
8 Valid CMMi Level 3/5 Certifcation
9 Valid ISO 27001/9001 Certifcation
10 Additional Certifcation/Awards (if Any)
11 List of supporting documents attached for this form
Thanking you,
Sincerely,
[Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date
Attachments: As per the RFP
Page 162 of 223 P4: Certificate of Incorporation
Page 163 of 223 P5: Format for Self-Declaration on Blacklisting
(on Company Letterhead) Date
To The VC&MD, APSRTC, RTC House 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001
Sir,
In response to the RFP No.______dated______for quoting against the RFP as an Director of M/s << Proposer>> , I / We hereby declare that our Company / Firm ______is having unblemished past record and was not declared blacklisted or ineligible to participate for Proposal Submission as on date of submission of the Proposal by any State/Central Govt. or PSU due to, breach of general or specific instructions, corrupt /fraudulent , Non Performance or any other unethical business practices.
Yours faithfully,
Authorized Signatory______Name______Designation______Company name______
Page 164 of 223 P6: Pending Litigation
(Each Bidder and associated OEMs must fill in this form on their company letter head)
Applicant Legal Name...... No pending litigation
Pending litigation is indicated below Value of Value of Matter in Year Pending Claim Pending Claim Dispute in INR as a % of Net
Date: …………………………………………………………………….. Name………………………………………………………….………..… In the capacity of…………………………………………………………. Signed……………………………………………………………………. Duly authorised to sign the application for and on behalf of……………. Stamp/ Seal………………………………………………………………
Page 165 of 223 P7: Self-Declaration/Self- Certification (Conflict of Interest)
(Company Letterhead)
Date To, The VC&MD, APSRTC, RTC House 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001
Sub: Undertaking on Conflict of Interest
Sir,
I/We as SI do hereby undertake that there is absence of, actual or potential conflict of interest on the part of the SI or any prospective OEM due to prior, current, or proposed contracts, engagements, or affiliations with the Contracting Authority.
I/We also confirm that there are no potential elements (time frame for service delivery, resource, financial or other) that would adversely impact the ability of the SI to complete the requirements as given in the RFP.
We undertake and agree to indemnify and hold the Contracting Authority harmless against all claims, losses, damages, costs, expenses, proceeding fees of legal advisors (on a reimbursement basis) and fees of other professionals incurred (in the case of legal fees & fee of professionals, reasonably) by the Contracting Authority and/or its representatives, if any such conflict arises later.
Yours faithfully,
Name………………………………………………………….………..… In the capacity of…………………………………………………………. Signed……………………………………………………………………. Stamp/ Seal………………………………………………………………
Page 166 of 223 P8: Financial Strength Details:
Financial Information Item/Year FY 17-18 FY 18-19 FY 19-20
Revenue (in INR Crs)
Proft Before Tac (in INR Crs)
Proft After Tax (in INR Crs)
Net Worth
Other Relevant Information
Mandatory Supporting Documents Auditor Certifed Financial Statements for the Last Five Financial Years
Note: Bidder must quote supporting document name, Section and page no. while referring all the financial details entered in this form. While entering net profit they must quote the Annual Report for the year (as supporting document name), Section and Page no. for quick reference during evaluation. Attested copies of Audited financial statements/Certificate from Chartered Accountant for last 3 financial years in support of the above shall be submitted.
Note: The bidder shall provide details in the above table and attach supporting documents.
Page 167 of 223 P9: Project Experience Information Sheet
(Must obtain from the STUs)
Date Name of the Bidder Tender Ref Number:
1. Name of the Organisation 2. Name of the contact Person 3. Telephone Numbers, Fax numbers, Postal Address, email Address & Website Project Deployment Details of the proposer
SNo Item Details
1 Client Name and Address (Including Country and Continent)
Clients Authorised Representative Information (Name, 2 Address, Telephone Numbers, Fax Numbers, email Address, Website)
3 Name of the project deployed
4 Scope of Work
5 Date of frst deployment
6 Contract Tenure
5 Project Value
6 Project Status as on bid calling date
7 List of supporting documents attached for this form
Thanking you,
Sincerely, [Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date
Page 168 of 223 P10: Certification of the Organisations
Page 169 of 223 P11: Proof of Bid Document Fee/Purchase
Page 170 of 223 P12: Proof of EMD Deposit
Page 171 of 223 P13: Letter of Understanding and Commitment
Format of the Letter of Commitment (Company Letterhead) Date: [●] To, The VC&MD, APSRTC, RTC House 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001
Re: Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Unified Digital Solutions for Ticketing and other Allied activities under BOOT model in APSRTC, Government of Andhra Pradesh.
Sir,
This has reference to the Proposal being submitted by______(name of the bidder) in respect project______.
We hereby acknowledge and confirm the following:
We, ______(name of the bidder), have examined in detail and have understood and satisfied ourselves regarding the requirements of the Project, including in respect of the following: 1. The Request for Proposal issued by the APSRTC; and 2. All subsequent written communications issued by the APSRTC to the Bidders.
I declare that all the provisions of this RFP/Tender Document are acceptable to my company and we agree to work in compliance with APSRTC guidelines wherever they are binding and applicable. I further certify that I am an authorized signatory of my company and I am, therefore, competent to make this declaration.
Thanking you,
Sincerely,
[Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date
Page 172 of 223 P14: Additional Criteria on Public Procurement
Page 173 of 223 P15: Details of Local Presence
Date:
This is to certify that ______(Company name) having its local office at ______(Address) has the following centre(s) in the State of Andhra Pradesh.
Name and Location of Contact Person Details Number of Projects Indian Client List Delivery Centre Handled (Mention a few)
Name and location of the Address Number of Employees Organisation
Name………………………………………………………….………..… In the capacity of…………………………………………………………. Signed……………………………………………………………………. Stamp/ Seal………………………………………………………………
Note: In case, the bidder does not have local presence in AP at the time of bidding, a self-declaration has to be provided by the bidder that they will establish a project office in AP within two (2) months from the issue of LOI if they are awarded the project.
Page 174 of 223 P16: Copy of GST Certificate and TAN/TIN if available
Page 175 of 223 P17: Copy of PAN
Page 176 of 223 P18: MoU or Letter of Association between Bidder and Consortium Member
Page 177 of 223 P19: Certifications ISO 9001:2008 or CMMi Level 3 or higher.
Page 178 of 223 P20: Any other Documents
Page 179 of 223 11.2 Technical Forms Evaluation Format
T1:Letter of Technical Proposal (Company Letter head) Date: [●]
To,
The VC&MD, APSRTC, RTC House 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001
Subject: Submission of the Project Plan for the functional scope specified in the RFP dated [ ]
Dear Sir,
We, the undersigned, offer to provide the following services in accordance with the RFP/Bidding.
Procure, Design, Develop, Integrate, Maintain and Enhance Application & Services on Smart Ticketing Solutions for Vijayawada and Visakhapatnam Cities proposed by APSRTC, Government of Andhra Pradesh. We are hereby submitting our Project Plan in this regard.
Project Plan Covers: i.High level understanding of functional requirement in this RFP. ii.Gantt Chart for Deliverables and Milestones iii.Resource Management.
Thanking you,
Sincerely,
[Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date
Enclosed: Project Plan Note Page 180 of 223 T2: Relevant Proposed Product Experience in Government Sector (PSU)
Project/Assignment Name:
Project Location within the Country:
Name of Funding Agency/Client:
Start Date:
Completion Date:
Approximate Value of Services
Name of the Associated Firm(s), if Any
Name of Senior Staf involved and functions performed:
Detailed Narrative Description of Project
Detailed Description of Actual Services provided by your Company
Note: Work Order and Completion certificates shall be provided. Non-compliance to this shall lead to non- evaluation of the projects.
Page 181 of 223 T3: Proposed Solution:
The bidder should provide detailed description for all the parameters mentioned below provided in this form
1. Understanding of the project (how the solution proposed is relevant to the understanding) 2. Solution architecture conceptualised for this project. Meeting the business requirements 3. Security architecture 4. Application deployment and testing Strategy 5. Quality Control suggested by responding firm 6. Integration architecture with other APSRTC Systems 7. Strategy for infrastructure deployment at data center to be proposed to meet SLA (Separate installation for Development / Test / Production) 8. Proposed Infrastructure Deployment at DC and DR. As entire hardware need not be deployed at one time. Bidder should propose rollout strategy as part of the solution.
Bidder also has to provide the following information as per the solution provided in the technical bid
Proposed Solution Version & Whether the solution is (Provide the Product Name or Features & SNo Year of OEM in compliance with RFP fll Custom built, in case of Functionalities Release Requirements new Development)
1. (*) Provide the Product Name or fill Custom Built, in case of a new development (It is possible that the SI has not suggested the solution as the list is indicative only. In case any of the items is not provided, the SI may indicate N/A in the corresponding cells.) 2. Please indicate N/A where not applicable. Please indicate N/L where there is no license requirement. 3. All the system software licenses shall be procured by the bidder. The system software licenses mentioned in the Bill of Materials shall be genuine, perpetual, full use and should provide patches, fixes, security updates directly from the OEM at no additional cost to APSRTC for the entire period of contract. 4. All the licenses shall be owned by the SI
Page 182 of 223 T4: Declaration for Bill of Material
Bidder must submit the detailed bill of material for various components of the solution. Bill of material should include at least the following details; Item Name, Type, Technical Specifications, Model Name, OEM and Data sheet. Technical Compliance Statement for each item procured under the project as per details given in Bill of Quantity and Technical Specifications given in this RFP.
The Infrastructure would be owned and provided by SI and shall Install, Commission, Configure, Test, Integrate, Manage and Support the application and off the shelf software as per the time frame stipulated by the given in the subsequent section(s) that meets or exceeds the requirements/guidelines stipulated in this RFP.
To ensure the SI to implement the application, the SI shall give the breakup of the essential/critical BOM to be made available as per the timelines.
IT Infrastructure:
SNo Description Development Phase Go-Live and O&M
Hardware
1 Application Servers
2 Operating Systems
3 DataBase Servers
4 Testing Servers
5 Unstructured/Bid Data Processing Servers
6 Load Balancers (Quantity in Number)
7 Storage (Quantity in TB)
8 Any Other equipment
Software
9 DateBase (No of Cores)
Development Tool Kits for Design, Deployment 10 (Quantity in Number)
11 Security Tool Kits (Quantity in Number)
12 EMS (Quantity in Number of Licenses)
13 SSL (Quantity in Number of Licenses)
14 Any Other
Page 183 of 223 Application Softwares, Hardware and others components, tools , etc., :
SNo Name of The Software/Product/Component Version Purpose Open Source (YES/NO)
Bidders shall furnish the complete BoM for software, hardware, and other components, tools, etc., even if the components, tools used are open source. It is expected that, the SI shall procure necessary technical support (including open source components) from OEMs/services providers for support & assistance, trouble shooting, upgradations etc.,
Bidders shall furnish the required information on their technical and commercial proposals in the enclosed formats only. Any deviations in format may make the tender liable for rejection. Do not, otherwise, edit the formats and proposal cover letters.
Page 184 of 223 T5: Project Management Framework, Proposed Approach and Methodology for the solution proposed.
The bidder should provide detailed description for all the parameters mentioned below provided in this form The proposal should clearly and concisely define the project management framework that shall be followed by the bidder. The framework should contain at least but not limited to the following:
1. The Project Organisation & Quality Management Strategy 2. Communication Management Strategy 3. Configuration Management Strategy 4. Risk Management Strategy - Highlight the associated risks/problems and plans for mitigation and explain the technical approach it would adopt to address them 5. Adherence to the proposed timelines Activities, Sequencing and dependencies among activities 6. Project requirement assessment, System integration and Customisation requirements, testing, deployment, warranty and maintenance, facilities management 7. SLA management methodology, SLA monitoring console for APSRTC 8. Highlight the associated risks/problems and plans for mitigation and explain the technical approach it would adopt to address them 9. Methodology for Integration with other APSRTC modules 10. Planning and Building Infrastructure (assessment, design, integration/migration of existing Portal infrastructure) 11. DC-DR hosting detailed architecture of h/w, s/w including virtualisation, scaling mechanism, BCP, security and network access
Page 185 of 223 T6: Work Plan and Resource allocation
The bidder should provide detailed description for all the parameters mentioned below provided in this form. Apart from the detailed Project Plan proposed by the Bidder, the following to be provided which would be evaluated in the following parameters:
1. Go-live and Operational Plan 2. Infrastructure Deployment plan 3. O & M Plan 4. APSRTC Integration Plan
The Bidder need to provide the activity schedule as per the table given below
Calendar Months SNo Activity 1 2 3 4 5 6 7 8 9 10 n
1
2
3
N
1. Indicate all main events/milestones/ activities of the assignment, including delivery (e.g: inception, interim and final), and other benchmarks. For phased assignments indicate activities, delivery of reports and benchmarks separately for each phase. 2. Duration of activities shall be indicated in the form of a bar chart.
Team Composition
SNo Name of the Staff Qualification Experience Past Relevant Position Task Experience Assigned Assigned
Team Deployment Structure
Designation Staf input (in the form of a bar chart) Total Staf Month Input SNo Name of the Staf 1 2 3 4 5 6 7 n Ofsite Onsite Total
Page 186 of 223 T7: Data Migration/Extraction and Infrastructure Plan
The bidder should provide detailed description for all the parameters mentioned below provided in this form
1. Planning and Assessment of Data Migration Requirements 2. Proposed approach and Methodology for Data Migration 3. Proposed Data Migration Strategy 4. Infrastructure sizing plan
Page 187 of 223 T8: Takeover and Exit Management
The bidder should provide detailed description for all the parameters mentioned below provided in this form
1. Comprehensiveness & completeness of the Plan for takeover 2. Comprehensiveness & completeness of the Plan for exit management
Page 188 of 223 T9: Help Desk, Support and Training Plan
The bidder should provide detailed description for all the parameters mentioned below provided in this form. 1. Proposed Training Schedule 2. Plan to develop Training Manuals 3. Training of Trainers, proposed training methodology, online help modules proposed 4. Refresher and retraining methodology 5. Plan for Number & Quality of personnel to be deployed for training
Proposed Formation/Location of Helpdesk & Other manpower Support:
1. Proposed methodology of formation of the manpower support team, Operating and Maintaining Application and Helpdesk: 2. Methodology for Helpdesk Management
Page 189 of 223 T10: Workflow with Screenshots for Online Ticketing Solution
Page 190 of 223 T11: Workflow with Screenshots of Operation Module Management
Page 191 of 223 T12: Workflow with screenshots of Dynamic/Flexi fare System
Page 192 of 223 T13: Workflow with Screenshots of Multi-Level Fare Structure System
Page 193 of 223 T14: Workflow with Screenshots of Mobile App ticketing
Page 194 of 223 T15: Workflow with Screenshots of Bus Pass Module.
Page 195 of 223 T16: Workflow with Screenshots of AVLS & PIS Mobile app.
Page 196 of 223 T17: Workflow with Screenshots of Logistics Booking
Page 197 of 223 T18: Workflow with Screenshots of Payment Modes and Integrations.
Page 198 of 223 T19: Workflow with Screenshots of eWallet.
Page 199 of 223 T20: Certificate on Average Tickets sold per day from all eligible projects.
The bidder should provide the details in this form
SNo Name of the Scope of Work Contracting Period of Status of the Average Seats Project Authority Contract Project sold per Day
Page 200 of 223 T21: DC Tier-III or above or its equivalent certification.
Page 201 of 223 T22: DR Tier-III or above or its equivalent certification.
Page 202 of 223 11.3 Commercial Submission Forms
C1: Financial Proposal Submission Form
Location Date
To The VC&MD, APSRTC, RTC House 1st Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001
Dear Sirs:
We, the undersigned, offer to provide the System Integration Services for development and implementation of the Smart Ticket Solutions for APSRTC in accordance with your Request for Proposal dated <<>>> and our Technical Proposal.
Our attached Financial Proposal is detailed in Form C2 (a) and C2 (b) are final and is exclusive of all taxes, duties, levies as may be applicable. We confirm that, all expenses and charges related to administrative expenses, bid preparation expenses, overhead costs, margins, and other out-of-pocket & incidental expenses are included as applicable in the forms C3 to C8.
Our Financial Proposal shall be binding upon us until the expiration of the validity period of the Proposal.
We understand you are not bound to accept any Proposal you receive.
Yours sincerely, Authorized Signature {In full and initials}: Name and Title of Signatory Address: Email:
Page 203 of 223 C2 (a) Product and its summary of components with IT infrastructure
OPRS AFCS+e PAAS AVLS PIS CCC CCMS Mobile POS Apps & SNo Description Other Services
I Services provided during Implementation Phase (CAPEX)
Product and its 1 related software (C3) Software 2 Development Cost (C4) Data Migration/ 3 Extraction (C5) Capacity Building 4 and Change Management (C6) Total CAPEX Cost (A)
II Services Provided during Post Implementation Phase (OPEX)
Proposed 5 Infrastructure for DC & DR (C7) Operations & 6 Maintenance (C8) Total OPEX Cost (B) Total CAPEX+OPEX III Cost (C=A+B) for 5 Years Average Number IV of Transactions per 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 Day (D) Average Transaction Cost per net seat V (E=C/(1826*D)) 6A 6B 6C 6D 6E 6F 6G 6H in INR upto 4 decimals in Ps Average Transaction Cost per net seat (F) VI in INR upto 4 F= 6A+6B+6C+6D+6E+6F+6G+6H decimals in Ps F1 = F*100 (in paise upto 4 decimals) G1 = F1*100 (in paise upto 2 decimals)
Page 204 of 223 C2 (b) Product and its summary of components (without Infrastructure)
OPRS AFCS+e PAAS AVLS PIS CCC CCMS Mobile POS Apps & SNo Description Other Services
I Services provided during Implementation Phase (CAPEX)
Product and its 1 related software (C3) Software 2 Development Cost (C4) Data Migration/ 3 Extraction (C5) Capacity Building 4 and Change Management (C6) Total CAPEX Cost (A)
II Services Provided during Post Implementation Phase (OPEX)
Operations & 5 Maintenance (C8) Total OPEX Cost (B) Total CAPEX+OPEX III Cost (C=A+B) for 5 Years Average Number IV of Transactions per 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 36,57,476 Day (D) Average Transaction Cost per net seat V (E=C/(1826*D)) 6A 6B 6C 6D 6E 6F 6G 6H in INR upto 4 decimals in Ps Average Transaction Cost per net seat (F) VI in INR upto 4 F= 6A+6B+6C+6D+6E+6F+6G+6H decimals in Ps
F2 = F*100 (in paise upto 4 decimals) G2 = F1*100 (in paise upto 2 decimals)
Page 205 of 223 C3 Product & its related Software
Total Base Total Quantity Rate Taxes SNo Description UOM Price Amount (A) (B) (D) (C=A*B) (C+D)
One time License fee for number of One users as specifed in RFP Time Note: License a.The price will be inclusive of all Products and 3rd party bolt-on software license and related costs, costs of database, integration tools, source code and other requisite software tools. b. This price will also include the 1 cost of multiple instances to be maintained both during and after implementation such as Development, Testing, Training, Production. c. Please provide copy of the proposed licensing policy d. Please give price breakup of all components of solution such as Product, 3rd party associated integration tools, database etc.,
Customisation and Confguration of proposed product which involves various activities as mentioned in 2 the scope of Work (which includes the provision of man power as mentioned in the RFP during implementation phase)
Integration and Functional Cost
Man Man Months Total Base Total Month Taxes Activity Propose Price Amount Rate (D) d (C=A*B) (C+D) (B) (A)
Development of Web Services for 1 integration with applications of APSRTC
Total amount in words:
Note: Form C3 shall be filled module wise as per Section 5 (Scope) and Grand Total shall be calculated. Grand Total from Form C3 should go to Form C2 SNO 1
Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address:
Page 206 of 223 C4 Proposed Software Development Cost
SNo Description Man Months Rate Card Cost for Development
A OPRS
1 Resource Type A (Business Analyst)
2 Resource Type B (Developer)
3 etc.,
B AFCS+Android ePOS
1 Resource Type A (Business Analyst)
2 Resource Type B (Developer)
3 etc.,
C PAAS
1 Resource Type A (Business Analyst)
2 etc.,
D AVLS
1 Resource Type A (Business Analyst)
2 etc.,
E PIS
1 Resource Type A (Business Analyst)
2 etc.,
F CCC
1 Resource Type A (Business Analyst)
2 etc.,
G CCMS
1 Resource Type A (Business Analyst)
2 etc.,
H Mobile Apps & Others
1 Resource Type A (Business Analyst)
2 etc.,
Total amount in words:
Note: Form C4 shall be filled module wise as per Section 5 (Scope) for DC & DR separately and Grand Total shall be calculated. Grand Total from Form C4 should go to Form C2 SNO 2. Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address:
Page 207 of 223 C5 Data Migration/Extraction
SNo Item Cost
1 Data Migration/Extraction
Total
Total amount in words:
Note: Form C5 shall be filled module wise as per Section 5 (Scope) and Grand Total shall be calculated. Grand Total from Form C5 should go to Form C2 SNO 3.
Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address
Page 208 of 223 C6 Capacity Building and Change Management
Approx No of Cost per SNo Training Modules Target Audiences Taxes Total Cost Trainees Trainee
1
2
3
n
Total
Total amount in words:
Total from Form C6 should goto Form C2 SNo4
Note: It is assumed that the APSRTC would arrange 4 training centers (Vijayawada, Vizianagaram, Kurnool, and Nellore) to accommodate 30-40 people at a time. The SI should arrange for the systems, connectivity, necessary trainers, training materials of required numbers. APSRTC will arrange other requirements like Projector, PA system, generator. TA/DA to the participants and the venue charges including the refreshments would be provided by APSRTC
The training need analysis of all key stakeholders has to be done and then training plan will have to be developed in line with overall project plan. Location for trainings will be Vijayawada, Vizianagaram, Kurnool, and Nellore. Given below are the high level requirements of Training Plan.
Note: 1. The size of each batch should not be more than 40. 2. It will be department wise training and training manuals need to be provided for each department. 3. Coverage of training of each department will not be the same
Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address
Page 209 of 223 C7 Proposed Infrastructure (Hardware) for DC and DR
SNo Equipment Total Quantity (A)
Hardware
Application Servers
Operating Systems
DataBase Servers
Testing Servers
Unstructured/Bid Data Processing Servers
Load Balancers (Quantity in Number)
Storage (Quantity in TB)
Any Other equipment
Software
DateBase (No of Cores)
Development Tool Kits for Design, Deployment (Quantity in Number)
Security Tool Kits (Quantity in Number)
EMS (Quantity in Number of Licenses)
SSL (Quantity in Number of Licenses)
Any Other
Total amount in words:
Note: Form C7 shall be filled module wise as per Section 5 (Scope) for DC & DR separately and Grand Total shall be calculated. Grand Total from Form C7 should go to Form C2 SNO 5.
Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address:
Page 210 of 223 C8 Operations & Maintenance
Application Maintenance & Operational Expense including upgradation, deployment of patches, fixes after Go-Live
SNo Year Cost per Year (A) Taxes (B) Grand Total (C= A+B)
P Application Maintenance
1 Year 2
2 Year 3
3 Year 4
4 Year 5
Grand Total for P
Total P amount in words:
SNo Year Type of Resource as per Man Number of Total Taxes Grand the Details mentioned Month Months Proposed (E=C*D) (F) Total (C ) (D) (G=F+E)
Q Operation Support
Year 2
Year 3
Year 4
Year 5
Grand Total for Q
Total Q amount in words:
Total (P+Q) amount in words:
Note: Form C7 shall be filled module wise as per Section 5 (Scope) and Grand Total shall be calculated. Grand Total from Form C7 (P+Q) should go to Form C2 SNo 6
Note: Year 1 isn’t mentioned as it is the implementation period for Go-Live. For item Q, please mention details separately for each type of resource. Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address
Page 211 of 223 C9 Additional Manpower Cost
SNo Designated Role/Title Man Month Cost Taxes Total
1 Project Manager
2 Business Analyst
3 Data Scientist
4 IT Infrastructure Manager
5 Database Administrator
6 Network Support Staf
7 Big Data Administrator
8 Change Management Lead
9 Technical Support Staf
Note: The APSRTC may require the services of any or all resources mentioned above for any additional scope of work and would use the above rates for the scope extension.
Authorized Signature {In full and initials}: Name and Title of Signatory Address: email Address
Page 212 of 223 12. Compliance Requirements:
Pre-Qualification Compliance:
Compliance SNo Particulars/ Parameters Yes/No
1 Certifcate of Incorporation of the Prime Bidder
Certifcate of Incorporation (for Companies) or copy of Partnership Deed (for 2 Partnership)
3 Letter of association from Consortium Partner
4 Self-Declaration on Black Listing from the Prime and each consortium partner
Self-Declaration (An afrmative statement) on actual or potential Confict of Interest 5 on the part of the SI or any prospective subcontractor due to prior, current, or proposed contracts, engagements, or afliations with APSRTC.
Prime Bidders Audited fnancial statements and a certifcate of revenue 6 composition for each of the 3 years as per form by the auditor for FY 17-18, FY 18-19, FY 19-20 for Annual Turn Over.
Prime Bidders Audited fnancial statements and a certifcate of revenue 7 composition for each of the 3 years as per form by the auditor for, FY 17-18, FY 18-19, FY 19-20 for Positive Net Worth
Audited Financial Statements for the consortium partners for FY 17-18, FY 18-19, 8 FY 19-20.
Prior Experience in implementation of proposed solution in India which have gone 9 live in the past fve Years (FY 15-16, FY 16-17, FY 17-18, FY 18-19, FY 19-20)
Copy of CMMi Level 3/5 or ISO 9001: 2008 certifcation which is valid as on date of 10 submission.
Receipt of the Bid Purchased from APSRTC. The Prime Bidder has to purchase the 11 tender document from APSRTC.
Page 213 of 223 Technical Compliance:
Evaluation Criteria SNo Compliance Yes/No I Past Experience and Technical Expertise
a Proposed Product Implementation
b Proposed Product implementation specific to Government Sector
c Certifications by the Firm
II Technical Solution Offered
a Proposed Solution
b Proposed Approach and Implementation methodology for the solution proposed
III Project Management and Work Plan
a Project Management Framework
b Take over and Exit Management
c Work Plan including WBS
d Training
e Proposed Infrastructure
IV Proposed Team
a Manpower Deployment Plan
b Technical Presentation
Page 214 of 223 13. Additional Information: Average Transactions in FY 2018-19 and 2019-20
Sno City/Mofussil AC/Non-AC Product Name Average Transactions/Day 1 Mofussil AC Amaravati 1,969 2 Mofussil AC Garuda 1,867 3 Mofussil AC Garuda Plus 182 4 Mofussil AC Indra 3,875 5 Mofussil AC Metro Luxury 1,003 6 Mofussil AC Night Rider 42 79 7 Mofussil AC Night Rider 48 99 8 Mofussil AC Vennela 245 9 Mofussil Non-AC Deluxe 3,533 10 Mofussil Non-AC Express 5,97,396 11 Mofussil Non-AC Ghat Service 2,188 12 Mofussil Non-AC Pallevelugu 23,72,260 13 Mofussil Non-AC Super Luxury 88,190 14 Mofussil Non-AC Ultra Deluxe 94,718 15 Mofussil Non-AC Ultra Pallevelugu 15,237 16 City Non-AC City Ordinary 3,34,208 17 City Non-AC Metro Express 1,11,425 18 Logistics 20,000 19 Bus Passes 9,000 Total 36,57,476
Page 215 of 223 14. Additional Information: Average Transactions during Nov’20 to Jan’21
Sno City/Mofussil AC/Non-AC Product Name Average Transactions/Day 1 Mofussil AC Amaravati 818 2 Mofussil AC Dolphin Cruise 337 3 Mofussil AC Garuda 594 4 Mofussil AC Garuda Plus 2 5 Mofussil AC Indra 3,693 6 Mofussil AC Metro Luxury 363 7 Mofussil AC Night Rider 42 163 8 Mofussil AC Night Rider 48 134 9 Mofussil AC Vennela 926 10 Mofussil Non-AC Deluxe 995 11 Mofussil Non-AC Express 4,31,416 12 Mofussil Non-AC Pallevelugu 9,81,573 13 Mofussil Non-AC Super Luxury 76,981 14 Mofussil Non-AC Ultra Deluxe 67,389 15 Mofussil Non-AC Ultra Pallevelugu 1,33,305 16 City Non-AC City Ordinary 1,12,909 17 City Non-AC Metro Express 41,498 18 Logistics 18,000 19 Bus Passes 3,500 Total 18,75,593
Page 216 of 223 15. Sample Dashboards with actionable insights Sample dashboards are prepared with proddutur (PDTR) depot ticket data for illustration purpose only. a. Top 20 stages for Boarding and Alighting of passengers
b. Average number of passengers travelling per day in PDTR buses
Page 217 of 223 c. Top 20 stages pattern - weekday pattern
d. Top 20 Stages in the month of Dec’19 - Date wise
Page 218 of 223 e. Top 20 Stages Hour wise Stacked Representation
f. Top 20 Stages - Hour wise
Page 219 of 223 16. Hardware Specifications:
Proposed Android ePOS/eTIM:
SNo Item Description Minimum Specifications 1 Processor Application Processor Quad Core 1.2Ghz 1GB RAM + 8GB Flash 2 Memory Internal 1 SD Slot - Min 8 GB 3 OS Operating System Android 8 with security system 4 SIM Dual SIM 5 SAM 2 SAM Magnetic ISO 1/2/3 6 Card Readers Smart Card EMV Level 1 Contactless EMV Level 1& 2 Compliant 7 Display Colour 5.0” IPS 1280*720 pixels 8 Touchscreen Capacitive Finger & Stylus Random or fixed virtual keypad 9 Keypad for PIN entry Video support 1080p video 10 Multimedia 1 Speaker Audio 1 Headphone Jack 1 Microphone 5 MP Autofocus camera, with flash Rear camera 0.3 MP 11 Data capture Front camera GPS/GLONASS/BeiDou Positioning Inbuilt OCR Application. Speed Printing Speed 50mm/sec 12 Thermal Printer Paper roll cage 58mm width LifeSpan Work Life 50 KM WAN 4G CAT4/3G/2G 13 Terminal LAN IEEE 802.1 WiFi 1b/g/n Connectivity Bluetooth 4.1(BQB certified) 14 Terminal Connections USB Micro-USB OTG 15 Battery Li-ion/ Li-Polymer 5200 mAh. Width <= 90 mm 16 Terminal Size Width and Thickness Thickness <= 65 mm 17 Weight in grams < 500 gms. Operating Temperature(DC unplugged) -10ºC to +45ºC (14ºF to 113ºF) 18 Environment Operating Temperature (DC Plugged) 0ºC to +40ºC (32ºF to 104ºF) Storage Temperature -20ºC to +70ºC (-4ºF to 158ºF) 19 Accessories Docking Station Adapter with Output 5 V, 2A 20 Security Certified PCI PTS 5.x Online & Offline
Page 220 of 223 Proposed Mobile Phone Specifications:
SNo Feature Specifications 1 Make Oppo, Realme, Samsung, Vivo, Xiaomi 2 Processor 1.5GHz Octacore Processor or Higher 3 RAM 3GB or above 4 Storage 32GB or above 5 SIM Dual SIM Network Should support all frequencies of GSM as listed by TRAI/WPC supporting 6 Technology 4G/5G Networks 7 Display Minimum 5.5” 8 Operating System Android 10.0 or Higher 9 Resolution 1280*720 Pixels 10 Front Camera 5MP or above 11 Rear Camera 8MP or above 12 Universal Port Micro USB or Type C 13 Bluetooth v4.1 or Higher 14 Wi-Fi 802.11 b/g/n 15 Battery Capacity 4000mAh or above. 300 Life Cycles or above 16 Headset 3.5 mm 17 Water Proof Splash Proof. 18 Warranty 1 Year with walk in Support and replacement within 48 Hrs. SAR (Specific Below 1.6 w/kg 19 Absorption Rate) 20 SD Card Provision Yes. Exclusive provision. Battery Charger * Standard Battery Charger along with other required accessories for the 21 Other accessories offered model to be supplied. if any The products should be in compliance with Meity Regulations and BIS Note: 1 standards as applicable. 2 Better or Higher Specifications are also accepted. Enterprise Mobility Management Software will be preloaded by Mobile device vendor/OEM level before delivery of the device to APSRTC. Enterprise Mobility Management server and client software shall be 3 supplied by device vendor. Procurement of Android ePOS or eTIM or Mobile Phone is out of scope of this RFP.
Page 221 of 223 Proposed LED Display Panel Specifications
SNo Description Feature Specifications 1 Pixel Pitch 3.0 mm 2 Pixel Density 111,111 dots/m2 3 Configuration 1R1G1B 4 Resolution 64*64=4096 Dots 5 Size (W*H*D) 192*192*14mm or any suitable size panels 6 Net Weight 0.296Kg+0.05Kg Module 7 Structure LEDs and ICs in the same PCB 8 Plastic Kit Polycarbonate Material 9 Input Voltage(DC) 4.5+0.1V 10 Maximum Current 4.3+0.1A 11 Power Consumption <= 20 Watts 12 Driving Method Constant Current 1/32 Scan 13 Cabinet Dimensions 610*382*77.5mm 14 Pixel Density 192*192=36864 15 Square Meters 0.2324 m2 16 Cabinet Weight 9.3Kg+0.05Kg Die-cast Cabinet 17 Max Power Consumption 174 Watts Average Power 58 Watts 18 Consumption Distribution Power (78% 223 Watts 19 Power efficiency) 20 Brightness >=600 cd/m2 21 Viewing angle - Horizontal 140+10 degree 22 Viewing angle - Vertical 130+10 degree 23 Display Screen Best Viewing Distance >=1.5 M 24 Black spot Ratio < 0.0003 25 Max Power Consumption <=5525 Watts/M2 26 Operation Environment Indoor 27 Control Systems Gray Scale 14-16 bits & other Specs 28 Display Colour 4398 Billion 29 Frame Frequency >=60 frames/sec 30 Refresh Frequency >=3840 Hz 31 Control Mode Computer Controlled, Point by Point
Page 222 of 223 SNo Description Feature Specifications 32 Brightness Adjustment 256 grade manual/automatic 33 Life Span >=100,000 hrs 34 Average Failure Free Time >=10,000 hrs
35 Attenuation (3 years later) <=150 36 Operation Temperature 0 Deg to 40 Deg C 37 Operating Humidity 10% - 90% RH Input Signals DVI/VGA, Video (Multiple formats), RGBHV, Composite Video 38 signal, S-Video, Ypbpr(HDTV)
Page 223 of 223