Pakistan International Airlines INVITATION FOR THE IMPLEMENTATION OF ENTERPRISE RESOURCE PLANNING (ERP) & MAINTENANCE REPAIR OVERHAUL (MRO) SOLUTION Section B Instructions to Contractors (ITC) Page 1
INVITATION TO BID FOR ERP IMPLEMENTATION (TERMS OF REFERENCE) 1. Introduction Pakistan International Airlines Corporation (PIA) has initiated a project to implement an Enterprise Resource Planning (ERP) solution in order to achieve greater operational efficiencies and facilitate the realization of growth targets. As a first phase, the areas of Finance; Human Resources and Administration; and Procurement and Inventory Control are being targeted. PIA now invites firms with experience of implementing ERP solutions in large public sector organizations and/or in the Airlines industry to bid for the following: 1. Provision of licenses for an ERP Package and Add-ons 2. Supply and Installation of Appropriate Hardware and Review of Infrastructure Environment 3. ERP Implementation, Training and Rollout 4. Post Implementation Warranty and Support 2. Request for Proposal A detailed Request for Proposal document is attached setting out the following: Section A - Project Detail Section B - Instructions To Contractors Section C - PIA s IT Environment Section D - Product Requirements (ERP Package & Add-ons) Section E - Product Requirements (Others) Section F - Services Requirements Section G - Hardware Requirements Section H - Requirements Compliance Matrix Section I - Completion and Compliance Checklist Section J - Criteria for Technical and Commercial Evaluation 3. Bidding Process Being a public sector corporation PIA complies with the Public Procurement Rules 2004 and the guidelines of the Public Procurement Regulatory Authority. The process being followed for selecting a vendor is Single-stage Two-envelope bidding, which requires technical and commercial proposals to be submitted in two separate sealed envelopes. Bidders are advised to carefully review, in particular, Instructions (Subsection B1) of Instructions to Contractors (Section B) and ensure that their bids comply with all stated conditions. Section B Instructions to Contractors (ITC) Page 2
4. Significant Dates From RFP Issuance to Contract Signing RFP Issuance September 02, 2013 Submission of Queries October 02, 2013 Pre-bid Meeting September 17, 2013 Written Responses to Queries October 02, 2013 Submission of Proposals October 02, 2013 till 1030 Hrs. Opening of Technical Bids October 02, 2013 at 1100 Hrs. Submission of Technical Evaluation Report Opening of Commercial Bids Announcement of Technical and Commercial Evaluation Results To be intimated Submission of Draft Contract Finalization of Contract Contract Signing with Successful Bidder Contract Timelines and Payment Terms This is a high priority project for PIA which is being monitored directly by the Board of Directors. Accordingly, an ambitious time schedule would be set targeting project completion within 18 months of contract signing. This period is inclusive of two months for post go-live support. While recognizing that each ERP vendor will have their own methodology PIA has developed the following schedule as a baseline against which the schedules proposed by each bidder will be measured, significant weightage being given to adhering as closely to the baseline dates as possible (albeit following the vendor s own methodology). The schedule also indicates the payment terms which PIA intends to follow, this being linked to achievements of specific project milestones: Section B Instructions to Contractors (ITC) Page 3
Major Project Milestones Signing of Contract (against performance guarantee) Associated ERP Implementation ERP Licenses Hardware Project Services Deliverables 1 Target Payment Target Payment Target Payment Date % 2 Date % 2 Date % 2 1, 2, 3 10 10 10 Installation of Interim Servers 6 - Delivery and Installation of SW (ERP Package and Add-ons Hardware Delivery (Production and DR Sites) Issuance of Certificate Upon Successful HW Installation Business Requirements Gathering and Analysis 7 80 8 30 9 30 To be decided To be decided To be decided 10, 11, 12 10 Build and Conduct UAT 13, 16, 17, 18, 19 20 End-User Training and Readiness 14, 15, 20, 21, 26 20 Project Go-Live 22, 23, 24 20 Completion of Post Go-live Support 25 10 30 20 Recurrent Costs Bidder to Specify Bidder to Specify Bidder to Specify Notes: 1. Successful completion of the project deliverables listed in Section 6 would mark the achievement of the project milestones 2. Although the payment schedule for each of the project components, that is, ERP Licenses, Hardware and ERP Implementation Services is separately mentioned, there is a high degree of interdependencies among them. If the Contractor is unable to achieve the target ERP Implementation deadlines this would not only impact the payment schedule for that particular component of the Contract but for others (ERP Licenses, Hardware) as well. To elaborate the point, timely delivery and installation of the required hardware, but without the ERP Implementation deadlines being achieved would require PIA to withhold scheduled payments against hardware as well. Section B Instructions to Contractors (ITC) Page 4
5. Suggested Project Deliverables The successful bidder will be required to provide deliverables during the course of this project, some of which are as follows: 1. Draft Contract 2. Final Contract 3. Project Charter Document including Detailed Project Plan 4. Fortnightly Progress Report 5. Status of Project Issues List. This should be updated weekly during the project duration. 6. Interim Servers, Operating Servers and Related Tools 7. ERP Software (Media) Installation 8. Installation of Hardware at Production and Disaster Recovery Sites 9. Certificate upon Successful Installation of Hardware 10. Requirements Specifications Document 11. Gap Analysis Document 12. Templates for Data Collection 13. Solutions Design Document 14. End-User Training Manuals and Exercise Guides based on the Configured Solution 15. Training Plan for ERP Overview, Configured ERP Application and for End-Users. The endusers training plan should be role-based 16. UAT Plan 17. Scenarios-based Test Scripts for User Acceptance Testing 18. Development/Provision of Standard and Customized Reports 19. Roles and Responsibility Matrix 20. Master Implementation / Rollout Plan 21. IT Infrastructure Readiness Report and Certification 22. Fully Configured ERP solution 23. Go-Live Certificate 24. Detailed Plan for Post-implementation Support 25. Project Completion Report and Certificate 26. Application Users or Operations Manuals This list may not necessarily be comprehensive or exhaustive. Hence, bidders are free to suggest additional deliverables, if necessary. 6. Pre-bid Meeting A pre-bid meeting will be scheduled at 11 a.m. on September 17, 2013 to respond to queries of interested bidders. General Manager Procurement Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport Karachi Email: gmptnl@piac.aero 7. Other Instructions 1. For any further query, bidders may contact GM Procurement & Logistics at gmptnl@piac.aero Section B Instructions to Contractors (ITC) Page 5
2. Bids must be delivered to the aforementioned address. All bids must be accompanied by a bid bond (included in the Commercial Proposal envelope) for 2 percent of the total bid price (in shape of Pay Order. 3. Successful bidder shall be required to furnish a Performance Guarantee which shall be 10% of the contract amount 4. Successful bidder shall be required to sign the Integrity Pact (format attached in RFP document) 5. Late bids will be rejected. Bids will be opened in the presence of the representatives of bidders who choose to attend. 6. Bid must be valid for at least 90 days (extendable) from the date of submission. Section B Instructions to Contractors (ITC) Page 6
Pakistan International Airlines (PIA), Pakistan s national flag carrier, plans to implement a proven, timetested, internationally acclaimed and airline specific Enterprise Resource Planning (ERP) and Maintenance Repair Overhaul (MRO) solution catering to its requirements in the following areas: 1 Enterprise Resource Planning (ERP) Existing scope of work includes the following ERP Modules. Finance & Controlling and Revenue Management Human Resources Procurement and Logistics Any other sub module as to meet the PIA s RFP requirement e.g.: 1. Work flow 2. Employee Self service 3. Document management system 4. Revenue Accounting 2 Maintenance Repair Overhaul (MRO) Implementation Engineering and Quality Assurance Aircraft- Line and Base Maintenance Engine Overhaul, Components Overhaul, Avionics Overhaul and Landing Gear Overhaul Aircraft Material Management including Rotable Control Check & Schedule Planning Repair Abroad Cost Allocation and Performance Monitoring Procurement and Inventory Control Cabin Maintenance Tenders would be called on Single Stage Two Envelope basis from ERP & MRO related companies or their authorized / certified representatives or partners or a consortium of such companies for the provision and implementation of an ERP & MRO as one bundle solution and on separate basis. A pre-bid meeting will be convened on September 17, 2013 at 1100 Hrs. in the Conference Room of P&L Department. Prospective bidders who wish to attend the pre-bid meeting are requested to send their nominations at contract.administration@piac.aero Bidders are required to submit a Pay Order of Rs. 10,000.00 (or its US$ equivalent) drawn on Pakistan International Airlines along with Technical Proposal as tender fee. Bidders are also required to submit 2% of total bid value as Earnest Money in shape of Pay Order along with Financial Proposal. Proposals must reach at address given below on / before October 03, 2013 till 10:30 Hrs (PST). Technical proposals will be opened on same date at 11:00 Hrs (PST). Bidders are required to submit two copies of Technical bid, marked as Original and Copy. PIA reserves the right to reject any or all bids, or decide not to implement the ERP solution with assigned reason(s) thereof. Bids received after date & time stipulated, shall not be considered. For any query, please feel free to contact: General Manager (Procurement & Logistics) Ph: +92-21-9904 5135, 9904 5549 Fax: +92-21-99040120 Email: gmptnl@piac.aero, contract.administration@piac.aero Section B Instructions to Contractors (ITC) Page 7
Request for Proposal For Enterprise Resource Planning Solution September 2013 Section B Instructions to Contractors (ITC) Page 8
TABLE OF CONTENTS SECTION A PROJECT DETAILS... A1 PIA BACKGROUND... A2 PROJECT BACKGROUND... 13 A3 PROJECT ORGANIZATION... 18 A4 PROJECT PHASES... 18 SECTION B INSTRUCTIONS TO CONTRACTORS (ITC)... 21 B1 INSTRUCTIONS... 22 B2 SUMMARY OF REQUIREMENTS... 35 B3 TEMPLATE FORMS... 36 B4 FORMAT AND CONTENTS OF PROPOSAL... 56 SECTION C PIA IT ENVIRONMENT... 62 C1 IT DEPARTMENT... 63 C2 EXISTING SYSTEMS... 64 C3 EXISTING IT INFRASTRUCTURE... 138 SECTION D PRODUCT REQUIREMENTS (ERP PACKAGE & ADD-ONS)... 143 D1 ERP PACKAGE AND ADD-ON REQUIREMENTS... 144 D2 INFORMATION NEEDS AND APPLICATION REQUIREMENTS... 155 SECTION E PRODUCT REQUIREMENTS (OTHERS)... 190 E1 RDBMS AND DATABASE ADMINISTRATION TOOLS... 191 E2 APPLICATION DEVELOPMENT TOOLS... 193 E3 QUERY AND REPORT GENERATOR TOOLS... 194 E4 INTERIM SERVERS... 195 E5 3 RD PARTY SOFTWARE... 196 SECTION F SERVICES REQUIREMENTS... 197 F1 IMPLEMENTATION... 198 F2 TRAINING... 202 F3 DATA MIGRATION... 205 F4 DOCUMENTATION... 206 F5 WARRANTY AND MAINTENANCE SUPPORT... 208 F6 VERSION AND UPGRADES... 210 SECTION G HARDWARE REQUIREMENTS... 211 G1 HARDWARE... 212 SECTION H REQUIREMENTS COMPLIANCE MATRIX... 214 H1 GLOBAL REQUIREMENTS GENERAL... 215 H2 GLOBAL REQUIREMENTS TECHNICAL... 223 H3 GLOBAL REQUIREMENTS OTHERS... 229 H4 FUNCTIONAL REQUIREMENTS FINANCE... 233 H5 FUNCTIONAL REQUIREMENTS HUMAN RESOURCES AND ADMINISTRATION... 247 H6 FUNCTIONAL REQUIREMENTS PROCUREMENT AND INVENTORY CONTROL... 258 H7 SERVICES REQUIREMENTS... 267 H8 HARDWARE REQUIREMENTS... 274 SECTION I COMPLETION AND COMPLIANCE CHECKLIST... Error! Bookmark not defined. I1 I2 I3 I4 PROPOSAL COMPLETION CHECKLIST... Error! Bookmark not defined. PRODUCTS AND SERVICES... Error! Bookmark not defined. BUSINESS INFORMATION AND APPLICATION NEEDS... Error! Bookmark not defined. ERP PACKAGE REQUIREMENTS... Error! Bookmark not defined. SECTION J CRITERIA FOR TECHNICAL AND COMMERCIAL EVALUATIONError! Bookmark not defined. Section B Instructions to Contractors (ITC) Page 9
Section B Instructions to Contractors (ITC) Page 10 SECTION A PROJECT DETAILS
A1 PIA BACKGROUND Pakistan International Airlines (PIA) came into existence in March 1955, when a privately owned company, Orient Airways, merged with the Government of Pakistan to form the state-owned airline. PIA has been an air travel pioneer since its inception. In 1962, PIA set out to break the record for the fastest flight between London and Karachi. With representatives of FAI (Federation Aeronautics International) on board to monitor the official timings, PIA completed the flight in 6 hours, 43 minutes, 51 seconds, a record which remains unbroken to this day. Section B Instructions to Contractors (ITC) Page 11
PIA Vision PIA's vision is to be a world class airline exceeding customer expectations through dedicated employees, committed to excellence. PIA Mission Employee teams will contribute towards making PIA a global airline of choice: Offering quality customer services and innovative products Participating in global alliances Using state-of-the-art technologies Ensuring cost-effective measures in procurement and operations Customer Expectations Service Innovation Cohesiveness Integrity Reliability Safety PIA Values Convenience, Caring, and Competitive Tariff Personalized and Courteous Cherishing New Ideas, Translated Into Action Respect for Individuals, Teamwork, and Effective Communication Business Ethics, Accountability, and Transparency Loyalty and Consistency Passengers, Employees, Environment, and Health Information Technology (IT) Objectives Keeping in line with the organization s vision and mission, the Information Technology department at PIA has formulated the following objectives: To implement industry standard systems / solutions which are integrated, adaptive and flexible to both internal and external challenges and evolve as technology progresses and must be capable to meet airline industry challenges. To carefully plan and deploy resources to ensure continuity of Information Technology services and its availability on 24x7 hours basis. To ensure that Information Technology is effectively applied to business needs. To provide technology tools to PIA staff for capturing and harnessing the knowledge base with the latest in IT, for timely management decision support. A high-level functional organization chart of PIA IT Department is provided in Section C. Section B Instructions to Contractors (ITC) Page 12
A2 PROJECT BACKGROUND PIA s management is of the view that new scenarios and changing business requirements necessitate a reassessment of business operations and a major upgrade of the information technology environment. In order to achieve greater operational efficiencies and facilitate the realization of growth targets, PIA has decided to implement a comprehensive Enterprise Resource Planning (ERP) solution. PIA intends to procure the best combination of technology products and services at the most reasonable cost. PIA desires to adopt a phased implementation approach. The areas of Finance; Human Resources and Administration; and Procurement and Inventory Control have been assigned initial priority. With rapid implementation methodologies and accelerated deployment options available in all good ERPs, it is PIA s intention to complete the implementation, training and rollout in minimum time period. The Contractor must recommend a suitable rapid implementation approach to help ensure project success within the proposed timeline. Since time is of essence, the proposed timeline will be fixed and strictly adhered to. The locations intended to be covered under the scope of the ERP Solution implementation are as follows: - PIA Head Office at Karachi PIA Computer Center at Karachi PIA Offices (International and Domestic all locations) PIA Stores, Hangars and Workshops (all locations) Section B Instructions to Contractors (ITC) Page 13
Locations: The table below lists domestic airports where PIA flies to: SR. NO. LOCATION 1. BAHAWALPUR 2. CHITRAL 3. DADU 4. DALBANDIN 5. DERA GHAZI KHAN 6. FAISALABAD 7. GILGIT 8. GWADAR 9. ISLAMABAD 10. JACOBABAD 11. KANDAWARI 12. KARACHI 13. LAHORE 14. MOENJODARO 15. MULTAN 16. PANJGUR 17. PASNI 18. PESHAWAR 19. QUETTA 20. RAHIM YAR KHAN 21. SAIDU SHARIF 22. SIALKOT 23. SKARDU 24. SEHMAN 25. SUKKUR 26. TURBAT Please note that this is an indicative list that may change with time. Section B Instructions to Contractors (ITC) Page 14
The table below lists international airports where PIA flies to: SR. NO. COUNTRY NUMBER OF AIRPORTS 1. AFGHANISTAN 1 2. BAHRAIN 1 3. BANGLADESH 1 4. CANADA 1 5. CHINA 1 6. DENMARK 1 7. FRANCE 1 8. GERMANY 1 9. GREECE 1 10. HONG KONG 1 11. INDIA 2 12. ITALY 2 13. JAPAN 1 14. JORDAN 1 15. KUWAIT 1 16. MALAYSIA 1 17. NEPAL 1 18. NETHERLANDS 1 19. NORWAY 1 20. OMAN 1 21. PHILIPPINES 1 22. QATAR 1 23. RUSSIAN FEDERATION 1 24. SAUDI ARABIA 4 25. SINGAPORE 1 26. SPAIN 1 27. SRI LANKA 1 28. THAILAND 1 29. TURKEY 1 30. UNITED ARAB EMIRATES 4 31. UNITED KINGDOM 5 32. UNITED STATES OF AMERICA 2 33. UZBEKISTAN 3 Please note that this is an indicative list that may change with time. Section B Instructions to Contractors (ITC) Page 15
The table below lists stores maintained by PIA: SR. NO. STOCK ROOM STOCK TYPE TECHNICAL / COMMERCIAL STATION ONLINE / OFFLINE 1. SR-A1 Component Technical Karachi Online 2. SR-B2 Consumable Technical Karachi Online 3. SR-09 Tires Technical Karachi Offline 4. SR-45 Engine Parts Technical Karachi Online 5. SR-14 Avionics Parts Technical Karachi Online 6. SR-26 Rubberized Technical Karachi Online 7. SR-81 Consumable Technical Karachi Online 8. SR-18 F-27 Parts Technical Karachi Online 9. SR-89 Pneumatic Technical Karachi Online 10. SR-20 Surplus Technical Karachi Online 11. SR-B3 A/C Furnishing Commercial Karachi Online 12. SR-80 Raw Material Commercial Karachi Online 13. SR-04 Chemical Commercial Karachi Online 14. SR-58 TGS Commercial Karachi Online 15. SR-82 Chemical Commercial Karachi Online 16. SR-41 Forms Commercial Karachi Online 17. SR-64 Printing Mat Commercial Karachi Online 18. SR-59 Advertising Commercial Karachi Offline 19. SR-16 Common Commercial Karachi Online 20. SR-39 Uniform Commercial Karachi Online 21. SR-17 FSD Commercial Karachi Online 22. SR-22 Consumable Technical Islamabad Online 23. SR-42 Component Technical Islamabad Online 24. SR-55 P.O.L Commercial Islamabad Offline 25. SR-51 Commercial Commercial Islamabad Offline 26. SR-49 Printing Stationery Commercial Islamabad Offline 27. SR-56 FSD Commercial Islamabad Offline 28. SR-43 Uniform Commercial Islamabad Offline 29. SR-50 TGS & MT Commercial Islamabad Offline 30. SR-48 Computer Paper Commercial Islamabad Offline 31. SR-33 Consumable Technical Lahore Online 32. SR-34 Component Technical Lahore Online 33. SR-36 Commercial Commercial Lahore Offline 34. SR-54 Common Commercial Lahore Offline 35. SR-46 Printing Stationery Commercial Lahore Offline 36. SR-60 FSD Commercial Lahore Online 37. SR-66 Consumable Technical Peshawar Offline 38. SR-83 Printing Stationery Commercial Peshawar Offline 39. SR-94 Uniform Commercial Peshawar Offline 40. SR-93 Commercial Commercial Peshawar Offline 41. SR-63 Component Technical Faisalabad Offline 42. SR-62 Consumable Commercial Faisalabad Offline 43. SR-70 Uniform Commercial Faisalabad Offline Section B Instructions to Contractors (ITC) Page 16
SR. NO. STOCK ROOM STOCK TYPE TECHNICAL / COMMERCIAL STATION ONLINE / OFFLINE 44. SR-76 Commercial Commercial Faisalabad Offline 45. SR-77 Consumable Technical Multan Offline 46. SR-79 Uniform Commercial Multan Offline 47. SR-57 Consumable Technical Quetta Offline 48. SR-61 Component Technical Quetta Offline 49. SR-96 Commercial Commercial Quetta Offline 50. SR-68 Printing Stationery Commercial Quetta Offline 51. SR-C8 FSD Commercial Quetta Offline Please note that this is an indicative list that may change with time. Section B Instructions to Contractors (ITC) Page 17
A3 PROJECT ORGANIZATION For realizing the overall business and technological objectives, a fully resourced IT team is collaborating with PIA s management, through various stages of this project. Together the team reports to Project Steering Committee and ERP Implementation Committee that has been set-up to oversee the progress and make decisions on key issues. The successful ERP Contractor would become a part of this team and will work under the guidance and control of Project Steering Committee and ERP Implementation Committee. A4 PROJECT PHASES The various components covered under this RFP are: Supply of ERP System, Appropriate Hardware and Review of Infrastructure Environment ERP Implementation, Training and Rollout Post Implementation Warranty and Support The following component-wise activities have been identified: Supply of ERP System, Appropriate Hardware and Review of Infrastructure Environment Supply of an appropriate ERP solution that caters to the requirements mentioned in this RFP document and has been successfully implemented in the Airline and Aviation Industry. ERP solution and systems shall comprehensively fulfill PIA s business process requirements and objectives. ERP Solution should be capable to meet present requirements and future needs as described in Section D. The solution being provided must be relevant and complete with a suitable disaster recovery plan. Proposed ERP should have verifiable Airline / Aviation references. Supply of appropriate hardware to run the ERP solution in a high availability environment Study and provide detailed infrastructure requirements for optimum performance. It must focus on the required network (number of nodes, bandwidth, network availability requirements, VPN, intranet and internet, Network Management System (NMS), remote log on, security requirements, etc.); power (availability, stability, backup support, etc.); housing; air-conditioning and other facilities required. It is the responsibility of the Contractor to provide a complete solution to PIA, clearly mentioning the various items, components, tools, risks involved, etc. Any shortfall or critical components not specified in this RFP which the Contractor considers necessary for the solution to work smoothly and efficiently should be separately and clearly mentioned. Section B Instructions to Contractors (ITC) Page 18
Any Contractor who fails to do so, if awarded the contract, would without prejudice to PIA s legal rights, be responsible to procure and provide to PIA such tools, items, and components at its own cost. ERP Implementation, Training and Rollout Devise an implementation approach / strategy that should be adopted after due consideration to project scope, applicable constraints and magnitude of business improvement goals. Contractor must provide detailed implementation methodology. Identify and formulate implementation procedures and controls for systems security, auditability, confidentiality, reliability, integrity, and business continuity. Prepare conceptual design and highlight parameters that will be configured in the ERP system in accordance with PIA business requirements. Provide integration solutions where ERP will be integrated with other applications as identified in the RFP. Configure the ERP based on approved conceptual design, parameters and integration areas. It should also include complete workflow for transaction approvals and escalation. Prepare reports that fulfill management and statutory reporting requirements. Convert and migrate historical and live data, efficiently and accurately. Prepare the user community for change through appropriate knowledge transfer and end-user training. Prepare and execute a comprehensive training plan to train the trainers / power users and end users. Gain acceptance for new systems by actively involving key users in driving the acceptance testing process and achieving cut-over to the new environment. Ensure smooth and seamless transition to new systems without any disturbance to the ongoing operational activities of PIA. Provide a sufficient number of properly qualified ERP experts for each specific area mentioned in the RFP. These should cover as a minimum experts having implementation experience in airline of size comparable to PIA in the areas of Human Resources, Finance and Procurement and Logistics. To address ERP implementation at all PIA locations in the following areas: Finance General Ledger Financial Analyzer Fixed Assets Management Cash Management Petty Cash Management Accounts Payable Revenue Accounting Accounts Receivable Insurance Management Leasing Management Budget and Cost Management Profitability Management Foreign Currency Management Taxation Management Treasury and Risk Management Section B Instructions to Contractors (ITC) Page 19
Human Resources and Administration HR Planning and Operations Recruitment Management Qualifications Management HR Development Performance Management Compensation and Benefits Management Training and Development Time Management Healthcare Management Travel Management Payroll Processing Final Settlement Processing Personnel Insurance Management Security Management Staff Funds Management Self Service HR Procurement and Inventory Control Contracts and Procurement Management Vendor Management Items Management Stores Management Inbound / Outbound Logistics Management The implementation areas are indicative only; details are provided in Section D. Post Implementation Warranty and Support Provide a team of certified experts to be stationed at PIA locations for post implementation support for a minimum period of two months to ensure optimum and seamless operations of systems and processes. Specify a detailed support program and mechanism. Contractor must provide at least Three years post implementation warranty for software and hardware. The Contractor has to ensure that all software and hardware supplied are free from defects / bugs / flaws / security holes, etc. Warranty periods for hardware / software should be clearly mentioned. Any discrepancies, mismatches and resource constraints experienced during the support period which were not specified in the Proposal will be responsibility of the Contractor. Section B Instructions to Contractors (ITC) Page 20
SECTION B INSTRUCTIONS TO CONTRACTORS (ITC) Section B Instructions to Contractors (ITC) Page 21
B1 INSTRUCTIONS 1. Eligible Contractors 1.2 For the purpose of this RFP all parties receiving or responding to this RFP are considered bidders or potential contractors and have been identified throughout the RFP accordingly. This will be a Single Stage Two Envelope Bidding Process. 1.3 The Contractors are invited to submit a detailed Technical Proposal and an item wise Commercial Proposal for Products and Services required for the assignment as named in the ERP. The proposal will be the basis for the ultimate execution of a contract with the selected successful Contractor(s). 1.4 Information relating to evaluation of proposals and recommendations concerning awards will not be disclosed to the Contractor or to other persons not officially concerned with the process. The Contractor shall maintain complete confidentiality of its proposal and shall not disclose the proposal or any terms thereof to any unrelated person or any third party. The Contractor shall also keep confidential all its discussions with PIA. 1.5 By submitting a Proposal, the Contractor agrees to be legally bound by the terms and conditions set out in this RFP. The Proposal will be considered as a binding offer from the Contractor subject to acceptance by PIA. 1.6 PIA will not be bound to accept the lowest or indeed any Proposal and will not be committed to any Proposal until a contract has been executed. PIA, in its absolute discretion and without liability to any party, may decide at any time to amend the RFP, extend the deadline for submission of Proposals or amendments to the Proposals or terminate the RFP process in whole or in part. PIA. 1.7 Both hardcopies and softcopies (on CDs) of technical and commercial proposals should be submitted. Separate CDs for Technical and Commercial proposals should be made. Utmost care should be exercised in enclosing each CD in a separate relevant envelope. Failure to do would disqualify the bidder. 2. Products and Services 2.1 For the purposes of this RFP, the Enterprise Resource Planning Package Solution, also called simply the ERP Package or ERP Solution, means all of the products and related services on turnkey basis to be provided by the selected Contractor under the contract. 2.2 Contractors are bound to submit solutions based on their proposals submitted. Section B Instructions to Contractors (ITC) Page 22
3. Cost of Bidding 3.1 The Contractors shall bear all costs associated with the preparation, submission and clarification of its proposal, presentations and meetings. PIA will, in no case, be responsible or liable for those costs, regardless of the conduct or outcome of the bidding process. 4. Content of RFP Documents 4.1 The contents of the RFP Documents are listed below and should be read in conjunction with any addenda issued in accordance with ITC Sub-section 6: Section A - Project Detail Section B - Instructions To Contractors Section C - PIA IT Environment Section D - Product Requirements (ERP Package & Add-ons) Section E - Product Requirements (Others) Section F - Services Requirements Section G - Hardware Requirements Section H - Requirements Compliance Matrix Section I - Completion and Compliance Checklist Section J - Criteria for Technical and Commercial Evaluation 4.2 Contractors must examine all instructions, forms, terms, specifications and other information in the RFP Documents. Each Contractor by submitting its proposal shall be deemed to have satisfied itself as to all the conditions and circumstances affecting the scope of work and bid amount / contract price. 4.3 Failure to furnish all information required by the RFP Documents or to submit a Proposal not substantially responsive to the RFP Documents in every respect will be at the Contractor s risk and may result in the rejection of their Proposal and the Contractor shall not hold PIA liable for such rejection in anyway whatsoever. PIA reserves the right to verify at its sole discretion any or all information submitted in response to the RFP Document. Any false information or misrepresentation or non-disclosure may result in rejection of the entire Proposal. 5. Clarification of RFP Documents 5.1 Contractors may seek clarification pertaining to the RFP Documents by submitting specific questions, in writing, to PIA. This could be done within ten (10) working days from the date of issuance of RFP. PIA will respond in writing within five working days. The questions and PIA s responses will be sent to all bidders. All queries have to be submitted to: General Manager Procurement Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport Section B Instructions to Contractors (ITC) Page 23
Karachi Ph: +92-21-99045135 Fax: +92-21-34570120/+92-21-34575200 Email: gmptnl@piac.aero, contract.administration@piac.aero 6. Amendment to RFP Documents 6.1 PIA may modify the RFP Documents by issuing addenda, for any reason, and at any time prior to the deadline for submission of Proposals. Any addenda to the RFP Documents shall be considered part of the RFP Document. 6.2 All Contractors will be notified of the addenda in writing by email, letter or facsimile, all such Contractors shall confirm the receipt of such addenda to PIA and it shall be binding on them. 6.3 To allow Contractors reasonable time to take any addenda into account in preparing their Proposals, PIA may, at its own discretion, extend, as necessary, the deadline for the submission of proposals. 7. Language of Proposals 7.1 Proposals and all correspondence and documents relating to the proposals exchanged between the Contractor and PIA, shall be written in English. 8. Documents Comprising the Proposal 8.1 The proposal submitted by the Contractor shall comprise the following: (a) The relevant completed Proposal Form and all Price Schedules as included in Section B, Subsection B3 Template Forms, completed and duly signed by the Contractor in accordance with ITC Sub-sections 9,10 and 14; (b) Bid security furnished in accordance with ITC Sub-section 13; (c) (d) A full description of the technical solution to the business requirements described in Sections D Product Requirements (ERP & Add-ons), Section E Product Requirements (Others), Section F Services Requirements and Section G Hardware Requirements. The completed Requirements Compliance Matrix (Section H), Proposal Completion Checklist (Section I, Subsection I1) and Compliance Checklists (Section I, Subsections I2 to I4). 9. Proposed Prices 9.1 The Contractor must provide the prices of the proposed Solution using the Price Schedule Templates provided in Subsection B3. Section B Instructions to Contractors (ITC) Page 24
9.2 Prices provided on the Price and Recurrent Costs Schedules (as per Templates) shall be listed individually in the following manner: (a) (b) (c) Unit and total prices of products offered, inclusive of all taxes and duties. Prices for implementation services on the Services Price Schedule. Recurrent costs on the Recurrent Costs Form, as follows: (i) (ii) the cost of all software updates, recurrent licensing fees, and any other items needed to operate the ERP Solution, plus any other recurrent supply of products specified in the RFP Documents, the cost of all maintenance and technical support services, and any other recurrent services specified in the RFP Documents, including all taxes payable by the Contractor thereon. PIA shall not be liable to pay any of the aforesaid charges, taxes, expenses, etc. at any point during or after the period of this contract. (d) (e) Totals of Products, Services and Recurrent Costs, on the Proposal Price Summary Form. The Contractors should highlight separately the prices for Passenger Revenue Accounting and Cargo Revenue Accounting systems. These should include separate software / licensing costs as well as implementation / services / maintenance costs. 9.3 The Contractor s separation of price components in accordance with ITC Subsection 9, item 9.2 will be solely for the purpose of facilitating the comparison of proposals and will not in any way limit PIA s right to contract on any of the terms offered. 9.4 Prices quoted by the Contractor shall be fixed maximum prices during the Contractor s performance of the contract. Proposals submitted with adjustable price quotations will be rejected and the Contractor shall not hold PIA liable in anyway whatsoever for such rejection. 9.5 This is a high priority project for PIAC which is being monitored directly by the high management. While recognizing that each ERP vendor will have their own methodology PIAC has developed the following schedule as a baseline against which the schedules proposed by each bidder will be measured, significant weightage being given to adhering as closely to the baseline dates as possible (albeit following the vendor s own methodology). In proposal Bidder shall specify a milestone based payment procedure however payments will be released as per milestones achieved at sole discretion of PIA. Section B Instructions to Contractors (ITC) Page 25
10. Suggested Project Deliverables The successful bidder will be required to provide deliverables during the course of this project, some of which are as follows: 27. Draft Contract 28. Final Contract 29. Project Charter Document including Detailed Project Plan 30. Fortnightly Progress Report 31. Status of Project Issues List. This should be updated weekly during the project duration. 32. Interim Servers, Operating Servers and Related Tools 33. ERP Software (Media) Installation 34. Installation of Hardware at Production and Disaster Recovery Sites 35. Certificate upon Successful Installation of Hardware 36. Requirements Specifications Document 37. Gap Analysis Document 38. Templates for Data Collection 39. Solutions Design Document 40. End-User Training Manuals and Exercise Guides based on the Configured Solution 41. Training Plan for ERP Overview, Configured ERP Application and for End- Users. The end-users training plan should be role-based 42. UAT Plan 43. Scenarios-based Test Scripts for User Acceptance Testing 44. Development/Provision of Standard and Customized Reports 45. Roles and Responsibility Matrix 46. Master Implementation / Rollout Plan 47. IT Infrastructure Readiness Report and Certification 48. Fully Configured ERP solution 49. Go-Live Certificate 50. Detailed Plan for Post-implementation Support 51. Project Completion Report and Certificate 52. Application Users or Operations Manuals This list may not necessarily be comprehensive or exhaustive. Hence, bidders are required to suggest additional deliverables, if necessary. Section B Instructions to Contractors (ITC) Page 26
11. Bid Currencies 11.1 All Prices are to be quoted in Pakistan Rupees. 12. Documents Establishing Contractor s Eligibility and Qualifications 12.1 The documentary evidence of the Contractor s qualifications and ability to perform the contract if its proposal is accepted shall establish to PIA s satisfaction: (a) (b) (c) (d) (e) that, in the case of a Contractor not doing business in Pakistan, the Contractor is represented in Pakistan and will be able (if awarded the Contract), to carry out the installation, implementation, support, maintenance, and other service obligations prescribed in the RFP Documents. Documentary evidence supporting the aforementioned must be provided; that the Contractor and any Sub-contractors have the financial, technical, and staff capabilities to support the ERP Solution, and have a successful performance history, appropriate for their role in fulfilling the contract. Only the pre-qualified Contractors can be designated as the Lead Contractor. In the event a proposal is jointly submitted by more than one Contractor, all other participants should be designated as Sub-contractors. Any planned or proposed use of Sub-contractors must be clearly documented in the proposal with their names and relationship defined. In addition the Lead Contractor should complete the Consortium Responsibilities Form in Section B, Subsection B3. The Contractor shall not be permitted to introduce any other sub-contractor, other than the ones already mentioned in the documents as mentioned aforesaid. Each Sub-contractor must sign a Letter of Authorization / Joint Venture Agreement authorizing the Lead Contractor to act on its behalf. A copy of this Letter of Authorization / Joint Venture agreement must be submitted along with the Proposal. The Lead Contractor shall be completely responsible for all contract services to be performed. The Lead Contractor must demonstrate that all aspects of this RFP Document have been carefully and completely considered. No substitution of a Sub-contractor shall be allowed during the term of this contract. Failure of a Sub-contractor to perform as expected shall not relieve the Lead Contractor of its duties to perform on the whole requirement and the Lead Contractor shall be liable for any / Section B Instructions to Contractors (ITC) Page 27
all loss(es / damage(s) that PIA may suffer as a result of failure of a Sub-contractor to perform any / all of its obligations under this contract. 13. Documents Establishing Products and Services Eligibility and Conformity to RFP Documents 13.1 Pursuant to ITC Sub-section 8, the Contractor shall furnish, as part of its Proposal, documents establishing the eligibility and conformity to the RFP Documents of all products and services that the Contractor proposes to supply under the contract. 13.2 The documentary evidence of conformity of the products and services to the RFP Documents may be in the form of written descriptions, literature, diagrams, certifications and client references, including: (a) (b) (c) a detailed description of the essential technical and performance characteristics of the products; an item-by-item commentary on PIA s Product and Services Requirements, as detailed in Sections D, E, F and G, demonstrating the substantial responsiveness of the proposed solution to the specifications provided; and a confirmation that the Contractor shall accept responsibility for the successful integration and interoperability of all proposed products and other PIA systems as required by the RFP Documents. 14. Bid Bond 14.1 Pursuant to ITC Sub-section 8, the Contractor shall furnish, along with its Commercial Proposal, an unconditional and irrevocable bid bond for 5% (five percent) of the total amount of the Products, Services and Support Prices. 14.2 The bid bond is required to protect PIA against the risk of the Contractor s conduct that would warrant the security s forfeiture, as per ITC Subsection 13, item 13.7. 14.3 The bid bond shall be denominated in Pakistan Rupees, shall be valid for ninety (90) days beyond the validity of the Proposal, and shall be in one of the following forms: (a) (b) a bank guarantee by a Pakistani Scheduled bank, in the form provided in the RFP Documents; A Pay Order / Demand Draft drawn on a Pakistani Scheduled bank. Section B Instructions to Contractors (ITC) Page 28
14.4 Any Proposal not secured in accordance with ITC Sub-section 13, items 13.1 and 13.3 will be rejected by PIA and the Contractor shall not hold PIA liable in anyway whatsoever for any such rejection. 14.5 Unsuccessful Contractors bid bond will be discharged or returned as promptly as possible after the expiration of the period of Proposal validity prescribed by PIA pursuant to ITC Sub-section 14. 14.6 The successful Contractor s bid bond will be discharged upon the Contractor signing the contract, pursuant to ITC Sub-section 24, and furnishing the performance security, pursuant to ITC Sub-section 23. 14.7 The bid bond may be forfeited: (a) (b) (c) If a Contractor attempts to withdraw its Bid before the date stipulated in the RFP for the validity of the Bid or any extension in this date agreed between the Company and the Contractor, if a Contractor attempts to modify or amend its Bid without the approval / consent of the Company before the date stipulated in the RFP for the validity of the Bid or any extension to this date agreed between the Company and the Contractor, In the case of a successful Contractor, if the Contractor fails to: (i) Furnish Performance Guarantee in accordance with ITC Sub-section 23; and / or (ii) Sign the contract in accordance with ITC Sub-section 24. The Contractor shall not hold the Company liable in anyway whatsoever for the amount so forfeited by the Company. 15. Period of Validity of Proposals 15.1 Proposals shall remain valid for 180 days from the date of Proposal submission prescribed by PIA, pursuant to ITC Sub-section 16. A Proposal valid for a shorter period shall be rejected by PIA and PIA shall not be liable for such rejection in anyway whatsoever. 15.2 In exceptional circumstances, PIA purely on its discretion may solicit the Contractor s consent to an extension of the period of validity. The request and the responses thereto shall be made in writing by letter or facsimile. The bid security provided under ITC Sub-section 13 shall also be suitably Section B Instructions to Contractors (ITC) Page 29
extended. A Contractor may refuse the request without forfeiting its bid security. 16. Format, Signing and Packaging of Proposals 16.1 The Contractor is required to submit the original and one copy each of its Technical and Commercial Proposals, clearly marking each ORIGINAL BID or COPY OF BID, as appropriate. In the event of any discrepancy between them, the original shall govern. One softcopy of the Technical Proposal on a CD should also be submitted. 16.2 The Technical and Commercial Proposals shall be typed or written in indelible ink and shall be signed by a person or persons duly authorized to bind the Contractor to the contract, which authorization shall be corroborated by a written power of attorney accompanying the Proposal. 16.3 The Technical and Commercial Proposals shall be submitted in separately sealed envelopes, each marked Technical Proposal and Commercial Proposal accordingly, and bearing the name and return address of the Contractor and the project name Licensing and Implementation of Enterprise Resource Planning (ERP) Solution. Proposals offered through telex / fax / cable / email will not be accepted. Proposals should be addressed to: General Manager (Procurement & Logistics) Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport, Karachi Ph: +92-21-99045135 Fax: +92-21-99040120 Email: gmptnl@piac.com.pk 16.4 If the envelopes are not sealed and marked as required by ITC Subsection 15, item 15.3, PIA will assume no responsibility for the Proposal s misplacement or premature opening. 16.5 Contractors shall organize their Proposals in accordance with the format specified in Section B4 Contents and Format of Proposal. Section B Instructions to Contractors (ITC) Page 30
17. Deadline for Submission of Proposals 17.1 Proposals must be received by PIA at the address and by the time specified in the RFP Covering Letter. Proposals received after this deadline will be rejected and returned to the Contractor unopened. 17.2 PIA may, at its discretion, extend this deadline for the submission of Proposals, in which case all rights and obligations of PIA and Contractors previously subject to the deadline will thereafter be subject to the deadline as extended. 18. Modification and Withdrawal of Proposals 18.1 The Contractor may modify or withdraw its Proposal after submission, provided that the modification, substitution or written notice of withdrawal of the Proposal is received by PIA prior to the deadline prescribed for submission of Proposals. No Proposal may be modified after the deadline for submission of Proposals. 18.2 No Proposal may be withdrawn in the interval between the deadline for submission of Proposals and the expiration of period of Proposal validity specified by the Contractor on the Proposal Form. Withdrawal of a Proposal during this interval may result in the Contractor s forfeiture of its bid security pursuant to ITC Sub-section 13, item 13.7 and PIA shall not be liable in anyway whatsoever to return / make good the loss of the bid security. 19 Opening of Proposals by PIA 19.1 PIA will open all Technical Proposals at a place and time to be advised in the covering letter by PIA. Contractors or their representatives may attend the opening, and those who are present shall sign a register evidencing their attendance. 19.2 No Proposal shall be rejected at Proposal opening, except for late Proposals, which shall be returned unopened to the Contractor pursuant to ITC Sub-section 16, item 16.1. 19.3 The Commercial Proposals of Contractors will be opened subsequently and evaluated. Contractors will be informed of the place and time by PIA. 20. Clarification of Proposals 20.1 During evaluation of Proposals, PIA may, at its discretion, ask the Contractor for a clarification of its Proposal. The request for clarification and the response shall be in writing, and no change in the prices or Section B Instructions to Contractors (ITC) Page 31
substance of the Proposal shall be sought, offered, or permitted during or after evaluation of the Proposal. 20.2 PIA may request the Contractor to arrange site visits for its reference sites. 20.3 PIA may also request the Contractor to give proof of concept by developing prototypes of specific scenarios identified by PIA. 21. Contacting PIA 21.1 Any effort by the Contractor to unethically influence PIA in the process of evaluating Proposals and in decisions concerning award of the contract will result in the rejection of the Contractor s Proposal. 21.2 The Contractors submitting proposals should attach a declaration that: (a) (b) (c) (d) They will not obtain or induce the procurement of the contract or any right, interest, privilege, or other obligation or benefit related to the contract from PIA or the Government of Pakistan, or any subdivision or agency thereof, through any corrupt business practice. They will not give or agree to give and shall not give or agree to give to anyone within or outside Pakistan either directly or indirectly through any person or organization, including affiliates, agents, associates, brokers, consultants, directors, promoters, shareholders, sponsors or subsidiaries, any commission, gratification, bribe, finder s fee or kickback, whether described as consultation fee or otherwise, with the object of obtaining or inducing pursuant to the contract or any right, interest, privilege or other obligation or benefit related to the contract in whatsoever form. They have made and will make full disclosure of all contracts and arrangements with all persons / organizations in respect of or related to the proposed contract with PIA and have not taken any action or will not take any action to circumvent the above declaration, representation or warranty. They agree to pay compensation to PIA in an amount equivalent to the direct losses to PIA, which would include the sum of any commission, gratification, bribe, finder s fee or kickback that would otherwise have been given to PIA in the form of a concession, given by the parties submitting proposals for the purpose of corruptly obtaining or including the procurement of the contract or any right, interest or other obligation or benefit related to this contract in whatsoever form from the parties submitting proposals, Section B Instructions to Contractors (ITC) Page 32
if it shall ultimately be determined by a final judicial decision that the party submitting proposals has so obtained or induced the procurement of the contract, or any right, interest, privilege or other obligation or benefit related to such contract. 22. PIA s Right to accept any Proposal and to reject any or All Proposals 22.1 PIA reserves the right (without limitation to any other right whatsoever) to accept or reject any Proposal, or to annul the bidding process and reject all Proposals at any time prior to contract award without incurring any liability to the affected Contractor or Contractors. 22.2 PIA also reserves the right (without limitation to any other right whatsoever) to award the consolidated contract in its entirety to a single Contractor or to award it in parts to more than one Contractor without incurring any liability to the affected Contractor or Contractors. 22.3 After receipt of proposals from the Contractors, PIA will evaluate and study the submitted proposals. PIA does not bind itself to award the contract to the lowest or to any Contractor but will take into consideration all relevant facts and aspects. Finalization of the Contract between the successful Contractor and PIA will be held in the presence of representatives of PIA s Procurement and Logistics department, at PIA Head Office, Procurement and Logistics Building or PIA Computer Center. The aim is to reach agreement on all points and sign a contract. 22.4 Having selected the successful Contractor on the basis of, among other things, an evaluation of the total solution offered, proposed methodology (work plan), verifiable successful implementations, and proposed key professional staff, PIA expects to finalize a contract on the basis of the products and available expertise named in the proposal. Before contract finalization, PIA will require assurances that products and experts will be actually available. PIA will not consider substitutions during contract finalization unless both parties agree that undue delay in the selection process makes such substitution unavoidable or that such changes are critical to meet the objectives of the assignment. 22.5 The finalization of the contract with the successful Contractor will conclude with a review of the agreed draft, to be signed by PIA and the Contractor, ensuring successful delivery and completion of the project. PIA and the successful Contractor will initial the agreed draft of the contract. If this process fails, PIA may invite the next Contractor for the award of the assignment. In this regard, Contractors should submit draft copies of their proposed contracts and Service Level Agreements along with their Technical Proposals. Section B Instructions to Contractors (ITC) Page 33
23. Performance Guarantee 23.1 Within five (5) working days of the receipt of notification of award of the Contract from PIA, the successful Contractor shall furnish a Performance Guarantee for 10% (ten percent) of Contract value in accordance with the conditions of Contract, using the Performance Security Form provided in the RFP document. 24 Signing of Contract 24.1 Within four (04) working days of receipt of the Performance Guarantee in accordance with ITC Sub-section 23, PIA will send the successful Contractor the Contract Form provided in the RFP documents, incorporating all agreements between the parties. 24.2 Within four (04) working days of receipt of the Contract Form, the successful Contractor shall sign and date the contract and return it to PIA. Section B Instructions to Contractors (ITC) Page 34
B2 SUMMARY OF REQUIREMENTS This schedule lists all major components of the ERP Solution to be procured through this Request for Proposal. Further details and exact specifications for each item are included in the Sections D, E and F. Item Type Description Project Site(s) ERP Package Application software modules to meet the Applications Head Office requirements as per details in Section D Other Locations 1 ERP Package Any Add-on required for ERP solution, if any Head Office Other Locations 3 rd Party Software As required by the proposed ERP Package and Add-on Applications Head Office Other Locations RDBMS As required by the proposed ERP Package and Add-on Head Office Applications Other Locations Recommended configuration of hardware and operating system software for the Production Environment will be provided by the Contractor and it shall not be binding on PIA to procure this from the Contractor. Hardware Others Installation / Implementation Services Training Data Migration Recurrent Services Interim Application / Data Server(s) including Operating Systems as required by the proposed ERP for Training, Development, Testing and Quality Assurance Environments will be provided by the Contractor at its own cost Application Development Tools, Query and Report Generating Tools, Business Intelligence Tools, Systems Administration Tools, Operating Systems, Systems Management Tools, etc. Installation, configuration and implementation of Hardware and Operating System, ERP Standard Software, Add-on Applications, 3 rd Party Applications. End User, Power User and Management training for ERP, Add-on and 3 rd Party Applications, Technical training for Developers and Administrators on Application Development Tools, Reporting Tools, RDBMS, DBA tools, OS, System Management Tools, etc. Development of applications and migration of data from legacy systems and manual records Post-Implementation support for three years (after Warranty Period) for ERP Package, Add-on applications, Hardware and 3 rd Party Software Maintenance and Support Head Office Other Locations Head Office Head Office Other Locations Head Office Other Locations Head Office All Locations 1 List of locations where PIA operates is available in Section A, Subsection A2. Section B Instructions to Contractors (ITC) Page 35
B3 TEMPLATE FORMS Notes for Contractors on the Template Forms 1. The Contractor shall complete and submit with its Proposal the Proposal Form and the required Price Schedules and in accordance with the requirements included in Section B, Subsection B1. 2. The Contractor should provide the Bid Bond as per the form included in this Subsection. 3. The Performance Guarantee form is not required at the time of Proposal submission by bidders. Only the successful Contractor will be required to provide Performance Guarantee as per the form included in Section B, Subsection B3. PIA, however reserves the right, in case of failure on part of selected the Contractor to provide the aforesaid Performance Guarantee in accordance to the instructions as laid down in Instruction to Contractors (ITC) Section B within the specified time, to forfeit the bid security furnished by the Contractor. Section B Instructions to Contractors (ITC) Page 36 Confidential
Proposal Form To: Dear Sir: General Manager (Procurement & Logistics) Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport Karachi Ph: +92-21-99045135 Fax: +92-21-99040120 Email: gmptnl@piac.com.pk Having examined the Request for Proposal Documents including Addenda Nos. [insert numbers, if issued and applicable], the receipt of which is hereby duly acknowledged, we, the undersigned, offer to produce, deliver, install, implement, support and maintain the ERP Solution in full conformity with the said RFP Documents. We undertake, if our Proposal is accepted, to implement the ERP Solution in accordance with the Project milestones agreed with PIA. We certify that a bid bond for 5% (five percent) of the total amount of the proposal is submitted as part of our Commercial Proposal. If our Proposal is accepted, we will provide a Performance Guarantee in the form and in the amounts, and within the times stipulated in the Request for Proposal Documents. We agree to abide by this Proposal for a period of 180 days from the date fixed for Proposal submission, and it shall remain binding upon us and may be accepted at any time before the expiration of that period. Until a formal Contract is prepared and executed, this Proposal, together with your written acceptance thereof and your notification of award, shall constitute a binding Contract between us. We understand that you are not bound to accept the lowest or any Proposal you may receive. Dated this day of 20. [signature] [in the capacity of] Duly authorized to sign Proposal for and on behalf of Section B Instructions to Contractors (ITC) Page 37 Confidential
Bidding Organization and Experience [Provide a brief (not more than five pages) description of the background and organization of your firm/entity and each sub contractor for this assignment.] Section B Instructions to Contractors (ITC) Page 38 Confidential
Bidder s Experience [Using the format below, provide information on each assignment for which your firm, and each associate for this assignment, was legally contracted either individually as a corporate entity or as one of the major companies within an association, for carrying out services similar to the ones requested under this assignment. Attach details on separate sheet if necessary.] Assignment name: Approx. value of the contract (in current PKR): Country/Province : Location within country: Name of Client: Address: Start date (month/year): Completion date (month/year): Name of Sub-Contractor, if any: Duration of assignment (months): Total No of staff-months of the assignment: (If applicable) Approx. value of the services provided by your firm under the contract (in current PKR): No of professional staff-months provided by Sub- Contractor: Name of senior professional staff of your firm involved and functions performed (indicate most significant profiles such as Project Director/Coordinator, Team Leader): Narrative description of Project: Description of actual services provided by your staff within the assignment: Section B Instructions to Contractors (ITC) Page 39 Confidential
Description of Approach, Methodology & Project Plan for the Project [In order to ensure timely completion of this project, the consultant/service provider should submit a methodology and detailed Project Plan including the estimated completion timeline of each area/sub area of the scope] Section B Instructions to Contractors (ITC) Page 40 Confidential
Team Composition and Task Assignments [Using the format below, provide information regarding the nominated project team for this assignment baed on proposed methodology and work plan. Depending upon skill sets, experience and technology certifications as mentioned in TECH FORM-7 and subject to the submission of documentary evidences] Professional Staff/Nominated Project Team Name of Staff Position Assigned Area/Task Assigned in this Project Skill Sets and Technology Certification Name(s) Section B Instructions to Contractors (ITC) Page 41 Confidential
Curriculum Vitae (CV) for Professional Staff [CVs should be submitted for Nominated Project Team/Professional Staff only] 1. Proposed Position: 2. Name of Firm [Insert name of firm proposing the staff]: 3. Name of Staff [Insert full name]: 4. Date of Birth: Nationality: 5. Education [Indicate college/university and other specialized education of staff member, giving names of institutions, degrees obtained, and dates when obtained]: 6. Technology Certification(s) Achieved [Provide name of all the technology certification achieved by the staff] 7. Other Trainings [Indicate significant training since, education under 5, were obtained]: 8. Countries of Work Experience: [List countries where staff has worked in the last ten years]: 9. Languages [For each language indicate proficiency: good, fair, or poor in speaking, reading, and writing]: 10. Employment Record [Starting with present position, list in reverse order every employment held by staff member since graduation, giving for each employment (see format here below): dates of employment, name of employing organization, positions held.]: From [Year]: To [Year]: Employer: Positions held: 11. Detailed Tasks Assigned [List all tasks to be performed under this assignment] Section B Instructions to Contractors (ITC) Page 42 Confidential
12. Work Undertaken that Best Illustrates Capability to Handle the Tasks Assigned [Among the assignments in which the staff has been involved, indicate the following information for those assignments that best illustrate staff capability to handle the tasks listed under point 11.] Name of assignment or project: Year: Location: Client: Main project features: Positions held: Activities performed: 13. Certification: I, the undersigned, certify that to the best of my knowledge and belief, this CV correctly describes myself, my qualifications, and my experience. I understand that any wilful misstatement described herein may lead to my disqualification or dismissal, if engaged. [Signature of staff member or authorized representative of the staff] Date: Day/Month/Year Full name of authorized representative: Section B Instructions to Contractors (ITC) Page 43 Confidential
Item No. Name of Contractor Page of Product Description Contractor Proposal Reference Products Price Schedule Product Producer Partner or Subcontractor Responsible for Supply and Installation Quantity Unit Price 1 (Rs.) Total Price (Rs.) (1) (2) (3) (4) (5) (6) (7) = (5) x (6) ERP Package Module A 3 Module B Subtotal Add-on Applications Add-on A 4 Add-on B Subtotal RDBMS Subtotal 3 rd Party Software Subtotal Hardware: Subtotal Other Products: Subtotal TOTALS Additional ERP Licensing Cost Per User 5 2 Signature of Contractor 1 Prices include all taxes payable by the Contractor thereon. 2 In case of discrepancy between unit price and total, the unit price shall prevail. Similarly, subtotals shall prevail over totals. 3 Price for each Application/Module/Tool should be provided separately 4 Price for each Add-On should be provided separately 5 Price for Each Additional ERP User should be provided separately Section B Instructions to Contractors (ITC) Page 44
Services Price Schedule Name of Contractor Page of Item No. Service Description Contractor Proposal Reference Partner or Subcontractor Responsible for Service Delivery Quantity Unit Price 6 (Rs.) Total Price (1) (2) (3) (4) (5) (6) = (4) x (5) Implementation ERP Package Add-on Applications 3 rd Party Software Subtotal Training Master Trainers End-users Technical Apps Dev Tool Reporting Tool DBA Tool RDBMS Operating System Sys Admin / Mgmt Others Data Migration Documentation Other TOTALS Subtotal (Rs.) 7 Signature of Contractor 6 Service prices include all taxes payable by the Contractor thereon. 7 In case of discrepancy between unit price and total, the unit price shall prevail. Similarly, subtotals shall prevail over totals. Section B Instructions to Contractors (ITC) Page 45
Recurrent Costs Schedule (Prices during the maintenance period for first five years) Name of Contractor Page of Maintenance Fee: ERP Package Add-on Application 3 rd Party Software RDBMS Sub-total Maximum compounded costs per annum after expiration of the warranty period (in Pak Rupees) 8 Total Recurrent Year 1 Year 2 Year 3 Year 4 Year 5 Costs Recurrent Software Licensing Fees: ERP Package Add-on Application 3 rd Party Software RDBMS Sub-total Hardware maintenance costs Other recurrent costs TOTALS Signature of Contractor 8 The annual costs should indicate the total costs for the year inclusive of all taxes. Section B Instructions to Contractors (ITC) Page 46
Name of Contractor Page of Proposal Price Summary Form Products Price Total Services Price Total Recurrent Costs Total Amount in Pak Rupees Total Proposal Price: Signature of Contractor Section B Instructions to Contractors (ITC) Page 47
Bid Bond Form BANK GUARANTEE NO. DATED: AMOUNT: EXPIRY: Pakistan International Airlines Karachi Airport Karachi BID BOND AS PER TENDER FOR LICENSING AND IMPLEMENTATION OF ERP SOLUTION WHEREAS (hereinafter called the Contractor ) has submitted to PAKISTAN INTERNATIONAL AIRLINES (hereinafter called the Company ) a bid dated day of year, for the execution of the above work. AND WHEREAS it is provided by this bid that the Contractor shall furnish the Company with security by way of an unqualified, unconditional and irrevocable bond or guarantee for the due fulfillment of certain matters relating to this Bid. AND WHEREAS have at the request of the Contractor agreed to give such security. NOW THEREFORE WE of undertake, subject to the following terms, to pay to the Company on its first written demand such sums as may be claimed by it in writing up to a maximum of Rs. as recorded on the Request For Proposal. 1. The PIAC may claim payment hereunder if either: 1.1 Before the date stipulated in the Request For Proposal for the validity of the Bid or any extension to this date agreed between the Company and the Contractor, the Contractor attempts to withdraw, modify, or amend his bid without the approval of the Company or 1.2 The Company has agreed with the Contractor that a Contract will be executed, but the Contractor fails to execute the formal Contract Document when requested to do so by the Company or Section B Instructions to Contractors (ITC) Page 48 Confidential
1.3 At the time of entering into a Contract with the Company to undertake and complete the work, the Contractor fails to provide the Bonds and Guarantees required by such Contract. 2. Payment shall be made hereunder on the Company s first demand in writing to us stating that one or more of the above events has occurred without any further condition or substantiation and without the necessity of any proceedings whatever, whether judicial or otherwise being instituted by the Company. 3. The Bond shall remain in full force and effect until the date when the Contractor shall have executed the formal Contract Document and provided the necessary Bonds and Guarantees there under or upon the written rejection by the Company of the Contractor s Bid, whichever is earlier, at which time the Bond shall automatically expire and be of no further effect. IN WITNESS WHEREOF this Bond has been duly signed and sealed on the day of year. For and on behalf of Officer Manager Witnesses: 1. 2. Section B Instructions to Contractors (ITC) Page 49 Confidential
Form of Contract Agreement THIS AGREEMENT made the day of year between Pakistan International Airlines (hereinafter called PIA ) of the one part and [name of Contractor] of [city and country of Contractor] (hereinafter called the Contractor ) of the other part: WHEREAS PIA invited Proposals for certain products and ancillary services, viz., ERP Solution and has accepted a Proposal by the Contractor for the supply of those products and services in the sum of [contract price in words and figures] (hereinafter called the Contract Price ). NOW THIS AGREEMENT WITNESSETH as follows: 1. In this Agreement words and expressions shall have the same meanings as are respectively assigned to them in the Conditions of Contract referred to. 2. The following documents shall be deemed to form and be read and construed as part of this Agreement, viz.: (a) (b) (c) (d) (e) (f) Request for Proposal; Summary of Requirements; Product and Services Requirements; General Instructions and Conditions of Contract (if any); Special Terms and Conditions of Contract (if any); Contractor s Proposal. 3. In consideration of the payments to be made by PIA to the Contractor as hereinafter mentioned, the Contractor hereby covenants with PIA to provide the products and services and to remedy defects therein in conformity in all respects with the provisions of the Contract. 4. PIA hereby covenants to pay the Contractor in consideration of the provision of the products and services and the remedying of defects therein, the Contract Price or such other sum as may become payable under the provisions of the Contract at the times and in the manner prescribed by the Contract. 5. Unless expressly stated herein, wherever any period or periods of time are specified, the parties hereto agree that time shall be the essence of the Contract. 6. Unless expressly stated herein, the failure of one party to exercise any option, right or remedy under the Contract or to demand compliance of any obligation of the other party, shall not constitute a waiver of any such option, right or remedy or the performance thereof. 7. Each of the rights and obligations contained in this Contract shall be deemed to be distinct and severable so that if one such right and obligation shall be declared or become illegal, void or unenforceable, then the remaining rights and obligations Section B Instructions to Contractors (ITC) Page 50 Confidential
shall (unless the effect is to frustrate the fundamental basis of this Contract) continue in full force and effect. 8. The Contractor shall not assign any of its duties / obligations under this contract to any third party. 9. The parties to the Contract shall not be liable for any loss, claims or demands of any nature whatsoever and shall not be deemed in breach of this Contract because of any delay or failure in observing or performing any of the conditions or provisions hereof if such delay or failure is caused by or arises out of any circumstances whatsoever, beyond the affected party s control, including (but without limiting the generality of the foregoing), war, sabotage, blockade, revolution, police action, riots or disorder, embargoes or trade restrictions of any sort, government or quasigovernment action, acts of God, fire, flood, earthquakes, explosion, accident, radiation, strike, lockouts or other Labor disputes or disasters. 10. PIA shall have the right to terminate the Contract: If the Contractor, in the judgment of PIA, is or has been engaged in corrupt or fraudulent practices in competing for or executing the Contract If the Contractor commits a breach of any of the terms and conditions of this Contract At its absolute discretion, at any time, by giving thirty days notice to the Contractor, whether or not in default, whereupon PIA s liability shall be to pay the Contractor remuneration of services performed up to the date of termination In any case, PIA terminates the contract on any of the aforesaid reasons; the Contractor shall be liable for all direct losses, damages and charges incurred by PIA, in relation to the termination of this contract. 11. All disputes or any difference or question which may arise between the parties hereto or any person claiming thereof, touching or arising out or in respect of this Contract or the subject matter thereof shall be referred to the arbitration in accordance with the Arbitration Act 1940, each party shall appoint its own Arbitrator and the decisions in such arbitration proceedings shall be final and binding on both the parties. The place for arbitration will be Karachi while the laws of the Islamic Republic of Pakistan will be the Governing Law. IN WITNESS whereof the parties hereto have caused this Agreement to be executed the day and year first above written. Signed, sealed, and delivered by the Section B Instructions to Contractors (ITC) Page 51 Confidential
said [name of representative] (for PIA) in the presence of [name of witness] Signed, sealed, and delivered by the said [name of representative] (for the Contractor) in the presence of [name of witness] Section B Instructions to Contractors (ITC) Page 52 Confidential
Pakistan International Airlines Karachi Airport Karachi Dear Sir, PERFORMANCE GUARANTEE Performance Guarantee Form BANK GUARANTEE NO. DATED: AMOUNT: EXPIRY: DESCRIPTION OF WORK Whereas, we understand that you have placed a Work Contract No. dated with (The Contractor) for the above mentioned work and that in accordance with the terms of the contract, the Contractor is required to furnish a Bank Guarantee in respect of it s obligations under the said contract for an amount equal to 10% of the contract value vise (amount of contract in words and figures). Now, therefore, in consideration of the above, we, (Name and address of Bank) hereby GUARANTEE irrevocably and unconditionally the due payment to you upon demand of first written such sum or sums not exceeding (amount of guarantee in words and figures) without whatsoever right of objection in the event that the contractor fails to perform or fulfill any of the terms and conditions of the contract at the time or during the period specified therefore in the contract, provided that any demand hereunder is received in writing at this office within the validity of this guarantee accompanied by your written declaration to us that the Contractor has failed to comply with the terms of the contract, and such declaration shall be accepted by us as conclusive proof that the amount claimed is due to you, and we shall forthwith pay you the entire amount claimed. Our liability under this guarantee shall not be affected by any dispute or difference between you and the Contractor or by any forbearance or indulgence granted by you to the Contractor or by any other security held by you from the Contractor relating to the above mentioned contract or any variation in the contract or any other matter or thing which might otherwise affect our liability hereunder. We further Guarantee that no change or addition to or other modification of the terms of the Contract shall in anyway release us from any liability under this Guarantee and we hereby waive notice of any such change, addition or modification. Section B Instructions to Contractors (ITC) Page 53 Confidential
This Guarantee will remain valid until... and any claims hereunder must be received by that date, after which this guarantee will become null and void, and must be returned to us for cancellation. This guarantee shall be construed in accordance with the laws of Pakistan. For and on behalf of Officer Manager Witnesses: 1. 2. Section B Instructions to Contractors (ITC) Page 54 Confidential
` Name of Firm 9 Consortium Responsibility Form Product or Form of Business 10 Role in Project 11 Responsibilities 12 Service 13 to be Provided Lead Contractor Joint Venture 14 Agreement Reference and Date For each partner list the staff members who will be a part of the project, their proposed roles and the minimum committed man days for each person. Signature and Stamp of Authorized Lead Contractor 9 Enter the name of each of the Consortium / Joint Venture / Sub-Contracted firms, starting with the Lead Contractor 10 State whether Individual, Sole Proprietor, Limited Liability Company, Partnership, Corporation, etc. 11 State the role of the Firm on the Project i.e. whether Lead Contractor, Project Manager, Software Supplier, Software Developer, Trainer, etc. 12 Clearly list all the key responsibilities the Firm would be undertaking on the Project 13 Include a time schedule for provision of products and services of each partner 14 Copy(s) of Agreement(s) to be attached Section B Instructions to Contractors (ITC) Page 55
B4 FORMAT AND CONTENTS OF PROPOSAL 1. GENERAL PROPOSAL REQUIREMENTS 1.1 PIA discourages lengthy and costly proposals. Proposals should be prepared simply and economically and provide a straightforward, concise description of the Contractors capabilities to satisfy the requirements of this RFP. Emphasis should be on completeness and clarity of content. 1.2 Contractors must follow all formats and address all portions of the RFP set forth herein providing all information requested. Contractors may retype or duplicate any portion of this RFP for use in responding to the RFP, provided that the proposal clearly addresses all of PIA's information requirements. 1.3 Contractors must respond to every subsection under the Technical Proposal and Commercial Proposal sections. Contractors must label each response to RFP requirements with the section and subsection numbers or Proposal Reference IDs associated with the subject requirement in this RFP Document. 1.4 Proposals must not contain extraneous information. All information presented in a Proposal must be relevant in response to a requirement of this RFP, must be clearly labeled, and, if not incorporated into the body of the Proposal itself, must be referenced to and from the appropriate place within the body of the Proposal. 1.5 Proposals shall be prepared on standard A4 size paper. Foldouts containing charts, spreadsheets, and oversize exhibits are permissible. All responses, as well as any reference material presented, must be written in English. Proposal pages must be numbered and responses must be identified by the related RFP section number. 1.6 Contractors shall divide their responses to this RFP into a Technical Proposal and a Commercial Proposal. Commercial Proposal and pricing information should not be included in the Technical Proposal. Inclusion of Commercial Proposal or pricing in the Technical Proposal shall make the proposal ineligible for further evaluation and participation in the process. Section B Instructions to Contractors (ITC) Page 56 Confidential
2. REQUIRED FORMAT OF THE PROPOSAL Each Contractor can submit only one Proposal. Contractor shall prepare their Proposal using the following structure and form. 2.1 Management Overview: The Contractor s response concerning its ability to satisfy the qualification, eligibility, business and technical requirements as stated in the RFP documents. The Contractor should summarize the proposed technical and service solution and qualitatively describe its advantages. 2.2 ERP Package: Complete details should be provided of the ERP Package that is being proposed as part of the solution. The ERP Packages general functional description and capabilities, with particular reference to Section D, Subsection D1, must be addressed. In addition specific details addressing how each of the Business Functional Needs and Application requirements, as detailed in Section D, Subsection D2, will be met by which module of the ERP Package, must be provided. The proposed ERP package should have tightly integrated modules and should seamlessly interface with PIA s existing software. The Contractor should elaborate on the extent and efforts for customization required to satisfy the functional requirements. The Contractor should also provide contingency and backup plans / procedures with guaranteed Service Level Agreements. Licensing cost for ERP users should be provided as follows: 50 ERP users 100 ERP users 500 ERP users 1,000 ERP users 1,500 ERP users 2,000 ERP users Unit cost for each ERP user If enterprise licensing option is available, please specify Licensing cost for self-service HR users should be provided as follows: 500 employee self-service users 1,000 employee self-service users 5,000 employee self-service users 10,000 employee self-service users 15,000 employee self-service users Unit cost for each employee self-service user If enterprise licensing option is available, please specify Contractor must also specify an Escrow arrangement for the availability of source code necessary to support the proposed solution in case the Section B Instructions to Contractors (ITC) Page 57 Confidential
Contractor or the principal vendors cease to exist, discontinue this line of business or are incapacitated in any way to support the proposed solution. 2.3 Add-on Applications: Where the suite of ERP modules does not meet all the functional requirements of PIA, and the Contractor proposes to custombuild application(s) as Add-ons to the ERP to fulfill the requirements, details of the application development methodology, development platform and tools, and extent of development complexity are to be provided. Their capability to integrate seamlessly with the ERP and other proposed external software utilities and modules should be described, with an overview of integration and data transfer mechanisms. The ownership rights of the Add-on applications will rest with PIA, including all Intellectual Property Rights. The Contractor s (or Consortium Partner s) experience of developing and implementing such Custom-Built applications must be highlighted. 2.4 Relational Database Management System: Complete details of the proposed RDBMS as well as Database Administration Tools are to be provided. These should include, as a minimum, the version, features, capabilities, adherence to industry standards, portability and openness. 2.5 Query and Report Generator Tools: Complete description of the tools that are being provided with the ERP standard functionality for end-user adhoc query and report generation, including capabilities for ease-of-use and learning. 2.6 Interim Server(s): A complete description of the hardware configuration and performance expectations of the proposed Interim Server should be provided as detailed in Section E, Subsection E4. The Contractor should also describe the contingency arrangements that will be in effect for the period that the Interim Server(s) is required, as well as maintenance responsibilities. The Site Specifications for installation of the Server(s) must be provided to enable PIA to cater for the requirements. 2.7 Implementation: The Contractor should provide details of the implementation methodology to be adopted, and include a componentwise detail-level plan. Details should be provided of the project organization that will be maintained, including, in the case of consortiums, relationships between the various parties and the communication process and plan. The project progress reporting and issue escalation mechanisms are to be highlighted. Details of how the identified resources will be utilized during the various phases of the Project should be described. These should include estimates of the total staff input (professional and support staff; staff time and location) needed to carry out the project, supported by bar chart diagrams showing the time proposed for each professional staff team member. The quality assurance process Section B Instructions to Contractors (ITC) Page 58 Confidential
to be followed for products and services, as well as responsibilities, should be described. Detailed time schedule should be provided highlighting main milestones and activities in detail with overall time span and the deliverables associated with each milestone. Contractors must clearly specify the facilities required by their staff during implementation. Implementation tasks requirements are detailed in Section F, Subsection F1. PIA at its discretion may interview the nominated ERP experts to assess their technical expertise and reserves the right to accept an ERP expert or ask for replacement of any or all such experts. PIA at its discretion may also ask for replacement of any expert at any stage of the project if PIA considers that the said expert is engaged in questionable activities or the performance of the expert is not at par with required standard. 2.8 Training: Details of Courses to be conducted by the Contractor should be provided, with description of type, content, duration and location of courses for each of the identified personnel levels, with reference to Section F, Subsection F2. The number of participants per course should be prescribed. Also describe the training material to be provided on completion of the course as well as certification / examination method to be followed. Following table indicates the approximate number of users that would require training: USER GROUPS EXPECTED ROLES NUMBER Senior Management (up to GM Level) Power / Key Users Report / MIS review Transaction review and approval Limited transaction entry / edit Finance 40 Human Resources and Admin System parameterization and configuration 25 Procurement and Logistics Master trainers 15 IT 20 Others 15 End Users Finance 300 Transaction entry / edit Human Resources and Admin 250 Transaction approvals Procurement and Logistics 150 Report / MIS review Station Users 300 Others 50 70 Section B Instructions to Contractors (ITC) Page 59 Confidential
USER GROUPS EXPECTED ROLES NUMBER Technical Users (IT Department) Technical Support 30 This is an indicative list that would be finalized by PIA at an appropriate time during the project. 2.9 Data Migration: Details of data migration strategy and process to be followed, including verification, should be provided with reference to Section F, Subsection F3. Details of forms, screens, or interim file arrangements should be described. The resources that will be required as well as any training requirements must be highlighted along with the programming effort that will be required. 2.10 3 rd Party Software and Interfaces: Contractor will be responsible to ensure that required 3 rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration tools, disaster recovery and business continuity tools, APIs / interfaces, etc. are all made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed ERP solution. These should be clearly spelt out in the Technical Proposal and corresponding pricing shown in the Commercial Proposal. 2.11 Documentation: Details of documentation to be provided for ERP and other Applications, describing a summary of contents, media on which provided, and the number of hard and soft copies. The Contractor should address the needs of End user as well as technical (operations, support, and development) staff with reference to Section F, Subsection F4. 2.12 Post-Implementation Warranty and Support: Details of postimplementation support that will be provided after the expiry of the warranty should be provided for each required component (As indicated in Section B, Subsection B2 - Summary of Requirements) and reference to Section F, Subsection F5. The type of support, coverage, location from which support will be provided should be described, as well as the level of expertise that will be employed for support. Also describe the escalation process that is to be followed, and the Service levels. A description of the handling of various categories of problems and response times should be provided. Contractor should also specify the versions of all software / documents being provided to PIA and ensure that these will be upgraded to the latest available certified version during the warranty period (reference to Section F, Subsection F6). 2.13 Technology Architecture: Details of the proposed technology architecture under which the ERP solution will be implemented should be provided, consistent with modern architectural design. It should also contain the details of technology standards supported and at what levels. Minimum Section B Instructions to Contractors (ITC) Page 60 Confidential
requirements for Local Area Network and Wide Area Network bandwidth should be specified, including a commentary on PIA s existing network set-up and its capability or otherwise in meeting the minimum requirements. 2.14 Hardware: The Contractor should provide the optimum platform configuration for Server hardware to run the ERP Package and other Applications, consistent with the ERP features and Technology architecture, as proposed in Subsection B4, item 2.13 above, and details provided in Section D, Subsection D1, items 2.8 and 2.9. The proposed ERP and RDBMS should be platform independent to give PIA the liberty to choose any appropriate platform in the future. Contractor has to propose complete hardware solution and minimum network infrastructure for smooth functioning. PIA reserves the right to purchase hardware / operating software from the successful Contractor or any other vendor of its choice 2.15 Deliverables: The Contractor must provide a complete list of all deliverables that it proposes to produce / make available to PIA during the course of this project. 2.16 Requirements from PIA: The Contractor must specify in detail the facilities to be provided by PIA for effective implementation. The Technical Proposal must clearly mention the responsibilities of PIA and the Contractor during different phases of the project. 2.17 Comments / Suggestions (Optional): The Contractor should provide any comments or suggestions on the Terms of Reference. 2.18 In case the Contractor fails to provide any / all of the abovementioned information or fails to abide by any of the terms and conditions of this Contract, PIA reserves a right to immediately terminate the Contract at any time before and / or during the Contract period without assigning any reason whatsoever and PIA shall not be liable to make good any loss / damage to the Contractor which may result on account of such termination. Section B Instructions to Contractors (ITC) Page 61 Confidential
SECTION C PIA IT ENVIRONMENT Section C PIA IT Environment Page 62 Confidential
C1 IT DEPARTMENT The Information Technology (IT) Department at PIA supports data gathering, processing, and reporting functions to the core business units and other support departments. Director (IT) heads the department. He functionally and administratively reports to Deputy Managing Director (DMD). The IT Department is divided into the following three sections: The approved staff strength of PIA s IT Department is around 335. The current structure and manpower resources of the IT Department may be fulfilling PIA s contemporary needs, however, they will have to transform and adjust in order to effectively respond to new challenges in the wake of ERP implementation and other business and technology initiatives. Section C PIA IT Environment Page 63 Confidential
C2 EXISTING SYSTEMS The data processing environment at PIA is a blend of legacy systems - some of which were developed more than twenty years ago - and modern state-of-the-art systems that have been acquired from different vendors. In order to keep abreast of the competition, PIA has been striving to obtain new systems, particularly those specific to the airline industry. At the same time in-house resources are also being utilized to develop and maintain various applications. Overall three categories of applications can be identified at PIA: Hosted Systems Acquired Systems In-house Developed Systems Following tables present a list of major applications being used by PIA: HOSTED SYSTEMS Reservation System (Sabre Multi Host) Passenger Check In System (ACSI) Revenue Management System (AirMax) Schedule Planning System (AirFlite) Flight Operations System (AirOps) Cargo Revenue Management (CargoMax) Revenue Integrity Management Systems (RIM) Frequent Flyer System (TLS) E-ticketing WEB Ticketing (Sabre Sonic WEB) SITA Shared Cargo ULD Management System Travel Information System (Timatic) Baggage Tracing System (World Tracer) ACQUIRED SYSTEMS Passenger Revenue Accounting System (QUASAR) Air-Pricing System Crew Scheduling System (AIMS) APIS System Queue Management System Section C PIA IT Environment Page 64 Confidential
IN-HOUSE DEVELOPED SYSTEMS Payroll Income Tax / Provident Fund Systems Human Resource System Leave and Passage System General Ledger System Budget / Agent Ledger Systems Flight Log System Uniform System PAMMIS (Aircraft Maintenance) POSS (Online Orders) Cargo Revenue Traffic Load Summary Mail Revenue Interline Billing Attendance Monitoring System Standby and Waitlist Passenger List Flight Status Board Web-based Passenger Information System Cargo Management System Customer Complaint Management System File Management System Flight Firming System New SpeedEX System Recipe Management System Medical Units Automation System Baggage Reconciliation System Human Resources Record System FREPAK System Fuel Management and Analysis System Route Performance and Profitability System Traffic Performance System Traffic Trend Bulletin System International Market Share Analysis System Domestic Market Competition Analysis System Section C PIA IT Environment Page 65 Confidential
International Market Affairs System It is anticipated that the proposed ERP will require interfaces with the Hosted and Acquired Systems. However, a number of in-house developed systems might get replaced by the selected ERP. Further details of some of these systems are presented below: Section C PIA IT Environment Page 66 Confidential
Module / Application Name Purpose / Details Hardware Platform Programming Language Operating System Database / File Structure Volume POSS (PIA Online Store System) Deals with planning of commercial and other inventory items IBM MP2003 COBOL/VSE VM/ESA VSE/ESA DLI/VSE VSAM PAMMIS (PIA Aircraft Maintenance Management Information System) Tracks the movement of aircraft parts that come to Engineering Department for maintenance IBM MP2003 VisualGen VM/ESA VSE/ESA DB2/VSE GENACCT (General Accounting System) Deals with disbursements made under different account heads Preparation of General Ledger Preparation of annual budget Preparation of subsidiary ledger IBM MP2003 COBOL/VSE VM/ESA VSE/ESA DB2/VSE VSAM FREPAK/OSPAK (Flight Regulatory/ Crew Scheduling System of PIA) Provides flight regulatory information of PIA flights for the day Show flight delays and reasons of delay Provides flight load summary for the day and year-to-date IBM MP2003 COBOL/VSE VM/ESA VSE/ESA DLI/VSE VSAM PAYROLL Deals with the payment made to employees in different cadres and keeps history thereof IBM MP2003 COBOL/VSE VM/ESA VSE/ESA VSAM POPIS (PIA Online Personnel Information System) Keep HR details of all employees like bio-data, family information, addresses, ACR, etc. Captures passage issuance details of employees Records attendance and leaves IBM MP2003 COBOL/VSE VM/ESA VSE/ESA DB2/VSE VSAM Revenue Accounting System TLS (Traffic Load Summary) Deals with Passenger, Cargo, Mail and Interline revenues Traffic Load Summary provides management reports for route performance, class wise seat availability and costing analysis IBM MP2003 COBOL/VSE VM/ESA VSE/ESA VSAM Income Tax Pints monthly, quarterly and annual income tax statements Prepares salary certificates Printing of CBR annual register IBM MP2003 COBOL/VSE VM/ESA VSE/ESA VSAM Provident Fund Staff Ledger Keeps track of employee s provident fund and profit paid thereon. Also generates reports Staff ledger deals with staff related loans / advances / accounts to be incorporated in G/L IBM MP2003 COBOL/VSE VM/ESA VSE/ESA VSAM Section C PIA IT Environment Page 67
Module / Application Name Purpose / Details Hardware Platform Programming Language Operating System Database / File Structure Volume QUASAR Passenger Revenue Accounting SUN Fire V1280 Unknown Sun Solaris Version 8 Oracle 350GB Oracle DB Size AIRPRICE Marketing Software SUN Fire V1280 Unknown Sun Solaris Version 8 Oracle 65GB Oracle DB Size Traffic Performance System Marketing Intelligence CICS / COBOL VSAM Traffic Trend Bulletin System Marketing Intelligence PC VB6 / Crystal Reports 9 Windows 2000 Server SQL Server 2000 International Market Share Analysis System Marketing Intelligence PC VB.NET / Crystal Reports 10 Windows 2000 Server SQL Server 2000 Domestic Market Competition Analysis System Marketing Intelligence PC VB.NET / Crystal Reports 10 Windows 2000 Server SQL Server 2000 International Market Affairs System Marketing Intelligence PC VB.NET / Crystal Reports 10 Windows 2000 Server SQL Server 2000 Section C PIA IT Environment Page 68
AIRLINE INFORMATION MANAGEMENT SYSTEM (AIMS) AIMS are Windows 2000/2003 client-server based software for airline crew, aircraft, and flight management and operations control. It is designed to assist airline management to more efficiently control and minimize costs related to crew, aircraft, flight support staff, administration, hotel, transport and communications. The proposed ERP solution has to be integrated with AIMS to cater to crew scheduling. Core Modules Core modules that make up the AIMS system are as follows: Crew Management o Planning o Pairing / patterns / crew routes construction o Assignment o Tracking o Check-in o Records (administrative, medical, training, etc) o Reports and Statistics Operational Control o Aircraft scheduling and assignment o Movement and control o Reports Commercial Planning o Flight schedule preparation o Upload / download SSIM files o Reports Section C PIA IT Environment Page 69
AIMS Application Interface with Other PIA Applications The following applications running at PIA are interfaced with AIMS. Data is extracted from AIMS which is then used in these applications. DHD System Arrival / Departure System AIMS versus Sabre System Flight Safety SMS System Free Pak System Auto Pairing Auto Rostering MIS Report AIMS at PIA Following is an overview of how AIMS is being used at PIA: Commercial Planning Section (CPS) of Marketing Division prepares flight schedule for next one month in Sabre Airflite Application. Copy of flight schedule is sent to the following departments to ensure resource availability: Flight Operations Flight Services Engineering Signed copies are sent back to CPS regarding confirmation of resource availability by: Flight Operations for cockpit crew Flight Services for cabin crew Engineering for aircraft CPS reviews flight schedule. Upon satisfaction, CPS uploads SSIM File (flight schedule) in AIMS Application and intimates Flight Operations / Services Sections. Flight Operations prepares pairings / patterns for cockpit crew and Flight Services prepares pairings / patterns for cabin crew in AIMS. CPS makes cost / benefits analysis and reviews / amends flight schedule accordingly. Thereafter, Flight Operations and Flight Services make changes in crew patterns and generate roster plan for cockpit crew and cabin crew respectively in AIMS. Roster plan is published and a copy of the plan is sent to the crew s residence. Roster plan can also be accessed by crew through web or Interactive Voice Response (IVR). Both Flight Operations and Flight Services sections track roster plan for any change. Crew record is updated accordingly in the system. Reports are generated by respective sections as and when required. Section C PIA IT Environment Page 70
System Related Information Application Category Acquired System Operating System Windows 2000 or 2003 Database Front End Application Source Code APIs Oracle 9i Delphi, C-Sharp Not available. Any changes to standard application are made by vendor upon request. Not available. The only interface available is known as AIMS Report Generator. All customized reports developed by PIA IT department are published through this interface, which can be accessed by AIMS users through AIMS Menu. Section C PIA IT Environment Page 71
Vacation Management* AIMS Application Overview & Interface With ERP System Automatic Crew Pairing Generator* Crew Database Maintenance Preparation of Flight Schedule (Commercial Planning) Crew Pairings/ Schedule Costing* Marketing Department HOTAC & Travel Management* Crew Management Flight Schedule Uploads into AIMS Application Operational Control Crew Training Planning & Tracking* - Planning - Scheduling - Tracking - Reports PIA In-House Applications / Programs Aircraft Scheduling APIS Reporting System Interactive Voice Response Crew Access Flight Operations / Services Departments - DHD System - Arrival/Departure System - AIMS versus Sabre System - Flight Safety System - Free Pak System - Auto Pairing - Auto Rostering - MIS Reports Flight Operations / Services Departments Crew Access to AIMS via internet - Crew Personal Data - Leave Management System* - Crew Training* - HOTAC / Travel Management System* - Crew Allowances* ERP System * Currently not in use Section C PIA IT Environment Page 72
QUASAR QUASAR, a product of Sabre Airline Solutions, is a passenger revenue accounting system which enables PIA to account for unearned revenue associated with ticket sales and earned revenue associated with ticket use. In addition, it provides information on earned revenue and passenger statistics to the upper management, marketing, sales and accounting areas. Timelines of revenue information are delivered through the system s sales-based accounting method. It stores reference tables that can be maintained online or loaded from an industry data supplier. The proposed ERP solution has to be integrated with QUASAR to help PIA in managing and accounting for its revenues. QUASAR Modules QUASAR provides revenue and marketing information through following major modules: Computer Reservation System (CRS) Data Capture and Ticket Database The system captures audits and records ticket data received electronically from all issuing CRSs. It uses these records to prorate and audit. Interline Accounting The system processes, prices and audits the interline payables and receivables for other carriers, plus it produces all the standard IATA / ACH forms and generates and accepts IDEC tapes. Sales and Lifts Accounting Sales processing accepts all forms of passenger traffic documents from all sources. The system generates account-coded and balanced entries to post completed sales transactions and creates online queues to correct errors. Lifts processing determines earned revenue by attaching a prorated fare to each lift. Proration and Audits The system prorates the fare paid to the coupon level based on either ATA or IATA interlines settlement rules. This includes the application of special prorate agreements and industry provisos. Commissions, including incentives, are audited and prorated to the coupon level and expensed when the coupon is flown. The system also checks sales for the correct fare and ensures that it complies with conditions of that fare. Data Sources Data regarding ticket sales and its utilization comes from the following sources: PIA sales offices (using Sabre application for recording of ticket sales data) Section C PIA IT Environment Page 73
PIA appointed agents within Pakistan (using ABACUS system for recording of ticket sales data) Billing and Settlement Plan (BSP) Airline Reporting Corporation (ARC) Extended Ticket Capture (ETC) Sales data for each ticket is electronically recorded in Sabre and then transferred through Transaction Control Number (TCN) file and ETC file to TCN Edit Process, where it is corrected in workflow queue and the tickets are prorated and saved in ticket database for further usage. TCN contains information on passenger taxes, fare, mode of payment, etc. Tax and fare audit is performed in the work flow area of QUASAR. QUASAR Product Integration with Sabre Applications QUASAR is integrated with the following Sabre Applications: SabreSonic: Passenger solutions for capture of ticket data (TCN), airlines sales, electronic ticket usage, operated flights and flight schedules. Sabre AirMax: Revenue Manager, enabling sharing of historical flight coupon values. Sabre AirPrice: Contract composer for obtaining market (net) fares and their conditions of use. System Requirements Delivered over the internet, QUASAR is remotely accessed through the Sabre emergo Web access environment. This delivery method requires an ISP or direct network connection and a web browser. The Sabre Airline Solutions business manages all necessary hardware, upgrades and applicable third-party software. Section C PIA IT Environment Page 74
Other System Related Information In-house / 3 rd Party 3 rd Party Hardware Platform SUN Fire V1280 Operating System Sun Solaris Version 8 Programming Language Unknown DB / File Structure Oracle Source Code Not Available Section C PIA IT Environment Page 75
QUASAR SYSTEM An Overview Interconnected Modules & Interface with ERP Sales Processing Sales Data Capture Lift/Sales Accounting Match Lift Processing Sales Posting & Unearned Revenue Lift CRS Match Pricing CRS Processing Proration Create Debit and Credit Memos Earned Revenue Recognition Marketing Information CRS Data Collection Fare, Tax & Commission Audits Quasar Database Interline Receivables/ Payables Reports & Invoices ERP Financial Accounting System Section C PIA IT Environment Page 76
SABRE AIROPS SUITE Introduction AirOps provides centralized, real time access to critical data such as flight, passenger, crew, maintenance, aircraft, airport, weather, payload and navigational, as well as fuel data. Currently PIA is in the process of implementing this application suite. The proposed ERP solution has to be integrated with this solution. The AirOps suite includes the following modules: Sabre Decision Manager Sabre Dispatch Manager Sabre Ground Manager Sabre Load Manager Sabre Movement Manager Sabre Re-accommodation Manager Currently PIA is using the following modules: Sabre Dispatch Manager (used by Flight Dispatch Section) Sabre Movement Manager (used by Flight Control Section) Sabre Dispatch Manager (Flight Planning) It enables Flight Operations department to operate its own dispatching and flight planning system. It interfaces with virtually all passenger reservations and message switching systems and provides centralized functionality of mainframe dispatch systems in a flexible client / server setting. Sabre Movement Manager It enables PIA to monitor and schedule daily maintenance and flight operations. It uses a Gantt chart to graphically show flight leg information from a central database. This module presents information about current operations and maintenance events, which assist in evaluating problems and determining costeffective solutions. Section C PIA IT Environment Page 77
It also includes the following additional modules: The Maintenance Routine module The Sabre EC slots real time slot request and management module The browser-based Flight Information Display System provides real-time updates of the latest flight departure and arrival information in a continuous test display. Information Flow Schedule Planning Section of Commercial Division sends flight schedule which is updated manually in Flight Online Schedule System (FOSS). From FOSS the schedule is mapped to Sabre AirOps Application. Thereafter, following information is updated / tracked through this application: Flight departure and arrival time reporting Flight plan document is prepared by Flight Dispatch Section in FOSS System and handed over to Pilot which consists of aircraft assignment, crew assignment, departure time, cargo load, passenger load, altitude, baggage load, fuel weights, etc. Any changes in the flight schedule (delays, cancellations, diversions, etc.) are updated in the system by Flight Control Section and reported to Central Reservation Control (CRC). Reasons for delays / cancellations / diversions are also mentioned and reported to CRC. CRC intimates to different stations for any changes in flight schedule and if required, passengers are re-accommodated for a particular flight. Aircraft maintenance information is also updated in the system. This assists the Flight Dispatch Section to prepare flight schedule in accordance with fleet availability. Note Both FOSS and AirOPS are applications of Sabre which are used to assist in flight operations. At PIA, FOSS will be replaced by AirOPS (browser-based application); however the functionality will remain the same. System Requirements The AirOps Suite is available in a variety of platforms, including Windows and UNIX, offering flexibility in deployment. Section C PIA IT Environment Page 78
Sabre AirOps Suite An-Overview It provides real-time access to critical data such as flight departure / arrival time, passenger, crew, aircraft maintenance, airport, weather, payload, navigational and fuel data. Flight Schedule from FOSS is uploaded in AirOps. Thereafter, all flight operations are tracked and updated in the AirOps System. Commercial Planning Flight Schedule Details Sabre FOSS System Uploads Flight Schedule Details Sabre AirOps Maintains; - Flight Departure/Arrival Time - Passenger - Crew - Aircraft Maintenance - Weather - Payload - Navigational & Fuel Data Communicates; Flight Delays, Cancellations, Diversions, etc. to Major Document Flight Dispatch Section prepares Flight Plan Document, which consists of: - Aircraft & Crew Assignment - Departure Time - Passenger & Cargo Load - Altitude - Baggage Load - Fuel Weights Central Reservation Control (CRC) - Communicates changes in flight schedule to all stations Section C PIA IT Environment Page 79
SABRE AIRFLITE SUITE The Sabre Airflite Planning and Scheduling suite combines core flight scheduling functions such as scheduling, profitability forecasting and analysis, fleet assignment and slot management through a seamless integration with shared interfaces and database information. This integration improves system performance and accuracy and reduces development efforts, resulting in a flexible, stable and efficient tool that runs on multiple platforms. Currently PIA is in the process of implementing this application suite. The proposed ERP solution has to be integrated with this solution. The Sabre Airflite Suite has the following components: Airflite Schedule Manager It enables an airline to develop flight schedules that meet customer needs. Using this system, an airline can increase its profitability by enhancing the flight schedule development process. Schedule Manager simplifies scheduling tasks previously performed manually, thus making time available for schedulers to continuously explore better solutions. It provides schedulers with options so they remain in control of the decision making process. It helps create a corporate wide flight scheduling database and provides easy connectivity to legacy systems while offering powerful tools and utilities that enable schedulers to view, edit and report flight schedule information. In PIA, changes in schedule are communicated through telex and updated in AIMS Application by the Flight Operations department. Airflite Profit Manager It evaluates the profitability of a given schedule to assist in strategic, long range planning. It can identify strengths or weaknesses within a carrier s schedule as well as quantify the impact a particular schedule may have. Profit Manager forecasts the typical week profitability for a complete O&D network. As part of this evaluation, the tool produces forecasts of passenger demand, passenger traffic and passenger revenue on all services (host and competitor) in the network. Profit Manager delivers a greater understanding of customer and market behavior, an increased focus on network management, quicker evaluation of multiple scenarios, effective management of schedule changes and centralized data sources for corporate use. Airflite Fleet Manager It enables an airline to optimally allocate fleet capacity to improve the profitability of a schedule. Fleet Manager employs a sophisticated global optimization technique to provide an airline with strategic and tactical analysis support when developing profitable and operationally feasible schedules. It enables schedulers Section C PIA IT Environment Page 80
to swap aircraft assignments, re-time and cancel flights, improve utilization and minimize aircraft towing. Schedulers can also use Fleet Manager as a schedule feasibility solver when creating a feasible schedule. The application incorporates a patented O&D passenger flow model in its global optimization. Airflite Slot Manager Enables an airline to manage and track its slot rights at FAA and IATA slotcoordinated airports. It streamlines the slot request process, reduces the number of errors associated with generating and sending SSIM slot request messages, and monitors slot status The system reduces the possibility of costly errors and provides support to maximize the usage of valuable slot assets. System Requirements Products in the Airflite suite operate in either Windows or UNIX environment. Oracle 9i ILOG CPLEX (can be bundled with an Airflite system install package) ILOG Jviews (can be bundled with an Airflite system install package) SAS (for profit manager calibration) JRE 1.5 or higher Weblogic Application Server JDBC drivers Netscape 4.75+ or IE 5.5+ One Pentium III 750 CPU for every six users 1 GB of RAM per user Section C PIA IT Environment Page 81
Sabre Airflite Integrated Solution An-Overview The Airflite Suite offers an integrated decision support environment to optimize the entire scheduling development process end to end from planning to distribution. Schedule Evaluation Schedule Optimization Decision Support Module to Forecast Network Profitability and Evaluate Flight Schedules Multi-Purpose Decision Support Module to Optimize Total Network Profitability Database Management Schedule Management - Schedule Manager - Slot Manager Environment to Develop, Evaluate, Manage and Distribute Flight Schedules Flight Schedule Details AIMS Application Sabre Reservation System Section C PIA IT Environment Page 82
Sabre Airflite Integration with ERP System Schedule Management Flight Schedule Details Sources of Revenue & Cost for Profitability Analysis Schedule Evaluation Display Results ERP System Database Schedule Optimization Fleet/Aircraft Information Display Results Section C PIA IT Environment Page 83
SABRE AIRMAX SUITE Introduction Today s airlines require systems that enable them to selectively accept or reject passenger bookings based on their overall revenue contributions and adjust inventories and prices up to and including the day of operation in response to demand. Revenue management often means the difference between profit and loss. The proposed ERP solution has to be integrated with this solution. The Sabre AirMax Revenue Management Suite offers sophisticated tools to manage an airline s revenue. Sabre AirMax Revenue Manager It is a robust and flexible tool, a best-of-breed solution supporting the entire range of revenue management applications including reservations data collection, offline data collection, forecasting, overbooking, optimization, performance measurement and reporting. The system can be run in different processing modes based on the desired level of sophistication in inventory control. It offers three levels of inventory controls: leg and segment, virtual nesting and O&D. System Requirements The AirMax Suite is platform independent and uses a browser interface. Open system architecture enables interactive processing with external systems; whereas data is warehoused in an Oracle database. Section C PIA IT Environment Page 84
Sabre AirMax Suite An-Overview Sabre Reservation System Operational Data Inventory Details/Seats Allocations Based on Demand, Class Wise Seats Allocations to Maximize Profits & Reduce Cost AirMax Revenue Management System Revenue Accounting Financial Accounting Seats Capacities, Allocations Fares Overbooking Values Alerts, Flight Management Management Reports QUASAR System Database ERP Financial Accounting System Database Section C PIA IT Environment Page 85
SABRE CARGOMAX SUITE Sabre CargoMax is an airline automated decision-support tool which helps to manage cargo operations at an optimal level, thereby increasing revenue while maximizing profit and improving customer relationships. The proposed ERP solution has to be integrated with this solution. The Sabre CargoMax Revenue and Pricing Suite offers the following products to help improve air processing. Sabre CargoMax Revenue Manager It helps an air cargo operation increase profits through effective cargo space management. Extensive computer models estimate the capacity of each departing flight and determine the most profitable space allocation of various cargo products. With Revenue Manager, much of the guesswork is taken out of managing a complex cargo operation so an air cargo company can: Determine cargo capacities for future flight departures based on passenger load, mail and bags. Accurately plan cargo loads for maximum revenue by forecasting available cargo capacity by market, segment, equipment type, day of the week and time of day. Capture additional revenue and reduce offloads through an optimized overbooking function that considers booking behavior. Improve earnings and service quality as the result of proactive identification of revenue streams and potential service failures. Depends on no-shows, cancellations, and over / under-tendering. Allocating cargo capacity to station / customers; considering past usage, density, revenue and routes. Allocating cargo capacities to various products or alternatively determine the minimum acceptable Bid Price; considering network effect of demand, density, revenue and routes. Proactively monitor flights to identify critical flights; premium flights / promotional flights. Revenue Management Features Revenue Manager uses several comprehensive, state-of-the-art optimization and forecasting models to support air cargo operations: Allotment Management and Utilization Tracking Section C PIA IT Environment Page 86
The allotment decision-support model assigns cargo capacity to attain the highest net revenue. It evaluates bids based on relative revenues and costs, historical utilization and global network effects of the resulting allotments. The usage tracking model provides station and shipper summary statistics, comparing average space utilization to allotments by flight and day of the week. Overbooking Optimum overbooking levels are calculated so you can intentionally sell more cargo space than available to offset the effect of cancellations and no-shows. Forecasting Three types of forecasting are provided: Capacity Available: Cargo capacity is computed for each departing flight in terms of weight, volume and containers. This forecast is based on current and historical operational conditions. For passenger aircraft, the number of scheduled passengers and bags is also considered. Show-up Rate: The ratio of the actual amount tendered to the weight or volume of cargo booked is expressed as the shipment show-up rate. Based on the historical average of similar shipments, the rate can be computed by market, product, shipper or a combination of these factors. This data is then used by the overbooking model. Demand: Sophisticated models are used to forecast demand at flight level and at the O&D level. What-if Analysis Revenue Manager provides an efficient method for evaluating the impact various circumstances such as extreme peaks and unusual market demand may have on capacity allotment. Route Generation Alternative routes that carry a shipment from its origin to its destination are created by considering shipment characteristics and aircraft limitations Booking Engine Available cargo capacity is distributed to shipment requests for optimal revenue gain. Shipment feasibility checks cover the areas of available capacity, service time window, equipment type, connect points and minimum / maximum connect times. Booking shipments, modifying existing shipments and checking the status of confirmed and unconfirmed bookings can be quickly accomplished. Recommended Market Allocations and bid Prices Revenue Manager recommends bid prices and gradients for various flight legs that assist with market allocations. This is accomplished by employing origin-, destination- and rate class-based revenue mix methodologies. Using unit profit Section C PIA IT Environment Page 87
contribution to evaluate revenue mix provides the flexibility to treat shipments differently based on certain business relationships. However, the system can also evaluate revenue mix based on revenue, revenue adjusted by value and profit adjusted by value. Performance Monitoring The system monitors the performance of the user set overrides and the forecasting modules against the actuals. It also monitors capacity forecasts, demand forecasts and show-up rate forecasts. Revenue-Opportunity Evaluation The system provides tools to measure the revenue enhancement due to overbooking and network management, including demand forecasting, route generation and bid pricing functions. The following areas of CargoMax have not yet been implemented. PIA is planning to buy these: CargoMax Accounting Manager CargoMax Reservation System (presently PIA is using SITA-based application, which is going to be discontinued in the near future). Section C PIA IT Environment Page 88
Flow of Information Flight schedule is entered in Sabre Airflite Suite from where it is uploaded in Sabre CargoMax Suite through SSIM file. Cargo Sita Reservation System provides an air cargo operation with reliable booking, inventory control and shipment tracking capabilities details to Sabre CargoMax. Sabre steady state load management provides post departure data to Sabre CargoMax. On the basis of above information, CargoMax forecasts cargo capacity and also interfaces with Sabre AirMax Suite to calculate passenger history, EBT, PLA (Pay Load Available) etc. System Requirements CargoMax Revenue Manager is a web-based application that can be linked with other complex systems, enabling individual workstations to be distributed across a network. Written in Java and using Oracle database, it runs on a Unix-based platform and supplies users with interactive communication to external legacy systems or other client-server applications. The system delivers a friendly graphical interface that provides full capabilities of Windows, graphics, control buttons and pull-down menus. Section C PIA IT Environment Page 89
Sabre CargoMax Integrated Solution An-Overview User Inputs Overrides Cargo Capacities, Allocations Bid Prices Overbooking Values Alerts, Flight Management Management Reports Capacity Updates Sabre AirMax Pax Forecasts CargoMax Revenue Manager Schedule, AWB Data, Allotments Cargo Reservation System AWB History, Revenue, Cost & Other Data Post Departure Data Operational Data (AWB, etc.) for Sales & Revenue Accounting Data Warehouse / Cargospot Sabre Steady State Cargo Accounting System ERP Financial Accounting System Section C PIA IT Environment Page 90
FREPAK (FLIGHT REGULATORY SYSTEM OF PIA) It is expected that the proposed ERP solution would replace FREPAK that runs at PIA Head Office as well as Lahore and Islamabad offices. The Contractor must familiarize itself with the complete functionality of FREPAK as it would be responsible to provide similar or better functionality in the proposed solution. Introduction FREPAK is an on-line real-time system for monitoring and controlling of aircraft movements and delays to enable such control to be exercised. Flight schedule from AIMS application is uploaded through SSIM file format in FREPAK system on a monthly basis. Thereafter, this schedule is tracked throughout the month for any changes (cancellations, delays etc) in the flight. Arrival / Departure times and delays are logged by the concerned user immediately on receipt of aircraft movement (MVT) messages. System displays alert messages of missing times when no information is logged within 45 minutes of scheduled departures. Flight control operators are advised to ensure that either actual time of departure (ATD) is logged within 45 minutes or expected time of departure (ETD) is sent along with the delay codes / comments. Delay codes have been established to communicate information concisely and to record it in the system for display and analysis. This ensures that all concerned agencies over the PIA network are aware of current flight status and can take necessary actions downstream. On-line reports (daily and quarterly) are available which can be used to display all incidents contributing to delays which are categorized by departments responsible. Such categorization and access to information on flights immediately contributes significantly to improve passenger services. After month-end closing, data is also downloaded on PC for preparation of graphical reports and sent to GM Central Control. Flight information from FREPAK system is extracted and transferred through FTP to the following recipients: Flight Kitchen System GM Revenue for coupon follow up of ship papers Technical Group Support for shift maintenance Section C PIA IT Environment Page 91
Loads Aircraft passenger and cargo load signal information is also received after the flight has taken off. Movement message is received when the plane takes off and lands. System also provides flight load summary for the day and year-to-date. Load data is also transferred to Marketing Intelligence System. FREPAK Functions Menu Following are the main menu functions of FREPAK system. Flight Display (Departures) Flight Display (Arrivals) Department Delay Actual Times/Delay Code update Delay Comments Exceptions (missing/delayed flights) Flight SKD update Delay Code Table Punctuality / summary of delayed incidents Weather update Flight Inquiry Menu Traffic Performance Menu Miscellaneous Transactions Major Reports Flight departure/arrival report Flight update report Traffic Performance Report Baggage discrepancy Statement Weather history data Summary of delay incidents Aircraft Movement Report PIA Locations Using FREPAK System Karachi (all departments) Islamabad (all departments) Lahore (all departments) Section C PIA IT Environment Page 92
Technical Information In-house / 3 rd Party Hardware Platform Program Language Operating System DB / File Structure In-house MP2003 (IBM mainframe) COBOL/VSE, CICS/VS VM/ESA VSE/ESA DLI/VSE VSAM Section C PIA IT Environment Page 93
FREPAK System An-Overview FREPAK is an on-line real-time system for monitoring and controlling of Aircraft Movements and Delays to enable such control to be exercised. Flight schedule from AIMS Application is uploaded through SSIM file format in FREPAK system on monthly basis. Thereafter, schedule is tracked throughout the month for any changes (flight cancellations, delays etc) in the flight. AIMS Application Flight Schedule Details - Flight Kitchen System - GM Revenue for Coupon Follow Up of Ship Papers - Technical Group Support for Shift Maintenance Flight Information FREPAK System - Flight Schedule Tracking/Changes - Monitoring Aircraft Movement - Actual Arrival/Departure Times - Delays/Cancellations Recording - Passenger/Cargo Loads Information Reports Major Reports - Flight departure/arrival report - Flight update report - Traffic Performance Report - Baggage discrepancy Statement - Weather history data - Summary of delay incidents - Aircraft Movement Report Loads Information Marketing Intelligence System Section C PIA IT Environment Page 94
ROUTE PERFORMANCE AND PROFITABILITY SYSTEM It is expected that the proposed ERP solution would replace this system that runs at PIA Head Office. The Contractor must familiarize itself with its complete functionality as it would be responsible to provide similar or better functionality in the proposed solution. Introduction This system includes the route economics reporting operational statistics, revenue, variable operating cost, direct fixed cost and indirect fixed cost. System is capable to compute Profit/Loss based on actual revenue and cost. However, if the cost or revenue is not available for any flight, it is capable to estimate these based on available data using averages. The system is used as: Planning Tool: enabling the planner to model the revenue, cost and profit/loss in order to decide about the viability of route/flight. Financial Tool: enabling to monitor and achieve the intended results through proper costing and analysis. Accounting Tool: through maintenance of central up to date cost, operation statistics and revenue. The major benefit of the system is that, it can be used for better and timely decision making because of the analytical capabilities that work on its rich database. It provides flight performance along with operational statistics and various cost heads at the desktop. The system has interfaces with the following systems that were required to import / export or to exchange data in order to eliminate duplication / manual entry of data: Fuel Management and Analysis System Traffic Performance System Passenger and Freight System Passenger Revenue Various templates have been developed so that different sections could fill them in with the relevant cost data including: Contractual agreed rates Overlying rates Aircraft types and related data Traffic handling Section C PIA IT Environment Page 95
Engineering cost Cockpit/Cabin crew slip, ground transportation and hotels Depreciation, rental and other direct fixed costs / rates Indirect fixed cost The system can be accessed across the network through Citrix Meta frame software and is operational at the following departments: Finance Financial Monitoring Fuel Management Marketing Intelligence Chief Financial Officer Flight Operations System computes the following useful information: Break Even yield Break Even seat factor Passenger load factor Cost/ASK Yield/RPK Cost/Atk Cost/Block hours Revenue / Block hours Fuel burn off / Block hours Aircraft utilization/day Sector wise/flight wise/tail wise analysis System generates various types of MIS reports. It includes profit/loss summaries: Sector wise Flight wise Route wise Region wise Aircraft type Tail wise Application Technical Information Microsoft Visual Basic.net Microsoft SQL Server 2000 Crystal Report 10 Section C PIA IT Environment Page 96
Infragistics Control version 6.1 Meta frame Citrix Server (Presentation Layer) Section C PIA IT Environment Page 97
PIA Route Profitability & Performance System An-Overview The system is used to compute flight route profit / loss based on actual revenue and cost data received from relevant sources. Sources of Cost Data from relevant sections - Contractual agreed rates - Overlying rates - Aircraft types and related data - Traffic handling - Engineering Cost - Direct Fixed Cost - Indirect Fixed Cost System Computes - Fuel Management System - Traffic Performance System - Passenger & Freight System - Passenger Revenue Interfaces ROUTE PROFITABILITY System - Break Even yield - Break Even seat factor - Passenger load factor - Cost/ASK - Yield/RPK - Cost/Atk - Cost/Block hours - Revenue / Block hours - Fuel burn off / Block hours - Aircraft utilization/day - Sector wise/flight wise/tail wise analysis Departments Using The System Major Reports Departments Reports - Finance - Financial Monitoring - Fuel Management - Marketing Intelligence - Chief Financial Officer - Flight Operation Route Profitability; - Sector Wise - Flight Wise - Route Wise - Region Wise - Aircraft Type - Tail # Wise Section C PIA IT Environment Page 98
CORPORATE STANDARD STATION ACCOUNTING PACKAGE (COSSAP) COSSAP is an in-house developed software used to enforce financial discipline and accuracy of reporting / accounting at PIA stations. It was designed, developed, implemented and is currently being maintained by the Finance Department of PIA. COSSAP is an effective tool to assist the Finance Managers in performance of their duties and responsibilities. The basic idea of developing COSSAP was to achieve standardization all over the PIA network and to enable stations personnel to benefit from the computer technology so that station functions are performed effectively and efficiently. It is expected that the proposed ERP solution would replace COSSAP at all stations and Head Office. The Contractor must familiarize itself with the complete functionality of COSSAP as it would be responsible to provide similar or better functionality in the proposed solution. COSSAP Environment COSSAP is a multi-user and multi-tasking system having the facility to communicate with a remote computer. This implies that more than one user can operate one program simultaneously and more than one program can also operate concurrently. Computer 486/586 Operating System Application and Database UNIX Multi User - networked through modems ORACLE (Forms, Reports and RDBMS) List of Modules in COSSAP The following is a list of modules included in COSSAP: 1. Station Master Data 2. Direct Passenger Sales 3. Direct Cargo Sales 4. Direct Refunds 5. Passenger Agent Sales / Refunds 6. Cargo Agent Sales / Refunds 7. Credit Control 8. Banking Control 9. Miscellaneous Transactions 10. Disbursement 11. Revenue Accounting Documents Control 12. DADS (Pricing) 13. Market / MIS 14. Station General Ledger 15. System Administration 16. State Bank Section C PIA IT Environment Page 99
Module Details 1 Station Master Data Module This module is station specific and is controlled by station and contains station s information like: 1.1 Fixed Parameters; Station Code Currency Finance Manager Name Station Head Name Pay Voucher Serial No. Invoice Number Serial Cheque Number Serial Bank Name Address, etc. 1.2 Details relating to Passenger / Cargo Agents and Customers 1.3 Bank Guarantee of Agent, its effective and expiry date, etc. 1.4 On-line calculator 2 Direct Passenger Sales Module This module takes care of direct passenger sales data entry and printing of invoices. Sales Accounting Report (SAR) data can be entered through this module, as well, to account for credit / cash transactions. Major Documents: Passenger and Baggage Sales Report (R-1) & R-1 JV Passenger and Baggage Sales Report (SAR Summary) and SAR JV SAR Invoice R-1 Invoice 3 Direct Cargo Sales Module This module provides options to enter data, print invoices / reports relating to station cargo sales and Charges Collect Shipment Application. Major Documents: Cargo Sales Report (R-2) and R-2 JV Cargo (Incoming) Collection Report (R-3) and R-3 JV Section C PIA IT Environment Page 100
4 Direct Refund Module This module covers all functions relating to refunds at stations including printing of pay vouchers, cheques and credit notes. Major Documents: Refund Report (R-6) and R-6 JV R-6 Cheque Payment Voucher R-6 Cash Voucher R-6 Credit Note / Adjustment Voucher 5 Passenger / Agent Sales / Refunds Module This module pertains to the preparation of: R-10 Agent Sales Application, Domestic and International Agent Refund Application Reports Printing Agent Ledger Application Major Documents: Agent Sales and Remittance Report (R-10) and R-10 JV Agent Outstanding Reported in (R-10) Passenger Agent Aging Statement 6 Cargo Agent Sales / Refunds Module This module caters for data entry of R-11 and Cargo Agent Sales which thereby helps to produce R-11 and Cargo Agent Sales Reports. Major Documents: Cargo Agent Sales and Remittance Report (R-11) and R-11 JV Cargo Agent Aging Statement Section C PIA IT Environment Page 101
7 Credit Control Module This module covers R-5 and R-8 Applications. R-5 Application includes; Cash Receipt Printing Stock Control Facility Credit Adjustments Debit Adjustments R-7 R-8 data is compiled automatically and there is no need of transferring data to R- 8 from various disks. Computerized follow-up letter along with details of overdue invoices can be generated to exercise regular monitoring of recoveries as well as better co-ordination among parties, Finance Unit and Marketing Section. Major Documents: Invoice Collection/Adjustment Report (R-5) and R-5 JV Invoice Collection Cash Receipt / Adjustment Advice Invoice Collection Advice (R-7) 8 Banking Control Module Printing of R-9 and bank deposit details is controlled through this module. No data entry is required for R-9 rather it is compiled automatically from all relevant reports. Major Documents: Monthly Summary of Collection (R-9) and R-9 JV Reconciliation of Collection Account Outstanding Deposits Slips 9 Miscellaneous Transactions Module This module provides functions relating to R-4 including printing of invoices / Cash Receipt (CR) and maintaining stock of R-4 Cash Receipt. Major Documents: Miscellaneous Cash / Credit Transactions Report (R-4) and R-4 JV 10 Disbursement Module This module controls the following: 10.1 Accounts Coding Manual Application Section C PIA IT Environment Page 102
This application is used by all users but controlled at Head Office level and has following tables: Aircraft Table Department Table Location Table Accounts Table Staff Accounts Table Pay Code Table Pay Group Table Accounts / Department Table Location / Department Table Section C PIA IT Environment Page 103
10.2 Budget Control Application This application is used by all users with reference to their station and at Head Office level as well. This module has the facility to enter data manually and through downloading, if prepared separately on some other system. It also facilitates preparation of budget based on previous data contained in history. Disbursement Application Employee Record Application Payee Record Application Imprest Bank Reconciliation Application Payroll Journal Voucher Application Cash Flow Statement VAT Application On-line Query (disbursement history) Payroll Application Closing of Month Major Documents: Budget Control Register (Location-Wise) Budget versus Actual Statement (DEP/LOC/ACT. Wise) Monthly Payment Book Disbursement Accounts Summary Station Payment Summary 11 Revenue Accounting Documents Control Module This module controls application relating to issue / receipt / withdrawal of documents, printing of stock issuance advice, inventory report of Main and Sub Stocks, document serial break. Letters and Average Monthly Consumption reported by Agent / Counters, for both Passenger and Cargo. Section C PIA IT Environment Page 104
11.1 Inventory Control Module This module is operated by Head Office and stations as well. Starting point is the placement of printing orders by Head Office. This is followed by recording of receipts by Head Office; issuance of stock to stations; subsequent issuance by stations to its counter and agents; and reporting back by counters and agents recorded by station. This module also gives a picture of inventory in hand by Head Office, Station, Counter, Agents on real time basis for passenger and cargo stocks. 11.2 Material Management This is a complete module for material management with reference to Procurement and Logistic Support. 12 DADS (Pricing) Module This module controls DADS related information. It updates DADS floated rates (both passenger and cargo), prepares monthly party-wise memo ledger, D-20 report, D-21 report and Memo Ledger Adjustments. 13 Marketing / MIS Module This module caters for yield reports and MIS Application like Sales vs. Refund Statement, Sales vs. Total Statement, Ticket Sold vs. Ticket Voided, Route Wise Agency Sales, Agents Productivity Report, Cost / Sales Ratio, etc. 14 Station General Ledger This module complies with accounting data from respective reports and prints Station General Ledger Report (Report / Account Wise). Section C PIA IT Environment Page 105
15 System Administration Module It includes the following areas: Transfer of data to floppy disk Import General Sales Agent (GSA) data from floppy disk Deletion / Copying of Sales Data (R-10) Delete / Copy of Data except R-10 Format High Density Diskette (3.5 ) Database Back-up Check Agency Sales / Refund Data Disk NIL Report Application Check Contents of Disk / Tape Closing of Month 16 State Bank Module This module compiles and print reports required to be submitted to local State Bank authorities of different international stations. It requires customization as per local rules and regulations. Major Documents: Passages Sold / Ticket Issued Report Cancellation / Refund of Passage Report Baggage Carried Report Section C PIA IT Environment Page 106
Additional Requirements of COSSAP Web-based Centralized database Zero, two and three decimal set of programs Based on two bank accounts - disbursement and collection Keep records of document stock (passenger / cargo) Recording of all station s financial activities Based on current / post data concept Facilitate subsidiary ledgers Facilitate various MIS reports Facilitate to keep all historical data Facilitate generation of financial report for submission to Head Office Facilitate to generate General Ledger Facilitate customized printing of cheques / vouchers at various stations Facilitate multi-currency operation Facilitate downloading / validation of foreign data Facilitate migration of data for / from other user (Sabre) Records to be identified with user s code Previous records to be copied to avoid lengthy data entry General Requirements All modules / applications should have entry forms with Edit, Delete, Find, Display and Batch Proof options. All monthly data must be transferred periodically into post table and access to that data should be restricted to display and print. All reports should be closed before taking their data for General Ledger and final print. No data entry should be allowed for any closed report. No data entry for any report should be allowed beyond two months of closing No access on another location / station data Should provide display forms for historical data Display / printing options for history / current data may be provided based on specific criteria Should have privilege to display data and printing option to Head Office Users should be allowed to display / print their own data as well as others of the same location Duplicate printing of Pay Vouchers (PV), Cash Receipts (CR) and Invoices must be labeled as duplicate No editing, updation and deletion is allowed on printed PVs, CRs and Invoices Station-wise central control of PVs, CRs, and Invoices should be available Section C PIA IT Environment Page 107
Provision to print reconciliation for any previous periods Periodical updation of R-8, Passenger Agent Ledger, Cargo Agent Ledger, Passenger Inventory and Cargo Inventory should be provided on user option. At least 30 users should be able to logon at any given point in time from same station / location Section C PIA IT Environment Page 108
Major Function / Report Details 1. Ticket Wise Sales At PIA Counter (R-1) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Ticket wise data entry Ticket wise balancing of Debit and Credit Ticket validation with Document Control Module Ticket wise identification of Agent / Counter Ticket wise identification of APW / DG50 Ticket wise identification of form of payment Ticket wise identification of cash payment e.g. mna, jd, cc etc. Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to check rates with DADS Module Facilitate to calculate commission on prescribed rates Ensure generation of invoices Ensure balancing of cash with R-9 Facilitate date range display/batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Update stock inventory Update Budget Control Register if expense account is operated Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Facilitate to migrate periodical data for SABRE SYSTEM in given format 2. Sales Summary of PIA Counter (SAR) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Date wise entry of sales summary Date wise balancing of Debit and Credit Ticket validation with Document Control Module for credit transactions Ticket wise identification of Agent / Counter for credit transaction Ticket wise identification of APW / DG50 for credit transaction Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Section C PIA IT Environment Page 109
Facilitate to calculate commission on prescribed rates Ensure generation of invoices for credit transactions Ensure balancing of cash with R-9 Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Update stock inventory Update Budget Control Register if expense account is operated Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 110
3. Air Waybill Wise Sales At PIA Counter (R-2) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current Air Waybill only. Air Waybill wise data entry Air Waybill validation with Document Control Module Air Waybill wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to calculate Excise duty automatically Facilitate to check rates with DADS Module Facilitate to calculate commission on prescribed rates Ensure generation of invoices Ensure balancing of cash with R-9 Air Waybill wise balancing of Debit and Credit Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Update stock inventory Update Budget Control Register if expense account is operated Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Facilitate to migrate periodical data for REVENUE SYSTEM in given format (AWB matching program) Section C PIA IT Environment Page 111
4. SPEEDEX Sales At PIA Counter (SPEEDEX) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current Airway Bill only. Date wise data entry Date wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to calculate Excise duty automatically Facilitate to calculate commission on prescribed rates Ensure generation of invoices Ensure balancing of cash with R-9 Date wise balancing of Debit and Credit Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Update Budget Control Register if expense account is operated Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 112
5. Air Waybill Wise Delivery of Charges Collect Shipment By PIA Counter (R-3) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current Air Waybill only. Air Waybill wise data entry Air Waybill wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Ensure generation of invoices Ensure printing of cash receipts Ensure balancing of cash with R-9 Air Waybill wise balancing of Debit and Credit Facilitate date range display / batch proofing Facilitate to display original value, weight and currency at origin station (sales point) Facilitate finalization of entered data on user s option Generate debtor s ledger Facilitate printing of final user s defined reports Update cash receipt stock Update Budget Control Register if expense account is operated Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Facilitate to migrate periodical data for REVENUE SYSTEM in given format (charges collect matching program) Section C PIA IT Environment Page 113
6. Miscellaneous Transaction Not Covered Under R-1, SAR, R-2, R-3, R-5, R-10, R-11 At PIA Counter (R-4) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Cash receipt / invoice number wise data entry Cash receipt / invoice number wise balancing of Debit and Credit Cash receipt / invoice number wise identification of form of payment Facilitate to check employee s identification from Database Facilitate to check customer s identification from Database Ensure validation of Account, Location, Department, Aircraft Code etc. from Account Coding Manual Ensure generation of invoices Ensure printing of cash receipts Ensure balancing of cash with R-9 Air Waybill wise balancing of Debit and Credit Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Facilitate printing of final user s defined reports Update cash receipt stock Update Budget Control Register if expense account is operated Update of staff ledger Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 114
7. Invoice Collection At PIA Counter (R-5) Types of Transactions 1. Regular Invoice collection (same station) 2. Outgoing R-7 (Collection of other station) 3. Incoming R-7 (Invoice collected by other station) 4. Debit / Credit adjustment Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Invoice wise data entry Invoice wise balancing of Debit and Credit Invoice validation with Debtors Ledger Invoice wise identification of customer Ensure printing of cash receipts Ensure balancing of cash with R-9 Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Facilitate printing of final user s defined reports Update cash receipt stock Update Budget Control Register if expense account is operated Facilitate printing of final user s defined reports at Head Office level Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 115
8. Ticket Wise Refund At PIA Counter (R-6) Types of Transactions 1. Cash Refund 2. Cheque Refund 3. Credit Refund Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Both Pay Voucher and Credit Note once printed cannot be deleted No duplicate entry is allowed Refunded data should be saved in history file so that the same document cannot be refunded twice. Facilitate cheque printing Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to enter unlimited number of Taxes Facilitate to check lost tickets from database Ticket wise data entry Ticket wise display off debit and credit Ticket wise identification of Agent / Counter Ticket wise identification of APW / DG50 / TAC Ensure generation of Credit Notes Facilitate date range display/batch proofing Facilitate finalization of entered data on user s option Facilitate printing of final user s defined reports Update Budget Control Register if expense account is operated Update debtor s ledger Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Facilitate to migrate periodical data for SABRE SYSTEM in given format Section C PIA IT Environment Page 116
9. Debtor s Ledger (R-8) This is a by-product of R-1, R-2, R-3, R-4, R-5, R-6, R-10 and R-11 10. Report Wise Cash Collection and Bank Deposits (R-9) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. To enter cash collections and deposit details Each transaction identified with report source i.e. R-1, R-2, R-3, R-4, R-5, R-10, R-11, etc. Each transaction identified with report date and deposit date Display report wise figure Display report amount and deposit amount on the basis of given date identified with report source Display collection date wise figure Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 117
11. Collection Reconciliation Facilitate to enter date of credit by bank Facilitate entry of transfer from collection account to disbursement account Facilitate entry of transfer from collection account to Head Office Facilitate entry of transfer from collection account to New York composite account Facilitate entry of transfer from collection account to territories Facilitate entry of transfer from collection account to investment account Facilitate entry of dishonored cheque Facilitate entry of bank charges Facilitate entry of interest received Facilitate entry of exchange gain / loss Facilitate entry of unlink Debit / Credit Facilitate printing of bank reconciliation statement Facilitate printing of bank reconciliation journal voucher Facilitate date range display / batch proof Facilitate finalization of entered date on user s option Updation of closing book / bank balance Facilitate printing of final user s defined reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Facilitate to migrate periodical date for funds management Section C PIA IT Environment Page 118
12. Passenger Agent Sales / Collection Summary (R-10) Display closed date and user Display receivable for current transaction Display progressive receivable of entered LOC / AGT Display progressive total of Debit / Credit amount pertaining to the current transaction Sales date wise data entry LOC / AGT validation with Agent profile Sales date wise identification of location / Agent Transaction wise identification of form of payment Transaction identification, e.g. A, B, C, D Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Ensure balancing of cash with R-9 Ensure balancing of sales, commission, taxes etc with ASR10 Ensure balancing of refund, commission, taxes etc with REF10 Facilitate to display status of R-10. ASR10, REF10 with reference to sales date and location agents Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate passenger agents ledger Update cash receipt stock Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 119
13. Ticket Wise Sales By PIA Agents (ASR10) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Ticket wise data entry Ticket validation with Document Control Module Ticket wise identification of Agent Ticket wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to check rates with DADS Module Facilitate to calculate commission on prescribed rates Ensure generation of invoices Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Update stock inventory Facilitate printing of final user s defined reports Facilitate to migrate periodical data for SABRE SYSTEM in given format Section C PIA IT Environment Page 120
14. Ticket Wise Refund By PIA Agents (REF10) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current ticket only. Ticket wise data entry Ticket validation with Document Control Module Ticket wise identification of Agent Ticket wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to calculate commission on prescribed rates Ensure generation of Credit Notes Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Facilitate printing of final user s defined reports Facilitate to migrate periodical data for SABRE SYSTEM in given format Section C PIA IT Environment Page 121
15. Cargo Agent Sales / Collection Summary (R-11) Display closed date and user Display receivable for current transaction Display progressive receivable of entered LOC / AGT Display progressive total of Debit / Credit amount pertaining to the current transaction Sales date wise data entry LOC / AGT validation with Agent profile Sales date wise identification of location / Agent Transaction wise identification of form of payment Transaction identification e.g. A, B, C, D Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Ensure balancing of cash with R-9 Ensure balancing of sales, commission, taxes etc with ASR10 Ensure balancing of refund, commission, taxes etc with REF10 Facilitate to display status of R-10. ASR10, REF10 with reference to sales date and location agents Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate Cargo Agents ledger Update cash receipt stock Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 122
16. Air Waybill Wise Sales By PIA Agents (ASR11) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current Air Waybill only. Air Waybill wise data entry Air Waybill validation with Document Control Module Air Waybill wise identification of Agent Air Waybill wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to check rates with DADS Module Facilitate to calculate commission on prescribed rates Ensure generation of invoices Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Update stock inventory Facilitate printing of final user s defined reports Facilitate to migrate periodical data for SABRE SYSTEM in given format Section C PIA IT Environment Page 123
17. Air Waybill Wise Refund By PIA Agents (REF11) Display closed date and user Display progressive total of Debit / Credit amount pertaining to the current Air Waybill only. Air Waybill wise data entry Air Waybill validation with Document Control Module Ensure no duplicate refund is allowed Air Waybill wise identification of Agent Air Waybill wise identification of form of payment Facilitate to enter unlimited number of Taxes Facilitate to enter unlimited other accounts on both side i.e. Debit and Credit with department code Facilitate to calculate commission on prescribed rates Ensure generation of Credit Notes Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Generate debtor s ledger Facilitate printing of final user s defined reports Facilitate to migrate periodical data for SABRE SYSTEM in given format Section C PIA IT Environment Page 124
18. Disbursement (D-15) Types of Transactions o Cash o Cheque o Direct bank transfer o Adjustment o Reversal o Perquisites o Lease o DADS o Regular payments like rent etc Display closed date and user Display progressive total of amount pertaining to the current pay voucher Pay voucher wise data entry Facilitate validation of employee record where applicable Facilitate validation of payee record Facilitate validation of chart of account Facilitate acceptance of flight number, flight date, sector and aircraft tail number for specified accounts Ensure expenses are within budgetary allocations Update budget control Update staff ledger Ensure no duplicate payment is made / released Facilitate printing of normal pay vouchers Facilitate printing of normal cheques Facilitate printing of customized pay vouchers / cheque Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate payment of bill / invoice is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 125
19. Payroll At International Facilitate to enter all basic component of salary Facilitate to enter user defined formulas for allowances Facilitate to enter user defined formulas for deductions Facilitate to enter advances and its deductions Facilitate to generate staff ledger Ensure printing of pay slips Ensure printing of payroll Ensure printing of bank advices Ensure printing of pay voucher / cheque Ensure integration with Disbursement (D-15) Ensure generation of payroll journal voucher Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Facilitate printing of final user s defined reports Updation of budget control Updation of staff ledger Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 126
20. Imprest Reconciliation Facilitate to enter date of cheque presentation Facilitate entry of transfer from collection account Facilitate entry of bank charges Facilitate entry of unlink Debit / Credit Facilitate printing of Bank Reconciliation Statement Facilitate printing of Bank Reconciliation Journal Voucher Facilitate date range display / batch proofing Facilitate finalization of entered data on user s option Facilitate to report and adjust stale cheque Finalization of entered data on user s option Updation of closing book/bank balance Facilitate printing of final user s defined reports Ensure integration with General Ledger of closed reports Duplicate generalization is not allowed Generalization of foreign currency is done in PKR at given rates Section C PIA IT Environment Page 127
Requirements for Passenger Revenue Accounting GENERAL a) Sales based system with prime coupon concept for production of timely and accurate Revenue earned & Un-earned transportation liability information. b) Capability to accommodate data from the following sources through interfacing: i. Auto Tickets/Reservation System. ii. Facility for feeding details of manually issued documents and refunded documents iii. Insertion of off-line files generated by Station Accounting Package. iv. Revenue documents stock control system for recording distribution, its consumptions and stock inventory details on the basis of pre-printed stock control numbers. v. ARC/BSP sales data. vi. Data capture/scanning facility for recording coupons usage. vii. Proration Package. viii. Interface with Fare Quote System. ix. IDEC payable input. x. Lost documents database and subsequent control on utilization on the basis of stock control numbers as well as system-generated numbers xi. Utility for correct capture of web-based/ e-tickets sales/ utilization data c) The quantification and substantiation of four major balances related to transportation revenue for corporate financial statements. i. Earned Revenue. ii. Unearned Revenue. iii. Interline Accounts Receivable. iv. OAL inward billing i.e. Accounts Payable. d) Separation of Domestic and international Accounting & Controls. e) Correct capturing and accounting of all the taxes collected on the tickets under relevant heads of accounts f) Complete system integrity through defined security levels for different categories of users. g) Provision of detailed/ user friendly utility-wise procedural manuals for all categories of users h) Complete transaction-wise audit trail for all the activities carried out by the users of the system. Section C PIA IT Environment Page 128
i) Automated availability of historical data for at least 5 years with easy/online access. j) Use of most modern/sophisticated EDP tools with a variety of equipment types for real time processing at point-of-sale level for editing/ generation of MIS Reports PROCESSING OF SALES DATA Facility To: 1. Interface or capture Sales data from sources such as: a) Auto Ticketing. b) Station Accounting Package. c) Station/Agency sales data capture in real time. d) ARC/BSP sales. 2. Segregate all Domestic and international tickets sales transactions with separates accounting entries. 3. Capture sales data in multiple currencies at various locations and within the same location (for automated as well as non-automated/ manual sales) 4. Update facility or data capture of pre-printed Stock Control Number and Computer Generated Ticket Numbers. 5. Record all types of issued in exchange transactions with complete trail which include: a) Reissues/Even Exchange. b) Reissues/Refunds. c) Reissues/Additional Collection. d) Reissues/Combined with PK and OAL coupons. 6. Data validation features like Check Digit Calculation, Sales proceeds against banking etc. 7. Revenue Documents Inventory/Stock Control by Station/Agent. 8. Auto proration of international ticket sales for: i. Assigning prorated actual vales on each flight coupon (As per IATA standards). ii. Updating flight coupon-wise value in ticket database. 9. Auto proration of pure domestic tickets on the basis of point-to-point fares Section C PIA IT Environment Page 129
10. Correct proration of fully/ partially exchanged documents involving additional collections in the same currencies or the currencies other than the currency of original issue. 11. Auto Preparation of Sales Reports Status. i. Received and Not Received. ii. Processed and Un-processed. 12. Auto Generation of station-wise Revenue Documents /Inventory / Stock position reports with serial break identification. 13. Generate ticket/ ticketing agent/counter/ Sales agent/ station-wise reports / sales summaries reflecting all debit and credit sides of the transaction. 14. Automated audit system with respect to the following: i. Gross fares ii. Net fares iii. All taxes 15. Facility to generate computer based ADM / ACM and creation of database for updating stations / agent s ledger and monitoring settled / unsettled ADMs. 16. Auto generation of various MIS / productivity reports in local as well as accounting currency including but not limited to the following. i. Station / Agency- wise sale. ii. Region-wise sales. iii. 5th & 6th Freedom Traffic iv. Station / Agency- wise sales v. Route / Sector wise sales/ Yields Analysis. vi. Station Yield. vii. Normal / Incentive / Overriding Commissions Analysis. viii. Guarantees vs. Agency Sales comparison. PROCESSING OF UTILIZED / UPLIFTED COUPONS Facility To: 1. Interface with flight operations systems for either downloading or updating flight schedule/operated schedule and non-scheduled operations. 2. Records Receipt and Control of Lifted flight coupons. 3. Auto generation of a Report pertaining to non-receipt of lifted flight coupons on any given date. Section C PIA IT Environment Page 130
4. Capture system generated numbers and pre-printed stock control of all the lifted flight coupons. 5. Data capture on the basis of Prime coupon concept. 6. Create/ update lost ticket database for all missing/stolen and lost documents/ coupons (Passenger/ Blank Lost). 7. Interface lost ticket database to detect fraudulent utilization of missing/stolen tickets/coupons with the utilization source i.e. a) Uplifted Flight Coupons. b) Re-issued Flight Coupons. c) Refund Flight Coupons. d) OAL inward Billing Coupons. 8. Generate flown/earned revenue Journal Voucher with accuracy and direct input to corporate financial ledger. 9. Facility to generate productivity statement / MIS report with PKRs and yields including but not limited to the following: i. Flight wise flown revenue/yield. ii. Aircraft/ tail-wise flown revenue. iii. Sector performance by station/yield iv. Sector performance by fare basis/yield. v. Station/Agent wise flown revenue/yield. vi. Region wise revenue/yield. vii. Freedom wise revenue/yield viii. Analysis/Reports based on gross & net fares ix. Travel class-wise Revenue/ Yield REPORTING / PROCESSING OF REFUNDS 1. Ability to capture counter/ non-bsp PK document holding agents refunds and generate required reports. 2. Segregate all domestic and international refunded ticket transactions and carry out accounting functions under applicable heads of accounts. 3. Facility to capture refunded coupons data in multi-currency environments. 4. Facilitate capture of pre-printed stock control numbers and system generated ticket numbers of all the refunded documents. 5. Creation of Rejection Queues for editing/correction. Section C PIA IT Environment Page 131
6. Proration facility for refunded coupons on the basis of reported refund value. 7. Auto generation of status of Field Offices / Agents Refund Reports: a) Received or Not- Received. b) Processed or Un- processed. 8. Facility to generate Adjustment Debit Memos/ Adjustment Credit Memos and creation of database of updating station /agent ledger and monitoring settled /unsettled Adjustment Memos. MATCHING OF SALES AND UTILIZATION 1. Complete Matching of audit coupons with the corresponding utilized coupons on daily basis. 2. Un-utilized coupons must be listed separately for substantiating the Un-Earned Revenue appearing in the Corporate Ledger. 3. Provide details of UN-REPORTED ARC/BSP/Other PK documents. 4. Provide statements of gain / loss on refund inward billing transaction. 5. Duplicate utilization coupon report. 6. Provide reports though inward billing transaction where online sector business transferred to other carriers. 7. Provide Exceptional report for: a. Out of sequence coupons usage b. Usage coupon date is less than date of sale c. Variances in Pax status, sector, class of travel and fare base. d. Utilization of any black listed document. INTERLINE BILLING It must provide direct connectivity with IATA clearing house (ICH-Web) & be SIS compliant. Issue invoices for prime & first rejection billing Issue invoices for inclusion in billing Issue invoices for 6% currency rate variation Generation of rejection memo & invoices through IATA clearing house (ICH)/Airline clearing house (ACH) in line with SIS instructions. Production of standard IATA forms (Form 01,02,03) through ICH/ACH Section C PIA IT Environment Page 132
For all OAL uplifted coupons, invoices be raised to other airlines & receivable be generated thereby. Automatic re-proration Provision v/s billing matching Automatic rejection or acceptance of billing Addition of first rejection memos Processing of charge memos & 2 nd & 3 rd rejection memos Management of correspondence & final settlements Maintenance of rejection history Automatic addition of accounting entries Identification of under and over billing and generation of required documents in standard IATA format. Editing of various accounting documents and forms. Availability of online information of other airline documents for a period of 21 months. To generate ADM for recall of overriding commission on IDEC payable data, if any Auto check IDEC payable data & generate variance report The table for exchange rates must contain following rate issued by IATA i. Mean Rate for the last 5 banking days. ii. Mean Rate of Exchange based on entire current month. It must be able to capture data from IDEC files and should generate IDEC files for outward billing. Production of: o Form 1 o Form 2 o Summary of Form 2 o Detailed Invoice o Automatic Rejection Memos o Accounting Summary. The table for exchange rates must contain following rate issued by IATA. i. Mean Rate for the last 5 banking days. ii. Mean Rate of Exchange based on entire current month. The above table should generate automatic supplementary billing when exchange rate is negative. PRORATION An integrated auto proration package. It should allow the airline to detect the applicability of appropriate rule, proviso requirement, and bilateral/multilateral agreement based on various factors such as sales /uplift periods, seasonality, place of issue, class and fare basis, sector and regions, discounts, type of Section C PIA IT Environment Page 133
journey, routing etc. and applying the same after resolving any conflict. It should adhere to IATA standards. TRAINING Vendor would be required to impart in depth training to a Core team of End users and ISD personnel who will then act as the Master Trainers for training rest of the personnel in PIA. The training should cover the following areas. i. Operation of the system. Vendor would be required to provide a user manual. ii. System architecture iii. Operating Environment iv. Disaster Recovery full back procedures. Section C PIA IT Environment Page 134
Requirements for Cargo Revenue Accounting 1. Stock Management It is vital that Cargo Revenue accounting documents are closely monitored. Stock processing from the printer through to the agent. Allocation of air waybill numbers for Cargo Accounts Settlement System (CASS) locations. Agents blacklisted because of default, etc. Blacklisted documents utilization report. 2. Sales (Unearned Revenue and Billing) Incidental charges are being punched directly from the air waybills other charges column while these should be calculated from the applicable rate that should be present in the system e.g. fuel surcharge, security charges, dangerous goods fees etc. in both own sales and agency sales. Sales/Lift matching which is non-existent presently should be conducted to avoid possible malpractices in own sales. Airline office and CASS as well as non CASS areas Sales Accounting. Invoicing of GSAs, agent and airline offices. Processing and accounting of Debit/Credit memos. Processing and accounting of Charges Correction Advices. Matching of sales vs. flown air waybills in agency sales. Direct billing of agents based on uplift. Automatic proration. Capture and accounting of sales returns. Automated generation of CCAs and DCMS. 3. Charges Collect Sales and Billing Invoicing of ground handling agents, GSAs airlines and stations for CC airway bills. Computation and accounting of CC fees. Accounting of interline provision for CC Collection on behalf of other carriers. Reconciliation of collection vs. billing for CC air waybills and accounting adjustment. Direct billing of customers for air bills and ground handling charges through automated invoices. Management of ground handling documents other than airway bills. 4. Pricing The system should enable the filing of spot rates and special or market rates with a mechanism for approval. The system should automatically compute the applicable rates, spot rates, special or contract rates and tact rates, while simultaneously determining the agency commission. Section C PIA IT Environment Page 135
5. Provision for Trucking Agreements with trucking can be filed in the system and its accounting also. 6. Interline Proration Proration process should be automatic to increase productivity and efficiency. Multiple Prorate Agreements Special Prorate Agreements Proration filing area for testing bilateral agreements, provisions and requirements. 7. Uplift and Flown Processing (Earned Revenue) Required for quick evaluation and determination of earned revenue for every shipment uplifted. Flights manifest monitoring. Net revenue determination. Automatic proration. Provision for interline and trucking sectors. Management of part shipment. Accounting for CC airway bills transferred to other airlines. 8. Interline Billing Evaluation of air waybills issued by other airlines and efficient generation of interline billing to quickly recoup money owned. Billing for another carriers prepaid air waybills uplifted. Billing for transfer of charges collect air waybills. Charge memos to other airlines can be captured and included in billing invoices. Billing for another carriers prepaid air waybill uplift. Rejection billing. Generation of airline invoices. Generation of standard IATA forms. 9. Interline Billing received from other Airlines Evaluation of interline bills received from other airlines and checking for validity and accuracy. Management of part shipment. Automatic proration. Matching of provision vs. billing Automatic rejection or acceptance of billing Generation of rejection memos Automatic accounting entries 10. Mail Processing Section C PIA IT Environment Page 136
Billing and revenue accounting of the documents issued by Postal Authorities. All of P.O. Mail is handled including letter and cards closed parcels and empty mail bags Special rate agreements with General Postal Authorities Standard Universal Postal Union (UPU) rates. Uplift revenue accounting Interline provision Billing to Postal Authorities and accounting Obtaining of supporting documents for invoices. Preparation of invoices AV3/AV5 (Admin Wise) Automated follow-up of invoices Re-billing of rejected invoices Accounting of revenue and receivables. Standard Industry Reports for control/ MIS purposes Section C PIA IT Environment Page 137
C3 EXISTING IT INFRASTRUCTURE 3.1 Servers The IT Department at PIA maintains a number of servers and storage arrays to support various applications. Some of these applications have been developed in-house while some have been acquired from third-party vendors. A certain number of applications are also hosted externally. The block diagram shown below represents how different applications and modules are connected to the 10 GBPS backbone: Section C PIA IT Environment Page 138 Confidential
3.2 Connectivity The fundamental purpose of a communications system is the exchange of data between two parties. Communications networks are designed by interconnecting a variety of devices. This is done to help share the information and make efficient use of common resources available within an organization. A high-level block diagram representing the PIA network is given below: Section C PIA IT Environment Page 139 Confidential
3.2.1 Local Area Network (LAN) The PIA LAN is centered at the Computer Centre building situated next to PIA Head Office, in the vicinity of Jinnah International Airport. It is based on a fiberoptic backbone and serves different locations as follows: Section C PIA IT Environment Page 140 Confidential
3.2.2 Wide Area Network (WAN) PIA also supports major WAN connectivity linking all its regional and local offices to PIA Computer Centre. The WAN setup is being done in two phases as follows: Section C PIA IT Environment Page 141 Confidential
Section C PIA IT Environment Page 142 Confidential
SECTION D PRODUCT REQUIREMENTS (ERP PACKAGE & ADD-ONS) Section D Product Requirements (ERP and Add-Ons) Page 143 Confidential
D1 ERP PACKAGE AND ADD-ON REQUIREMENTS 1. Overview of Solution Requirements PIA desires to procure and implement an ERP Solution for its business needs which would comprise the following:- A comprehensive suite of integrated applications specific to Airline industry in: Finance Human Resources and Administration Procurement and Inventory Control Add-on applications, to be kept at a minimum Future value added-modules The solution to PIA s information needs and application requirements, described in Section D, Subsection D2, should conform to the features the marketplace is offering in Airline industry solutions. The Contractor must provide an effective solution in a cost beneficial way, keeping in view the specific information and application needs of PIA. The Technical Proposal submitted in response to this RFP should clearly describe how the Contractor will meet the needs of PIA, either directly, in whole or in part, or through alternatives. Further, the Contractor must suggest solutions that will require minimum customization or add-ons, maximum or completely seamless integration between applications, lower systems implementation risks, while at the same time providing the best possible performance at an economical price. The Contractor shall present a fully responsive written Technical Proposal to address the requirements defined in the following sections and explain approach to each requirement. The proposal must also identify any requirement the Contractor cannot satisfy. Sufficient details should be included to demonstrate the Contractor s knowledge of the project and the ability to satisfy each requirement. Each Contractor can submit only one solution. Section D Product Requirements (ERP and Add-Ons) Page 144 Confidential
2. Technology Requirements 2.1 New Technology The system should be designed in such a way as to easily allow the incorporation of new technologies, as they become available. 2.2 Multiple Environments In addition to the production environment, the system must support independent copies for training, development, and test environments. These environments must be sufficiently isolated from production and from each other so that operations in one environment do not affect those of another. The environments will be employed as follows: Production all production processing will be performed in this environment. Development all development activities including unit and system testing will be conducted in this environment. Test after all development, unit and system testing has been completed, this environment will be used for User Acceptance Testing before the system is accepted into production. Training for all in-house implementation and post implementation training activities 2.3 System Performance The system must be responsive with high availability feature. The system should support rapid fail-over or redeployment in the event of problems or planned maintenance. Ninety-nine percent of all fail-over events must take place in less than five minutes. Any volume (batch) processing must not interfere with online responsiveness or availability. Contractor must provide system availability figures of its proposed solution. In case various components have different values, these must be specifically mentioned. 2.4 Archive and Purge The system must support the periodic archival and purging of unused or obsolete information. Archived information should be available for historical reporting in such a manner that queries could be performed on archived data using automated data retrieval functions. Contractor must provide a complete data archival plan. Section D Product Requirements (ERP and Add-Ons) Page 145 Confidential
2.5 Recovery The system must automatically recover to the last complete prior transaction in the event of a failure. The system must clearly indicate to the user that a transaction failed and that it must be re-entered. Recovery must occur without operator intervention. Contractor must provide contingency and backup recovery procedures with guaranteed Service Level Agreements (SLAs). 2.6 Backup and Reorganization The system must provide for the unattended daily backup of all information and data to a media that can be stored offsite for disaster recovery purposes. Backups must not prevent the system from being available at all times and must not disrupt system operations. There should be no performance degradation during data backup. Database reorganizations should not significantly impair system availability. Contractor must provide the calculation of time taken to backup data with respect to data size increase. 2.7 Print Management The system should provide a method for managing the print environment for report distribution so that reports are directed to the appropriate print facility. Both high speeds centralized printing facilities as well as local LAN-based printing facilities will be employed in addition to printing over internet / intranet. 2.8 Technology Architecture The Contractor should provide recommendations of the technology architecture under which the proposed ERP Package will operate, with the following features preference: N-tiered Client/Server architecture incorporating thin presentation-logic-client communicating with client-neutral, server-based applications, communicating with the database Thin client, for remote users Applications distributed at servers located at Head Office Centralized database, located at Head Office While designing the technology architecture, the Contractor should ensure that the following are kept under consideration: Solution should be scalable with complete platform independence PIA does not intend to be tied down to a single platform Solution should be effortlessly portable from one system to another Should provide support for different flavors of UNIX; however it should be a totally interoperable solution Section D Product Requirements (ERP and Add-Ons) Page 146 Confidential
There must be open source support. In this context, the Contractor must specify the current scenario vis-à-vis the solution offered and the future roadmap Optimization of licensing costs for the platform software PIA s existing Local and Wide Area Network, and minimization of Wide Area Network bandwidth requirements, Simplicity of System Administration and Operations, Ease of business continuity planning and execution. Contractors should present a number of architecture options, providing pros and cons of each option, as well as the Contractors recommended option. 2.9 Server The Contractor should provide both its minimum and optimum configuration requirements for Application and Database Servers to run the ERP Package and other applications, consistent with the ERP features and proposed technology architecture (2.8 above), and multiple environment requirements (2.2 above). The recommended configuration should cater for the existing load as well as annual volume growth of 10-15% for the next five years. The configuration should be capable of retaining data for at least eleven years (that is, current year plus ten years historical record). The solution must be redundant, reliable and consistently available to allow uninterruptible 24x7 operations. The main servers will be housed in PIA s Information Technology Department. The production server configuration should include redundant (RAID5) data storage (including SAN) and multiple processors and cater for compatibility with PIA s existing LAN / WAN environment as described in Section C, Subsection C3. The Contractor should take into consideration the areas of performance and scalability, reliability and fault tolerance while recommending Server configurations. Contractor must provide performance guarantees of the solution under different scenarios such as concurrent users during normal working, during data backup, during overload, during partial system failure, etc. 2.10 Systems and Network Management Tools Contractors are required to recommend suitable Systems and Network Management Tools. These tools should ensure proper planning, configuration, and problem handling of IT resources and support such tasks as defining, resolving, and managing problems; operating networks and multi-vendor systems; distributing and managing software and data; controlling operations; Section D Product Requirements (ERP and Add-Ons) Page 147 Confidential
planning and managing performance; administering security; maintaining asset information; and planning for the future capacity of systems. 2.11 Authentication The system must support authentication methods that will assure that only authorized users are able to access protected data and transactions. These could include support for digital signatures and PKI infrastructure also. Section D Product Requirements (ERP and Add-Ons) Page 148 Confidential
3. General Requirements 3.1 Common Characteristics Common characteristics represent capabilities that should be shared by all functional areas of the ERP Solution. They are to be considered along with the more specific functional requirements that follow in the design of a system. 3.2 Integration The software should support modern best business practices, with data located in one integrated system shared across all organizational units. The software should support enterprise-wide business processes with a goal of eliminating multiple handling of data and increasing accuracy. It should also be integrated with future modules using the same development language / platform. 3.3 Configuration PIA desires to procure a system that will require minimum software modification to meet its business requirements. The software should allow for easy configuration to meet those requirements without changing software code or requiring Add-ons. Changes to parameters, software switches, processing rules, and other tailoring approaches may be acceptable. The configuration should be accomplished in a way that does not adversely impact future installation of system upgrades. The software must be flexible enough to allow easy reconfiguration as requirements change. 3.4 Technology Interfaces The Contractor should provide standard application programming interfaces, tools and methodologies that allow current and future releases to accommodate interfaces without re-programming. A standard approach to interfaces should be employed to avoid multiple, unique approaches for different systems. The Contractor will have to ensure, at its cost, availability of not only its own APIs but also from other parties to enable integration with other applications that it has proposed along with the ERP as well as existing applications that will continue to run at PIA and will require integration with the proposed ERP. Contractor must ensure to provide XML-based APIs wherever these are available. All these APIs will be made available to PIA and PIA will have the right to use these for application integration and report generation. Section D Product Requirements (ERP and Add-Ons) Page 149 Confidential
3.5 Access Control The system must support multiple levels of security while providing single sign-on facility to the users. This includes protecting certain fields from unauthorized access. In addition, access to certain functions and data must be protected until they are approved by PIA s concerned policy makers. Application security should be integrated with database security. Data files / tables should only be accessed through the ERP; direct access through different query languages should not be possible. Templates or group functions should be provided to facilitate maintenance. Changes in assignment (employee transfers) or termination / retirement should automatically trigger a review of the employee s security privileges. Comprehensive logs of transactions and security incidents must be maintained for auditing purposes. System should provide authorization, authentication, integrity and non-repudiation facilities for critical transactions. Password length as per industry standards should be supported. System should be capable to maintain audit trails and logs, allow secure remote login and support digital signature and time stamp, etc. 3.6 User Interface The system should provide an intuitive, user-friendly, and easy-to-use interface that minimizes the need for training. The system should have a common look and feel across all applications with screen labeling in English and Urdu. Online help should be available for all applications and should allow for customization. The system must address the needs of infrequent or low volume users as well as those who use the system several hours each day. It should have fast data entry screens for bulk data entry. The system may be accessible using standard personal computer through browser. It should also allow opening multiple sessions and defining navigational menus that can be created by end-users according to their job requirements. It should also allow for switching between different programs without first having to exit from the system. Business rules should be incorporated into the system such that the rules are applied at the time information is entered into the system. The system should identify errors, inconsistencies or additional requirements at the time data is entered. Processing of the transaction should be suspended and / or re-routed to resolve the problem in real time. 3.7 Reporting / Inquiry The system must include comprehensive inquiry / reporting tools that allow for easy access to authorized data. Executive interfaces to the data with drill down capability to examine details should be included in these tools. It should also be possible to create reports that reflect status as of a specified point in time. Standard reports should be included to serve as models for customized reporting and to provide for basic functional reports. Report wizards or similar techniques Section D Product Requirements (ERP and Add-Ons) Page 150 Confidential
should be available to guide users through report creation. The system must be designed such that reporting activities do not compromise responsiveness of the interactive system. Reports should be formatted to print on local PC and LAN attached printers, centralized high-speed printers, as well as over internet and intranet. It should be possible to deliver fixed reports to users on a pre-determined schedule to be reviewed online, to be retained online or to be printed at the user s discretion. System should be able to deliver the reports using its own messaging / workflow engine as well as PIA s email system, Lotus Notes. The system should be able to demonstrate useful demographic and forecasting capabilities; support text-based, parameterized and wild-card searches; and provide users the ability to develop ad hoc reports at their discretion. The system must include a data dictionary or similar provision to allow non-technical users to identify the appropriate data elements for inclusion in their reports. 3.8 Analytic Tools PIA desires decision support tools and information bases that are fully integrated with the system to facilitate strategic planning, tactical operations and organization-wide analysis. The system should support the easy movement of data to common packaged PC-based applications such as Microsoft Office. The system should include the ability to locate information or text through a search capability. The system should be capable of producing what if scenarios to support decision-making. 3.9 Communication The system should foster information sharing at all levels of the organization. For example, policy directives and goals should be incorporated into the budget planning process; departments should be able to share purchasing intentions and specifications and best business practices should be readily available for consultation. In addition, the system should provide a single place for users to quickly access information and updates on organizational news and policies. 3.10 Flexibility The system must be easily reconfigured to respond to changes in business practices, policy directives, organization structure, statutes and regulations. As business requirements change, the system must also change to support the new Section D Product Requirements (ERP and Add-Ons) Page 151 Confidential
requirements. Flexibility should extend both to enterprise-wide as well as industry specific practices. 3.11 System Availability Overall it should be a highly available solution. It must be available for access by authorized personnel from anywhere at any time of the day or night (24 x 7 availability). The system must be equally usable from remote locations as from the Head Office. Web-based access should be supported. 3.12 Transaction Timing The system must support real time operations. Changes to data or the status of processes should be immediately available in the system. System operations should not artificially constrain the business processes supported by the system. The system must support effective dating for transactions, including both future and retroactive changes. The authority for such transactions must be included in the security capabilities of the system. The assignment of a retroactive date must generate the changes required to bring the system up to the current date. 3.13 Online Documentation and Training The system must include customizable online documentation and training materials such as context-specific help, search capability, business process documentation and process maps. 3.14 Storage / Record Retrieval Record collection and retention is an important organizational requirement. The ability to easily archive, retain and access records is required. Records retention procedures must allow information to be stored in a way that can be accessible indefinitely. Section D Product Requirements (ERP and Add-Ons) Page 152 Confidential
3.15 Data Support The solution should be able to support multiple data types text, image, voice, etc. It should be able to support data upload to and download from different systems in multiple formats. Besides simple upload / download facility it should also be able to communicate and support data interchange with mobile devices such as cellular phones, handheld terminals, PDAs, etc. It should also be able to support other devices such as scanners, barcode readers, biometric devices, card readers, RFID devices, etc. Support for important messaging / data formats / standards must include, as a minimum, Aircraft Communication Addressing and Reporting System (ACARS), SITATEX, ASCII, EDI, SMS, XML, Spec 2000, UNeDocs, MS-Office, Lotus Notes, etc. 3.16 System Security System provided must be secure and meet all standard security requirements i.e. Identification, Authentication, Authorization and Integrity. System should allow implementation of industry standard security policies and capability to evolve to meet security challenges. Details of the proposed security tools must be provided. 3.17 Web-enablement The proposed System should be Internet ready and allow web-enabled access to users from anywhere across the world through a web portal. It should also be compliant with the Service Oriented Architecture (SOA). 3.18 Self-Service Portal The proposed System should be capable of providing the users access to selfservice portals where they can log in and obtain different levels of information such as directory lists, airline schedules, seat availability on flights, etc. It should also allow users to update personal information and enter requests such as leave and passage approval, purchase of tickets, etc. 3.19 Workflow The proposed System should be capable of providing Workflow functionality to users by which information and requests could be automatically routed to the concerned levels for approval. Section D Product Requirements (ERP and Add-Ons) Page 153 Confidential
3.20 Others Besides above mentioned characteristics the proposed ERP should also be capable of: Supporting multi currency Supporting multi languages Supporting multiple legal companies Supporting multiple tax structures (that is, supporting individual country tax structure and reporting) Interfacing with legacy systems Storing transactions and balances of legacy systems Supporting user defaults Supporting user defined screens Supporting multiple date formats Supporting multiple decimal formats in amounts Providing easy development of user defined reports Supporting user defined fields Scheduling of jobs for unattended operations Maintaining effective dates of master file data Section D Product Requirements (ERP and Add-Ons) Page 154 Confidential
D2 INFORMATION NEEDS AND APPLICATION REQUIREMENTS PIA requires management information systems that support its decision makers by fulfilling their daily information needs and also assisting them in creating different scenarios and providing what-if analysis. Some of PIA s operations are centralized at the Head Office while many are distributed at its various stations both online and offline domestic and international. Contractor must analyze these functions and provide a solution that will best fit this model. The business information needs of PIA have been defined / identified at various levels of governance and management starting with those of its Board of Directors and then of its individual functional areas. 1 Information Requirements of Board of Directors An analysis of the past and present can help set growth targets and make informed decisions with regards to the future direction of PIA. Based on this notion the Board of Directors may want an analysis of operational and financial performance that should also help derive a future prognosis of PIA. The information and analytical demands at this level call for speed and accuracy though less of this information fits a predefined format or structured model. The broad-based information needs of PIA s Board of Directors may be classified as follows: Familiarity with the mission, vision, goals and objectives of PIA to be able to deliberate and decide on its business plans and strategies short-, mediumand long-term Awareness of the trends in the international airline industry to be able to assess its impact on the business of PIA Knowledge of government policies with regards to the airline industry and its impact on PIA s business strategy Understanding of the competitive (and investments) scenario in the local, regional and international airline industry to be able to reposition PIA, if necessary Analysis of flight safety, security and performance standards for formulating future strategies Awareness of PIA s current market position vis-à-vis competition Status of ongoing and planned investment projects as well as of other projects that are significant and important to PIA Analysis of the operational and financial well-being and strengths and weaknesses of PIA Section D Product Requirements (ERP and Add-Ons) Page 155 Confidential
Understanding of the manpower needs of PIA to consider sanctioning of new hires, promotions, etc., and to suggest any other organization changes Attentiveness to the corporate image of PIA in both the local and international markets 2 Information Requirements of Senior Management The Chairman and CEO and other key senior management personnel are responsible for managing the day-to-day operations of PIA. Their information needs pertain to monitoring, controlling and directing the operational and financial management activities of PIA. In disseminating information to management, one needs to avoid information overload. The need is for the right amount of information and at the right time. These should be fulfilled with features such as Key Performance Indicators (KPIs), Balance Scorecards, Dashboards, etc. The information requirements of PIA s management pertain to: Close and thorough monitoring of progress on ongoing and planned projects Monitoring the status of aircraft availability, passenger and cargo revenues, route and aircraft profitability Tracking fixed assets and materials inventory Historical, current and projected financial status of PIA Monitoring of actual expenditures against budgets Assessment of current and future manpower requirements derived from PIA s operating plans and business strategies Evaluation of the strengths and weaknesses of existing manpower resources which among other things assist in determining the training and development needs, management succession planning, etc. Awareness of inventions, innovations, new markets, new customers and geographical changes It is important to reemphasize that the information requirements of PIA s Board of Directors and senior management do not necessarily lend themselves to a predefined structure and do not fit a particular descriptive model or arrangement. Their information requirements will have to be fulfilled by collecting, processing, analyzing and disseminating data gathered from a variety of internal and external sources. For this purpose, there is a need to implement Strategic Enterprise Management, Business Intelligence, and Data Warehousing application systems with the following characteristics: Section D Product Requirements (ERP and Add-Ons) Page 156 Confidential
Business planning and simulation Business information sourcing (internal and external) Business performance monitoring and analysis Company benchmarking Data Mining Open reporting architecture 3 Functional Information Requirements The identification of functional information needs and related application systems have been approached by determining the essential business processes PIA has to perform in actualizing its mission and vision and fulfilling its business objectives. These pertain to the following functional areas: Finance Human Resources and Administration Procurement and Inventory Control Each functional area has been discussed by identifying the functionality required within each area. Besides these functional areas much of PIA s operations are handled at its various stations. Contractor will have to take into account the operations at these locations both domestic and international. Contractor should note that the following sub-sections contain minimum functionalities required by PIA that have been provided for indicative purposes. These will be finalized by Contractor in consultation with PIA during the preparation of conceptual design of ERP. The Contractor will then configure the ERP based on the conceptual design. Section D Product Requirements (ERP and Add-Ons) Page 157 Confidential
3.1 Finance As PIA increases investments in its new fleet the role of the financial management function will assume a much bigger dimension. In addition, there will be a need for instituting more effective financial discipline and controls throughout PIA. The successful realization of PIA s enhanced investment strategy also enjoins on the financial management function to ensure efficiencies, cost effectiveness, and responsiveness in line with the requirements of management and Board of Directors. The financial management function in PIA is organized around: Costing and Budgeting Revenue Accounting Funds Management General Accounting High Level Specification of Finance Applications 3.1.1 General Ledger The General Ledger is the key component of any financial management system. It gathers transactions/data from various sources for maintaining the books of accounts and for reporting to management, the Board of Directors, and other stakeholders of the company. The essential functionality of the General Ledger should be: Maintaining charts of accounts for multi-company processing Supporting multiple chart of accounts for one company Maintaining ledger accounts with complete hierarchical structure Maintaining hierarchies of cost centers and profit centers Providing graphical representation of hierarchies with easy navigation and drill-down features Maintaining statistical ledgers for quantities, volumes, number of flights, etc. Allowing at least 30 digits for the qualified chart of accounts in order to incorporate notional account, group companies, business units, locations, aircrafts, flight numbers, departments / cost centers based on the financial statement segments Allowing at-least 14 posting periods in a financial year Allowing multiple financial years for multiple companies Classifying multiple levels of chart of accounts Section D Product Requirements (ERP and Add-Ons) Page 158 Confidential
Providing and supporting a dynamic business unit structure in the chart of accounts Allowing mass maintenance of accounts by copying one chart into another as reference or deleting / blocking multiple accounts Allowing access to certain types of accounts to authorized users / usergroups Uploading budget from the Budgets and Cost Management System Posting of journal entries from subsidiary ledgers Processing entries directly entered in the General Ledger Accounting for special projects / subsidiaries; such as SpeedEX, etc. Processing entries from other systems Auto-generating entries of recurring items Maintaining and analyzing budgeted and actual amounts by account head Allocating expenses on the basis of defined parameters Maintaining multi-currency accounts Catering for inter-company settlements Maintaining ledgers for management and statutory reporting Generating consolidated financial statements (Balance Sheet, Profit and Loss Account, Cash flow, Statement of Changes in Equity, etc.) along with consolidated supporting schedules setting off inter-company balances Allowing separate closing of individual areas for example Fixed Asset, Accounts Receivable, Accounts Payable, General Ledger, etc. Allowing real-time online updates of General Ledger along with provision of temporary and permanent stoppages for account closing purposes these stoppages should be controlled by authority levels based on different types of vouchers / sub-ledger entries Allowing posting of transactions after temporary closing Allowing multiple year-end processing Processing month-end and year-end accounts Automatically calculating retained earnings Generating financial statements 3.1.2 Financial Analyzer The financial analyzer is a tool for detailed analysis of financial data and ratios and it fulfils varied management information requirements. It helps management view the financial performance of the company from various perspectives, which may not be possible through standard General Ledger reports. It should be able to produce complete books of accounts with accompanying notes to accounts in line with International Accounting Standards and the Companies Ordinance. It should also be able to provide comparisons of actual / Section D Product Requirements (ERP and Add-Ons) Page 159 Confidential
current period data with budgeted data as well as with data of previous period and same period of previous year. 3.1.3 Fixed Assets Management The Fixed Assets system should support tracking of fixed assets including, additions, transfers, disposals, original cost, net book value and depreciation, etc. It should assist PIA in managing the complete asset management life cycle that is, acquiring, tracking, managing and disposing and should include every aspect including labor, administration / maintenance, equipment, inventory and warranties. It should be capable of: Maintaining ownership data for assets Recording asset supplier information Maintaining number of flying hours in case of aircrafts Maintaining original and net book value, Calculating asset depreciation based on multiple depreciation methods, Allowing changes in book value and changes in depreciation rate Tracking physical location of assets at any given time Maintaining asset and depreciation records for management and statutory reporting Recording asset replacement value Allowing zero value assets Allowing inter-company assets transfer, for example from one subsidiary to another Showing assets in-transit during transfers till acknowledged by receiving location Handling mass transfer of assets Splitting of assets Recording asset assemblies and sub-assemblies (parent-child relationship) Processing disposal of assets Capitalizing projects and transferring costs Revaluing assets Section D Product Requirements (ERP and Add-Ons) Page 160 Confidential
3.1.4 Cash Management The Cash Management system should maintain up-to-date balances of PIA s bank accounts and of cash in-hand and provide cash flow forecasts. It should be capable of: Maintaining records of daily cash balances including details of daily receipts and disbursement of cash Monitoring bank balances Identifying withdrawal limits before a transaction for each bank account maintained in the system Transferring funds from one bank account into another Uploading and recording account statements received from banks Automatically processing bank reconciliation statements based on payments and deposits Forecasting cash requirements based on accruals, cash in hand, bank balances, outstanding and anticipated invoices from suppliers and agents / other customers, etc. Monitoring of markup rates and appropriate placement of funds Calculating markup in running finance and deposit / savings accounts Maintaining detailed records of investments of liquid funds including maturity profiles of funds invested Supporting user-defined cash flow statements 3.1.5 Petty Cash Management The purpose of Petty Cash Management system is to maintain and process cash disbursements at various locations including Head Office. It should be capable of: Recording cash receipts Recording cash disbursements Maintaining and verifying cash balances Determining withholding tax and sales tax on cash disbursements Submitting claims to Head Office for replenishment of petty cash 3.1.6 Accounts Payable The Accounts Payable system that supports maintenance of financial liabilities should be capable of: Creating and managing vendor master records Section D Product Requirements (ERP and Add-Ons) Page 161 Confidential
Adopting to PIA s payment policies including the limits of approval authorities Recording supplier s invoices and updating liabilities Checking for duplicate invoices Performing the two-way and three-way match between purchase order, receiving statement and supplier s invoice Processing payments to suppliers, employees and other parties through different methods such as cash, authority letter for payment through Petty Cash, cheque both manual and pre-printed system generated, bank transfer letter both hardcopy and data file for upload, letter of credit, credit card, internet, etc. Allowing partial payments against invoices Splitting one payment between different entities Linking with payment systems of various banks offering e-payment services Recording withholding tax liability Processing payment of government dues deducted at source and generating tax challans / returns Maintaining records of General Sales Tax paid on purchase of materials and hiring of services for subsequent credit at the output stage Allowing payments to be made both from Head Office and remote locations Providing online payment support for PIA s upcountry and international stations Provisioning for making payments in foreign currencies Booking exchange rate gains and losses for foreign currency payments Allowing generation of recurring payment vouchers for recurring payments Aging of accounts payables 3.1.7 Revenue Accounting This is the key functionality required by PIA to capture and manage the revenues generated by its operations at various locations. This includes revenue streams generated from passenger, cargo and interline segments as well as other services provided by PIA. Revenue Accounting System should supports IATA norms & connect to IATA web application plus upgrade to future IATA norms implemented without delay. Revenue Accounting should be SIS (Simplified interline settlement) compliant. It should be capable of: Provision for import of other Manual data like exchange rates etc. Capturing details of tickets / air waybills issued to agents (stock control). Capturing ticket / air waybill number and other details for sales of tickets / booking of cargo. Handling sales proceeds and matching of passenger revenues. Handling bookings and matching of cargo revenues. Section D Product Requirements (ERP and Add-Ons) Page 162 Confidential
Handling revenues generated through inter-line operations. Handling sales of services to other airlines / agencies. Handling sales returns / refunds to customers as well as agents Segregating all domestic and international refunded tickets. Handling sales returns / refunds in multi currency environment. Calculating agents commissions. Integrating with Sabre Applications, PIA s QUASAR system (for passenger revenues), SITA hosted applications (for cargo revenue) and PIA s Awards Plus program (for passenger ticket redemption). Contractors should carefully read details of PIA applications, particularly about COSSAP, presented in Section C2 Existing Systems. The proposed solution should be able to fulfill all the requirements stated therein. Contractors should carefully read Requirements for Passenger Revenue Accounting presented in Section C2 Existing Systems. The proposed solution should be able to fulfill all the requirements stated therein. Contractors should carefully read Requirements for Cargo Revenue Accounting presented in Section C2 Existing Systems. The proposed solution should be able to fulfill all the requirements stated therein. Ticket wise identification of APW and automated invoice generation along with accounting treatment thereon. MCOs accounting and report generation of tickets issued against MCO along with accounting treatment thereon..issuance of automated short collection investigation reports and ADMS for any variation in MCO amounts and tickets issued thereon along with proration. Capable of creating sales contract, agreements, orders with other airlines and third parties based on different criteria such as flat rate, fixed price, time & material. Section D Product Requirements (ERP and Add-Ons) Page 163 Confidential
3.1.8 Accounts Receivable The Accounts Receivables system is required to support tracking of receivables. It should be capable of: Creating and maintaining customer / agent master records Creating customer groups and clubbing related customers together Managing credit ratings for customers / agents Creating sales contracts / agreements / orders with other airlines and third parties based on different criteria such as flat rate, fixed price, time and material, etc. Creating sales orders by direct manual entry in the system as well as by automatically converting data imported from other applications such as QUASAR, Sabre, etc. Generating invoices and maintaining receivables Sending payment reminders through email and fax Providing multi-currency support for sales of tickets and other goods and services Generating debit / credit notes for adjustments to accounts receivables Enabling electronic submission of invoices and debit / credit notes Recording payments received Offsetting payments against outstanding credit by manually selecting open items or running automatic settlements based on pre-defined rules Recording and managing receipt of security deposits / bank guarantees from agents and customers Calculating and managing incentives and commissions to agents Managing credit sales Maintaining and processing aging statements Maintaining credit, payment and bad-debt history of customers 3.1.9 Insurance Management Insurance Management should be capable of maintaining and processing insurance policies taken out by PIA. Besides other things, it should be capable of: Maintaining market valuation of assets and linking them with the asset master of Fixed Assets Management Providing true / logical valuation for insurance purpose of all assets including aircraft fleet and properties. Professional risk management techniques should be applied with an aim to minimize risk and optimize savings in premium costs Section D Product Requirements (ERP and Add-Ons) Page 164 Confidential
Calculating insurance premiums based on approved quotes and triggering requests for payment of premium Calculating monthly allocation of insurance cost Generating required renewal / underwriting information for renewal of aviation / aircraft fleet and general insurance policies Generating correctly the required information for settlement of insurance claims by insurance companies. For example, in case of aviation insurance claims the standard information which is required for claim processing like certificate of registration, certificate of airworthiness, investigation report, etc. should be available in the system. Same should apply to claims handling for all general / aviation insurance policies Tracking outstanding insurance claims raised Handling and processing customer insurance claims against PIA Section D Product Requirements (ERP and Add-Ons) Page 165 Confidential
3.1.10 Leasing Management This system should be capable of maintaining and processing records related to leased assets and should include the following functionality: Terms and conditions and other relevant details of leasing arrangements leasing company, type of lease (operating or financial lease), lease rentals, down payment, residual value, lease period, etc. Auto-generating recurring payment vouchers in Accounts Payable Identifying physical location of leased assets Identifying users of leased assets Processing disposal of leased assets Handling and managing aircraft leasing, for example wet lease, etc. 3.1.11 Budget and Cost Management Budget and Cost Management system should support preparation of detailed budgets by cost center and by expense head and their monitoring against actual expenditures. It should also allow for revision to original budgets and consolidation of budgets. In addition, it should be capable of: Creating and maintaining hierarchical structures for cost centers Creating and maintaining different cost / expenditure types (direct, indirect, fixed, variable, semi-variable, etc.) and collecting data relating to those types Defining a complete budget hierarchy and classifying revenue and expenditure items. The budget model should be flexible and capable to update itself with the changes in operations / flight schedules Providing graphical representation of budget hierarchy with easy navigation and drill-down features Creating and maintaining cost collectors such as maintenance orders Supporting hierarchical structure of managing the maintenance orders Collecting shop floor data against maintenance orders Recording man-hours against maintenance orders Issuing external repair orders against maintenance orders Defining control limits for over-expenditure against specified budget heads Performing budget availability checks while posting transactions restricting spending beyond budget limits Managing over-expenditure through special approvals based on authority levels and generating reports to monitor use of special approvals Maintaining baseline and revised budgets Allowing import of budgets created in external systems such as MS-Excel and others Section D Product Requirements (ERP and Add-Ons) Page 166 Confidential
Allowing manual input of budget data at lowest level of detail and rolling-up to provide summarized data Allowing manual input of budget data at summarized level and allocating it either manually or automatically through pre-defined formulae Maintaining sales targets for passenger and cargo revenue generation Distribution of annual budget over specified periods; monthly distribution or on a seasonal pattern Comparing budgeted and actual expenditures Supporting standard costing model based on actual operations, comparable with the actual results along with the variance analysis. It should automatically prepare standard reports from fixed and flexible budgetary inputs. Supporting and providing Activity Based Costing Managing overhead costing Integrating with PIA s MRO solution for job order costing Allowing allocation of expenditures from one cost centre to another based on PIA defined rules Determining dependence on fuel pricing and providing different what-if analysis and recommendations for hedging Supporting different budgeting techniques including zero based budgeting 3.1.12 Profitability Management As part of PIA s strategic information needs, profitability status by different criteria is of prime importance. It should be able to identify and highlight profitable stations, routes and also provide the profitability status of various flights. It should be able to collect actual financial data from Revenue Accounting and match it against the planning data from Budget and Cost Management. It should also be capable of: Creating and maintaining hierarchical structures for profit centers Planning and setting up sales / performance targets Handling special agreements with IATA, different airlines and agents Collecting operational and financial data, such as: Flight schedules Fare paying passengers Flight logs Freight tonnage Maintenance and repair charges Engines / components / spares reservation / leasing charges Aircraft rental charges Section D Product Requirements (ERP and Add-Ons) Page 167 Confidential
Block hours Fuel uplift charges Landing / navigational charges En-route charges Handling charges aircraft, passenger, cargo / baggage, etc. Passenger related expenses taxes, handling, meals, give-aways, etc. Flight disruption charges - hotel accommodation, meals, transportation, parking, security, technical handling, crew allowances, etc. Crew related expenses allowances, transportation, layover, flying, etc. Commissions to agents for ticket sales Fixed costs Preparing traffic load summaries Generating aircraft- and route-wise fuel uplift report Providing costing reports including but not limited to direct overhead costing, variable overhead costing, indirect fixed costing, etc. Calculating route and aircraft profitability and development of route economics Providing profitability analysis for other activities such as maintenance services, training, catering, etc. provided to third parties Preparing financial statements (balance sheet, income statement, cash flow statement and profitability statement) for stations based on their local base currencies along with conversion to PKR Statistical and operational performance reporting based on airline specific Key Performance Indicators (KPIs) such as: Market share Available seat per kilometer (ASK) Passenger yield (Revenue per passenger kilometer RPK) Revenue seat factor Available freight tonnes per kilometer (AFTK) Cargo yield (Revenue freight tonnes per kilometer RFTK) Load factor Best / worst performing flight segments / routes Best / worst performing stations Earnings by hubs and international entity including code-sharing Largest revenue earning routes Ranking of cities against revenue generated Others Reporting by: Region Network Section D Product Requirements (ERP and Add-Ons) Page 168 Confidential
Route City Pair Station Aircraft What-if analysis 3.1.13 Foreign Currency Management As part of its operations, PIA regularly deals in foreign currencies. To handle these currencies it requires functionality that can support these operations. It should be capable of: Supporting daily maintenance of foreign currency rates Allowing currency rate conversion calculations Supporting multiple currency rates for different purposes Supporting different decimal places for different currencies; for example 0 for Japanese Yen, 2 for Pak Rupees, 3 for Omani Riyal, etc. Supporting currency conversion, translation and revaluation Maintaining both foreign and local currency amounts for individual transactions Calculating and posting exchange rate gains and losses 3.1.14 Taxation Management PIA operates its offices in many countries of the world; as a result it has to cater to the taxation requirements of these countries. These requirements arise as PIA is involved in making payments for different services received. It should be capable of: Allowing different tax regimes Supporting tax systems in vogue in countries where PIA offices are located Supporting calculations of VAT Supporting sales tax Supporting Civil Aviation tax Supporting withholding tax Supporting income tax Supporting zero tax Supporting tax reporting Maintaining effective dates for tax exemption certificates 3.1.15 Treasury and Risk Management Section D Product Requirements (ERP and Add-Ons) Page 169 Confidential
PIA s Treasury department needs to make sound investments, manage its investment portfolio, mitigate financial risks, hedge against increasing fuel prices and monitor and adjust currency and interest rate positions. Treasury and Risk Management should be capable of: Minimizing idle cash Managing portfolios Positioning in multiple currencies Supporting various financial instruments such as debts, investments, foreign exchange, derivatives, etc. Tracking exposures and hedges Analyzing and mitigating risks Managing liquidity Carrying out sensitivity analysis Simulating different scenarios Section D Product Requirements (ERP and Add-Ons) Page 170 Confidential
3.2 Human Resources and Administration PIA is pursuing a strategy of recruiting and retaining talented resources and training them to achieve operational excellence. It is essential to strengthen the manpower resources as operational staff has the responsibility to minimize risks related to engineering and operations. At the same time, business support staff has the responsibility to support cost effective and efficient operations as a whole. This brings the important role of the Human Resources (HR) function into view. Enlightened human resource practices will allow PIA to attract, retain, and develop critical manpower resources and to optimally utilize their expertise and knowledge. The most important information requirement of the HR function is to maintain records of the skills available with and required by various operational and business support functions in PIA. This information helps them match the required skills with those that are already available. The resulting gap analysis helps plan recruitment, staff training and development activities. The Human Resources and Administration function at PIA is organized into the following departments: Human Resources Management Recruitment, Placement and Records Organization Development Welfare Security High Level Specification of Human Resources and Administration Applications 3.2.1 HR Planning and Operations HR Planning and Operations should support maintenance of the organization structure, available jobs and their descriptions / specifications, job standards, employee database, etc. In addition, it should be capable of: Setting up and managing HR budgets Updating organizational charts Creating and maintaining job specifications and job descriptions Simulating, analyzing, forecasting and experimenting with proposed organizational changes Providing analytical reporting such as headcount planning cost simulation, etc. Managing and optimizing the workforce within PIA Section D Product Requirements (ERP and Add-Ons) Page 171 Confidential
Managing capacity planning and load planning Maintaining employee personnel details including staff number, name, address, family details, etc. Maintaining employment history including personal data, joining date, confirmation date, group/grade level, promotions with dates, placements, transfers, temporary transfers, foreign postings, separation date, training history, etc. Maintaining performance appraisals that should include the overall rating, last year s objectives versus actual achievements, objectives for next year, training and development needs, performance improvement plans appraiser s comments, etc. Allowing employee photographs and other documents to be added as part of employee records Automatically monitoring dates for various HR processes; that is specifying date-driven reminders to initiate follow up activities (for example, annual increment, periodic performance review, expiry of employment contract, retirement date, etc.) Integrating with PIA s document management system where physical records are currently being archived Recording employee grievances and decisions made thereon Maintaining records of employees on deputations and secondments Managing disciplinary cases against employees Maintaining contract details of contractual employees Managing award schemes 3.2.2 Recruitment Management The purpose of Recruitment Management is to facilitate the process of selecting the most suitable candidate for employment. This system should be capable of: Maintaining a database of applicants with details of their personal data including education, qualification and work experience related information Managing selection testing Scheduling and arranging interview sessions Organizing and tracking candidates throughout the entire recruiting process Maintaining a list of available job positions Processing recruitment requisitions against sanctioned positions Allowing web-based job application and resume submission as well as online submission of application fee Identifying candidates based on the matching of job requirements with the skills and qualifications of each individual Short-listing candidates based on job specifications Section D Product Requirements (ERP and Add-Ons) Page 172 Confidential
Identifying specific essential requirements for a job and allowing comparison of candidates based on these requirements Recording the ratings and comments of the interviewers Issuing acceptance / rejection letters depending on recruitment decisions Updating employee records from the selected candidate s files Allotting Personnel Number and Under Training Number to selected candidates 3.2.3 Qualifications Management Qualifications management is a very important functionality required by PIA. Recording and monitoring of the knowledge, skills, qualifications, licenses, certifications and competencies of its operational staff pilots, engineers, flight crew, ground staff, etc. is vital for safe and efficient management of its operations. It should be capable of: Defining profiles for candidates and employees along with specifying the type of information that should be stored with each profile Recording the qualifications required to perform specific jobs or tasks, including work-related skills and specific certifications or licenses in the qualifications catalog integrating with PIA s MRO application for linking job (maintenance) requirements with available qualifications Identifying qualifications such as licenses that require monitoring of expiration and renewal dates Linking similar qualifications as an alternative to one another, 3.2.4 HR Development HR development is an important activity carried out by the Human Resources function at PIA. It helps in people development that ultimately benefits the organization in the long run. It should be capable of: Creating and managing career paths within the company Basing career and succession planning on career paths or on an individual s skills and potential Defining and maintaining both company and individual goals Designating individuals for positions or marking them as having the potential to succeed in a particular area or position Mapping a career path for employees outside of their current disciplines Allowing employees to match their qualifications with requirements of a position and determining what (training, proficiency) is needed to meet their goal Managing job rotations and postings Section D Product Requirements (ERP and Add-Ons) Page 173 Confidential
Matching an individual s skills or qualifications to those required for a position, identifying gaps and proposing training and development plans to acquire the necessary skills Keeping track of on-the-job training and training activities such as classes, seminars and workshops Managing internship programs 3.2.5 Performance Management The Human Resources function at PIA supports the core business and other support functions in evaluation of their staff to determine the effectiveness of the staff development processes in place. It should be capable of: Providing a flexible framework to create and administer the process of performance reviews and appraisals. Setting up performance targets and their measurement criteria Having the capability of recording individual employee s Smart Goals Integrating performance reviews into PIA s total rewards strategy. Planning, designing, performing and analyzing multiple appraisal models for multiple purposes. Using a variety of appraisal models as templates to support the staff appraisal process, including: Bell curves Personnel, employee and manager appraisals 360-degree feedback Evaluation of work or projects Event, instructor and participant appraisals Multiple number of appraisers Section D Product Requirements (ERP and Add-Ons) Page 174 Confidential
3.2.6 Compensation and Benefits Management Compensation and Benefits Management should support, maintain and process company guidelines with regards to salaries and wages, perquisites / benefits, facilities, allowances and other staff costs as well as staff increments. It should be capable of: Maintaining ranges of compensation and benefits offered to staff in each group / grade and those on foreign postings Maintaining a record of actual compensation and benefits of all employees Maintaining a database of compensation and benefits of employees of benchmarked companies Maintaining Consumer Price Index (CPI) survey and details of the State Bank of Pakistan s (SBP) report with regards to inflation Making a comparative assessment of compensation and benefits of PIA and other benchmarked companies Evaluating the impact of inflation on purchasing power of PIA's employees using the CPI survey and SBP report details Maintaining surveys and Central Bank reports for countries where PIA employees are posted Evaluating the impact of inflation on salaries and allowances for employees posted abroad 3.2.7 Training and Development Training and Development should identify and target training and professional development needs of staff based on current and projected business requirements of PIA. It should maintain profiles of employee s skills and intellectual assets manage training requirements and activities, identify career and succession planning objectives and track progress. It should be capable of: Maintaining list of resources (rooms, audio-visual aids, trainers, etc.) and allocating them to different courses Maintaining training and development plans of employees Maintaining records of available training programs / catalogues in-house and external (local and oversees) sources Scheduling in-house training programs along with resources required Maintaining calendars of external training programs Determining course demand based on pre-bookings and / or actual attendance of prior periods Registering attendees directly as well as through web access. Also allowing online submission of training fee Recording feedback provided by trainees and trainers Section D Product Requirements (ERP and Add-Ons) Page 175 Confidential
Integrating with Performance Management System to allow appraisals for instructors, attendees and courses. Also matching trainings required to fulfill promotion criteria Conducting and grading different tests / exams Maintaining records of training programs attended by individuals / corporate Maintaining attendance records of external training participants Issuing training certificates Recording trainings attended by employees and the grades obtained by them. For regulated trainings (such as CAA) recording of certificates, issuance dates, expiry dates, dates for refresher courses, etc. Performing a gap analysis between job specifications and employee skills to plan and fulfill training and professional development requirements of each individual 3.2.8 Time Management Time management is required to optimize the process of planning, managing and evaluating the working times and performance of internal and external employees. The system should be able to handle the working time provisions of PIA in lines with those that are required by law. It should be capable of: Maintaining the PIA calendar with holidays Maintaining multiple calendars simultaneously, for instance Gregorian for Pakistan, Hijri for Saudi Arabia, etc. Recording employee attendance Interfacing with different time-recording machines (with bio-metrics capability) to capture real-time attendance data Maintaining leaves, absences, days-off, on-corporation services (OCS) duration etc., of each individual Assisting in shift / roster planning for various departments and crews based on actual / forecasted workload. Integrating with Sabre s Flight Scheduler to capture flight schedules, AIMS software for crew scheduling and MRO solution with engineering shift scheduling Administering shift / roster plans considering defined requirements along with employee skills, qualifications, and availability merging load planning with capacity planning Providing information to crew and other staff of their rosters through SMS or making the information available to them when they dial in to PIA s Call Centre Processing day-to-day changes in the shift schedule based on transactions that affect requirements or availability of staff Identifying and managing rotating assignments Establishing automatic substitution and on-call procedures Section D Product Requirements (ERP and Add-Ons) Page 176 Confidential
Checking employee time assignments against PIA s policies and legal requirements Evaluating time data used for calculation of overtime, shift allowance, night allowance, and other allowances specific to cockpit and cabin crews, engineering staff, etc. Providing attendance and overtime data for payroll processing Processing leave applications 3.2.9 Healthcare Management Healthcare Management should be capable of managing the healthcare requirements of nearly 18,000 employees, plus eligible dependants and retirees. Its main features would include the following: Processing candidate, employee, retiree and dependant registration Initiating medical test procedure for recruitment and recording medical fitness of flight staff Maintaining medical history of PIA staff, retirees and their dependants Processing patient referrals Recording diagnosis and treatment details provided by consultants or hospitals Maintaining list of hospitals, consultants and medical stores on PIA s panel Maintaining the Pharmacopoeia document (PIA s list of authorized medicines) Maintaining treatment costs for management reporting Issuing medicines to PIA staff and their dependants 3.2.10 Travel Management PIA provides travel passage to employees, retirees and their dependants depending on their entitlements. This creates a need for a Travel Management system to support flight reservations, maintain traveling records, etc. It should be capable of: Managing requests for travel passage including approvals from appropriate authorities Maintaining record of employees traveling on corporation service Calculating allowances for employees traveling on corporation service Maintaining records of and providing assistance in obtaining visas Issuing tickets / passages based on entitlements Maintaining traveling schedules of employees, retirees and dependants Keeping track of traveling history of employees, retirees and dependants Section D Product Requirements (ERP and Add-Ons) Page 177 Confidential
3.2.11 Payroll Processing The Payroll should process payment of salaries, wages, benefits, and allowances of employees based on the compensation and benefits data available in Compensation and Benefits Administration and the attendance record maintained in Time Management. It should be an airline industry specific payroll catering to various types of airline specific allowances. Payroll should be capable of: Processing compensation and benefits of each individual based on pay package and attendance record Calculating payroll based on multiple shifts with time data collected from various time collection devices Calculating various allowances for flying staff based on specific flight timings different for cockpit and cabin crew Managing salaries of employees posted at various foreign locations based on the calendars applicable in those countries Managing salaries and running payroll of local employees posted at various foreign locations based on their local statutory, taxation and labor law requirements Catering to the laws of Pakistan as well as the countries where payroll will be run (a list of foreign stations is available in Section A, Sub-section A2) Handling across the board, one-time payments like bonuses, etc. Allowing retro-processing and arrears processing Auto generation of salary increments Adhoc salary increments for individual / groups Processing of loans and advances to employees Generating bank advice for salary transfer to relevant bank accounts Printing salary cheques for employees without bank accounts Generating pay slips of employees Deducting income tax at source Generating location-wise periodic tax returns for statutory reporting / filing with different tax authorities Generating tax deduction certificates of individual employees Providing complete integration between HR and financials systems Simulating payroll runs before actual payroll is run Generating pension run for pensioners 3.2.12 Final Settlement Processing This system should facilitate calculations and processing of final settlements for all employees; whether regular and contractual. Components of final settlement Section D Product Requirements (ERP and Add-Ons) Page 178 Confidential
include all allowances, deductions, leaves, passages, provident fund, leave encashment, loans; preparation of audit sheet and pension sheet; calculation of income tax payable by employee. It should have the following functionalities: Capturing reasons for separation; such as retirement, resignation, termination, etc. Identifying in advance about the retiring employees and generating necessary letters / memos Capturing details of exit interview Withholding salary and other benefits till all clearances are obtained Preparing Audit Sheet with all final settlement calculations Preparing Pension Sheet calculating pension amounts Preparing gratuity information for each employee Maintaining income tax brackets and calculating final settlement amounts after catering for tax deduction Maintaining detailed history for possible re-hiring cases 3.2.13 Personnel Insurance Management PIA offers various group insurance policies to its employees voluntary, term, and provident fund. Besides it also offers accidental death / injury policies for cabin crew and cockpit crew; and personal accident travel (PAT) policy for nonflying employees traveling on PIA business. The Personnel Insurance Management System should provide a database for maintaining insurance claims and what has been disbursed to them. It should include the following features: Maintaining a list of various insurance policies that PIA offers to its employees Maintaining a database of different insurance policies that each employee has subscribed to Calculating insurance premiums based on approved quotes and triggering requests for payment of premium Generating required renewal / underwriting information for renewal of insurance policies Calculating monthly allocation of insurance cost Maintaining insurance claims made by employees Maintaining insurance claims made on behalf of employees Maintaining correspondence with Insurance Companies Integrating with Payroll Processing Providing standard / basic information like death certificate, etc. for settlement of group insurance claims Section D Product Requirements (ERP and Add-Ons) Page 179 Confidential
Maintaining records of claims actually paid to the employees or their nominees 3.2.14 Security Management The Security Division of PIA issues different security cards and passes to its employees, their family members, retirees, and contractors. These include the PIA ID Card, Family Card, Retired Employee Card, and Airport Pass (permanent and temporary passes). Security clearance for foreign postings and interaction with VVIPs are also processed by the Security Division. Functionalities should include: Maintaining data of employees, family members and retired employees required for issuance of respective security cards Issuing ID cards and different types of passes Maintaining photographs of employees, family members, and retired employees Integrating with Time Management so that security cards issued to employees can also be swiped on the time-recording machines 3.2.15 Staff Funds Management Staff Funds Management should maintain and process records related to administration of provident fund, pension, gratuity, and worker s profit participation fund and maintain related books of accounts. All regular employees at PIA are entitled to Provident Fund. 8.33% of an employee s basic salary is deducted from their payroll, and is matched by PIA. Regular employees can also benefit from Additional Provident Fund, amounting to a contribution of 10% of employee s basic salary; PIA, however does not contribute to this fund. Besides other things, it should be capable of the following functions: Managing Provident Fund and Additional Provident Fund contributions by the employee and PIA Posting and bookkeeping of all employees funds Processing Provident Fund loan applications Recording and managing loans and advances disbursed to employees against funds Integrating with Payroll Management for employee contributions, loan disbursements, and loan repayments Processing pension appraisal of employees at the time of retirement Calculating refund of Additional Provident Fund amount Recording monthly payments to retirees and their dependents Calculating profits earned on portfolio investments of funds Section D Product Requirements (ERP and Add-Ons) Page 180 Confidential
3.2.16 Self Service HR Employee Self Service allows to monitor and update employee own record. it should be capable of the following functions: Maintain personal information, such as home address and emergency contacts View payslips and pay rate change history Update bank accounts and pay distribution information Submit leave applications (absence requests) View leave history Enter qualifications, licenses, certificates, professional training and language skills. Section D Product Requirements (ERP and Add-Ons) Page 181 Confidential
3.3 Procurement and Inventory Control PIA s objective of achieving greater efficiency and economy in technical, operational and business support functions requires harmonized materials planning, accurate consumption monitoring, shorter purchasing cycles, effective stores management, well coordinated logistics, etc. The need for effective procurement and stores management becomes more significant as PIA pursues increased investment in new aircraft and improved engineering facilities. The Procurement and Logistics (P&L) Department of PIA is responsible for the procurement activity of the corporation for all the goods and services at economic prices following procurement rules and procedures, custodian of its inventory and its provision to the authorized users in an efficient manner. Total 51 stores are being managed by PIA at various locations. A detailed list is available in Section A, Subsection A2. There is partial automation at the stores. PIA s in-house developed application, PIA Online Store System (POSS), deals with planning and transaction capturing of commercial and other inventory items. The structure of P&L Department at PIA is organized around the following divisions: 1. Procurement Purchase Technical Purchase Commercial Purchase Technical (Commercial) Purchase New York 2. Logistics Logistics Stores Inventory Control Shipping and Disposal QC & Inspection COMAT Section D Product Requirements (ERP and Add-Ons) Page 182 Confidential
High Level Specification of Procurement and Inventory Control Applications 3.3.1 Contracting and Procurement Management The purpose of Contracting and Procurement Management is to manage purchase of materials and services against indents / requisitions / capital expenditure sanctions raised by different departments and purchase / work orders issued to suppliers. It should also maintain a database of registered / prequalified vendors and facilitate hiring of vendors, suppliers, contractors and other service providers. The main features and functionality will include: Recording and processing profiles and other relevant details of suppliers and service providers potential and pre-qualified. Supplier database should be at least per JAA / FAA / CAA compliance Supporting interaction with the supplier as per Spec 2000; for example, Purchase Order transmission and acknowledgement, etc. Maintaining indents / requisitions / capital expenditure sanctions raised by various departments Supporting online approvals for requisitioning, ordering and invoicing Generating requisitions from other areas / systems such as Engineering (MRO), Flight Kitchen (MRP Recipe Management), etc. Handling requisitions for different types of procurement such as: Stock items Non-stock items Assets Services Other agreements Routing and authorizing procurement documents based on pre-defined criteria Comparing actual cost of purchases against available budgets, budget monitoring. Validating available budget at the time of Requisition and Ordering Generating requests for quotation for pre-qualified supplier / Approved Vendor List or service providers Maintaining price quotations received from suppliers or service providers Supporting on-line bidding by suppliers Supporting the tendering process based on PPRA rules Evaluating proposals online based on cost, delivery time, supplier's record, proposed warranty, technical support, etc. Section D Product Requirements (ERP and Add-Ons) Page 183 Confidential
Generating price comparison statements for items to be purchased or services to be availed Creating purchase / work orders / contracts and tracking procurement status Handling multiple currencies on the same purchase / work order / contract Capturing details of Repair Service Agreements with fixed price / PBH for services, man-hour rates, repair lead-time, warranty conditions, part exchange program, reliability guarantee in compliance with product support documents, for example GCP 2000, PSAA, etc. Tracking receipt of materials / services against purchase / work orders / contracts Tracking materials under inspection and the quantities accepted and / or rejected against purchase orders Logging and approving invoices from suppliers and contractors after threeway matching with Purchase / Work Order and receipt of goods / services 3.3.2 Vendor Management The purpose of Vendor Management is to help PIA in strategic sourcing. It will support creation of vendor master records and maintaining information regarding them, specifically their performance history. This system should be capable of: Vendor performance management in accordance with GCP 2000 and PSAA Evaluating supplier's performance based on lead time, enquiry response time, quantity discrepancies, quality discrepancies, price variance, rejection rate, changes to delivery date, quality of exchanges, etc. Maintaining performance history of suppliers Creating and managing vendor master records Categorizing vendors in categories like aircraft parts vendors, other international vendors, local vendors, employees, etc. Blocking vendors for various reasons such as bankruptcy, blacklisting, poor performance, etc. Pre-qualifying vendors / Approved Vendor List (AVL) Linking vendors to proprietary/ related items Linking AVL with Quality Systems (QS) approval process 3.3.3 Items Management The purpose of Items Management is to identify and maintain information related to store items, particularly aircraft parts, as well as tools and equipments. This system should be capable of: Section D Product Requirements (ERP and Add-Ons) Page 184 Confidential
Maintaining a list of items, tools and equipments with unique identification numbers, detailed specifications, inventory value, previous purchase price, purchase history, min, max and reorder levels, etc. Providing quick referencing / accessing functionality with barcodes and RFID tagging Supporting capturing of the following minimum data related to aircraft parts: Vendor part number OEM part number Part description Relationship tables (WBS) Price Vendor Reliability factor (MTBUR meantime between unscheduled removal / MTBF meantime between failure) Service Level (as per PIA Policy) Alternate parts Limitations of alternate usage Authority for declaring alternate (for e.g. IPL reference, QA letter, etc.) IPC references with usage code Normal stock rooms and shops authorized to withdraw the items Material groups responsible for the item Quantity per aircraft Recommended quantity as per RSPL Essentiality code Class (Rotable, Repairable, Consumable) Buy direct from vendor / OEM, etc. Handling aircraft parts according to a minimum of ten different classes such as rotables, repairables, consumables, etc. Loading initial provision of aircraft parts in the system for aircraft maintenance plan based on manufacturer recommendations Allowing revisions (new, change, remove) to the initial provisioning list Establishing safety stock base keeping in mind the service levels provided by the various vendors / as per PIA Policy Establishing project requirements based on forecast, extrapolation, trend and smoothing factors Monitoring forecast accuracy and identifying deviation Identifying material by OEM part number Grouping all materials of the same form, fit and function under a material number (interchangeability of parts one-way, two-way) Section D Product Requirements (ERP and Add-Ons) Page 185 Confidential
Identifying material to the aircraft types, ATA chapter, classification characteristics of the material, etc. Providing price information about the material including valuation price (at moving average), batch price (Purchase Order based), catalogue price (from various vendors), etc. Provide linkage with various vendors / OEMs current catalogue list price Changing material classification with adequate control (for example, rotable to repairable) Supporting different treatment for each material classification in terms of provisioning formula, movement types, issue control, serialized numbering, etc. Providing parts interchangeability management capability and displaying all interchangeable item at the time of requisition (when requisitioned item is not available) Tracking the shelf life of items, monitoring them and flagging out expired items. Supporting salvaging and re-certification of components from scrap items (Bring On Charge the salvaged components) Keeping track of warranty of items supplied warranties could be of different nature such as repair, purchase, service, etc. 3.3.4 Stores Management The purpose of Stores Management is to support receipts, issues, and transfers of materials and to maintain records of on-hand balances. In addition, it should be capable of: Supporting the requirements of ATA Spec 2000 Providing warehouse management functionality including space management and binning. Warehouses (physical and logical) shall include: Central Stations (local / overseas) In-house maintenance facilities Aircraft Flight spare containers Bench stock (at workshops) Workshops (internal and external) - for both items under repair and spares holding Loan (from and to) Document stock (tickets, air waybills, etc.) Quarantine stock Consignment stock, etc. Section D Product Requirements (ERP and Add-Ons) Page 186 Confidential
Optimizing space allocation for all items by volume and weight, environmental conditions, movement (that is, fast / slow moving items), etc. Identifying materials available at various locations Identifying the aircraft on which a flight container is placed as well as the spares in that flight container Notifying material controller if certain materials reach the threshold level Supporting multiple warehousing for materials. Auto-replenishing (either transfer or reorder) stock in predefined warehouses when it reaches the replenishment level Receiving material in store and holding in quarantine till quality checks are made. It should also support acceptance of services Storing quality assurance certificates (scanned images) and delivery documents in image format and linking them to the Purchase Order Valuing material in each store by moving average price with reference information of purchase price for each batch Tracking on-hand balances and quantities reserved by aircraft Tagging materials reserved against provisional requests. Supporting hard allocation of reserved materials. The release of hard reserved materials for other use should be approved by an authorized party Dispatching materials outside the warehouse based on the following: Sales Sending to line stations Sending items out for repair Returning third party items Returning leased items Returning other operator items Transferring between warehouses Lending to another airline / organization Exchanging with another airline / organization Issuing for consumption (for example, against a Job Order) Disposing off as scrap, etc. Monitoring the whereabouts of dispatched item (based on their batch / serial number) until acknowledgement of receipt Reserving materials manually as well as automatically through other systems such as MRO or through internal requisitions. Issuing materials against requests received. While issuing, recommending the issue of materials down to the batch number. The batch number should be determined either by a first in first out basis or shelf life Producing pick lists for items to be issued Supporting sales of items to other airlines / parties Section D Product Requirements (ERP and Add-Ons) Page 187 Confidential
Supporting stock exchange between aircrafts and between PIA and other airlines Generating inter-store stock transfer notes Supporting and tracking outstanding loans (both from and to PIA) and providing regular reports / alerts for stock items, spares, tools, etc. Determining min, max and reorder levels based on historical and planned consumption patterns Identifying and regularly reporting on non-moving / slow-moving materials Supporting a permanent on-going stock-taking process Scheduling and recording physical count of high value and frequently used items Determining variances between book records and physical count of materials Managing items declared surplus or redundant and managing their sale with a view to optimizing the revenues 3.3.5 Inbound / Outbound Logistics Management The purpose of the Inbound / Outbound Logistics Management is to track shipments of imported / exported materials, status of letters of credit, and compile and compute the total landed cost of each shipment. It should be capable of: Recording authorizations received from government agencies for foreign exchange spending Maintaining records of letter of credits, including the date of establishing the L/C, bank s name, bank charges, insurance cost, supplier of materials, exchange rates, purchase order number, retirement date, etc. Tracking shipments based on intimation received from suppliers or freight forwarders Highlighting delayed items or those missing in-transit and supporting insurance claims Calculating landed cost based on total charges Providing interface with Customs systems and assisting in obtaining clearance from Customs authorities Processing retirement of documents and maintaining relevant records Processing and maintaining details of goods cleared from Customs Supporting statutory / regulatory reporting and documentation requirements when components are moved to external contractors. This will include at least the following: Preparation of air waybill Preparation of freight forwarder instructions Preparation of other accompanying documents Section D Product Requirements (ERP and Add-Ons) Page 188 Confidential
Preparation of Indemnity Bond Integration with freight forwarders for on-line status information Section D Product Requirements (ERP and Add-Ons) Page 189 Confidential
SECTION E PRODUCT REQUIREMENTS (OTHERS) Section E Product Requirements (Others) Page 190 Confidential
E1 RDBMS AND DATABASE ADMINISTRATION TOOLS The Contractor is required to supply the latest version of RDBMS that effectively supports the proposed ERP Package. To this extent certification of ERP manufacturer that the particular version of RDBMS is fully supported by the ERP should be provided. Besides, the Contractor must also provide an install base of the RDBMS with the proposed ERP in projects of comparable size. Database schema definition, management, query and reporting facilities must be provided. Historical transactions must be maintained by the RDBMS. Facilities for reviewing transactions, multiple transaction roll back and transaction log reporting are required. Database update facilities must include features such as the use of working copies and status reporting on query and update operations. The system must provide locking mechanisms for update and delete operations. The system must maintain concurrent control mechanisms to ensure the correctness of transactions and to detect and resolve deadlocks on the network. The system must support authorization lists and groups for create, read, update and delete. The provision of on-line facilities to manage transactions and overall on-line system performance is desirable. The system must provide users and applications with distribution independence. Users do not need to know where database objects are located. The system must operate in a distributed environment where different nodes of the network run at different functional levels. The system must have the ability to automatically recover and restore the database fully to the last consistent state after a media or system or database failure. The ability to notify users as to what transactions were being processed but not written to the database during a crash is highly desirable. The system should have archive logs and checkpoint facilities and the capability to roll back / undo to any one checkpoint. The system must continue to be available to users during any backup process or alteration of the database schema s and definitions. The system must support one-to-one, one-to-many and many-to-one relationships. The system must be capable of working in a multi-tier environment, and provide the appropriate tools for partitioning the location of the processing. All tuning must be independent to the user. All information in the database must be represented as values in the table. Section E Product Requirements (Others) Page 191 Confidential
Null value support (as opposed to empty character strings, blank characters or zero) must be available for all data types. Database recovery must be made in minimum acceptable downtime. Acceptable downtime is to be negotiated and agreed upon RDBMS should have a support for ETL RDBMS should have support for SAN storage and cluster environment Load balancing and failover must be supported to minimize down time RDBMS should support DR sites and automatic standby configurations. It must be capable of operating in the DR environment and support synchronous as well as asynchronous data replication at remote DR site RDBMS should be capable of supporting large amounts of data in terra bytes RDBMS should have support for transmission of data from other new systems as well as exiting legacy systems It should support libraries to enable backup on tape and disk drives It should have support for new firewalls and n-tier network architecture It should have support for OLAP, OLTP and DSS systems For effective monitoring and management of the database, the Contractor is required to provide, as part of its solution, Database Administration Tools that will help database administrators in database monitoring, storage analysis, capacity planning and performance monitoring and including trend analysis, size estimation and table creation. Section E Product Requirements (Others) Page 192 Confidential
E2 APPLICATION DEVELOPMENT TOOLS All application development and maintenance will be carried out on the centrally located development server. The Contractor will be required to propose and supply application development tools, consistent with the proposed ERP package. It is expected that the proposed solution comes with a built-in 4GL development environment tool set. Section E Product Requirements (Others) Page 193 Confidential
E3 QUERY AND REPORT GENERATOR TOOLS The Contractor must provide complete query and report generator functionality, preferably within the provided system. The report generator functionality must include a scheduling or production process for routine reporting. The report generator functionality must be robust and oriented to the skills of "average" desktop systems users and should support SQL. It is expected that the solution would support industry standard report generators such as Crystal Reports, Business Objects, etc. Formatting and statistical capabilities such as averaging, multi-level sub-totaling, percent change comparisons, standard mathematical operations and financial calculations is required. Generated reports must be able to be saved in several output formats, at a minimum: MS Word, MS Excel, Text, PDF, HTML and XML. The Contractor must describe its query and report generator systems in detail in the Technical Proposal. Section E Product Requirements (Others) Page 194 Confidential
E4 INTERIM SERVERS 1. In order to avoid any delay in meeting the Project completion milestone, and to cater for the lead time required by PIA in the procurement process, the Contractor is required, as part of its proposal to provide, without any cost to PIA, Interim Servers and Operating System Software, as follows: a) the Server, (or Servers) will be installed by the Contractor at PIA s Computer Centre. b) the Server(s) will be used for the purpose of configuration of the ERP Package, development of Add-on applications. Besides, interim servers will be needed for training of staff, and testing the system. c) all necessary hardware components such as CD-ROM drives, tape drives (for back up purposes), etc. are considered part of of interim servers d) software components, such as RDBMS, development tools, 3 rd party software, etc. provided by the selected Contractor will be used on the Interim Servers. 2. It is anticipated that the Server(s) will be required for a period of approximately nine (9) to ten (10) months from the date of supply of Server Hardware, Operating System Software and ERP Package Software. 3. The details of the proposed Interim Server(s) hardware Configuration and Operating System software are to be provided by the Contractor in its proposal. 4. The configuration of these machines should be capable to support the number of users as specified by the Contractor in its plan. 5. In its proposal, the Contractor will provide site specification requirements for the installation and operation of Interim Server(s). 6. PIA - at the end of implementation and rollout - may at its discretion, decide to purchase the interim servers provided by the Contractor. In this regard, the Contractor should, as part of its Commercial Proposal, separately mention the cost at which it would offer these machines for sale to PIA. However, this cost component should not be added to the total bid price, nor should it be used to calculate the bid bond amount. Section E Product Requirements (Others) Page 195 Confidential
E5 3 RD PARTY SOFTWARE 1. In order to effectively manage and run the complete solution some other 3 rd party software and application programming interfaces (APIs) may also be required to integrate various applications and execute and monitor the complete solution. 2. The Contractor will be responsible to ensure that all required 3 rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration tools, disaster recovery and business continuity tools, APIs / interfaces, etc. are made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed ERP solution. 3. It is the responsibility of the Contractor to offer PIA a complete solution in all respects delays or costs arising out of any shortcoming will have to be borne by the Contractor. Section E Product Requirements (Others) Page 196 Confidential
SECTION F SERVICES REQUIREMENTS Section F Services Requirements Page 197 Confidential
F1 IMPLEMENTATION 1. As part of its proposal, the Contractor must submit an Implementation Strategy and Plan which caters for the following, to be performed by the Contractor: a) Installation of the Interim Server(s) including the Operating System. b) Installation of all supplied Application software, RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Interim Server(s). c) Installation of all supplied Application software, RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Permanent Servers. d) Implementation of Database security features e) Development of a Business Requirement Document (conceptual system design) for each functional area by mapping the business processes for the parameterization / configuration of ERP Package. This document should be based on PIA s reengineered business processes that would be made available to the Contractor. PIA will review and approve this document before Contractor can start work on parameterization / configuration of the ERP f) Development of business case scenarios g) Parameterization of supplied Software i.e. the configuration of application software via selection of in-built values, setting up of tables, etc. to meet the business requirements. h) Software modifications, where required, to supplied Application software and development of extensions and / or modules to meet the business requirements. i) Integration with PIA s other applications such as Sabre, AIMS, SITA Cargo,, MRO solution, QUASAR, Recipe Management, Corporate e-mail, PIA website, etc. j) Design and development of customized reports, screens, workflows, etc. PIA will try to maximize the use of standard reports, screens and workflows available in the proposed solution; however the Contractor cannot set an upper limit to the number of customization that it will undertake. k) Design, development and initial set up of databases. l) Unit, Integration and System testing prior to User Acceptance testing. m) Preparation of data migration strategy and plan and undertaking data migration activities based on the plan. n) Design and implementation of Online and Batch job operational procedures until implementation is successfully completed at all locations. o) Progress reporting (on a weekly basis) on the Contractor s activities. p) Quality Assurance for Contractor related activities. q) Any other tasks required in successful delivery of the supplied products and services. Section F Services Requirements Page 198 Confidential
2. The Contractor must utilize airline industry specific rapid implementation templates to ensure implementation within the specified timelines. Details of such templates should be submitted with the Technical Proposal. 3. A detailed comprehensive project plan is to be prepared by Contractor and submitted as a part of the proposal. The plan shall be mutually approved and incorporated as part of contract and reviewed at regular intervals. 4. The Contractor must submit a detailed project organization structure identifying, by name, the specific individuals who would be assigned different tasks of this project. The Contractor must assign full-time Project Manager and ERP module track leaders on this Project. The Project Manager as well as each ERP track leader must have the experience of implementing the proposed ERP in at least two airlines. A personnel roster containing detailed responsibilities of the Contractor s staff who shall be assigned to perform duties or services under the contract should be provided. It should include estimated number of days to be worked on the project for each person broken down in different phases of the project; with clear identification of the start and end dates for each phase. These staff members must have the experience of at least two complete implementations. If additional members are assigned their detailed CVs should be submitted as part of the proposal. The Contractor will not be allowed to assign staff members who do not have the experience of at least two complete life-cycle implementations of the proposed ERP. Daily charge-out rates for each Contractor staff must be provided in the Commercial Proposal. If deployment of the Contractor s proposed staff is less than the estimate provided in the personnel roster, PIA would make proportionate deductions from Contractor s payments. However, in order to ensure timely completion, the Contractor may have to deploy additional resources, if required, without extra cost to PIA. The Contractor shall be contractually bound to maintain the proposed team dedicated to the PIA project with the exception of a staff member leaving the Contractor organization. In such cases staff proposed as substitutes must have qualifications equivalent to or better than those being replaced and must be approved by PIA. 5. The Contractor must submit a detailed Testing Methodology. The Contractor may perform Unit, Integration, and Systems Tests off-site; however, the official Systems Test and all User Acceptance Tests (UAT) and Performance Accepatnce Tests (PAT) must be performed on-site using PIA s testing environment. Section F Services Requirements Page 199 Confidential
6. The Contractor must provide, by phase, the proposed number of personnel to be based on-site at PIA s premises, and space and other requirements to be provided by PIA during Implementation. 7. The Contractor will develop a system handover plan which indicates the conditional criteria required to fully handover the daily operation of the system to PIA s technical staff. At a minimum, the handover plan must include the state of readiness required for system handover and all required documentation. 8. The Contractor s implementation plan must take into consideration the business priority areas and applications. 9. System Performance: During system installation the Contractor will evaluate performance factors including, but not limited to, transaction volumes, response times, CPU utilization, and input / output activity. The Contractor will be responsible for tuning the application to meet acceptable response times. 10. Capacity Evaluation: The Contractor will conduct a Capacity Test that will include stress and volume testing. Capacity testing shall include a stress test that includes simulation of at least 30% of the system workload and volume tests that test the database activity against at least 30% of the data volume. The Contractor will document, the conclusions resulting from the test. 11. Project Management and Reporting: The Contractor is required to maintain a project plan covering its components of the project and each individual phase. The plan shall include project organization, work break down structures, schedules, critical path determination, and other features required to track and manage this project. The Contractor will be required to prepare and submit weekly progress reports to PIA on each component of the Project under which it is responsible. 12. Project Quality Management: In its proposal, the Contractor must describe its approach for assuring the quality of its components on this project. The proposal must demonstrate an understanding of the Contractor s ultimate responsibility for quality and define a comprehensive set of reasonable and effective practices for fulfilling that responsibility. The Contractor must also specify whether third party audit / quality assurance visits will be undertaken and who will bear the cost of these visits. 13. Acceptance Testing: PIA will conduct a rigorous acceptance test of the system. PIA user staff and information system specialists will exercise all system functional aspects using PIA-developed test data to assure that the system meets defined business and technical performance requirements. During this test, PIA will identify required modifications and document them through the problem resolution or change management processes (described below) as Section F Services Requirements Page 200 Confidential
appropriate. The Contractor shall modify the system as required and provide new versions of modified components to PIA for testing. PIA will notify the Contractor in writing when it determines that the system is acceptable. 14. Problem Resolution: The Contractor and PIA will cooperate to resolve system problems found during acceptance testing and production use, including the warranty period. PIA will prioritize and report problems in a written format. The Contractor shall track these problems to closure and report their status. The Contractor shall evaluate each reported problem, estimate the time needed to resolve the problem, identify potential impacts on the system and the project, and report to PIA. If PIA decides to proceed, the Contractor shall resolve the problem according to its assigned priority. 15. Change Management: PIA and Contractor will cooperate in managing changes to previously agreed upon system functional capabilities. PIA will identify potential functional changes and propose these to the Contractor in writing. The Contractor shall evaluate each proposal, identify potential impacts on the system and the project timeline, and report to PIA. If PIA decides to proceed, it will prioritize the change and authorize the Contractor in writing to perform the work. The Contractor shall track the status of in-progress change orders and report to PIA upon request. However, cost escalation will not be allowed under any circumstances. 16. Configuration Management: The Contractor shall manage version releases of all contract deliverables and certain other critical documents as determined by PIA. This process shall assure that the status of all deliverables is known, that only approved versions are released for production use, that prior released versions can be recreated, and that changes are made to released deliverables only when authorized by PIA. The final release of each controlled deliverable must reside in a library (preferably computer based) under PIA control. Section F Services Requirements Page 201 Confidential
F2 TRAINING 1. Training is required in two main areas: (a) Technical Support Staff, and (b) Systems Users. Technical Support Staff will comprise of System Operators, System Administrators, Database Administrators and Developers. Systems Users will comprise the staff from different functions of the company, including, but not limited to, Finance, Human Resources and Administration, Procurement and Logistics, Information Technology and those belonging to the stations. Three levels of Systems Users are currently identified as: Key Users (responsible for system parameterization in the future), End Users and Senior Management (who are expected to be provided System Overview). 2. As part of the proposal, the Contractor must describe in detail its approach to meeting the training requirements for each audience. The description must include methods proposed to deliver both training and documentation. The Contractor should describe the general content of all training materials, training courses, and documentation proposed. 3. The Contractor will be required to develop a Training Strategy to ensure that all identified Systems Users and Technical Support Staff is thoroughly trained in the use and support of the system. Training for Key Users must be imparted early in the implementation stage, preferably in the first month, to enable them to actively participate in the parameterization process 4. The Training Strategy should include a training solution to support the training of users throughout PIA in the functionality of the various ERP components and Add-on applications. The Contractor will be required to develop formalized classroom training sessions, to be delivered by their staff, for each of the user groups identified to ensure that the trainees become familiar with all the system features of the implemented applications. In addition, where required, for technical staff, informal training should also be included. 5. For PIA technical staff, the Training Strategy should include a plan to train the required staff in the Development and Administration tools supplied, and provide them the knowledge to efficiently operate, use and maintain the system independent of Contractor assistance. Technical training materials must be comprehensive and detailed. 6. The Training Strategy will address, at a minimum, the following: a) Description of the Course, the Course outline, specifications of the number and appropriateness of staff who will attend, probable dates for classes, etc. b) Proposed content of all training materials. c) Description of proposed software / tools (these may include training aids, manuals, on-line references, quick reference guides or templates, or computer based training), and their use during the training. Section F Services Requirements Page 202 Confidential
d) Details of the physical locations to be used for training. e) Training evaluation methodology f) The names, qualification and Formal Training experience in man-months, of the instructors for each training course. 7. The Contractor is required to provide materials for training users in central and remote locations. The User Staff training materials must cover, at a minimum, the following topics: a) Systems Overview systems benefits; data inputs, outputs, and reports produced; major systems business functions; Users Manual contents and usage; b) Systems Usage entering data and data validation; data correction and user help features; menu and system function traversal; problem recovery; report contents, report generation / suppression; search and inquiry features; record update procedures; c) Systems Operation job recovery; job scheduling; job cycles (daily, monthly, quarterly, annual, and special); special forms usage; 8. The Contractor must provide material for training Technical Staff such as database administrators, system administrators, operators, and developers. This material must cover all aspects of systems design, operation, and maintenance including, at a minimum, the following topics: application and database design and architecture; application structure and module / sub-module / program / subroutine relationships; application start-up / shut-down procedures; application back-up, recovery, and restart procedures; data dictionary structure and maintenance procedures; database logical and physical organization, and maintenance procedures; application security features; audit and testing procedures; Section F Services Requirements Page 203 Confidential
system data entry; checking, correction, and validation procedures; user help procedures and features; system troubleshooting and system tuning procedures and features; system administration functions management; setting and changing system password and user ID security features; system interface processing; on-line and batch processing procedures; unique processing procedures; report generation procedures; menu structures, chaining, and system command mode operations. 9. PIA requires the training material on CDs. All training material provided by the Contractor will be reproduced and used as needed by PIA. 10. Cost of Foreign Training, if proposed, should be included in the Contractor s Commercial Proposal and include all expenses related to travel, accommodation, tuition fees and other incidentals. Section F Services Requirements Page 204 Confidential
F3 DATA MIGRATION 1. The Contractor should include, as a part of its proposal, a description of its general approach to the data migration process (manual and automated) for historical and cutover data. 2. The Data Migration Strategy must address, at a minimum, the following: a) Migration overview with objectives, approach, impact, and resources b) Migration data (source and volume) c) Migration process (automated or manual, verification procedures) d) Migration support (systems, policy and hardware) e) Migration schedule f) Migration preparation task outline 3. The Detailed Migration Plan must address the following tasks: a) Identify data elements to be migrated. b) Identify necessary computer processing workloads. c) Identify any special forms and procedures. d) Identify any control procedures and evaluation criteria. e) Identify, with the assistance of PIA, the personnel needed to participate in the migration of the data. f) Plan any special training for migration activities. g) Plan any interim file maintenance requirements. h) Develop migration programs (this includes specifications, program coding, test plans, and complete testing). i) Present Migration Plan, Procedures, and Programs to PIA for approval. 4. The Contractor should perform the following tasks: a) Study the existing application, databases and manual data sources b) Design and develop a solution including intermediate utility (if any) to convert the data from existing databases to the new databases. c) Demonstrate and test this data migration on sample test data from existing live applications. d) Develop and document all operational and technical areas for above solution e) Migrate data from the legacy systems to ERP Section F Services Requirements Page 205 Confidential
F4 DOCUMENTATION 1. As part of its Technical Proposal, the Contractor must describe the level and types of documentation that will be delivered. This documentation must cover each level of operation, for example: user, security administrator, database administrator, operator, developer, etc. 2. Two complete hardcopy sets of documentation for all Contractor supplied components for this Project must be furnished, in addition to softcopies on CDs. 3. The manuals should feature clear organization of content, easy to understand language, useful graphic presentations, and a thorough index and glossary. These will be under the following categories: Detailed process manuals User manuals Operational manuals 4. These manuals must address the view of the system required by business unit staff (end users). It must contain sufficient information to enable the user to independently operate the system, troubleshoot simple problems, and correct problems. The User Manuals must be able to serve as a reference guide and a teaching aid. It must cover all facets of system functions and operations, including: Complete instructions for the users, completely explaining the use of each system function; System usage scenarios, based on real world examples drawn from the dayto-day workloads of typical users, that fully describe and explain the salient features and operation of the system; How input data are stored and related between system records; How to generate / suppress standard and ad hoc reports; Normal report distribution; Prioritization processing, system determined priorities, and user override procedures; System log-on, log-off, and security features; Error messages and error correction procedures; Help features and usage; System troubleshooting; Mandatory data fields and default data values; Traversing system menus; Screen layouts and contents; Inquiry functions Section F Services Requirements Page 206 Confidential
5. Besides, detailed User Manuals, Quick Reference cards will be produced by the Contractor, which will be an immediate aid to the user and quickly describe operations. 6. The Technical Manuals must address the view of the systems required by developers, administrators and other technical personnel. It should provide an understanding of the application; database design and file structures; relationships between programs, security; troubleshooting; special constraints; and other operational guidelines. 7. Copies of all licenses, warranties, maintenance agreements and similar materials for all Contractor delivered components of the project must be furnished separately. 8. Contractor must submit sample copies of all documents that it will prepare / deliver to PIA during the course of this project. Section F Services Requirements Page 207 Confidential
F5 WARRANTY AND MAINTENANCE SUPPORT 1. The Contractor will provide warranty services for a period of at least one year for software and a minimum of three years for hardware by ensuring that the system in every way meets the specifications stated in this RFP. The warranty will begin upon PIA s written final acceptance 15 of the system. All warranty support services, whether on- or off-site, are to be rendered free-of-charge to PIA. The Contractor shall be responsible for all costs (including but not limited to travel, accommodation, conveyance, other incidentals, etc.) associated with warranty support services. 2. Separate and apart from the warranty support services, the Contractor shall provide support ( Maintenance ) services for Applications, and RDBMS beginning upon the end of the warranty services and extended up to five (5) years thereafter. 3. The Contractor must describe in detail in the Technical Proposal its User and Technical Support Plan for the warranty and maintenance periods, covering the resources, timing and procedures that will be available to provide this support. The plan must include identifications of procedures for 24 x 7 support for on-site and off-site maintenance, for: on-site fault diagnostic techniques; remote or tele-diagnostic fault diagnosing techniques; average time to arrive on-site; mean time to fix major system components; fault escalation procedures; maintenance of error logs. 4. The Contractor must specify the various categories of problems it will support and describe the severity levels of problems. The escalation process must assure appropriate management contacts can be made in the event that the support response is not effective. PIA would like to sign a Service Level Agreement (SLA) (that would include penalties for non-performance or poor delivery) for maintenance support with the Contractor. 5. Details of the establishment of an effective Hot Line Telephone and Support Desk service should be provided. 15 Acceptance The ERP Solution shall be deemed accepted upon the successful completion of Acceptance Testing of all supplied applications and modules, conducted in accordance with PIA's Acceptance Criteria which will test the desired functionality and interoperability of Contractor supplied applications and modules. Section F Services Requirements Page 208 Confidential
6. PIA may require the Contractor to develop additional customized reports, screens, workflows, etc. during the maintenance and support period. Contractor must specify in its Technical Proposal a solution to accommodate PIA s requirement. The Commercial Proposal must contain the pricing mechanism for additional development / customization. 7. The Contractor must provide a list of clients in Pakistan for which ERP Maintenance Support is, or has been provided during the past three years. Details of modules supported should be included. Section F Services Requirements Page 209 Confidential
F6 VERSION AND UPGRADES 1. Contractor must ensure that training material / software / process documents are duly licensed for the purpose of implementation and use by PIA of the ERP. These are to be of latest version and Contractor must ensure up-gradation of all modules / material / process documents during the warranty period and as part of after-warranty maintenance support. 2. During the implementation and subsequent rollout, the Contractor would be responsible to arrange and provide free version upgrades of all components under its responsibility. Contractor must ensure that at the time of handing over the solution to PIA all components are of the latest release and that the total solution is certified by the Contractor for completeness. Section F Services Requirements Page 210 Confidential
SECTION G HARDWARE REQUIREMENTS Section G Hardware Requirements Page 211 Confidential
G1 HARDWARE 1. The Contractor must evaluate and prepare an appropriate configuration to run the proposed ERP solution. PIA is looking for a high-availability solution including servers, clustering design, and disaster recovery recommendations besides maintenance / repair options needed for the associated infrastructure. a) Contractor should submit details of the proposed configuration, including layout diagram detailing model designation(s), memory size, number of CPUs, type of drives with capacity and counts. b) The offered solution should comply with the Open Systems Architecture and latest technology trends. c) The solution should be scalable, both horizontally and vertically. d) The hardware should be sized keeping in view the operational requirements of the ERP and associated applications. e) The hardware should be fully capable of hosting the ERP certified database. f) The hardware must allow each partition of the ERP environment to be isolated in such a way that a software fault in one partition will not have an impact on another partition. g) All software required for clustering of servers and implementation of DRP should be included in the solution. h) The solution should be fully supported by the Contractor for not less than ten years from the date of supply. It should remain capable of being supported, upgraded and extended by the Contractor during this period. i) The solution provided should be accompanied with complete documentation, operating manuals, system diagrams, startup and recovery procedures and all other information required for proper and efficient operation. j) Contractor should provide all technical materials and verifiable benchmarks related to the proposed solution. The hardware should be certified by the ERP principal vendor for the operation of the ERP and be reasonably expected to be certified for future versions of the ERP during the expected life of the hardware. k) Contractor should provide information on warranties on the equipment and any options regarding warranty extension. Principal s assurance is required for parts availability after expiry of warranty period. l) The Contractor must provide thorough and contemporary 3 rd -party testing software for acceptance and load testing. The testing should be done according to systems equipment specifications as well as generally accepted practices. m) All test results should be completely documented by the Contractor. Complete test documentation including results of the 3rd party load / stress testing software should be provided to PIA. n) Based on PIA s high availability requirements, failover design should be based on protecting single point of failure. Section G Hardware Requirements Page 212 Confidential
o) For high availability on the application layer, the solution should implement log on load balancing between the application servers. It should not need any form of reallocation of resources between servers. The application environment should be sized and designed such that upon failure of an application server (based on single point of failure), minimum degradation of performance is experienced. p) A Disaster Recovery (DR) design should be provided which provides a seamless, pragmatic DR process. It should integrate within the overall design of the ERP landscape. q) The DR process should be simple to execute. A step-by-step process and procedure is required to minimize the potential for human error in a time of crisis and disaster. Additionally, the DR design must be easily tested with minimal impact on day-to-day operations. Section G Hardware Requirements Page 213 Confidential
SECTION H REQUIREMENTS COMPLIANCE MATRIX Section H Requirements Compliance Matrix Page 214 Confidential
H1 GLOBAL REQUIREMENTS GENERAL Detailed below are the global requirements applicable for the entire solution. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Description Remarks 4 Standard feature (S) Is available as a standard feature Module / standard feature of the proposed solution 3 Workaround (W) Is available as a work-around and without customization Is not a standard feqture of the proposed solution, but an acceptable workaround ix possible without any customization to the ERP and without incurring additional cost. Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal 2 Enhancement through add-on or third-party solution (E) 1 Customization (C) 0 Not available (N) The required functionality Is available through application add-on or third-party solution The feature/functionality can be made available through customization Cannot be catered as standard feature, workaround, enhancement, customization Is not a feature of the standard solution, but is possible through an application add-on or a third-party solution. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be fulfilled through a feature of the standard solution and any third-party application, but can be catered by developing a custom-built program for PIA. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be catered in any way. In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 215
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 1 Common Characteristics 1.1 Common characteristics are shared by all areas of the ERP Solution 2 Integration 2.1 2.2 Software supports modern best business practices, with data located in one integrated system shared across all organizational units It will also be integrated with future modules using the same development language / platform 3 Configuration 3.1 Software will require minimum software modification to meet its business requirements. It will allow for easy configuration to meet those requirements without changing software code or requiring Add-ons 4 Technology Interfaces 4.1 4.2 4.3 Software has standard application programming interfaces, tools and methodologies that allow future releases to accommodate interfaces without re-programming A standard approach to interfaces is available to avoid multiple, unique approaches for different systems The Contractor has ensured, at its cost, availability of not only its own APIs but also from other parties to enable integration with other applications that it has proposed along with the ERP as well as existing applications that will continue to run at PIA and will require integration with the proposed ERP 4.4 Contractor has ensured to provide XML-based APIs wherever these are available 5 Access Control 5.1 The system supports multiple levels of security while providing single sign-on facility to the users 5.2 Individual fields will be protected from unauthorized access 5.3 5.4 Access to certain functions and data will be protected until they are approved by PIA s concerned policy makers Application security will be integrated with database security. Data files / tables will only be accessed through the ERP; direct access through different query languages will not be possible Section H Requirements Compliance Matrix Page 216
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 5.5 Templates or group functions will be provided to facilitate maintenance 5.6 5.7 5.8 5.9 5.10 Changes in assignment (employee transfers) or termination / retirement will automatically trigger a review of the employee s security privileges Comprehensive logs of transactions and security incidents will be maintained for auditing purposes. System will be capable to maintain audit trails and logs System will provide authorization, authentication, integrity and non-repudiation facilities for critical transactions Password length and acceptable character combination as per industry standards are supported System will allow setting up of password change frequency and the number of previous passwords that could not be repeated 5.11 System will force users to change their passwords after pre-defined intervals 5.12 System will allow secure remote login and will support digital signature and time stamp, etc. 6 User Interface 6.1 The system will have a common look and feel across all applications 6.2 Screen labeling will be available in English and Urdu 6.3 Online help will be available for all applications and will allow for customization 6.4 The system will have fast data entry screens for bulk data entry 6.5 The system will be accessible using standard personal computer through browser 6.6 System will allow opening multiple sessions 6.7 6.8 6.9 System will allow for switching between different programs without first having to exit from the system. System will allow defining navigational menus that can be created by end-users according to their job requirements Business rules will be incorporated into the system such that the rules are applied at the time information is entered into the system Section H Requirements Compliance Matrix Page 217
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 6.10 The system will have validation routines / parameters to identify errors, inconsistencies or additional requirements at the time data is entered 7 Reporting / Inquiry 7.1 The system will include comprehensive inquiry / reporting tools that allow for easy access to authorized data 7.2 Drill down capability to examine details will be available 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 It will also be possible to create reports that reflect status as of a specified point in time Standard reports will be included to serve as models for customized reporting and to provide for basic functional reports Report wizards or similar techniques will be available to guide users through report creation The system will be such that reporting activities do not compromise responsiveness of the interactive system Reports will be formatted to print on local PC and LAN attached printers, centralized high-speed printers as well as over internet and intranet It will be possible to deliver fixed reports to users on a pre-determined schedule to be reviewed online, to be retained online or to be printed at the user s discretion System will be able to deliver the reports using its own messaging / workflow engine as well as PIA s email system, Lotus Notes The system will be able to demonstrate useful demographic and forecasting capabilities 7.11 The system will support text-based, parameterized and wild-card searches 7.12 System will provide users the ability to develop ad hoc reports at their discretion 7.13 The system will include a data dictionary or similar provision to allow non-technical users to identify the appropriate data elements for inclusion in their reports 8 Analytic Tools 8.1 PIA desires decision support tools and information bases that are fully integrated with the system to facilitate strategic planning, tactical operations and organizationwide analysis these will be available Section H Requirements Compliance Matrix Page 218
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 8.2 8.3 The system will support the easy movement of data to common packaged PC-based applications such as Microsoft Office The system will be capable of producing what if scenarios to support decisionmaking 9 Communication 9.1 9.2 The system will foster information sharing at all levels of the organization. For example, policy directives and goals will be incorporated into the budget planning process; departments will be able to share purchasing intentions and specifications and best business practices will be readily available for consultation The system will provide a single place for users to quickly access information and updates on organizational news and policies 10 Flexibility 10.1 The system will be easily reconfigured to respond to changes in business practices, policy directives, organization structure, statutes and regulations 10.2 Flexibility will extend both to enterprise-wide as well as industry specific practices 11 System Availability 11.1 Overall it will be a highly available solution 11.2 The system will be available for access by authorized personnel from anywhere at any time of the day or night (24 x 7 availability) 11.3 The system will be equally usable from remote locations as from the Head Office 11.4 Web-based access will be supported 12 Transaction Timing 12.1 12.2 12.3 The system will support real time operations. Changes to data or the status of processes will be immediately available in the system System operations will not constrain the business processes supported by the system The system will support effective dating for transactions, including both future and retroactive changes. The authority for such transactions will be included in the security capabilities of the system Section H Requirements Compliance Matrix Page 219
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 12.4 The assignment of a retroactive date will generate the changes required to bring the system up to the current date 13 Online Documentation and Training 13.1 The system will include customizable online documentation and training materials such as context-specific help, search capability, business process documentation and process maps 13.2 Context sensitive help will include: 13.2.1 Menu options 13.2.2 Tabs 13.2.3 Data entry fields 13.2.4 Buttons 13.2.5 Icons 14 Storage / Record Retrieval 14.1 14.2 Record collection and retention is an important organizational requirement. The ability to easily archive, retain and access records is required Records retention procedures will allow information to be stored in a way that can be accessible indefinitely 15 Data Support 15.1 The solution will support multiple data types text, image, voice, etc. 15.2 15.3 The system will support data upload to and download from different systems in multiple formats Besides simple upload / download facility it will also communicate and support data interchange with mobile devices such as: 15.3.1 cellular phones 15.3.2 handheld terminals 15.3.3 PDAs, etc. 15.4 System will support other devices such as: Section H Requirements Compliance Matrix Page 220
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 15.4.1 Scanners 15.4.2 barcode readers 15.4.3 biometric devices 15.4.4 card readers 15.4.5 RFID devices, etc. 15.5 Support for important messaging / data formats / standards will include, as a minimum: 15.5.1 Aircraft Communication Addressing and Reporting System (ACARS) 15.5.2 SITATEX 15.5.3 ASCII 15.5.4 EDI 15.5.5 SMS 15.5.6 XML 15.5.7 Spec 2000 15.5.8 UNeDocs 15.5.9 MS-Office 15.5.10 Lotus Notes, etc. 16 System Security 16.1 16.2 System provided is secure and meets all standard security requirements i.e. Identification, Authentication, Authorization and Integrity System allows implementation of industry standard security policies and is capable to evolve to meet security challenges 16.3 Details of the proposed security tools is provided 17 Web-enablement 17.1 The proposed system is Internet ready and allows web-enabled access to users from anywhere across the world through a web portal Section H Requirements Compliance Matrix Page 221
GLOBAL REQUIREMENTS GENERAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 17.2 The system is compliant with the Service Oriented Architecture (SOA) 18 Self-Service Portal 18.1 18.2 The proposed system will provide the users access to self-service portals where they can log in and obtain different levels of information such as directory lists, airline schedules, seat availability on flights, etc The proposed system will also allow users to update personal information and enter requests such as leave and passage approval, purchase of tickets, etc. 19 Workflow 19.1 The proposed system will provide Workflow functionality to users by which information and requests could be automatically routed to the concerned levels for approval 20 Others 20.1 Some other requirements include: 20.1.1 Supporting multi currency 20.1.2 Supporting multi languages 20.1.3 Supporting multiple legal companies 20.1.4 Supporting multiple tax structures (that is, supporting individual country tax structure and reporting) 20.1.5 Interfacing with legacy systems 20.1.6 Storing transactions and balances of legacy systems 20.1.7 Supporting user defaults 20.1.8 Supporting user defined screens 20.1.9 Supporting multiple date formats 20.1.10 Supporting multiple decimal formats in amounts simultaneously 20.1.11 Supporting user defined fields 20.1.12 Scheduling of jobs for unattended operations 20.1.13 Maintaining effective dates of master file data Section H Requirements Compliance Matrix Page 222
H2 GLOBAL REQUIREMENTS TECHNICAL Detailed below are the technical requirements applicable for the entire solution. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Description Remarks 4 Standard feature (S) Is available as a standard feature Module / standard feature of the proposed solution 3 Workaround (W) Is available as a work-around and without customization Is not a standard feqture of the proposed solution, but an acceptable workaround ix possible without any customization to the ERP and without incurring additional cost. Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal 2 Enhancement through add-on or third-party solution (E) 1 Customization (C) 0 Not available (N) The required functionality Is available through application add-on or third-party solution The feature/functionality can be made available through customization Cannot be catered as standard feature, workaround, enhancement, customization Is not a feature of the standard solution, but is possible through an application add-on or a third-party solution. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be fulfilled through a feature of the standard solution and any third-party application, but can be catered by developing a custom-built program for PIA. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be catered in any way. In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 223
GLOBAL REQUIREMENTS - TECHNICAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 1 New Technology 1.1 The system is designed in such a way that it easily allows the incorporation of new technologies, as they become available 2 Multiple Environments 2.1 The system supports multiple environments. These environments are sufficiently isolated from each other so that operations in one environment do not affect those of another. The environments are as follows: 2.1.1 Production all production processing will be performed in this environment 2.1.2 2.1.3 Development all development activities including unit and system testing will be conducted in this environment Test after all development, unit and system testing has been completed, this environment will be used for User Acceptance Testing before the system is accepted into production 2.1.4 Training for all in-house implementation and post implementation training activities 3 System Performance 3.1 3.2 3.3 The system is responsive and available; it supports rapid fail-over or redeployment in the event of problems or planned maintenance. Ninety-nine percent of all fail-over events will take place in less than five minutes Any volume (batch) processing will not interfere with online responsiveness or availability System availability figures of the proposed solution are provided. In case various components have different values, these are specifically mentioned. 4 Archive and Purge 4.1 The system supports periodic archival and purging of unused or obsolete information 4.2 Archived information is available for historical reporting in such a manner that queries can be performed on archived data using automated data retrieval functions 4.3 A complete data archival plan is provided 5 Recovery Section H Requirements Compliance Matrix Page 224
GLOBAL REQUIREMENTS - TECHNICAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 5.1 5.2 5.3 The system automatically recovers to the last complete prior transaction in the event of a failure The system clearly indicates to the user that a transaction failed and that it must be re-entered. Recovery occurs without operator intervention Contingency and backup recovery procedures with guaranteed Service Level Agreements (SLAs) have been provided 6 Backup and Reorganization 6.1 The system provides for the unattended daily backup of all information and data to a media that can be stored offsite for disaster recovery purposes 6.2 System supports different types of backups such as: 6.2.1 Full backup 6.2.2 Incremental backup 6.2.3 Online backup 6.2.4 Offline backup 6.3 Backups do not prevent the system from being available at all times and do not disrupt system operations 6.4 There is no performance degradation during data backup 6.5 Database reorganizations do not significantly impair system availability 6.6 The calculation of time taken to backup data with respect to data size increase has been provided. 7 Print Management 7.1 The system provides a method for managing the print environment for report distribution so that reports are directed to the appropriate print facility. It caters to both high speed centralized printing facilities as well as local LAN-based printing facilities that will be employed in addition to printing over internet / intranet 8 Technology Architecture 8.1 Recommendations of the technology architecture under which the proposed ERP Package will operate are provided, with the following features preference: Section H Requirements Compliance Matrix Page 225
GLOBAL REQUIREMENTS - TECHNICAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 8.1.1 N-tiered Client/Server architecture incorporating thin presentation-logic-client communicating with client-neutral, server-based applications, communicating with the database 8.1.2 Thin client, for remote users 8.1.3 Applications distributed at servers located at Head Office 8.1.4 Centralized database, located at Head Office 8.2 Able to support different network based services / protocols such as: 8.2.1 TCP/IP 8.2.2 DHCP 8.2.3 WINS 8.2.4 DNS 8.2.5 NetBEUI 8.2.6 LDAP 8.2.7 FTP 8.2.8 DLC 8.3 System is able to support open specifications for APIs / middleware applications such as: 8.3.1 COM / DCOM 8.3.2 CORBA 8.3.3 RMI 8.3.4 ALE 8.3.5 MQ Series Link 8.3.6 OLE / COM2 8.3.7 ODBC 8.4 It is able to integrate with Internet technologies such as: Section H Requirements Compliance Matrix Page 226
GLOBAL REQUIREMENTS - TECHNICAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 8.4.1 HTTP 8.4.2 XML 8.5 Scalable architecture is supported, such as: 8.5.1 SMP 8.5.2 MPP 8.5.3 Clustering 8.6 8.6.1 While designing the technology architecture, the following are kept under consideration: Solution is scalable with complete platform independence without tying down PIA to a single platform 8.6.2 Solution is effortlessly portable from one system to another 8.6.3 8.6.4 It provides support for different flavors of UNIX; however it is a totally interoperable solution There is open source support. In this context, the current scenario vis-à-vis the solution offered and the future roadmap are provided 8.6.5 Optimization of licensing costs for the platform software 8.6.6 PIA s existing Local and Wide Area Network, and minimization of Wide Area Network bandwidth requirements 8.6.7 Simplicity of System Administration and Operations 8.6.8 Ease of business continuity planning and execution 9 Server 9.1 9.2 9.3 The recommended configuration caters for the existing load as well as annual volume growth of 10-15% for the next five years The configuration is capable of retaining data for at least eleven years (that is, current year plus ten years historical record) The solution is redundant, reliable and consistently available to allow uninterruptible 24x7 operations Section H Requirements Compliance Matrix Page 227
GLOBAL REQUIREMENTS - TECHNICAL Sr. No. Requirement Response (S, W, E, C, N) Remarks 9.4 9.5 9.6 The production server configuration includes redundant (RAID5) data storage and multiple processors and caters for compatibility with PIA s existing LAN / WAN environment The areas of performance and scalability, reliability and fault tolerance while recommending Server configurations have been taken into consideration Performance guarantees of the solution under different scenarios such as concurrent users during normal working, during data backup, during overload, during partial system failure, etc. have been provided 10 System and Network Management Tools 10.1 Suitable Systems and Network Management Tools have been recommended. These tools will ensure proper planning, configuration, and problem handling of IT resources and support such tasks as: 10.1.1 defining, resolving, and managing problems 10.1.2 operating networks and multi-vendor systems 10.1.3 distributing and managing software and data 10.1.4 controlling operations 10.1.5 planning and managing performance 10.1.6 administering security 10.1.7 maintaining asset information 10.1.8 planning for the future capacity of systems 11 Authentication 11.1 The system supports authentication methods that will assure that only authorized users are able to access protected data and transactions 11.2 These include support for: 11.2.1 digital signatures 11.2.2 PKI infrastructure Section H Requirements Compliance Matrix Page 228
H3 GLOBAL REQUIREMENTS OTHERS Detailed below are other global requirements applicable for the entire solution. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Description Remarks 4 Standard feature (S) Is available as a standard feature Module / standard feature of the proposed solution 3 Workaround (W) Is available as a work-around and without customization Is not a standard feqture of the proposed solution, but an acceptable workaround ix possible without any customization to the ERP and without incurring additional cost. Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal 2 Enhancement through add-on or third-party solution (E) 1 Customization (C) 0 Not available (N) The required functionality Is available through application add-on or third-party solution The feature/functionality can be made available through customization Cannot be catered as standard feature, workaround, enhancement, customization Is not a feature of the standard solution, but is possible through an application add-on or a third-party solution. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be fulfilled through a feature of the standard solution and any third-party application, but can be catered by developing a custom-built program for PIA. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be catered in any way. In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 229
GLOBAL REQUIREMENTS - OTHERS Sr. No. Requirement Response (S, W, E, C, N) Remarks 1 RDBMS AND DATABASE ADMINISTATION TOOLS 1.1 Database schema definition, management, query and reporting facilities provided 1.2 1.3 Historical transactions will be maintained by the RDBMS. Facilities for reviewing transactions, multiple transaction roll back and transaction log reporting are available Database update facilities include features such as the use of working copies and status reporting on query and update operations. 1.4 The system provides locking mechanisms for update and delete operations. 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 The system maintains concurrent control mechanisms to ensure the correctness of transactions and to detect and resolve deadlocks on the network. The system supports authorization lists and groups for create, read, update and delete There is a provision of on-line facilities to manage transactions and overall on-line system performance. The system provides users and applications with distribution independence. Users do not need to know where database objects are located. The system operates in a distributed environment where different nodes of the network run at different functional levels. The system has the ability to automatically recover and restore the database fully to the last consistent state after a media failure. The ability to notify users as to what transactions were being processed but not written to the database during a crash is available. The system has checkpoint facilities and the capability to roll back / undo to any one checkpoint. The system will continue to be available to users during any backup process or alteration of the database schema s and definitions. 1.14 The system will support one-to-one, one-to-many and many-to-one relationships. 1.15 The system is capable of working in a multi-tier environment, and provides the appropriate tools for partitioning the location of the processing. All tuning will be independent to the user. 1.16 All information in the database is represented as values in the table. Section H Requirements Compliance Matrix Page 230
GLOBAL REQUIREMENTS - OTHERS Sr. No. Requirement Response (S, W, E, C, N) Remarks 1.17 1.18 Null value support (as opposed to empty character strings, blank characters or zero) is available for all data types. Database recovery will be made in minimum acceptable downtime. Acceptable downtime will be negotiated and agreed upon 1.19 RDBMS has a support for ETL 1.20 RDBMS has support for SAN storage and cluster environment 1.21 Load balancing and failover are supported to minimize down time 1.22 RDBMS will support DR sites and automatic standby configurations. It will be capable of operating in the DR environment and support synchronous as well as asynchronous data replication at remote DR site 1.23 RDBMS will support large amounts of data in terra bytes 1.24 RDBMS will have support for transmission of data from other new systems as well as exiting legacy systems 1.25 It will support libraries to enable backup on tape and disk drives 1.26 It have support new firewalls and n-tier network architecture 1.27 It will support OLAP, OLTP and DSS systems 2 APPLICATION DEVELOPMENT TOOLS 2.1 The proposed solution has a built-in 4GL development environment tool set 3 QUERY AND REPORT GENERATOR TOOLS 3.1 The report generator functionality includes a scheduling or production process for routine reporting 3.2 The report generator functionality supports Structured Query Language (SQL) 3.3 It also supports industry standard report generators such as Crystal Reports, Business Objects, etc. 3.4 Report generator has formatting and statistical capabilities such as: 3.4.1 Averaging 3.4.2 Multi-level sub-totaling Section H Requirements Compliance Matrix Page 231
GLOBAL REQUIREMENTS - OTHERS Sr. No. Requirement Response (S, W, E, C, N) Remarks 3.4.3 Percent change comparisons 3.4.4 Standard mathematical operations 3.4.5 Financial calculations 3.5 Generated reports are able to be saved in several output formats, such as: 3.5.1 MS Word 3.5.2 MS Excel 3.5.3 Text 3.5.4 PDF 3.5.5 HTML 3.5.6 XML 4 INTERIM SERVERS 4.1 Specifications are provided for interim servers that will be used for ERP configuration, add-on software development, user training, etc. 4.2 All necessary hardware components are also provided 4.3 The configuration of these machines will support the number of users as specified in the plan. 5 3 RD PARTY SOFTWARE 5.1 All required 3rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration tools, disaster recovery and business continuity tools, APIs / interfaces, etc. will be made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed ERP solution. 5.2 A complete solution in all respects has been offered to PIA delays or costs arising out of any shortcoming will be borne by the Contractor. Section H Requirements Compliance Matrix Page 232
H4 FUNCTIONAL REQUIREMENTS FINANCE Detailed below are the functional requirements applicable for Finance. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Description Remarks 4 Standard feature (S) Is available as a standard feature Module / standard feature of the proposed solution 3 Workaround (W) Is available as a work-around and without customization Is not a standard feqture of the proposed solution, but an acceptable workaround ix possible without any customization to the ERP and without incurring additional cost. Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal 2 Enhancement through add-on or third-party solution (E) 1 Customization (C) 0 Not available (N) The required functionality Is available through application add-on or third-party solution The feature/functionality can be made available through customization Cannot be catered as standard feature, workaround, enhancement, customization Is not a feature of the standard solution, but is possible through an application add-on or a third-party solution. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be fulfilled through a feature of the standard solution and any third-party application, but can be catered by developing a custom-built program for PIA. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be catered in any way. In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 233
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 1 General Ledger 1.1 Maintaining charts of accounts for multi-company processing 1.2 Supporting multiple chart of accounts for one company 1.3 Maintaining ledger accounts and hierarchies of cost centers and profit centers 1.4 Providing graphical representation of account hierarchy with easy navigation and drill-down features 1.5 Maintaining statistical ledgers for quantities, volumes, number of flights, etc. 1.6 Allowing at least 30 digits for the qualified chart of accounts in order to incorporate notional account, group companies, business units, locations, aircrafts, flight numbers, departments / cost centers based on the financial statement segments 1.7 Allowing at-least 14 posting periods in a financial year 1.8 Allowing multiple financial years for multiple companies 1.9 Classifying multiple levels of chart of accounts 1.10 Providing and supporting a dynamic business unit structure in the chart of accounts 1.11 Allowing mass maintenance of accounts by copying one chart into another as reference or deleting / blocking multiple accounts 1.12 Allowing access to certain types of accounts to authorized users / user-groups 1.13 Uploading budget from the Budgets and Cost Management System 1.14 Posting of journal entries from subsidiary ledgers 1.15 Processing entries directly entered in the General Ledger 1.16 Accounting for special projects / subsidiaries; such as SpeedEX, etc. 1.17 Processing entries from other systems 1.18 Auto-generating entries of recurring items 1.19 Maintaining and analyzing budgeted and actual amounts by account head 1.20 Allocating expenses on the basis of defined parameters 1.21 Maintaining multi-currency accounts Section H Requirements Compliance Matrix Page 234
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 1.22 Catering for inter-company settlements 1.23 Maintaining ledgers for management and statutory reporting 1.24 Generating consolidated financial statements (Balance Sheet, Profit and Loss Account, Cash flow, Statement of Changes in Equity, etc.) along with consolidated supporting schedules setting off inter-company balances 1.25 Consolidating and summarizing accounts 1.26 Consolidating financial accounts across multiple companies 1.27 1.28 Allowing separate closing of individual areas for example Fixed Asset, Accounts Receivable, Accounts Payable, General Ledger, etc. Allowing real-time online updates of General Ledger along with provision of temporary and permanent stoppages for account closing purposes these stoppages should be controlled by authority levels based on different types of vouchers / sub-ledger entries 1.29 Allowing posting of transactions after temporary closing 1.30 Allowing multiple year-end processing 1.31 Processing month-end and year-end accounts 1.32 Automatically calculating retained earnings 1.33 Generating financial statements 2 Financial Analyzer 2.1 2.2 2.3 Providing detailed analysis of financial data and ratios to fulfill varied management information requirements Producing complete books of accounts with accompanying notes to accounts in line with International Accounting Standards and the Companies Ordinance Providing comparisons of actual / current period data with budgeted data as well as with data of previous period and same period of previous year 3 Fixed Assets Management 3.1 Maintaining ownership data for assets 3.2 Recording asset supplier information Section H Requirements Compliance Matrix Page 235
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 3.3 Maintaining number of flying hours in case of aircrafts 3.4 Maintaining original and net book value 3.5 Calculating asset depreciation based on multiple depreciation methods 3.6 Allowing changes in book value and changes in depreciation rate 3.7 Tracking physical location of assets at any given time 3.8 Maintaining asset and depreciation records for management and statutory reporting 3.9 Recording asset replacement value 3.10 Allowing zero value assets 3.11 Allowing inter-company assets transfer, for example from one subsidiary to another 3.12 Showing assets in-transit during transfers till acknowledged by receiving location 3.13 Handling mass transfer of assets 3.14 Splitting of assets 3.15 Recording asset assemblies and sub-assemblies (parent-child relationship) 3.16 Processing disposal of assets 3.17 Capitalizing projects and transferring costs 3.18 Revaluing assets 4 Cash Management 4.1 Maintaining records of daily cash balances including details of daily receipts and disbursement of cash 4.2 Monitoring bank balances 4.3 Identifying withdrawal limits before a transaction for each bank account maintained in the system 4.4 Transferring funds from one account into another 4.5 Uploading and recording account statements received from banks Section H Requirements Compliance Matrix Page 236
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 4.6 4.7 Automatically processing bank reconciliation statements based on payments and deposits Forecasting cash requirements based on accruals, cash in hand, bank balances, outstanding and anticipated invoices from suppliers and agents / other customers, etc. 4.8 Monitoring of markup rates and appropriate placement of funds 4.9 Calculating markup in running finance and deposit / savings accounts 4.10 Maintaining detailed records of investments of liquid funds including maturity profiles of funds invested 4.11 Supporting user-defined cash flow statements 5 Petty Cash Management 5.1 Recording cash receipts 5.2 Recording cash disbursements 5.3 Maintaining and verifying cash balances 5.4 Determining withholding tax and sales tax on cash disbursements 5.5 Submitting claims to Head Office for replenishment of petty cash 6 Accounts Payable 6.1 Creating and managing vendor master records 6.2 Adopting to PIA s payment policies including the limits of approval authorities 6.3 Recording supplier s invoices and updating liabilities 6.4 Checking for duplicate invoices 6.5 6.6 Performing the two-way and three-way match between purchase order, receiving statement and supplier s invoice Processing payments to suppliers, employees and other parties through different methods: 6.6.1 Cash 6.6.2 Authority Letter for payment through Petty Cash Section H Requirements Compliance Matrix Page 237
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 6.6.3 Cheque both manual and pre-printed system generated 6.6.4 Bank Transfer Letter both hardcopy and data file for upload 6.6.5 Letter of Credit 6.6.6 Credit Card 6.6.7 Internet 6.7 Allowing partial payments against invoices 6.8 Splitting one payment between different entities 6.9 Linking with payment systems of various banks offering e-payment services 6.10 Recording withholding tax liability 6.11 6.12 Processing payment of government dues deducted at source and generating tax challans / returns Maintaining records of General Sales Tax paid on purchase of materials and hiring of services for subsequent credit at the output stage 6.13 Allowing payments to be made both from Head Office and remote locations 6.14 Providing online payment support for PIA s upcountry and international stations 6.15 Provisioning for making payments in foreign currencies 6.16 Booking exchange rate gains and losses for foreign currency payments 6.17 Allowing generation of recurring payment vouchers for recurring payments 6.18 Aging of accounts payables 7 Revenue Accounting 7.1 Capturing details of tickets / air waybills issued to agents (stock control) 7.2 Capturing ticket / air waybill number and other details for sales of tickets / booking of cargo 7.3 Handling sales proceeds and matching of passenger revenues 7.4 Handling bookings and matching of cargo revenues Section H Requirements Compliance Matrix Page 238
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 7.5 Handling revenues generated through inter-line operations 7.6 Handling sales of services to other airlines / agencies 7.7 Handling sales returns / refunds to customers as well as agents 7.8 Calculating agents commissions 7.9 Integrating with: 7.9.1 Sabre Applications 7.9.2 QUASAR system (for passenger revenues) 7.9.3 SITA hosted applications (for cargo revenue) 7.9.4 PIA s Awards Plus program (for passenger ticket redemption) 7.10 7.11 7.12 7.13 7.14 7.15 7.16 Contractor has read the details of PIA applications, particularly about COSSAP, and the proposed solution fulfills all the requirements stated therein Contractor has read the Requirements for Passenger Revenue Accounting, and the proposed solution fulfills all the requirements stated therein Contractor has read the Requirements for Cargo Revenue Accounting, and the proposed solution fulfills all the requirements stated therein Ticket wise identification of APW and automated invoice generation along with accounting treatment thereon. MCOs accounting and report generation of tickets issued against MCO along with accounting treatment thereon. Issuance of automated short collection investigation reports and ADMS for any variation in MCO amounts and tickets issued thereon along with proration. Capable of creating sales contract, agreements, orders with other airlines and third parties based on different criteria such as flat rate, fixed price, time & material. 8 Accounts Receivable 8.1 Creating and maintaining customer / agent master records 8.2 Creating customer groups and clubbing related customers together 8.3 Managing credit ratings for customers / agents Section H Requirements Compliance Matrix Page 239
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 8.4 8.5 Creating sales contracts / agreements / orders with other airlines and third parties based on different criteria such as flat rate, fixed price, time and material, etc. Creating sales orders by direct manual entry in the system as well as by automatically converting data imported from other applications such as QUASAR, Sabre, etc. 8.6 Generating invoices and maintaining receivables 8.7 Sending payment reminders through email and fax 8.8 Providing multi-currency support for sales of tickets and other goods and services 8.9 Generating debit / credit notes for adjustments to accounts receivables 8.10 Enabling electronic submission of invoices and debit / credit notes 8.11 Recording payments received 8.12 Offsetting payments against outstanding credit: 8.12. By manually selecting open items 8.12. By running automatic settlements based on pre-defined rules 8.13 Recording and managing receipt of security deposits / bank guarantees from customers / agents 8.14 Calculating and managing incentives and commissions to agents 8.15 Managing credit sales 8.16 Maintaining and processing aging statements 8.17 Maintaining credit, payment and bad-debt history of customers 9 Insurance Management 9.1 9.2 9.3 Maintaining market valuation of assets and linking them with the Assets Master of the Fixed Assets Management Providing true / logical valuation for insurance purpose of all assets including aircraft fleet and properties. Professional risk management techniques should be applied with an aim to minimize risk and optimize savings in premium costs Calculating insurance premiums based on approved quotes and triggering requests for payment of premium Section H Requirements Compliance Matrix Page 240
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement 9.4 Calculating monthly allocation of insurance cost 9.5 Tracking outstanding insurance claims raised 9.6 9.7 Generating required renewal / underwriting information for renewal of aviation / aircraft fleet and general insurance policies Generating correctly the required information for settlement of insurance claims by insurance companies. For example, in case of aviation insurance claims the standard information which is required for claim processing like certificate of registration, certificate of airworthiness, investigation report, etc. should be available in the system. Same should apply to claims handling for all general / aviation insurance policies 9.8 Handling and processing customer insurance claims against PIA 10 Leasing Management 10.1 Terms and conditions and other relevant details of leasing arrangements leasing company, type of lease (operating or financial lease), lease rentals, down payment, residual value, lease period, etc. 10.2 Auto-generating recurring payment vouchers in Accounts Payable 10.3 Identifying physical location of leased assets 10.4 Identifying users of leased assets 10.5 Processing disposal of leased assets 10.6 Handling and managing aircraft leasing, for example wet lease, etc. 11 Budget and Cost Management 11.1 Creating and maintaining hierarchical structures for cost centers 11.2 11.3 11.4 Creating and maintaining different cost / expenditure types (direct, indirect, fixed, variable, semi-variable, etc.) and collecting data relating to those types Defining a complete budget hierarchy and classifying revenue and expenditure items. The budget model should be flexible and capable to update itself with the changes in operations / flight schedules Providing graphical representation of budget hierarchy with easy navigation and drilldown features Response (S, W, E, C, N) Remarks Section H Requirements Compliance Matrix Page 241
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 11.5 Creating and maintaining cost collectors such as maintenance orders 11.6 Supporting hierarchical structure of managing the maintenance orders 11.7 Collecting shop floor data against maintenance orders 11.8 Recording man-hours against maintenance orders 11.9 Issuing external repair orders against maintenance orders 11.10 Defining control limits for over-expenditure against specified budget heads 11.11 11.12 Performing budget availability checks while posting transactions restricting spending beyond budget limits Managing over-expenditure through special approvals based on authority levels and generating reports to monitor use of special approvals 11.13 Maintaining baseline and revised budgets 11.14 Allowing import of budgets created in external systems such as MS-Excel 11.15 Allowing manual input of budget data at lowest level of detail and rolling-up to provide summarized data 11.16 Allowing manual input of budget data at summarized level and allocating it: 11.16 Manually 11.16 Automatically through pre-defined formulae 11.17 Maintaining sales targets for passenger and cargo revenue generation 11.18 Distribution of annual budget over specified periods; monthly distribution or on a seasonal pattern 11.19 Maintaining cost centers for cost collection 11.20 Comparing budgeted and actual expenditures 11.21 Supporting standard costing model based on actual operations, comparable with the actual results along with the variance analysis. It should automatically prepare standard reports from fixed and flexible budgetary inputs 11.22 Supporting and providing Activity Based Costing 11.23 Managing overhead costing Section H Requirements Compliance Matrix Page 242
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 11.24 Integrating with PIA s MRO solution for job order costing 11.25 11.26 Allowing allocation of expenditures from one cost centre to another based on PIA defined rules Determining dependence on fuel pricing and providing different what-if analysis and recommendations for hedging 11.27 Preparing Traffic Load Summary reports 11.28 Supporting different budgeting techniques including zero-based budgeting 12 Profitability Management 12.1 Creating and maintaining hierarchical structures for profit centers 12.2 Planning and setting up sales / performance targets 12.3 Handling special agreements with IATA, different airlines and agents 12.4 Collecting operational and financial data, such as: 12.4. Flight schedules 12.4. Fare paying passengers 12.4. Flight logs 12.4.4 Freight tonnage 12.4. Maintenance and repair charges 12.4. Engines / components / spares reservation / leasing charges 12.4. Aircraft rental charges 12.4. Block hours 12.4. Fuel uplift charges 12.4. 12.4. 12.4. Landing / navigational charges En-route charges Handling charges aircraft, passenger, cargo / baggage, etc. 12.4. Passenger related expenses taxes, handling, meals, give-aways, etc. Section H Requirements Compliance Matrix Page 243
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 12.4. Flight disruption charges - hotel accommodation, meals, transportation, parking, security, technical handling, crew allowances, etc. 12.4. 12.4. 12.4. Crew related expenses allowances, transportation, layover, flying, etc. Commissions to agents for ticket sales Fixed costs 12.5 Preparing traffic load summaries 12.6 Generating aircraft- and route-wise fuel uplift report 12.7 Providing costing reports including but not limited to direct overhead costing, variable overhead costing, indirect fixed costing, etc. 12.8 Calculating route and aircraft profitability and development of route economics 12.9 Providing profitability analysis for other activities such as maintenance services, training, catering, etc. provided to third parties 12.10 12.11 Preparing financial statements (balance sheet, income statement, cash flow statement and profitability statement) for stations based on their local base currencies along with conversion to PKR Statistical and operational performance reporting based on airline specific Key Performance Indicators (KPIs) such as: 12.11 Market share 12.11 Load factor 12.11 Passenger yield (Revenue per passenger kilometer) 12.11 Revenue seat factor 12.11 Best / worst performing flight segments / routes 12.11 Best / worst performing stations 12.11 Earnings by hubs and international entity including code-sharing 12.11 Largest revenue earning routes 12.11 Ranking of cities against revenue generated 12.11 Others Section H Requirements Compliance Matrix Page 244
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 12.12 Reporting by: 12.12 Region 12.12 Network 12.12 Route 12.12 City Pair 12.12 Station 12.12 Aircraft 12.12 What-if analysis 13 Foreign Currency Management 13.1 Supporting daily maintenance of foreign currency rates 13.2 Allowing currency rate conversion calculations 13.3 Supporting multiple currency rates for different purposes 13.4 Supporting different decimal places for different currencies; for example 0 for Japanese Yen, 2 for Pak Rupees, 3 for Omani Riyal, etc. 13.5 Supporting currency conversion, translation and revaluation 13.6 Maintaining both foreign and local currency amounts for individual transactions 13.7 Calculating and posting exchange rate gains and losses 14 Taxation Management 14.1 Allowing different tax regimes 14.2 Supporting tax systems in vogue in countries where PIA offices are located 14.3 Supporting calculations of VAT 14.4 Supporting sales tax 14.5 Supporting Civil Aviation tax 14.6 Supporting withholding tax 14.7 Supporting income tax Section H Requirements Compliance Matrix Page 245
FUNCTIONAL REQUIREMENTS FINANCE Sr. No. Requirement Response (S, W, E, C, N) Remarks 14.8 Supporting zero tax 14.9 Supporting tax reporting 14.10 Maintaining effective dates for tax exemption certificates 15 Treasury and Risk Management 15.1 Minimizing idle cash 15.2 Managing portfolios 15.3 Positioning in multiple currencies 15.4 Supporting various financial instruments such as debts, investments, foreign exchange, derivatives, etc. 15.5 Tracking exposures and hedges 15.6 Analyzing and mitigating risks 15.7 Managing liquidity 15.8 Carrying out sensitivity analysis 15.9 Simulating different scenarios Section H Requirements Compliance Matrix Page 246
H5 FUNCTIONAL REQUIREMENTS HUMAN RESOURCES AND ADMINISTRATION Detailed below are the functional requirements applicable for Human Resources and Administration. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Description Remarks 4 Standard feature (S) Is available as a standard feature Module / standard feature of the proposed solution 3 Workaround (W) Is available as a work-around and without customization Is not a standard feqture of the proposed solution, but an acceptable workaround ix possible without any customization to the ERP and without incurring additional cost. Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal 2 Enhancement through add-on or third-party solution (E) 1 Customization (C) 0 Not available (N) The required functionality Is available through application add-on or third-party solution The feature/functionality can be made available through customization Cannot be catered as standard feature, workaround, enhancement, customization Is not a feature of the standard solution, but is possible through an application add-on or a third-party solution. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be fulfilled through a feature of the standard solution and any third-party application, but can be catered by developing a custom-built program for PIA. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be catered in any way. In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 247
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 1 HR Planning and Operations 1.1 Setting up and managing HR budgets 1.2 Updating organizational charts 1.3 Creating and maintaining job specifications and job descriptions 1.4 Simulating, analyzing, forecasting and experimenting with proposed organizational changes 1.5 Providing analytical reporting such as headcount planning, cost simulation, etc. 1.6 Managing and optimizing the workforce within PIA 1.7 Managing capacity planning and load planning 1.8 1.9 1.10 1.11 1.12 1.13 Maintaining employee personnel details including staff number, name, address, family details, etc. Maintaining employment history including personal data, joining date, confirmation date, group/grade level, promotions with dates, placements, transfers, temporary transfers, foreign postings, separation date, training history, etc. Maintaining performance appraisals that should include the overall rating, last year s objectives versus actual achievements, objectives for next year, training and development needs, performance improvement plans, appraiser s comments, etc. Allowing employee photographs and other documents to be added as part of employee records Automatically monitoring dates for various HR processes; that is specifying datedriven reminders to initiate follow up activities (for example, annual increment, periodic performance review, expiry of employment contract, retirement date, etc.) Integrating with PIA s document management system where physical records are currently being archived 1.14 Recording employee grievances and decisions made thereon 1.15 Maintaining records of employees on deputations and secondments 1.16 Managing disciplinary cases against employees 1.17 Maintaining contract details of contractual employees Section H Requirements Compliance Matrix Page 248
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 1.18 Managing award schemes 2 Recruitment Management 2.1 Maintaining a database of applicants with details of their personal data including education, qualification and work experience related information 2.2 Managing selection testing 2.3 Scheduling and arranging interview sessions 2.4 Organizing and tracking candidates throughout the entire recruiting process 2.5 Maintaining a list of available job positions 2.6 Processing recruitment requisitions against sanctioned positions 2.7 2.8 Allowing web-based job application and resume submission as well as online submission of application fee Identifying candidates based on the matching of job requirements with the skills and qualifications of each individual 2.9 Short-listing candidates based on job specifications 2.10 Identifying specific essential requirements for a job and allowing comparison of candidates based on these requirements 2.11 Recording the ratings and comments of the interviewers 2.12 Issuing acceptance / rejection letters depending on recruitment decisions 2.13 Updating employee records from the selected candidate s files 2.14 Allotting Personnel Number and Under Training Number to selected candidates 3 Qualifications Management 3.1 3.2 Defining profiles for candidates and employees along with specifying the type of information that should be stored with each profile Recording the qualifications required to perform specific jobs or tasks, including work-related skills and specific certifications or licenses in the qualifications catalog integrating with PIA s MRO application for linking job (maintenance) requirements with available qualifications Section H Requirements Compliance Matrix Page 249
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 3.3 Identifying qualifications such as licenses that require monitoring of expiration and renewal dates 3.4 Linking similar qualifications as an alternative to one another, 4 HR Development 4.1 Creating and managing career paths within the company 4.2 Basing career and succession planning on career paths or on an individual s skills and potential 4.3 Defining and maintaining both company and individual goals 4.4 Designating individuals for positions or marking them as having the potential to succeed in a particular area or position 4.5 Mapping a career path for employees outside of their current disciplines 4.6 Allowing employees to match their qualifications with requirements of a position and determining what (training, proficiency) is needed to meet their goal 4.7 Managing job rotations and postings 4.8 4.9 Matching an individual s skills or qualifications to those required for a position, identifying gaps and proposing training and development plans to acquire the necessary skills Keeping track of on-the-job training and training activities such as classes, seminars and workshops 4.10 Managing internship programs 5 Performance Management 5.1 Providing a flexible framework to create and administer the process of performance reviews and appraisals. 5.2 Setting up performance targets and their measurement criteria 5.3 Having the capability of recording individual employee s Smart Goals 5.4 Integrating performance reviews into PIA s total rewards strategy. 5.5 Planning, designing, performing and analyzing multiple appraisal models for multiple purposes. Section H Requirements Compliance Matrix Page 250
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 5.6 Using a variety of appraisal models as templates to support the staff appraisal process, including: 5.6.1 Bell curves 5.6.2 Personnel, employee and manager appraisals 5.6.3 360-degree feedback 5.6.4 Evaluation of work or projects 5.6.5 Event, instructor and participant appraisals 5.6.6 Multiple number of appraisers 6 Compensation and Benefits Management 6.1 Maintaining ranges of compensation and benefits offered to staff in each group / grade and those on foreign postings 6.2 Maintaining a record of actual compensation and benefits of all employees 6.3 6.4 6.5 6.6 6.7 6.8 Maintaining a database of compensation and benefits of employees of benchmarked companies Maintaining Consumer Price Index (CPI) survey and details of the State Bank of Pakistan s (SBP) report with regards to inflation Making a comparative assessment of compensation and benefits of PIA and other benchmarked companies Evaluating the impact of inflation on purchasing power of PIA's employees using the CPI survey and SBP report details Maintaining surveys and Central Bank reports for countries where PIA employees are posted Evaluating the impact of inflation on salaries and allowances for employees posted abroad 7 Training and Development 7.1 Maintaining list of resources (rooms, audio-visual aids, trainers, etc.) and allocating them to different courses 7.2 Maintaining training and development plans of employees Section H Requirements Compliance Matrix Page 251
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 7.3 Maintaining records of available training programs / catalogues in-house and external (local and oversees) sources 7.4 Scheduling in-house training programs along with resources required 7.5 Maintaining calendars of external training programs 7.6 7.7 Determining course demand based on pre-bookings and / or actual attendance of prior periods Registering attendees directly as well as through web access. Also allowing online submission of training fee 7.8 Recording feedback provided by trainees and trainers 7.9 Integrating with Performance Management System to allow appraisals for instructors, attendees and courses. Also matching trainings required to fulfill promotion criteria 7.10 Conducting and grading different tests / exams 7.11 Maintaining records of training programs attended by individuals / corporate 7.12 Maintaining attendance records of external training participants 7.13 Issuing training certificates 7.14 7.15 Recording trainings attended by employees and the grades obtained by them. For regulated trainings (such as CAA) recording of certificates, issuance dates, expiry dates, dates for refresher courses, etc. Performing a gap analysis between job specifications and employee skills to plan and fulfill training and professional development requirements of each individual 8 Time Management 8.1 Maintaining the PIA calendar with holidays 8.2 Maintaining multiple calendars simultaneously, for instance Gregorian for Pakistan, Hijri for Saudi Arabia, etc. 8.3 Recording employee attendance 8.4 Interfacing with different time-recording machines (with bio-metrics capability) to capture real-time attendance data Section H Requirements Compliance Matrix Page 252
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 8.5 Maintaining leaves, absences, days-off, on-corporation services (OCS) duration etc., of each individual 8.6 Assisting in shift / roster planning for various departments and crews based on actual / forecasted workload. Integrating with Sabre s Flight Scheduler to capture flight schedules and also AIMS software for crew scheduling and MRO solution with engineering shift scheduling 8.7 Administering shift / roster plans considering defined requirements along with employee skills, qualifications, and availability merging load planning with capacity planning 8.8 Providing information to crew and other staff of their rosters through SMS or making the information available to them when they dial in to PIA s Call Centre 8.9 Processing day-to-day changes in the shift schedule based on transactions that affect requirements or availability of staff 8.10 Identifying and managing rotating assignments 8.11 Establishing automatic substitution and on-call procedures 8.12 Checking employee time assignments against PIA s policies and legal requirements 8.13 Evaluating time data used for calculation of overtime, shift allowance, night allowance, and other allowances specific to cockpit and cabin crews, etc. 8.14 Providing attendance and overtime data for payroll processing 8.15 Processing leave applications 9 Healthcare Management 9.1 Processing candidate, employee, retiree and dependant registration 9.2 Initiating medical test procedure for recruitment and recording medical fitness of flight staff 9.3 Maintaining medical history of PIA staff, retirees and their dependants 9.4 Processing patient referrals 9.5 Recording diagnosis and treatment details provided by consultants or panel hospitals 9.6 Maintaining list of hospitals, consultants and medical stores on PIA s panel Section H Requirements Compliance Matrix Page 253
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 9.7 Maintaining the Pharmacopoeia document (PIA s list of authorized medicines) 9.8 Maintaining treatment costs for management reporting 9.9 Issuing medicines to PIA staff and their dependants 10 Travel Management 10.1 Managing requests for travel passage including approvals from appropriate authorities 10.2 Maintaining record of employees traveling on corporation service 10.3 Calculating allowances for employees traveling on corporation service 10.4 Maintaining records of and providing assistance in obtaining visas 10.5 Issuing tickets / passages based on entitlements 10.6 Maintaining traveling schedules of employees, retirees and dependants 10.7 Keeping track of traveling history of employees, retirees and dependants 11 Payroll Processing 11.1 11.2 11.3 11.4 11.5 11.6 Processing compensation and benefits of each individual based on pay package and attendance record Calculating payroll based on multiple shifts with time data collected from various time collection devices Calculating various allowances for flying staff based on specific flight timings different for cockpit and cabin crew Managing salaries of employees posted at various foreign locations based on the calendars applicable in those countries Managing salaries and running payroll of local employees posted at various foreign locations based on their local statutory, taxation and labor law requirements Catering to the laws of Pakistan as well as the countries where payroll will be run (a list of foreign stations is available in Section A, Sub-section A2) 11.7 Handling across the board, one-time payments like bonuses, etc. 11.8 Allowing retro-processing and arrears processing Section H Requirements Compliance Matrix Page 254
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 11.9 Auto generation of salary increments 11.10 Adhoc salary increments for individuals / groups 11.11 Processing of loans and advances to employees 11.12 Generating bank advice for salary transfer to relevant bank accounts 11.13 Printing salary cheques for employees without bank accounts 11.14 Generating pay slips of employees 11.15 Deducting income tax at source 11.16 Generating location-wise periodic tax returns for statutory reporting / filing with different tax authorities 11.17 Generating tax deduction certificates of individual employees 11.18 Providing complete integration between HR and financials systems 11.19 Simulating payroll runs before actual payroll is run 11.20 Generating pension run for pensioners 12 Final Settlement Processing 12.1 Capturing reasons for separation; such as retirement, resignation, termination, etc. 12.2 Identifying in advance about the retiring employees and generating necessary letters / memos 12.3 Capturing details of exit interview 12.4 Withholding salary and other benefits till all clearances are obtained 12.5 Preparing Audit Sheet with all final settlement calculations 12.6 Preparing Pension Sheet calculating pension amounts 12.7 Preparing gratuity information for each employee 12.8 Maintaining income tax brackets and calculating final settlement amounts after catering for tax deduction 12.9 Maintaining detailed history for possible re-hiring cases Section H Requirements Compliance Matrix Page 255
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 13 Personnel Insurance Management 13.1 Maintaining a list of various insurance policies that PIA offers to its employees 13.2 13.3 13.4 Maintaining a database of different insurance policies that each employee has subscribed to Calculating insurance premiums based on approved quotes and triggering requests for payment of premium Generating required renewal / underwriting information for renewal of insurance policies 13.5 Calculating monthly allocation of insurance cost 13.6 Maintaining insurance claims made by employees 13.7 Maintaining insurance claims made on behalf of employees 13.8 Maintaining correspondence with Insurance Companies 13.9 Integrating with Payroll Processing 13.10 Providing standard / basic information like death certificate, etc. for settlement of group insurance claims 13.11 Maintaining records of claims actually paid to the employees or their nominees 14 Security Management 14.1 Maintaining data of employees, family members and retired employees required for issuance of respective security cards 14.2 Issuing ID cards and passes 14.3 Maintaining photographs of employees, family members, and retired employees 14.4 Integrating with Time Management so that security cards issued to employees can also be swiped on the time-recording machines 15 Staff Funds Management 15.1 Managing Provident Fund and Additional Provident Fund contributions by the employee and PIA 15.2 Posting and bookkeeping of all employees funds Section H Requirements Compliance Matrix Page 256
FUNCTIONAL REQUIREMENTS - HUMAN RESOURCES AND ADMINISTRATION Sr. No. Requirement Response (S, W, E, C, N) Remarks 15.3 Processing Provident Fund loan applications 15.4 Recording and managing loans and advances disbursed to employees against funds 15.5 Integrating with Payroll Management for employee contributions, loan disbursements, and loan repayments 15.6 Processing pension appraisal of employees at the time of retirement 15.7 Calculating refund of Additional Provident Fund amount 15.8 Recording monthly payments to retirees and their dependents 15.9 Calculating profits earned on portfolio investments of funds Section H Requirements Compliance Matrix Page 257
H6 FUNCTIONAL REQUIREMENTS PROCUREMENT AND INVENTORY CONTROL Detailed below are the functional requirements applicable for Procurement and Inventory Control. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Description Remarks 4 Standard feature (S) Is available as a standard feature Module / standard feature of the proposed solution 3 Workaround (W) Is available as a work-around and without customization Is not a standard feqture of the proposed solution, but an acceptable workaround ix possible without any customization to the ERP and without incurring additional cost. Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal 2 Enhancement through add-on or third-party solution (E) 1 Customization (C) 0 Not available (N) The required functionality Is available through application add-on or third-party solution The feature/functionality can be made available through customization Cannot be catered as standard feature, workaround, enhancement, customization Is not a feature of the standard solution, but is possible through an application add-on or a third-party solution. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be fulfilled through a feature of the standard solution and any third-party application, but can be catered by developing a custom-built program for PIA. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal The requirement cannot be catered in any way. In case the Contractor does not provide any response, it will be assigned zero 0 The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 258
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 1 Contracting and Procurement Management 1.1 1.2 1.3 1.4 Recording and processing profiles and other relevant details of suppliers and service providers potential and pre-qualified. Supplier database should be at least per JAA / FAA / CAA compliance Supporting interaction with the supplier as per ATA Spec 2000; for example, Purchase Order transmission and acknowledgement, etc. Maintaining indents / requisitions / capital expenditure sanctions raised by various departments Supporting online approvals for requisitioning, ordering and invoicing based on financial approving authorities and transaction types 1.5 Generating requisitions from other areas / systems such as MRO, MRP, etc. 1.6 Handling requisitions for different types of procurement such as: 1.6.1 Stock items 1.6.2 Non-stock items 1.6.3 Assets 1.6.4 Services 1.6.5 Other agreements 1.7 Routing and authorizing Procurement documents based on pre-defined criteria 1.8 Comparing actual cost of purchases against available budgets, budget monitoring 1.9 Validating available budget at the time of Requisition and Ordering 1.10 Generating requests for quotation for pre-qualified suppliers / Approved Vendor List or service providers 1.11 Maintaining price quotations received from suppliers or service providers 1.12 Supporting on-line bidding by suppliers 1.13 Supporting the tendering process based on PPRA rules 1.14 Evaluating proposals online based on cost, delivery time, supplier's record, proposed warranty, technical support, etc. Section H Requirements Compliance Matrix Page 259
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 1.15 Generating price comparison statements for items to be purchased or services to be availed 1.16 Online approval of comparative statement. 1.17 Creating purchase / work orders / contracts against approved comparative statement. 1.18 Online tracking of procurement cycle. 1.19 Handling multiple currencies on the same purchase / work order / contract 1.20 Capturing details of Repair Service Agreements with fixed price / PBH for services, man-hour rates, repair lead-time, warranty conditions, part exchange program, reliability guarantee in compliance with product support documents, for example GCP 2000, PSAA, etc. 1.21 Tracking receipt of materials / services against purchase / work orders / contracts 1.22 1.23 Tracking materials under inspection and the quantities accepted and / or rejected against purchase orders Logging and approving invoices from suppliers and contractors after three-way matching with Purchase / Work Order and receipt of goods / services 1.24 Managing material return against purchase 1.25 Generating automatic debit note against material return 2 Vendor Management 2.1 Vendor performance management in accordance with GCP 2000 and PSAA 2.2 Evaluating supplier's performance based on lead time, enquiry response time, quantity discrepancies, quality discrepancies, price variance, rejection rate, changes to delivery date, quality of exchanges, etc. 2.3 Maintaining performance history of suppliers 2.4 Creating and managing vendor master records 2.5 2.6 Categorizing vendors in categories like aircraft parts vendors, other international vendors, local vendors, employees, etc. Blocking vendors for various reasons such as bankruptcy, blacklisting, poor performance, etc. Section H Requirements Compliance Matrix Page 260
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 2.7 Pre-qualifying vendors / Approved Vendor List (AVL) 2.8 Linking vendors to proprietary/ related items 2.9 Linking AVL with Quality Systems (QS) approval process 3 Items Management 3.1 Maintaining a list of items, tools and equipments with unique identification numbers, detailed specifications, inventory value, previous purchase price, purchase history, min, max and reorder levels, etc. 3.2 Providing quick referencing / accessing functionality with barcodes and RFID tagging 3.3 Supporting capturing of the following minimum data related to aircraft parts: 3.3.1 Vendor part number 3.3.2 OEM part number 3.3.3 Part description 3.3.4 Relationship tables (WBS) 3.3.5 Price 3.3.6 Vendor 3.3.7 Reliability factor (MTBUR - meantime between unscheduled removal / MTBF meantime between failure) 3.3.8 Service level (as per PIA policy) 3.3.9 Alternate parts 3.3.1 Limitations of alternate usage 3.3.1 Authority for declaring alternate (for e.g. IPL reference, QA letter, etc.) 3.3.1 IPC references with usage code 3.3.1 Pointer to purchase and airworthiness related documents locations 3.3.14 Normal stock rooms and shops authorized to withdraw the items 3.3.1 Material groups responsible for the item Section H Requirements Compliance Matrix Page 261
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 3.3.1 Quantity per aircraft 3.3.1 Recommended quantity as per RSPL 3.3.1 Essentiality code 3.3.1 Class (Rotable, Repairable, Consumable) 3.3.2 Buy direct from vendor / OEM, etc. 3.4 3.5 Handling aircraft parts according to a minimum of ten different classes such as rotables, repairables, consumables, etc. Loading initial provision of aircraft parts in the system for aircraft maintenance plan based on manufacturer recommendations 3.6 Allowing revisions (new, change, remove) to the initial provisioning list 3.7 3.8 Establishing safety stock base keeping in mind the service levels provided by the various vendors / as per PIA policy Establishing project requirements based on forecast, extrapolation, trend and smoothing factors 3.9 Monitoring forecast accuracy and identifying deviation 3.10 Identifying material by OEM part number 3.11 3.12 3.13 Grouping all materials of the same form, fit and function under a material number (interchangeability of parts one-way, two-way) Identifying material to the aircraft types, ATA chapter, classification characteristics of the material, etc. Providing price information about the material including valuation price (at moving average), batch price (Purchase Order based), catalogue price (from various vendors), etc. 3.14 Provide linkage with various vendors / OEMs current catalogue list price 3.15 3.16 Changing material classification with adequate control (for example, rotable to repairable) Supporting different treatment for each material classification in terms of provisioning formula, movement types, issue control, serialized numbering, etc. Section H Requirements Compliance Matrix Page 262
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 3.17 Providing parts interchangeability management capability and displaying all interchangeable item at the time of requisition (when requisitioned item is not available) 3.18 Tracking the shelf life of items, monitoring them and flagging out expired items 3.19 3.20 Supporting salvaging and re-certification of components from scrap items (Bring On Charge the salvaged components) Keeping track of warranty of items supplied warranties could be of different nature such as repair, purchase, service, etc. 4 Stores Management 4.1 Supporting the requirements of ATA Spec 2000 4.2 Providing warehouse management functionality including space management and binning. Warehouses (physical and logical) shall include: 4.2.1 Central 4.2.2 Stations (local / overseas) 4.2.3 In-house maintenance facilities 4.2.4 Aircraft 4.2.5 Flight spare containers 4.2.6 Bench stock (at workshops) 4.2.7 Workshops (internal and external) - for both items under repair and spares holding 4.2.8 Loan (from and to) 4.2.9 Document stock (tickets, air waybills, etc.) 4.2.1 Quarantine stock 4.2.1 Consignment stock, etc. 4.3 Optimizing space allocation for all items by volume and weight, environmental conditions, movement (that is, fast / slow moving items), etc. 4.4 Identifying materials available at various locations Section H Requirements Compliance Matrix Page 263
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 4.5 Identifying the aircraft on which a flight container is placed as well as the spares in that flight container 4.6 Notifying material controller if certain materials reach the threshold level 4.7 4.8 4.9 4.10 Supporting multiple warehousing for materials. Auto-replenishing (either transfer or reorder) stock in predefined warehouses when it reaches the replenishment level Receiving material in store and holding in quarantine till quality checks are made. It should also support acceptance of services Storing quality assurance certificates (scanned images) and delivery documents in image format and linking them to the Purchase Order Valuing material in each store by moving average price with reference information of purchase price for each batch 4.11 Tracking on-hand balances and quantities reserved by aircraft 4.12 Tagging materials reserved against provisional requests. Supporting hard allocation of reserved materials. The release of hard reserved materials for other use should be approved by an authorized party 4.13 Dispatching materials outside the warehouse based on the following: 4.13. Sales 4.13. Sending to line stations 4.13. Sending items out for repair 4.13.4 Returning third party items 4.13. Returning leased items 4.13. Returning other operator items 4.13. Transferring between warehouses 4.13. Lending to another airline / organization 4.13. Exchanging with another airline / organization 4.13. Issuing for consumption (for example, against a Job Order) 4.13. Disposing off as scrap, etc. Section H Requirements Compliance Matrix Page 264
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 4.14 Monitoring the whereabouts of dispatched item (based on their batch / serial number) until acknowledgement of receipt 4.15 Reserving materials manually as well as automatically through other systems such as MRO 4.16 Issuing materials against requests received. While issuing, recommending the issue of materials down to the batch number. The batch number should be determined either by a first in first out basis or shelf life 4.17 Producing pick lists for items to be issued 4.18 Supporting sales of items to other airlines / parties 4.19 Supporting stock exchange between aircrafts and between PIA and other airlines 4.20 Generating inter-store stock transfer notes 4.21 4.22 Supporting and tracking outstanding loans (both from and to PIA) and providing regular reports / alerts Determining min, max and reorder levels based on historical and planned consumption patterns 4.23 Identifying and regularly reporting on non-moving / slow-moving materials 4.24 Supporting a permanent on-going stock-taking process 4.25 Scheduling and recording physical count of high value and frequently used items 4.26 Determining variances between book records and physical count of materials 4.27 Managing items declared surplus or redundant and managing their sale with a view to optimizing the revenues 5 Inbound / Outbound Logistics Management 5.1 5.2 Recording authorizations received from government agencies for foreign exchange spending Maintaining records of letter of credits, including the date of establishing the L/C, bank s name, bank charges, insurance cost, supplier of materials, exchange rates, purchase order number, retirement date, etc. 5.3 Tracking shipments based on intimation received from suppliers or freight forwarders Section H Requirements Compliance Matrix Page 265
FUNCTIONAL REQUIREMENTS - PROCUREMENT AND INVENTORY CONTROL Sr. No. Requirement Response (S, W, E, C, N) Remarks 5.4 Highlighting delayed items or those missing in-transit and supporting insurance claims 5.5 Calculating landed cost based on total charges 5.6 Providing interface with Customs systems and assisting in obtaining clearance from Customs authorities 5.7 Processing retirement of documents and maintaining relevant records 5.8 Processing and maintaining details of goods cleared from Customs 5.9 Supporting statutory / regulatory reporting and documentation requirements when components are moved to external contractors. This will include at least the following: 5.9.1 Preparation of air waybill 5.9.2 Preparation of freight forwarder instructions 5.9.3 Preparation of other accompanying documents 5.9.4 Preparation of Indemnity Bond 5.9.5 Integration with freight forwarders for on-line status information Section H Requirements Compliance Matrix Page 266
H7 SERVICES REQUIREMENTS Detailed below are the services requirements. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Remarks 1 Y = Yes Details of how the services would be provided 0 N = No / Cannot be provided Nil In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 267
SERVICES REQUIREMENTS Sr. No. 1 IMPLEMENTATION Requirement 1.1 An Implementation Strategy has been submitted that covers: 1.1.1 Installation of the Interim Server(s) including the Operating System. 1.1.2 1.1.3 Installation of all supplied Application software, RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Interim Server(s). Installation of all supplied Application software, RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Permanent Servers. 1.1.4 Implementation of Database security features 1.1.5 Development of Business Requirement Document for each functional area which maps the business process for the parameterization / configuration of ERP Package. This document will be based on PIA s reengineered business processes provided by PIA. 1.1.6 Development of business case scenarios 1.1.7 1.1.8 1.1.9 1.1.1 Parameterization of supplied Software i.e. the configuration of application software via selection of in-built values, setting up of tables, etc. to meet the business requirements. Software modifications, where required, to supplied Application software and development of extensions and / or modules to meet the business requirements. Integration with PIA s other applications such as Sabre, AIMS, SITA Cargo, MRO solution, QUASAR, Recipe Management, Corporate e-mail, PIA website, etc. Design and development of customized reports, screens, workflows, etc. There is no upper limit to the customization that will be undertaken 1.1.1 Design, development and initial set up of databases. 1.1.1 1.1.1 Testing Strategy. Unit, Integration and System testing prior to User Acceptance testing. Data migration activities. These include preparation of data migration strategy and plan and undertaking data migration activities based on the plan 1.1.14 Design and implementation of Online and Batch job operational procedures until implementation is successfully completed at all locations. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 268
SERVICES REQUIREMENTS Sr. No. Requirement 1.1.1 Progress reporting on Contractor related activities. 1.1.1 Quality Assurance for Contractor related activities. 1.1.1 1.2 1.3 Any other tasks required in successful delivery of the supplied products and services. Airline industry specific rapid implementation templates will be utilized to ensure quick implementation. Details of such templates are submitted with the Technical Proposal A detailed comprehensive project plan is prepared and submitted as a part of the proposal. 1.4 A detailed project organization structure has been submitted: 1.4.1 1.4.2 1.4.3 1.4.4 1.5 1.6 Identifying the specific individuals who would be assigned different tasks of this project. Assigning a full time Project Manager to manage this Project. This person is from the list of Lead Consultants submitted by the Contractor in response to the EOI. He / she has the experience of implementing the proposed ERP in at least two airlines. Containing a personnel roster containing detailed responsibilities of Contractor staff assigned to perform duties or services. The roster includes estimated number of hours to be worked on the project for each person broken down in different phases of the project clearly identifying the start and end dates for each phase. These staff members are from the list of implementers provided in response to the EOI. Substitutes to the nominated staff will have qualifications equivalent to or better than those who will be replaced. A system turnover plan will be developed that will indicate the conditional criteria required to fully turn over the daily operation of the system to PIA technical staff. At a minimum, the turnover plan will include the state of readiness required for system turnover and all required documentation. During system installation the Contractor will evaluate performance factors including, but not limited to, transaction volumes, response times, CPU utilization, and input / output activity. The Contractor is responsible for tuning the application to meet acceptable response times. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 269
SERVICES REQUIREMENTS Sr. No. 1.7 1.8 1.9 1.10 1.11 Requirement The Contractor will conduct a Capacity Test that will include stress and volume testing. Capacity testing shall include a stress test that includes simulation of at least 30% of the system workload and volume tests that test the database activity against at least 30% of the data volume. The Contractor will document, the conclusions resulting from the test. The Contractor will maintain a project plan covering its components of the project and each individual phase. The plan shall include project organization, work break down structures, schedules, critical path determination, and other features required to track and manage this project. The Contractor will prepare and submit weekly progress reports to PIA on each component of the Project for which it is responsible. The Contractor has described its approach for assuring the quality of its components on this project. Contractor has also specified whether third party audit / quality assurance visits will be undertaken and who will bear the cost of these visits. The Contractor will manage version releases of all contract deliverables and certain other critical documents as determined by PIA. 2 TRAINING 2.1 Training Strategy has been submitted as part of the Technical Proposal 2.2 2.3 It describes in detail the approach to meeting the training requirements for each type of audience The general content of all training materials, training courses, and documentation proposed has been described in the Technical Proposal 3 DATA MIGRATION 3.1 A description of the general approach to the data migration process (manual and automated) for historical and cutover data has been provided. 3.2 Migration approach / strategy addresses the following: 3.2.1 Migration overview with objectives, approach, impact, and resources 3.2.2 Migration data (source and volume) 3.2.3 Migration process (automated or manual, verification procedures) 3.2.4 Migration support (system, policy and hardware) Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 270
SERVICES REQUIREMENTS Sr. No. 3.2.5 Migration schedule 3.2.6 Migration preparation task outline Requirement 3.3 Migration Plan addresses the following tasks: 3.3.1 Identify data elements to be migrated. 3.3.2 Identify necessary computer processing workloads. 3.3.3 Identify any special forms and procedures. 3.3.4 Identify any control procedures and evaluation criteria. 3.3.5 Identify, with the assistance of the PIA, the personnel needed to participate in the migration of the data. 3.3.6 Plan any special training for migration activities. 3.3.7 Plan any interim file maintenance requirements. 3.3.8 Develop migration programs (this includes specifications, program coding, test plans, and complete testing). 3.3.9 Present Migration Plan, Procedures, and Programs to PIA for approval. 4 DOCUMENTATION 4.1 Contractor will provide user manuals that will cover as a minimum the following: 4.1.1 4.1.2 Complete instructions for the users, completely explaining the use of each system function; System usage scenarios, based on real world examples drawn from the day-to-day workloads of typical users, that fully describe and explain the salient features and operation of the system; 4.1.3 How input data are stored and related between system records; 4.1.4 How to generate / suppress standard and ad hoc reports; 4.1.5 Normal report distribution; 4.1.6 Prioritization processing, system determined priorities, and user override procedures; 4.1.7 System log-on, log-off, and security features; Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 271
SERVICES REQUIREMENTS Sr. No. Requirement 4.1.8 Error messages and error correction procedures; 4.1.9 Help features and usage; 4.1.1 System troubleshooting; 4.1.1 Mandatory data fields and default data values; 4.1.1 Traversing system menus; 4.1.1 Screen layouts and contents; 4.1.14 Inquiry functions 4.2 Contractor will provide technical manuals that will cover as a minimum the following: 4.2.1 4.2.2 4.3 Addresses the view of the system required by developers, administrators and other technical personnel. Provides an understanding of the application; database design and file structures; relationships between programs, security; troubleshooting; special constraints; and other operational guidelines Contractor has submitted sample copies of all proposed documents that it will prepare / deliver to PIA during the course of this project. 5 WARRANTY AND MAINTENANCE SUPPORT 5.1 5.2 Contractor will provide warranty services for a period of three years by ensuring that the system in every way meets the specifications stated in this RFP Separate and apart from the warranty support services, the Contractor shall provide support ( Maintenance ) services for Applications, and RDBMS beginning upon the end of the warranty services and extended up to three (3) year thereafter 5.3 Contractor has provided its User and Technical Support Plan detailing the following: 5.3.1 on-site fault diagnostic techniques; 5.3.2 remote or tele-diagnostic fault diagnosing techniques; 5.3.3 average time to arrive on-site; 5.3.4 mean time to fix major system components; 5.3.5 fault escalation procedures; Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 272
SERVICES REQUIREMENTS Sr. No. 5.3.6 maintenance of error logs. Requirement 5.4 Contractor will establish Hotline and Helpdesk support 5.5 Contractor has specified a solution to accommodate PIA s requirement of additional customized reports during the maintenance and support period. 6 VERSIONS AND UPGRADES 6.1 6.2 Contractor has assured that training material / software / process documents will be duly licensed for the purpose of implementation and use by PIA of the ERP. These will be of latest version and Contractor will ensure up-gradation of all modules / material / process documents during the warranty period and as part of afterwarranty maintenance support. During the implementation and subsequent rollout Contractor will be responsible to arrange and provide free version upgrades of all components under its responsibility. Contractor will ensure that at the time of handing over the solution to PIA all components are of the latest release and that the total solution is certified by the Contractor for completeness. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 273
H8 HARDWARE REQUIREMENTS Detailed below are the hardware requirements. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Vendor Score Response Remarks 1 Y = Yes Details of how the hardware requirements will be fulfilled 0 N = No / Cannot be provided Nil In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 274
HARDWARE REQUIREMENTS Sr. No. 1 HARDWARE 1.1 1.2 Requirement Contractor has submitted details of the proposed configuration, including layout diagram detailing model designation(s), memory size, number of CPUs, type of drives with capacity and counts. The offered solution complies with the Open Systems Architecture and latest technology trends. 1.3 The solution is scalable, both horizontally and vertically. 1.4 The hardware is sized keeping in view the operational requirements of the ERP and associated applications. 1.5 The hardware is fully capable of hosting the ERP certified database. 1.6 1.7 1.8 1.9 1.10 1.11 1.12 The hardware allows each partition of the ERP environment to be isolated in such a way that a software fault in one partition will not have an impact on another partition. All software required for clustering of servers and implementation of DRP is included in the solution. The solution will be fully supported by the Contractor for not less than ten years from the date of supply. It will remain capable of being supported, upgraded and extended by the Contractor during this period. The solution provided will be accompanied with complete documentation, operating manuals, system diagrams, startup and recovery procedures and all other information required for proper and efficient operation. Contractor will provide all technical material and verifiable benchmarks related to the proposed solution. The hardware is by the ERP principal vendor for the operation of the ERP and is reasonably expected to be certified for future versions of the ERP during the expected life of the hardware. Contractor has provided information on warranties on the equipment and any options regarding warranty extension. Principal s assurance for parts availability after expiry of warranty period is also provided. The Contractor has provided a thorough and contemporary 3rd party testing software for acceptance and load testing. The testing will be done according to system equipment specifications as well as generally accepted practices. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 275
HARDWARE REQUIREMENTS Sr. No. Requirement Response (Y / N) Remarks 1.13 All test results will be completely documented by the Contractor. Complete test documentation including results of the 3rd party load / stress testing software will be provided to PIA. 1.14 Based on PIA s high availability requirements, failover design is based on protecting single point of failure. 1.15 For high availability on the application layer, the solution will implement log on load balancing between the application servers. It does not need any form of reallocation of resources between servers. The application environment is sized and designed such that upon failure of an application server (based on single point of failure), minimum degradation of performance will be experienced. 1.16 A Disaster Recovery (DR) design is provided which provides a seamless, pragmatic DR process. It integrates within the overall design of the ERP landscape. 1.17 The DR process is simple to execute. A step-by-step process and procedure is provided to minimize the potential for human error in a time of crisis and disaster. Additionally, the DR design can be easily tested with minimal impact on day-to-day operations. Section H Requirements Compliance Matrix Page 276
REQUEST FOR PROPOSAL PIA MRO PROJECT PIA MRO Project Page 277
Table of Content REQUEST FOR PROPOSAL...277 SECTION A.280 PROJECT DETAIL.280 A1. Project Details... 281 1. Project Background 281 2. Locations 281 3. Business Objectives 281 4. Information Technology (IT) Objectives 282 A2.Project Organization... 282 A3.Project Stages & Important Milestones... 282 1.Project Components 282 2.Phase-wise Objectives 283 A4. Product Requirement (MRO Package)... 284 1. Overview of Solution Requirements 284 2. General Requirements 284 3. Technology Requirements 288 SECTION B...293 INSTRUCTIONS TO BIDDERS (ITB)...293 B1. Instructions For Bid Submission... 294 1.Introduction 294 2.The Request for Proposal Document 295 3.Clarification of RFP Document 295 5.Preparation of Proposals 297 6.Proposed Prices 300 7.Documents Establishing Contractor s Eligibility and Qualifications 301 8.Document Establishing Products, Services Eligibility & Conformity to RFP Document 9.Bid Bond 302 10.Period of Validity of Proposals 303 11.Submission of Proposals 303 13.Right of Negotiations 304 14.Award of Contract 305 15.Confidentiality 305 16.Bidder s Profile 305 17.Legal Binding 305 18.Performance Guarantee 306 19.Signing of Contract 306 20.Clarification of Proposals 306 21.Contacting PIA 306 B2 SUMMARY OF REQUIREMENTS... 308 B3 Template Forms... 309 Implementation 312 Training 312 Documentation 312 Other 312 TOTALS 312 1.General Proposal Requirements 323 2.Required Format of the Proposal 323 SECTION C PIA MRO Project Page 278
Product DETAIL (MRO Package and Add-ons) SECTION D SERVICES REQUIREMENTS D1.Implementation D2.Training D3.Data Migration D4.Documentation D5.Warranty And Maintenance Support D6.Version And Upgrades D7.Information Needs And Application Requirements SECTION E PRODUCT REQUIREMENTS (OTHERS) E1 RDBMS And Database Administration Tools E2 Application Development Tools E3 Query And Report Generator Tools E4 Interim Servers and Operating System E5 3rd Party Software SECTION F BIDDER S QUALIFICATION & EXPERIENCE F1 Bidder s Qualifications And Experience SECTION G HARDWARE REQUIREMENTS G1 Hardware SECTION H REQUIREMENTS COMPLIANCE MATRIX H1 GLOBAL REQUIREMENTS GENERAL H2 GLOBAL REQUIREMENTS TECHNICAL H3 GLOBAL REQUIREMENTS OTHERS H4 FUNCTIONAL REQUIREMENTS MRO Solution H5 SERVICES REQUIREMENTS H6 HARDWARE REQUIREMENTS SECTION I COMPLETION AND COMPLIANCE CHECKLIST I1 PROPOSAL COMPLETION CHECKLIST I2 PRODUCTS AND SERVICES I3 BUSINESS INFORMATION AND APPLICATION NEEDS I4 MRO PACKAGE REQUIREMENTS J1 EVALUATION CRITERIA AND WEIGHTAGE PIA MRO Project Page 279
PIA MRO Project Page 280 SECTION A PROJECT DETAIL
A1. Project Details 1. Project Background Pakistan International Airlines (PIA) desire to start renewing the IT landscape and business requirements necessitates. Reassessment of business operations and a major upgrade of the information technology environment are the focused objective. In order to achieve greater operational efficiencies and facilitate the realization of growth targets, PIA has decided to implement a comprehensive Maintenance, Repair and Overhaul (MRO) solution which is best combination of technology products and services at the most reasonable cost. PIA is requesting an airline industry specific and proven airline IT solution. Beside MRO a separate, parallel exercise of similar nature is also currently underway in the areas of Finance; Human Resources, Administration; Procurement and Inventory Control. The main component of the project is: Business process study / business process reengineering Procurement of MRO system and supporting infrastructure MRO implementation, training and rollout Post-implementation support PIA expects the MRO contractor to recommend a suitable implementation approach to help ensure project success within the stipulated timeline. Since time is of essence the timeline will be fixed and strictly adhered to. Contractor will bear liquidated damages to the tune of 0.05 percent of the bid value per day of delay beyond the agreed upon deadline. This would however be limited to a maximum of 10 percent of the bid value. 2. Locations The locations intended to be covered under the scope of the MRO Solution implementation are as follows: - PIA Head Office at Karachi PIA Engineering, all locations in Karachi, Islamabad and Lahore as well as the PIA line stations PIA Stores, Hangers and Workshops (all locations) PIA Computer Center at Karachi PIA procurement cell (New York & UK) Any other location as defined by PIA engineering and P&L section 3. Business Objectives To operate efficiently and effectively by having streamlined business processes, integrated information systems, optimum utilization of available resources and spare parts, within engineering department and across the entire organization. PIA MRO Project Page 281
It is the PIA engineering ultimate goal, to keep the entire fleet always in airworthy condition. The new system shall support this goal by monitoring LRU changes, scheduled maintenance and modifications, but also to keep track on deferred defects. Form the commercial point of view, the on-time performance and dispatch reliability of the entire fleet is of essence. A well structured maintenance planning supported by the system shall support this objective. The number of AOG situations to be reduced. With transparent data and streamlined business processes PIA Engineering to be in a position for more cost efficiency and a higher performance. PIA Engineering is a player in the 3 rd party MRO business. With the new MRO functionality the PIA Engineering shall be more attractive for the 3 rd party market. 4. Information Technology (IT) Objectives Keeping in-line with the organization s vision and mission, the Information Technology department at PIA has formulated the following objectives: To implement industry standard systems / solutions which are integrated, adaptive and flexible to both internal and external challenges and evolve as technology progresses and must be capable to meet present and future airline industry challenges. To carefully plan and deploy resources to ensure continuity of Information Technology services and its availability on 24x7 hours basis. To ensure that Information Technology is effectively applied to business needs. To provide technology tools to PIA staff for capturing and harnessing the knowledge base with the latest in IT, for timely management decision support. A2. Project Organization For realizing the overall business and technology objectives, a fully resourced team of implementers will collaborate with PIA s management, functional and IT staff through various stages of this project. Together the team reports to Project Steering Committee and MRO Implementation Committee that has been set-up to oversee the progress and make decisions on key issues. The successful MRO Contractor would become a part of this team and the tri-partite arrangement will work under the guidance and control of Project Steering Committee and MRO Implementation Committee. A3. Project Stages & Important Milestones 1. Project Components The various components of the project are: Detailed design and blue print MRO System Implementation Plan PIA MRO Project Page 282
Power user, end user and technical training Infrastructure evaluation and recommendations for upgrade Monitoring the project System Customization Data migration System Testing Performance Tuning and Acceptance Testing Cutover Post Cutover Support 2. Phase-wise Objectives The following are the phase-wise objectives of the project: 2.1 Implementation Strategy Implementation strategy shall be adopted after due consideration to project scope, applicable constraints and magnitude of business improvement goals. Bidder must provide detailed implementation methodology. PIA at its discretion may interview the nominated consultants to assess their technical expertise and reserves the right to accept a consultant or ask for replacement of any or all consultant. PIA at its discretion may also ask for replacement of any consultant at any stage of the project if PIA considers that the said consultant is engaged in questionable activities or the performance of the consultant is not at par with required standard. Implementation of procedures and controls for a reasonable level of systems security, audit ability, confidentiality, reliability, integrity, and business continuity. Conversion/ Migration of historical and live data, efficiently and accurately. Smooth and seamless transition to new systems without any disturbance to the ongoing operational activities of PIA. Prepare conceptual design and highlight parameters that will be configured in the MRO system in accordance with PIA business requirements. It should also include complete workflow for transaction approvals and escalation. Provide integration solutions where MRO will be integrated with other applications running in PIA and forthcoming ERP application. The vendor has to ensure that all software supplied is free from defects/ bugs/ flaws/ security holes etc. Warranty periods for hardware/software may clearly be mentioned 2.2 Training Preparation of the user community for change through appropriate knowledge transfer and end- user training. Prepare and implement a comprehensive training plan to train the trainers/power users, technical users /end users. Gain acceptance for new systems by actively involving key users in driving the acceptance testing process and achieving cut-over to the new environment. Ensure smooth and seamless transition to new systems without any disturbance to the ongoing operational activities of PIA. Provide a sufficient number of properly qualified MRO system experts for each specific area mentioned in the RFP. These should cover as a minimum experts having implementation experience in airline of size comparable to PIA in engineering areas. PIA MRO Project Page 283
2.3 Post Implementation Support At no extra cost to PIA, a team of certified experts to be stationed at PIA Location (A1-2 above) for MRO Implementation and post implementation support for a period of three years minimum to ensure optimum and seamless operations of systems and processes. Any discrepancies, mismatches and resource constraints experienced and not specified will be responsibility of the Bidder/contractor. Hardware/software warranties & guarantees: Bidder/contractor must provide at least three years warranties for software and hardware post implementation. A4. Product Requirement (MRO Package) 1. Overview of Solution Requirements PIA desires to procure an MRO Solution for PIA s engineering business needs which would comprise the following: - An MRO Package which can be integrated with PIA s Existing system and forthcoming ERP Application. Add-on or Custom Built Applications shall be acceptable if minimum. Future Value added modules. The solution to PIA s business needs should cover the features the marketplace is widely offering in airline industry solutions and must meet the specific needs of PIA. Bidders are expected to match the requirements to the features/functionality that each proposes in a cost beneficial way. To that end it is expected the Technical Proposal submitted in response to this RFP Document will clearly describe how the Bidder expects to meet the business needs of PIA. Further, Bidders are expected to suggest solutions that will require maximum customization with minimum modification or add-ons, maximum or completely seamless integration between applications, lower systems implementation risk, while at the same time providing the best possible performance at an economical price. Bidder shall present a written technical proposal to address the requirements in the following Sections. Proposals must identify any requirements the Bidder cannot satisfy. Sufficient details should be included to demonstrate the Bidder s knowledge of the Project and their ability to satisfy each requirement. 2. General Requirements The following narrative represents a summary of the general requirements envisioned by PIA in the MRO Solution. PIA MRO Project Page 284
2.1 Common Characteristics Common characteristics represent capabilities that should be shared by all functional areas of the MRO Solution. They are to be considered along with the more specific functional requirements that follow in the design of a system. 2.2 Integration The software should support modern best industry practices, with data located in one integrated system shared across all organizational units. The software should support enterprise-wide business processes with a goal of eliminating multiple handling of data and increasing data accuracy. The proposed MRO System should be capable to integrate with forthcoming ERP application and to interface with existing applications running in PIA. PIA MRO Project Page 285
2.3 Configuration PIA desires to procure a system that will require minimum software modification to meet its business requirements. The software should allow for easy tailoring and customization to meet those requirements without changing software code or requiring Add-ons. Changes to parameters, software switches, processing rules, and other tailoring approaches may be acceptable. The tailoring should be accomplished in a way that does not adversely impact the future installation of system upgrades released from the Bidder. 2.4 Technology Interfaces The Bidder should provide standard application programming interfaces, tools and methodologies that allow future releases to accommodate interfaces without re-programming. A standard approach to interfaces should be employed to avoid multiple, unique approaches for different systems. The Bidder will have to ensure, at its own cost, availability of APIs for both its proposed system as well as system running in PIA. Bidder must ensure to provide XML-based APIs wherever these are available. 2.5 User Interface The system should provide an intuitive, user-friendly, and easy-to-use interface that minimizes the need for training. The system should have a common look and feel across all applications. Online help should be available for all applications and should allow for customization. The system must address the needs of infrequent or low volume users as well as those who use the system several hours each day. The system must be equally usable from remote locations as from the Head Office. Web-based access should be supported Business rules should be incorporated into the system such that the rules are applied at the time information is entered into the system. The system should identify entry errors, inconsistencies or logical disorder at the time data is entered. Processing of the transaction should be suspended and/or re-routed to resolve the problem in real time. 2.6 Security & Authorization The system must support multiple levels of security. This includes protecting certain fields from unauthorized access. In addition, access to certain functions and data must be protected until they are approved by PIA s concerned policy makers. Changes in assignment or termination should automatically trigger a review of the employee s security privileges. Comprehensive logs of transactions and security incidents must be maintained for auditing purposes. System should provide authorization, authentication, integrity and non-repudiation facilities for critical transactions. System should be capable to maintain logs etc. System should be capable of secure remote login. System should support electronic signature and time stamp etc. 2.7 Reporting / Inquiry The system must include comprehensive reporting tools that allow for easy access to authorized data. Executive interfaces to the data with drill down capability to examine details should be included in the reporting tools. It should also be possible to create reports that reflect status as of a specified point in time. Standard reports should be included that will PIA MRO Project Page 286
serve as models for customized reporting as well as provide for basic functional reports. Report wizards or similar techniques should be available to guide users through report creation. The system must be designed such that reporting activities do not compromise the responsiveness of the interactive system. Reports should be formatted to print on local PC and LAN attached printers as well as on centralized high-speed printers using by PIA. It should be possible to deliver fixed reports to users on a pre-determined schedule to be reviewed online, to be retained online or to be printed at the user s discretion. The system should be able to demonstrate useful demographic and forecasting capabilities; support text based searches and provides departments the ability to develop ad hoc reports at their discretion. The system must include a data dictionary or similar provision to allow nontechnical users to identify the appropriate data elements for inclusion in their reports. 2.8 Analytic Tools PIA desires decision support tools and information bases that are fully integrated with the system to facilitate strategic planning, tactical operations and organization-wide analysis. The system should support the easy movement of data to common packaged PC-based applications such as Microsoft Office and text files. The system should include the ability to locate information or text through a search capability. The system should be capable of producing what if scenarios to support decision-making. 2.9 Communication The system should foster information sharing at all levels of the organization. For example, policy directives and goals should be incorporated into engineering maintenance planning process; various functional units of engineering and other departments should be able to share required information e.g. schedules, material requirements and job specifications etc. 2.10 Flexibility The system should be easily reconfigurable to respond to changes in business practices, policy directives, organization structure, statutes and regulations. As business requirements change, the system should also change to support the new requirements. Flexibility should extend both to enterprise-wide as well as industry specific practices. 2.11 System Availability Overall it should be a highly available solution. It must be available for access by authorized personnel from anywhere at any time of the day or night (24 x 7 availability). The system must be equally usable from remote locations as from the Head Office. 2.12 Transaction Timing PIA MRO Project Page 287
The system must support real time operations. Changes to data or the status of processes should be immediately available in the system. System operations should not artificially constrain the business processes supported by the system. The system must support effective dating for transactions, including both future and retroactive changes. The authority for such transactions must be included in the security capabilities of the system. The assignment of a retroactive date must generate the changes required to bring the system up to the current date. 2.13 Online Documentation and Training The system must include customizable online documentation and training materials such as context-specific help, search capability, business process documentation and process maps. 2.14 Storage/Record Retrieval Record collection and retention is an important organizational requirement. The ability to easily archive, retain and access records is required. Records retention procedures must allow information to be stored in a way that can be accessible indefinitely. 2.15 System Security System provided must be secure and meet all standard security requirements i.e. Identification, Authentication, Authorization and Integrity. System should allow implementation of industry standard security policies and capable to evolve to meet security challenges. 3. Technology Requirements 3.1 New Technology The system should be designed in such a way as to easily allow the incorporation of new technologies, as they become available. 3.2 Multiple Environments In addition to the production environment, the system must support independent copies for training, development, and quality control / test. These environments must be sufficiently isolated from production and from each other so that operations in one environment will not affect those of another. The environments will be employed as follows: Production all production processing will be performed in this environment. Development all development activities including unit and system testing will be conducted in this environment. PIA MRO Project Page 288
Quality Control / Testing after all development unit and system testing has been completed, this environment will provide a system for departments/units to check the quality and testing of enhancements/modifications before they are accepted into production. 3.3 System Performance The system must be responsive and available. The system should support rapid fail-over or redeployment in the event of problems or planned maintenance. Ninety-nine percent of all fail-over events must take place in less than five minutes. Any volume (batch) processing must not interfere with online responsiveness or availability. 3.4 Archive and Purge The system must support the periodic archival and purging of unused or obsolete information. Archived information should be available for historical reporting. The system should remain continuously available during archiving/purging 3.5 Recovery The system must automatically recover to the last complete prior transaction in the event of a failure. The system must clearly indicate to the user that a transaction failed and that it must be re-entered. Recovery must occur without operator intervention. Bidder must provide contingency and back-up recovery procedures with guaranteed SLA (Service Level Agreement). 3.6 Backup / Recovery and Reorganization The system must provide for the unattended daily backup of all information and data to a media that can be stored offsite for disaster recovery purposes. Backups must not prevent the system from being available at all times and must not disrupt system operations. Database reorganizations should not significantly impair the availability of the system. 3.7 Print Management The system should provide a method for managing the print environment for report distribution so that reports are directed to the appropriate print facility. Both high speeds centralized printing facilities as well as local LAN-based printing facilities will be employed. Users may also print the documents. 3.8 Fallback Solution In case, if the system or parts of the system is not operative, a manual or semi-manual fallback solution to be developed, to continue the MRO operation. After restart of the system it must be possible to update the system accordingly. 3.9 Ability for system and license updates The bidder should guarantee that the provided MRO Package s customization or modification shall be ready for any future updates. This guarantee shall also be given for any underlying software such as RDBMS, Operating System, Network Management and other PIA MRO Project Page 289
tools. Also the Bidder may give further advices updating the system to major or minor releases. It is in PIA discretion to follow the advice. 3.10 Technology Architecture The Contractor should provide recommendations of the technology architecture under which the proposed MRO Package will operate, with the following features preference: N-tiered Client/Server architecture incorporating thin presentation-logic-client communicating with client-neutral, server-based applications, communicating with the database Thin client/pc based, for remote users Applications distributed at servers located at Head Office Centralized database, located at Head Office While designing the technology architecture, the Contractor should ensure that the following are kept under consideration: Solution should be scalable with complete platform independence PIA does not intend to be tied down to a single platform Solution should be effortlessly portable from one system to another Should provide support for different flavors of UNIX, Windows etc.; however it should be a totally interoperable solution There must be open source support. In this context, the Contractor must specify the current scenario vis-à-vis the solution offered and the future roadmap Optimization of licensing costs for the platform software PIA s existing Local and Wide Area Network, and minimization of Wide Area Network bandwidth requirements, Simplicity of System Administration and Operations, Ease of business continuity planning and execution. Contractors should present a number of architecture options, providing pros and cons of each option, as well as the Contractors recommended option. 3.11 Server Hardware and Infrastructure The Contractor should provide both its minimum and optimum configuration requirements for Application and Database Servers to run the MRO Package and other applications, consistent with the MRO features and proposed technology architecture (3.11 above), and multiple environment requirements (3.3 above). The recommended configuration should cater for the existing load as well as annual volume growth of 10-15% for the next five years. The configuration should be capable of retaining data for at least eleven years (that is, current year plus ten years historical record). The solution must be redundant, reliable and consistently available to allow uninterruptible 24x7 operations. The main servers will be housed in PIA s Information Technology Department. The production server configuration should include redundant (RAID-5) data storage (including SAN) and multiple processors and cater for compatibility with PIA s existing LAN / WAN environment. The Contractor should take into consideration the areas of performance and scalability, reliability and fault tolerance while recommending Server configurations. PIA MRO Project Page 290
Contractor must provide performance guarantees of the solution under different scenarios such as concurrent users during normal working, during data backup, during overload, during partial system failure, etc. The Contractor shall also give solid recommendations for the proper LAN and WAN as well as the End-User infrastructure. 3.12 Systems and Network Management Tools Bidders are required to recommend suitable Systems and Network Management Tools. The Systems Management Tools should ensure proper planning, configuration, and problem handling of IT resources and support such tasks as: - Defining, resolving, and managing problems; Operating networks and multi-vendor systems; Distributing and managing software and data; Controlling operations; Planning and managing performance; Administering security; Maintaining asset information; and Planning for the future capacity of systems. 3.13 Data Support The solution should be able to support multiple data types text, image, voice, etc. It should be able to support data upload to and download from different systems in multiple formats. Besides simple upload / download facility it should also be able to communicate and support data interchange with mobile devices such as cellular phones, handheld terminals, PDAs, etc. It should also be able to support other devices such as scanners, barcode readers, biometric devices, card readers, RFID devices, etc. Support for important messaging / data formats / standards must include, as a minimum, Aircraft Communication Addressing and Reporting System (ACARS), SITATEX, ASCII, EDI, SMS, XML, Spec 2010, UNe Docs, MS-Office, Lotus Notes, etc. 3.14 Web-enablement The proposed System should be Internet ready and allow web-enabled access to users from anywhere across the world through a web portal. It should also be compliant with the Service Oriented Architecture (SOA). 3.15 Workflow The proposed System should be capable of providing Workflow functionality to users by which information and requests could be automatically routed to the concerned levels for approval. PIA MRO Project Page 291
3.16 Others Besides above mentioned characteristics the proposed MRO should also be capable of: Supporting multi currency Supporting multi languages Supporting multiple legal companies Supporting multiple tax structures (that is, supporting individual country tax structure and reporting) Interfacing with legacy systems Storing transactions and balances of legacy systems Supporting user defaults Supporting user defined screens Supporting multiple date formats Supporting multiple decimal formats in amounts Providing easy development of user defined reports Supporting user defined fields Scheduling of jobs for unattended operations Maintaining effective dates of master file data PIA MRO Project Page 292
PIA MRO Project Page 293 SECTION B INSTRUCTIONS TO BIDDERS (ITB)
B1. Instructions For Bid Submission 1. Introduction The Bidders are invited to submit a detailed Technical Proposal and an item wise Financial/Commercial proposal for Products and Services required for the assignment as named in the MRO. The proposal will be the basis for negotiations and ultimately execution of a contract with the selected successful bidder(s). The assignment may be implemented in accordance with sequence as defined in section A (A3) in the RFP or in parallel as per critical path identified by Bidder and agreed by PIA. The performance of the Bidder under each set of tasks must be to PIA s satisfaction 16. In each case Bidder shall complete task satisfactorily before initiating next sequential task. The Bidders must familiarize themselves with local conditions and take them into account in preparing their proposals. PIA will provide the inputs specified in the RFP and assist the Bidder in obtaining administrative licenses and permits needed to carry out the project, and make available relevant project data and reports. However, procurement of licenses, permits etc. shall not be PIA s responsibility. Information relating to evaluation of proposals and recommendations concerning awards will not be disclosed to the Contractor or to other persons not officially concerned with the process. The Contractor shall maintain complete confidentiality of its proposal and shall not disclose the proposal or any terms thereof to any unrelated person or any third party. The Contractor shall also keep confidential all its discussions and negotiations with PIA. By submitting a Proposal, the Contractor agrees to be legally bound by the terms and conditions set out in this RFP. The Proposal will be considered as a binding offer from the Contractor subject to acceptance by PIA. If during the course of any discussions or negotiations PIA and the Contractor agree to vary any terms of the Proposal, the Proposal will be deemed to be amended to the extent of the agreed variation and PIA, at its discretion, may accept the Proposal as deemed amended. PIA will not be bound to accept the lowest or indeed any Proposal and will not be committed to any Proposal until a contract has been executed. PIA may in its discretion accept a nonconforming Proposal. PIA, in its absolute discretion and without liability to any party, may decide at any time to amend the RFP, invite Contractors, or any one or some of them, to amend their Proposal, extend the deadline for submission of Proposals or amendments to the Proposals or terminate the RFP process in whole or in part. PIA will be under no obligation to explain the reasons for its decision and in its sole discretion may call for further Proposals for the provision of the same or similar services at any time. 1.1 Products and Services For the purposes of this RFP, the Maintenance Repair Overhaul Solution, also called simply the MRO Package or MRO Solution, means all of the products/solutions/ 16 PIA will issue a completion certificate for each stage and a final completion certificate on completion of the project. PIA MRO Project Page 294
/software/training/licenses/ and related services to be provided by the selected Bidder under the contract. Contractors are bound to submit solutions based on their proposals based on Two Stage Two Envelope Procedure. 1.2 Cost of Bidding The Bidders shall bear all costs associated with the preparation and submission of its proposal and any negotiations, and Pakistan International Airline, hereinafter referred to as PIA, will in no case be responsible or liable for those costs or any of the losses to the bidder, regardless of the conduct or outcome of the bidding process. 2 The Request for Proposal Document 2.1 Content of RFP Documents The contents of the RFP Documents are listed below and should be read in conjunction with any addenda issued in accordance with ITB: Section A - Project Details Section B - Instructions to Bidders Section C - Product Detail (MRO Package and Add-Ons) Section D - Services Requirements Section E - Product Requirements (Others) Section F Bidder s Qualification and Experience. Section G Hardware Requirements. Section H Requirements Compliance Matrix. Section I Completion And Compliance Checklist. Bidders are expected to examine all instructions, terms and conditions, technical specifications and other information in the RFP Document and each Bidder shall satisfy itself before submitting their proposals as to the nature and scope of the work involved in implementing the MRO Solution in accordance with PIA s requirements as specified in the RFP. Each Bidder by submitting its proposal shall be deemed to have satisfied itself as to all the conditions and circumstances affecting the bid amount/contract price. Failure to furnish all information required by the RFP Document or to submit an incomplete Proposal or Proposal not substantially responsive to the RFP Document in every respect will be at the Bidder s risk and may result in the rejection of its Proposal. PIA reserves the right to verify at its sole discretion any or all information submitted in response to the RFP Document. Any false information or misrepresentation or non-disclosure may result in rejection of the entire Proposal. 3. Clarification of RFP Document PIA has made every effort to make the RFP Document as clear as possible. However, in a project of this size and complexity, Bidders may need more clarifications. PIA MRO Project Page 295
Bidders may request for clarification on any of the RFP documents up to seven days before the proposal submission date. Any request for clarification must be sent in writing by paper mail, cable, telex, facsimile, or electronic mail to the PIA s address indicated in the RFP. PIA may respond by cable, telex, facsimile, or electronic mail to such requests and will send written copies of the response (including an explanation of the query but without identifying the source of inquiry) to all parties who intend to submit proposals. Contact Address General Manager (Procurement & Logistics) Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport Karachi Ph: +92-21-99045135 Fax: +92-21-99040120 Email: gmptnl@piac.aero, contract.administration@piac.aero PIA MRO Project Page 296
4. Amendment to RFP Document PIA may modify the RFP Document by issuing addenda, for any reason, and at any time prior to the deadline for submission of Proposals. Any addenda to the RFP Document shall be part of the RFP Document. All Bidders will be notified of the addenda in writing via letter or facsimile, and it will be binding on them. To allow the Bidders reasonable time to take any addenda into account in preparing their Proposals, PIA may, at it s own discretion, extend, as necessary, the deadline for the submission of proposals. 5. Preparation of Proposals 5.1 Language of Proposals Proposals and all correspondence and documents relating to the proposals exchanged by the Bidders and PIA shall be in English. 5.2 Documents Comprising the Proposal Bidders will be required to submit separate proposals along with implementation plan for Complete MRO Implementation each comprising of following two proposals. A. Technical Proposal (One original and one copy Soft Copy and Hard Copy ) B. Financial/Commercial Proposal (One original and one copy) The relevant completed Proposal Form and all Price Schedules as included in Section B, Subsection B3 Template Forms, completed and duly signed. Bid security furnished in accordance with ITB Sub-section 9; A full description of the technical solution to the business requirements described in Sections C Product Requirements (MRO & Add-ons), Section D Services Requirements and Section E Product Requirements (Others). The completed Requirements Compliance Matrix (Section H), Completion Checklist and Compliance Checklists (Section I, Subsections I1 to I4). 5.2.1 Technical Proposal In preparing the Technical Proposal, Bidders are expected to examine the documents constituting this RFP in detail. Deficiencies in providing the information requested may result in rejection of a proposal. While preparing the Technical Proposal, Bidders must give particular attention to the following: If a Bidder considers that it does not have all the expertise for the assignment, it may, subject to PIA s prior approval, obtain a full range of expertise by associating with individual Bidder and/or other Bidders or entities in a joint venture as appropriate. Bidders may associate with other parties invited for this assignment (through this RFP) only with approval of PIA. PIA MRO Project Page 297
It is desirable that the majority of the key professional staff proposed by the Bidder should be its permanent employees or have an extended and stable working relationship with it. Proposed professional staff must, at a minimum, have sufficient experience in the required field, preferably working under conditions similar to those prevailing in the country of the assignment. Alternative professional staff shall not be proposed, and only one curriculum vitae (CV) may be submitted for each position. Reports to be issued by the Bidders as part of this assignment must be in English language. 5.2.1.1 Information Required Detailed project plan with timeframe for task and sub task. A brief description of the bidder s organization and an outline of recent experience on assignments of a similar nature. For each assignment, the profiles of the staff proposed, duration of the assignment, contract amount, and bidder s involvement. Any comments or suggestions on the Terms of Reference and on the data, a list of products/services, and facilities to be provided by PIA. A description of the methodology and work plan for implementation of the project. The list of the proposed staff team by specialty, the tasks that would be assigned to each staff team member, and their timing. CVs recently signed by the proposed professional staff and the authorized representative submitting the proposal. Key information should include number of years working for the firm/entity and degree of responsibility held in various assignments during the last ten (10) years. Estimates of the total staff input (professional and support staff; staff time) needed to carry out the project, supported by bar chart diagrams showing the time proposed for each professional staff team member. A detailed description of the proposed methodology, staffing, and monitoring of training, if the RFP specifies training as a major component of the project. Any additional information requested in the RFP. Technical team training, end-user training. Note: The Technical Proposal shall not include any financial information. 5.2.2 Financial Proposal In preparing the Financial Proposal, Bidders are expected to take into account the requirements and conditions outlined in the RFP documents. The Financial Proposal should list all costs associated with the project, further broken-down into per module costs, costs of PIA MRO Project Page 298
licenses if any, hardware, software, cost of operating software, database software or any other software with required number of licenses for each component of the application, operating system or any other utility software required, cost of training, post implementation support, cost of warranties if any etc. If appropriate, these costs should be broken down by activity and, if appropriate, into foreign and local expenditures. Bidders must quote all prices of their goods and services in Pak Rupees only. Proposals must remain valid for 180 days after the submission date. During this period, the bidder is expected to keep available the professional staff proposed for the assignment. PIA will endeavor to complete negotiations within this period. However, if necessary, PIA may require extension in the said validity period. The proposal submitted by the bidders shall comprise the following: 5.2.2.1 The relevant completed Proposal Form and all Price Schedules as included in Section B3. 5.2.2.2 A full description of the technical solution to the business requirements described in Sections C Product Requirements (MRO Package) and Section D Services Requirements. 5.2.3 No Brokers The Bidders submitting proposals should attach declaration that: 5.2.3.1 They will not obtain or induce the procurement of the contract or any right, interest, privilege, or other obligation or benefit related to the contract from the PIA or the Government of Pakistan, or any subdivision or agency thereof, through any corrupt business practices. 5.2.3.2 Without limiting the generality of the foregoing, the parties submitting proposals will represent and warrant that they will not give or agree to give and shall not give or agree to give to anyone within or outside Pakistan either directly or indirectly through any natural or juridical person, including its affiliate, agent, associate, broker, consultant, director, promoter, shareholder, sponsor or subsidiary, any commission, gratification, bribe, finder s fee or kickback, whether described as consultation fee or otherwise, with the object of obtaining or inducing pursuant to the contract or any right, interest, privilege or other obligation or benefit related to the contract in whatsoever form. 5.2.3.3 The parties submitting proposals will certify that they have made and will make full disclosure of all contracts and arrangements with all persons in respect of or related to the proposed contract with the PIA and has not taken any action or will not take any action to circumvent the above declaration, representation or warranty. 5.2.3.4 The parties submitting proposals agree to pay compensation to the PIA in an amount equivalent to the direct losses to the PIA, which would include the sum of any commission, gratification, bribe, finder s fee or kickback that would otherwise have been given to PIA in the form of a concession, given by the parties submitting proposals for the purpose of corruptly obtaining or including the procurement of the contract or any right, interest or other obligation or benefit related to this contract PIA MRO Project Page 299
in whatsoever form from the parties submitting proposals, if it shall ultimately be determined by a final judicial decision that the party submitting proposals has so obtained or induced the procurement of the contract, or any right, interest, privilege or other obligation or benefit related to such contract. 5.2.3.5 Notwithstanding with any other clause the parties submitting the proposal undertake that they will declare that any contract signed or to be signed has been reached in a fair and legitimate manner and parties submitting proposals will furnish PIA with their promotional material, as, as is customary business practice, of de minim is value, prior to or subsequent to the conclusion of any contract between the parties submitting proposals and PIA. 5.2.3.6 For the sake of clarity, it is agreed and understood that the undertakings to be provided as contained in this clause do not and shall not prevent either the PIA or the parties submitting proposals from using the services of the professional experts such as, but not limited to, legal counsel, technical support, communication and public relation entities, financial institution and the parties submitting proposals may have recourse to their members and to their respective subsidiaries and affiliates as the case may be. 5.2.3.7 PIA may at its discretion levy penalties in case of project delays / malfunctions etc 5.2.3.8 In proposal Bidder shall specify a milestone based payment procedure however payments will be released as per milestones achieved at sole discretion of PIA. 6. Proposed Prices Prices provided shall be listed individually in the following manner: 6.1 Unit and total prices of products offered, inclusive of all taxes and duties paid. 6.2 Separate prices for each item of the hardware / software / licenses etc. 6.3 Prices for implementation services. 6.4 Prices for training Master Trainers, Power Users and End Users etc. local and foreign component to be mentioned separately. 6.5 Recurrent costs after the expiration of the warranty period on the Recurrent Costs Form, as follows: 6.5.1 The cost of all software updates, recurrent licensing fees, and any other items needed to operate the MRO Solution, plus any other recurrent supply of products specified in the RFP Document, 6.5.2 The cost of all maintenance and technical support services, and any other recurrent services specified in the RFP Document, including all taxes payable by the Bidder thereon. PIA MRO Project Page 300
6.5.3 Cost of post implementation support along with number of experts stationed at PIA premises. 6.6 Totals of Products, Services and Recurrent Costs, on the Proposal Price Summary Form. 6.7 There should be no hidden costs. Any cost not mentioned and to be incurred later for proper fault free execution of the project is the responsibility of the Bidder. 6.8 All costs are to be quoted in Pak rupees and must be fixed. 7. Documents Establishing Contractor s Eligibility and Qualifications 7.1 The documentary evidence of the Contractor s qualifications and ability to perform the contract if its proposal is accepted shall establish to PIA s satisfaction: 7.1.1 That, in the case of a Contractor not doing business in Pakistan, the Contractor is represented in Pakistan and will be able (if awarded the Contract), to carry out the installation, implementation, support, maintenance, and other service obligations prescribed in the RFP Documents. Documentary evidence supporting the aforementioned must be provided; 7.1.2 That the Contractor and any Sub-contractors have the financial, technical, and staff capabilities to support the MRO Solution, and have a successful performance history, appropriate for their role in fulfilling the contract. 7.1.3 In the event a proposal is jointly submitted by more than one Contractor, all other participants should be designated as Sub-contractors. Any planned or proposed use of Sub-contractors must be clearly documented in the proposal with their names and relationship defined. In addition the Lead Contractor should complete the Consortium Responsibilities Form in Section B, Subsection B3. The Contractor shall not be permitted to introduce any other sub-contractor, other than the ones already mentioned in the documents as mentioned aforesaid. 7.1.4 Each Sub-contractor must sign a Letter of Authorization / Joint Venture Agreement authorizing the Lead Contractor to act on its behalf. A copy of this Letter of Authorization / Joint Venture agreement must be submitted along with the Proposal. The Lead Contractor shall be completely responsible for all contract services to be performed. The Lead Contractor must demonstrate that all aspects of this RFP Document have been carefully and completely considered. 7.1.5 No substitution of a Sub-contractor shall be allowed during the term of this contract. Failure of a Sub-contractor to perform as expected shall not relieve the Lead Contractor of its duties to perform on the whole requirement and the Lead Contractor shall be liable for any / all loss(es) / damage(s) that PIA may suffer as a result of failure of a Sub-contractor to perform any / all of its obligations under this contract. PIA MRO Project Page 301
8. Document Establishing Products, Services Eligibility & Conformity to RFP Document 8.1 Pursuant to ITB Sub-section 5.2, the Contractor shall furnish, as part of its Proposal, documents establishing the eligibility and conformity to the RFP Documents of all products and services that the Contractor proposes to supply under the contract. 8.2 The documentary evidence of conformity of the products and services to the RFP Documents may be in the form of written descriptions, literature, diagrams, certifications and client references, including: 8.2.1 A detailed description of the essential technical and performance characteristics of the products. 8.2.2 An item-by-item commentary on PIA s Product and Services Requirements, as detailed in Sections C, D & E, demonstrating the substantial responsiveness of the proposed solution to the specifications provided. 8.2.3 A confirmation that the Contractor shall accept responsibility for the successful integration and interoperability of all proposed products and other PIA systems as required by the RFP Documents. 9. Bid Bond 9.1 Pursuant to ITB Sub-section 5.2, the Contractor shall furnish, along with its Financial Proposal, a bid bond for 5% (five percent) of the total amount of the Products, Services and Support Prices. 9.2 The bid bond is required to protect PIA against the risk of the Contractor s conduct that would warrant the security s forfeiture, as per ITB Sub-section 9, item 9.7. 9.3 The bid bond shall be denominated in Pakistan Rupees, shall be valid for One Hundred and Eighty (180) days beyond the validity of the Proposal, and shall be in one of the following forms: 9.3.1 A bank guarantee by a local Pakistani bank of the Contractor s choice, in the form provided in the RFP Documents; 9.3.2 A Pay Order / Demand Draft drawn on a local Pakistani bank. 9.4 Any Proposal not secured in accordance with ITB Sub-section 9, items 9.1 and 9.3 will be rejected by PIA and the Contractor shall not hold PIA liable in anyway whatsoever for any such rejection. 9.5 Unsuccessful Contractors bid bond will be discharged or returned as promptly as possible after the expiration of the period of Proposal validity prescribed by PIA pursuant to ITB Sub-section 10. PIA MRO Project Page 302
9.6 The successful Contractor s bid bond will be discharged upon the Contractor signing the contract, pursuant to ITB Sub-section 19, and furnishing the performance guarantee, pursuant to ITB Sub-section 18. 9.7 The bid bond may be forfeited: 9.7.1 If a Contractor attempts to withdraw its Bid before the date stipulated in the RFP for the validity of the Bid or any extension in this date agreed between the Company and the Contractor, 9.7.2 If a Contractor attempts to modify or amend its Bid without the approval / consent of the Company before the date stipulated in the RFP for the validity of the Bid or any extension to this date agreed between the Company and the Contractor, The Contractor shall not hold the Company liable in anyway whatsoever for the amount so forfeited by the Company. 10. Period of Validity of Proposals Proposals shall remain valid for at least 180 days from the date of Proposal submission or any extension thereof, prescribed by PIA. A Proposal valid for a shorter period shall be rejected by PIA. 11. Submission of Proposals 11.1 The Bidder is required to submit an original and one copy of each of its Technical and Commercial Proposals clearly mark each ORIGINAL BID or COPY OF BID, as appropriate. In the event of any discrepancy between them, the original shall govern. 11.2 The Technical and Commercial Proposals shall be typed or written in indelible ink and shall be signed by a person or persons duly authorized to bind the Bidder to the contract. 11.3 The Technical and Financial Proposals shall be submitted in separately sealed envelopes, each marked Technical Proposal and Financial Proposal accordingly, and bearing the name and complete return address of the Bidder, be addressed to General Manager (Procurement & Logistics) Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport, Karachi Ph: +92-21-9045135 Fax: +92-21-9040120 Email: gmptnl@piac.aero, contract.administration@piac.aero PIA MRO Project Page 303
12. Deadline for Submission of Proposals 12.1 Proposals must be received by PIA at the address and by the time specified in the RFP Document covering letter. Proposals received after this deadline will be rejected and returned to the Bidder unopened. 12.2 PIA may, at its discretion, extend this deadline for the submission of Proposals, in which case all rights and obligations of PIA and Bidders previously subject to the deadline will thereafter be subject to the deadline as extended. 12.3 PIA reserves the right to reject any or all proposals or divide the business in more than one bidder or not to implement the MRO solution. 13. Right of Negotiations 13.1 PIA reserves the right to negotiate the Contract Price, Quantities and terms and conditions of Contract with the Successful Bidder, that is, once the evaluation has concluded. 13.2 After receipt of the proposals from the Bidders, PIA will evaluate and study the proposals submitted. PIA does not bind itself to award the contract to the lowest or to any Bidder but will take into consideration all relevant facts and aspects. Negotiations will be held with successful Bidder, at PIA s head office. The aim is to reach agreement on all points and sign a contract. However, if circumstances at the time of negotiations are such that change of venue is required for holding negotiations the Bidder may request for such change but it shall be PIA s sole discretion to accept or reject such request. 13.3 Negotiations will include a discussion of the Technical Proposal, the proposed methodology (work plan), staffing and any suggestions made by the Bidder to improve the Terms of Reference. PIA and the Bidder will then work out final Terms of Reference, project plans (staffing levels) and bar charts indicating activities, staff, and periods in the field and in the home office, staff-months, logistics, and reporting. The agreed work plan and final Terms of Reference will then be incorporated in the Description of Services and form part of the contract. Special attention will be paid to maximize the services that Bidder can offer within the available budget and to clearly defining the inputs required from PIA to ensure satisfactory implementation of the project. 13.4 The financial negotiations will include a clarification (if any) of the Bidder s tax liability in the Pakistan and the manner in which it will be reflected in the contract; and will reflect the agreed technical modifications in the cost of the products and services. The successful Bidder shall be solely responsible for all its tax and other liabilities and any payments to be made by PIA under the contract will be subject to all applicable withholding taxes. 13.5 Having selected the successful Bidder on the basis of, among other things, an evaluation of proposed key professional staff, PIA expects to negotiate a contract on the basis of the products and available expertise named in the proposal. Before contract negotiations, PIA will require assurances that products and experts will be actually PIA MRO Project Page 304
available. PIA will not consider substitutions during contract negotiations unless both parties agree that undue delay in the selection process makes such substitution unavoidable or that such changes are critical to meet the objectives of the assignment. 13.6 The negotiations with the successful Contractor will conclude with a review of the agreed draft of a tri-partite contract, to be signed by PIA, its Consultants and the Contractor, ensuring successful delivery and completion of the project. To complete negotiations PIA, its Consultants and the successful Contractor will initial the agreed draft of the contract. If negotiations fail, PIA may invite the next Contractor to negotiate a contract. 14. Award of Contract The contract will be awarded following negotiations. After negotiations are completed with the successful Bidder, PIA will promptly notify other Bidder(s) accordingly. 15. Confidentiality 15.1 Information relating to evaluation of proposals and recommendations concerning awards will not be disclosed to the Bidder or to other persons not officially concerned with the process. The Bidder shall maintain complete confidentiality of its proposal and shall not disclose the proposal or any terms thereof to any unrelated person or any third party. The Bidder shall also keep confidential all its discussions and negotiations with PIA. 15.2 For the purpose of this RFP all Bidders receiving or responding to this RFP are considered potential contractors and have been identified throughout the RFP accordingly. 16. Bidder s Profile In assessing a potential contractor s ability to provide the MRO System, PIA is seeking details of the Bidders structure including: 16.1 The core activities of the business; 16.2 The products and/or services provided; and 16.3 The future Plans of the bidder. 17. Legal Binding 17.1 By submitting a Proposal, the Bidder agrees to be legally bound by the terms and conditions set out in this RFP. The Proposal will be considered as a binding offer from the supplier capable of acceptance by PIA. If during the course of any discussions or negotiations PIA and the Bidder agrees to vary any terms or the Proposal, the Proposal will be deemed to be amended to the extent of the agreed variation and PIA may accept the Proposal as deemed amended. 17.2 PIA will not be bound to accept the lowest or indeed any Proposal and will not be committed to any Proposal until a contract has been executed. PIA may in its discretion accept a non-conforming Proposal. PIA, in its absolute discretion and PIA MRO Project Page 305
without liability, may decide at any time to amend the RFP, invite Bidders, or any one or some of them, to amend their Proposal, extend the deadline for submission of Proposals or amendments to the Proposals or terminate the RFP process in whole or in part. PIA will be under no obligation to explain the reasons for its decision and in its sole discretion may call for further Proposals for the provision of the same or similar services at any time. 18. Performance Guarantee The successful bidder will be required to furnish, on or before the date of the signing of the contract, a performance bond equal to the10% (ten percent) value of the contract price/successful bid amount from a reputable scheduled bank acceptable to PIA. 19 Signing of Contract 19.1 After the receipt of the Performance Guarantee in accordance with ITB Sub-section 18, PIA will send the successful Bidder the Contract Form provided in the RFP documents, incorporating all agreements between the parties. 19.2 Within fifteen (15) days of receipt of the Contract Form, the successful Bidder shall sign and date the contract and return it to PIA. By mutual agreement, the contract signature date may be postponed by up to fifteen (15) days. 20. Clarification of Proposals 20.1 During evaluation of Proposals, PIA may, at its discretion, ask the Bidder for a clarification of its Proposal. The request for clarification and the response shall be in writing, and no change in the prices or substance of the Proposal shall be sought, offered, or permitted during or after evaluation of the Proposal. 20.2 PIA may also request the Bidder to arrange site visits, demos, presentations for its reference sites. 21. Contacting PIA 21.1 Any effort by the Bidder to influence PIA in the process of evaluating Proposals and in decisions concerning award of the contract will result in the rejection of the Bidder s Proposal. 21.2 The Bidders submitting proposals should attach a declaration that: (a) (b) They will not obtain or induce the procurement of the contract or any right, interest, privilege, or other obligation or benefit related to the contract from PIA or the Government of Pakistan, or any subdivision or agency thereof, through any corrupt business practice. They will not give or agree to give and shall not give or agree to give to anyone within or outside Pakistan either directly or indirectly through any person or organization, including affiliates, agents, associates, brokers, consultants, directors, promoters, shareholders, sponsors or subsidiaries, any PIA MRO Project Page 306
commission, gratification, bribe, finder s fee or kickback, whether described as consultation fee or otherwise, with the object of obtaining or inducing pursuant to the contract or any right, interest, privilege or other obligation or benefit related to the contract in whatsoever form. (c) (d) They have made and will make full disclosure of all contracts and arrangements with all persons in respect of or related to the proposed contract with PIA and have not taken any action or will not take any action to circumvent the above declaration, representation or warranty. They agree to pay compensation to PIA in an amount equivalent to the direct losses to PIA, which would include the sum of any commission, gratification, bribe, finder s fee or kickback that would otherwise have been given to PIA in the form of a concession, given by the parties submitting proposals for the purpose of corruptly obtaining or including the procurement of the contract or any right, interest or other obligation or benefit related to this contract in whatsoever form from the parties submitting proposals, if it shall ultimately be determined by a final judicial decision that the party submitting proposals has so obtained or induced the procurement of the contract, or any right, interest, privilege or other obligation or benefit related to such contract. PIA MRO Project Page 307
B2 SUMMARY OF REQUIREMENTS This schedule lists all major components of the MRO Solution to be procured through this Request for Proposal. Further details and exact specifications for each item are included in the Sections C, D and E. Item Type Description Project Site(s) MRO Package Application software modules to meet the Applications requirements as per details in Section C. Also any Add-on required for MRO solution, if any Head Office Other Locations 3 rd Party Software As required by the proposed MRO Package and Add-on Applications Head Office RDBMS As required by the proposed MRO Package and Add-on Applications Head Office Recommended configuration of hardware and operating system software for the Production Environment will be provided by the Contractor and it shall not be binding on PIA to procure this from the Hardware Contractor. Head Office Interim Application / Data Server(s) including Operating Systems as required by the proposed MRO for Training, Development, Testing and Quality Assurance Environments will be provided by the Contractor at its own cost Application Development Tools, Query and Report Generating Tools, Others System Administration Tools, Operating Systems, Systems Head Office Management Tools, etc. Installation / Implementation Services Installation, configuration and implementation of Hardware and Operating System, MRO Standard Software, Add-on Applications, 3 rd Party Applications. Head Office Other Locations Training Data Migration Recurrent Services End User, Power User and Management training for MRO, Add-on and 3 rd Party Applications, Technical training for Developers and Administrators on Application Development Tools, Reporting Tools, RDBMS, DBA tools, OS, System Management Tools, etc. Development of applications and migration of data from legacy systems and manual records Post-Implementation support for three years (after Warranty Period) for MRO Package, Add-on applications, Hardware and 3 rd Party Software Maintenance and Support Head Office Other Locations Head Office All Locations Section B Instructions to Contractors (ITB) Page 308
B3 Template Forms Notes for Contractors on the Template Forms 1. The Contractor shall complete and submit with its Proposal the Proposal Form and the required Price Schedules and in accordance with the requirements included in Section B, Subsection B3. 2. The Contractor should provide the Bid Bond as per the form included in this Subsection. 3. The Performance Guarantee form should not be completed by the Contractors at the time of their Proposal preparation. Only the successful Contractor will be required to provide Performance Guarantee as per the form included in Section B. PIA, however reserves the right, in case of failure on part of the Contractor to provide the aforesaid Performance Guarantee in accordance to the instructions as laid down in Instruction to Contractors (ITB) Section B within the specified time, to forfeit the bid security furnished by the Contractor. of 440 Page 309
Proposal Form To: General Manager (Procurement and Logistics) Pakistan International Airlines Procurement and Logistics Building Near PIA Head Office Karachi Airport Karachi Dear Sir: Having examined the Request For Proposal Documents including Addenda Nos. [insert numbers, if issued and applicable], the receipt of which is hereby duly acknowledged, we, the undersigned, offer to produce, deliver, install, implement, support and maintain the MRO Solution in full conformity with the said RFP Documents. We undertake, if our Proposal is accepted, to implement the MRO Solution in accordance with the Project milestones agreed with PIA. We certify that a bid bond for 5% (five percent) of the total amount of the proposal is submitted as part of our Financial Proposal. If our Proposal is accepted, we will provide a Performance Guarantee in the form and in the amounts, and within the times stipulated in the Request For Proposal Documents. We agree to abide by this Proposal for a period of 180 days from the date fixed for Proposal submission, and it shall remain binding upon us and may be accepted at any time before the expiration of that period. Until a formal Contract is prepared and executed, this Proposal, together with your written acceptance thereof and your notification of award, shall constitute a binding Contract between us. We understand that you are not bound to accept the lowest or any Proposal you may receive. Dated this day of 20. [signature] [in the capacity of] Duly authorized to sign Proposal for and on behalf of of 440 Page 310
Name of Contractor Page of Products Price Schedule Item No. Product Description Contractor Proposal Reference Product Producer Partner or Sub-contractor Responsible for Supply and Installation Quantity Unit Price 17 (Rs.) (1) (2) (3) (4) (5) (6) MRO Package Add-on Applications Subtotal RDBMS Subtotal 3 rd Party Software Subtotal Hardware: Subtotal Other Products: Subtotal TOTALS Total 18 Price (Rs.) (7) = (5) x (6) Additional MRO Licensing Cost / User 19 Signature of Contractor 17 Prices include all taxes payable by the Contractor thereon. 18 In case of discrepancy between unit price and total, the unit price shall prevail. Similarly, subtotals shall prevail over totals. 19 Price for Each Additional MRO User should be provided separately PIA MRO Project Confidential
Services Price Schedule (Prior to Maintenance) Name of Contractor Page of Item No. Service Description Contractor Proposal Reference Partner or Sub-contractor Responsible for Service Delivery Quantity Unit Price 20 Total Price (1) (2) (3) (4) (5) (6) = (4) x (5) Implementation MRO Package Add-on Applications 3 rd Party Software Subtotal Training Master Trainers End-users Technical Apps Dev Tool Reporting Tool DBA Tool RDBMS Operating System Sys Admin / Mgmt Others Subtotal Data Migration Documentation Other TOTALS (Rs.) (Rs.) 21 Signature of Contractor 20 Service prices include all taxes payable by the Contractor thereon. 21 In case of discrepancy between unit price and total, the unit price shall prevail. Similarly, subtotals shall prevail over totals. PIA MRO Project Confidential
Name of Contractor Page of Recurrent Costs Schedule (Prices during the maintenance period for first three years) Maintenance Fee: MRO Package Add-on Application 3 rd Party Software RDBMS Sub-total Maximum compounded costs per annum after expiration of the warranty period (in Pak Rupees) 22 Year 1 Year 2 Year 3 Total Recurrent Costs Recurrent Software Licensing Fees: MRO Package Add-on Application 3 rd Party Software RDBMS Sub-total Hardware maintenance costs Other recurrent costs TOTALS Signature of Contractor 22 The annual costs should indicate the total costs for the year inclusive of all taxes. PIA MRO Project Confidential
Proposal Price Summary Form Name of Contractor Page of Products Price Total Services Price Total Recurrent Costs Total Amount in Pak Rupees Total Proposal Price: Signature of Contractor PIA MRO Project Confidential
Bid Bond Form BANK GUARANTEE NO. DATED: AMOUNT: EXPIRY: Pakistan International Airlines Karachi Airport Karachi BID BOND AS PER TENDER NO. FOR WHEREAS (hereinafter called the Contractor ) has submitted to PAKISTAN INTERNATIONAL AIRLINES (hereinafter called the Company ) a bid dated day of year, for the execution of the above work. AND WHEREAS it is provided by this bid that the Contractor shall furnish the Company with security by way of an unqualified bond or guarantee for the due fulfillment of certain matters relating to this Bid. AND WHEREAS have at the request of the Contractor agreed to give such security. NOW THEREFORE WE of undertake, subject to the following terms, to pay to the Company on its demand such sums as may be claimed by it in writing upto a maximum of Rs. as recorded on the Request For Proposal. 1. The Company may claim payment hereunder if either: 1.1 Before the date stipulated in the Request For Proposal for the validity of the Bid or any extension to this date agreed between the Company and the Contractor, the Contractor attempts to withdraw, modify, or amend his bid without the approval of the Company or 1.2 The Company has agreed with the Contractor that a Contract will be executed, but the Contractor fails to execute the formal Contract Document when requested to do so by the Company or Page 315
1.3 At the time of entering into a Contract with the Company to undertake and complete the work, the Contractor fails to provide the Bonds and Guarantees required by such Contract. 2. Payment shall be made hereunder on the Company s first demand in writing to us stating that one or more of the above events has occurred without any further condition or substantiation and without the necessity of any proceedings whatever, whether judicial or otherwise being instituted by the Company. 3. The Bond shall remain in full force and effect until the date when the Contractor shall have executed the formal Contract Document and provided the necessary Bonds and Guarantees there under or upon the written rejection by the Company of the Contractor s Bid, whichever is earlier, at which time the Bond shall automatically expire and be of no further effect. IN WITNESS WHEREOF this Bond has been duly signed and sealed on the day of year. For and on behalf of Officer Manager Witnesses: 1. 2. Page 316
Form of Contract Agreement THIS AGREEMENT made the day of year between Pakistan International Airlines (hereinafter called PIA ) of the one part and [name of Contractor] of [city and country of Contractor] (hereinafter called the Contractor ) of the other part: WHEREAS PIA invited Proposals for certain products and ancillary services, viz., MRO Solution and has accepted a Proposal by the Contractor for the supply of those products and services in the sum of [contract price in words and figures] (hereinafter called the Contract Price ). NOW THIS AGREEMENT WITNESSETH as follows: 1. In this Agreement words and expressions shall have the same meanings as are respectively assigned to them in the Conditions of Contract referred to. 2. The following documents shall be deemed to form and be read and construed as part of this Agreement, viz.: (e) (f) (g) (h) (e) (f) Instructions to Contractors; Summary of Requirements; Product and Services Requirements; General Instructions and Conditions of Contract; Special Terms and Conditions of Contract; Contractor s Proposal. 3. In consideration of the payments to be made by PIA to the Contractor as hereinafter mentioned, the Contractor hereby covenants with PIA to provide the products and services and to remedy defects therein in conformity in all respects with the provisions of the Contract. 11. PIA hereby covenants to pay the Contractor in consideration of the provision of the products and services and the remedying of defects therein, the Contract Price or such other sum as may become payable under the provisions of the Contract at the times and in the manner prescribed by the Contract. 12. Unless expressly stated herein, wherever any period or periods of time are specified, the parties hereto agree that time shall be the essence of the Contract. 13. Unless expressly stated herein, the failure of one party to exercise any option, right or remedy under the Contract or to demand compliance of any obligation of the other party, shall not constitute a waiver of any such option, right or remedy or the performance thereof. 14. Each of the rights and obligations contained in this Contract shall be deemed to be distinct and severable so that if one such rights and obligations shall be declared or become illegal, void or unenforceable, then the remaining rights and Page 317
obligations shall (unless the effect is to frustrate the fundamental basis of this Contract) continue in full force and effect. 15. The Contractor shall not assign any of its duties / obligations under this contract to any third party. 16. The parties to the Contract shall not be liable for any loss, claims or demands of any nature whatsoever and shall not be deemed in breach of this Contract because of any delay or failure in observing or performing any of the conditions or provisions hereof if such delay or failure is caused by or arises out of any circumstances whatsoever, beyond the affected party s control, including (but without limiting the generality of the foregoing), declared war, sabotage, blockade, revolution, police action, riots or disorder, embargoes or trade restrictions of any sort, government or quasi-government action, acts of God, fire, flood, earthquakes, explosion, accident, radiation, strike, lockouts or other Labor disputes or disasters. 17. The Company shall have the right to terminate the Contract: If the Contractor, in the judgment of the company, is or has been engaged in corrupt or fraudulent practices in competing for or executing the Contract If the Contractor commits a breach of any of the terms and conditions of this Contract In any case the Company terminates the contract on any of the aforesaid reasons, the Contractor shall be liable for all direct losses, damages and charges incurred by the Company, in relation to the termination of this contract. 18. All disputes or any difference or question which may arise between the parties hereto or any person claiming thereof, touching or arising out or in respect of this Contract or the subject matter thereof shall be referred to the arbitration in accordance with the Arbitration Act 1940, which shall take place in Karachi. Each party shall appoint its own Arbitrator and the decisions in such arbitration proceedings shall be final and binding on both the parties. IN WITNESS whereof the parties hereto have caused this Agreement to be executed in accordance with their respective laws the day and year first above written. Signed, sealed, and delivered by the said [name of representative] (for PIA) Page 318
in the presence of [name of witness] Signed, sealed, and delivered by the said [name of representative] (for the Contractor) in the presence of [name of witness] Page 319
Pakistan International Airlines Karachi Airport Karachi Dear Sir, PERFORMANCE GUARANTEE Performance Guarantee Form BANK GUARANTEE NO. DATED: AMOUNT: EXPIRY: DESCRIPTION OF WORK Whereas, we understand that you have placed a Work Contract No. dated with (The Contractor) for the above mentioned work and that in accordance with the terms of the contract, the Contractor is required to furnish a Bank Guarantee in respect of it s obligations under the said contract for an amount equal to 10% of the contract value viz (amount of contract in words and figures). Now, therefore, in consideration of the above, we, (Name and address of Bank) hereby GUARANTEE irrevocably and unconditionally the due payment to you upon demand of first written such sum or sums not exceeding (amount of guarantee in words and figures) without whatsoever right of objection in the event that the contractor fails to perform or fulfill any of the terms and conditions of the contract at the time or during the period specified therefore in the contract, provided that any demand hereunder is received in writing at this office within the validity of this guarantee accompanied by your written declaration to us that the Contractor has failed to comply with the terms of the contract, and such declaration shall be accepted by us as conclusive proof that the amount claimed is due to you, and we shall forthwith pay you the entire amount claimed. Our liability under this guarantee shall not be affected by any dispute or difference between you and the Contractor or by any forbearance or indulgence granted by you to the Contractor or by any other security held by you from the Contractor relating to the above mentioned contract or any variation in the contract or any other matter or thing which might otherwise affect our liability hereunder. We further Guarantee that no change or addition to or other modification of the terms of the Contract shall in anyway release us from any liability under this Guarantee and we hereby waive notice of any such change, addition or modification. Page 320
This Guarantee will remain valid until... and any claims hereunder must be received by that date, after which this guarantee will become null and void, and must be returned to us for cancellation. This guarantee shall be construed in accordance with the laws of Pakistan. For and on behalf of Officer Manager Witnesses: 1. 2. Page 321
Consortium Responsibility Form Name of Firm 23 Form of Business 24 Role in Project 25 Lead Contractor Responsibilities 26 Product or Service 27 to be Provided Joint Venture 28 Agreement Reference and Date For each partner list the staff members who will be a part of the project, their proposed roles and the minimum committed man-days for each person. Signature and Stamp of Authorized Lead Contractor 23 Enter the name of each of the Consortium / Joint Venture / Sub-Contracted firms, starting with the Lead Contractor 24 State whether Individual, Sole Proprietor, Limited Liability Company, Partnership, Corporation, etc. 25 State the role of the Firm on the Project i.e. whether Lead Contractor, Project Manager, Software Supplier, Software Developer, Trainer, etc. 26 Clearly list all the key responsibilities the Firm would be undertaking on the Project 27 Include a time schedule for provision of products and services of each partner 28 Copy(s) of Agreement(s) to be attached Page 322
B4. Format and Contents of Proposal 1. General Proposal Requirements 1.1 Proposals should be prepared simply and provide a straightforward, concise description of the Bidder s capabilities to satisfy the requirements of this RFP. 1.2 Bidders must follow all formats and address all portions of the RFP set forth herein providing all information requested. Bidders may retype or duplicate any portion of this RFP for use in responding to the RFP, provided that the proposal clearly addresses all of PIA's information requirements. 1.3 Bidders must respond to every subsection under the Technical Proposal and Cost Proposal sections. Bidders must label each response to RFP requirements with the section and subsection numbers or Proposal Reference IDs associated with the subject requirement in this RFP. 1.4 All information presented in a Proposal must be relevant in response to a requirement of this RFP, must be clearly labeled, and must be referenced to and from the appropriate place, within the body of the Proposal. 1.5 Proposals shall be prepared on standard A4 size paper. Foldouts containing charts, spreadsheets, and oversize exhibits are permissible. Proposal pages must be numbered and responses must be identified by the related RFP section number. 1.6 Bidders shall divide their responses to this RFP into a Technical Proposal and a Financial Proposal. Financial Proposal and pricing information should not be included in the Technical Proposal. Inclusion of Price Proposal or pricing in the Technical Proposal shall make the proposal non-responsive. 2. Required Format of the Proposal Each Contractor can submit only one Proposal. Bidders shall prepare their Bids using the following structure and form. 2.1 Executive Summary The Bidder s response concerning its ability to satisfy the qualification, eligibility, business and technical requirements as stated in the RFP Document. The Bidder should summarize the proposed technical and service solution and qualitatively describe its advantages in the Executive Summary. 2.2 Bidder s Qualification and Experience The Bidder should provide information regarding his eligibility, qualification and relevant experience to perform the requirements under Section F Bidder s Qualification and Experience of this RFP. 2.3 MRO Package Section H Requirements Compliance Matrix Page 323
Complete details should be provided of the MRO Package that is being proposed as part of the solution. The MRO Package s general functional description and capabilities, with particular reference is defined in Section C Product Requirements (MRO Package). The MRO Package should have all integrated modules and should seamlessly interface with PIA s existing internal and external software and with other proposed external software utilities and modules should be described, with an overview of integration and data transfer mechanisms. The security and manageability features should also be highlighted. The Bidder should elaborate on the extent and efforts for customization required to satisfy the functional requirements. Bidder should provide contingency and backup plans/procedures with guaranteed Service Level Agreements. Licensing cost for MRO users should be provided as follows: For 500 MRO users For 1000 MRO users For 2000 MRO users For 3,000 MRO users Additional 100 MRO users Unit cost for each MRO user In case of concurrent users License may be reduce accordingly. Contractor must also specify an Escrow arrangement for the availability of source code necessary to support the proposed solution in case the Contractor or the principal vendors cease to exist, discontinue this line of business or are incapacitated in any way to support the proposed solution. 2.4 Relational Database Management System (RDBMS) Complete details of the RDBMS are to be provided, including features and capabilities, adherence to industry standards, portability and openness, with reference. Features and capabilities of the Database Administration Tools that are proposed should be provided. 2.5 Query and Report Generator Tools Complete description of the tools that are being provided with MRO Package standard functionality for End-User ad-hoc query and report generation, including capabilities for ease-of-use and learning. Section H Requirements Compliance Matrix Page 324
2.6 Implementation Strategy The Bidder should provide details of the implementation strategy to be adopted, and include a component-wise high-level plan. Details should be provided of the project organization that will be maintained. The Project progress reporting mechanism is to be highlighted. Details of how the resources will be utilized during the various phases of the Project should be described. The quality assurance process to be followed for products and services, as well as responsibilities, should be described. Implementation tasks requirements are detailed in Sub Section D1. Detailed time schedule shall be provided highlighting main milestones and activities in detail with overall time span. Bidders must clearly specify the facilities required by their consultants during implementation. 2.7 Interim Server(s) A complete description of the hardware configuration and performance expectations of the proposed Interim Server should be provided. The Contractor should also describe the contingency arrangements that will be in effect for the period that the Interim Server(s) is required, as well as maintenance responsibilities. The Site Specifications for installation of the Server(s) must be provided to enable PIA to cater for the requirements. 2.8 Training to Users and Management Details of Training to be conducted by the successful Bidder should be provided, with description of type, content, duration and location of courses for each of the identified personnel levels, with reference to Sub Section D - Services Requirements. Also describe the training material to be provided on completion of the course as well as certification/examination method to be followed. 2.9 Data Migration All details of data conversion strategy and process have to be defined. Details of forms, screens, or interim file arrangements should be described. The resources that will be required as well as any training requirements must be highlighted. The programming effort that will be undertaken should also be described. 2.10 3rd Party Software Interfaces Contractor will be responsible to ensure that required 3rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration tools, disaster recovery and business continuity tools, APIs / interfaces, etc. are all made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed MRO solution. These should be clearly spelt out in the Technical Proposal and corresponding pricing shown in the Price Proposal. Section H Requirements Compliance Matrix Page 325
2.11 Documentation Details of documentation have to provide for MRO and other Applications. It should describe a summary of contents, media on which provided, and the number of hard and soft copies. The Bidder should address the needs of End user as well as technical (operations, support and development). 2.12 Post-Implementation Warranty / Support Details of post-implementation support during and after warranty period that will be provided after the expiry of the warranty should be provided for each required component with reference to Section D - Services Requirements. The type of support, coverage, location from which support will be provided, should be described, as well as the level of expertise that will be employed for support. Also describe the escalation process that is to be followed, and the service levels. A description of the handling of various categories of problems and response times should be provided along with the cost. 2.13 Technology Architecture Details of the proposed technology architecture under which the MRO solution will be implemented should be provided, consistent with modern n- tiered client/server and distributed computing design and details provided in Section C Product Requirements (MRO Package and Add-Ons). 2.14 Recommendations for Hardware Configuration and System Management Tools The Bidder should provide its recommendations for the platform configuration for server hardware to run the MRO package and other applications. The proposed MRO package and Rational Database shall be platform independent so that shall give PIA liberty for choosing any appropriate platform in the future. Bidder has to propose complete hardware solution and minimum network infrastructure. PIA reserves the right to purchase hardware/operating software from the successful Bidder or any other vendor of its choice. Section H Requirements Compliance Matrix Page 326
SECTION C Product DETAIL (MRO Package and Add-ons) Section H Requirements Compliance Matrix Page 327
The following functional requirements are demanded by PIA Engineeing. 1. Required Engineering Functionality 1.1 MPD Process Read New Maintenance Planning Document (MPD) Version/ Automated Upload The MPD document update delivered by the aircraft OEM on regular basis to be automated uploaded into the system. In case of non-customized MPD delivery, a filter according to the PIA effectively shall generate customized version. Structural repairs may cause a single aircraft tracing in the MPD by defining threshold and interval. Maintain New Version And Get Approval The System Engineer shall check the new version by using the revision marks update the version, print and ask Civil Aviation Authority (CAA) for approval. Optimize MPD Items An editing functionality shall allow, it to optimize MPD items according to PIA needs. Release MPD To Service When CAA approval is granted, the new MPD version will replace the former MPD version in the production system. Maintenance production planning and scheduling will act according the revised MPD version. Define MEL The Minimum Equipment List to be defined along with the PIA MPD and updated according to the fleet configuration. 1.2 Reliability Management Reliability and Performance Report, A/C, Chapter, Engine, Component Aircraft Engineering s duty is to monitor aircraft, engine and component reliability. The data is to be provided out of line and base maintenance defect management, component and engine overhaul defect notifications. Also the needed performance data to be interfaced and provided. The system shall provide all needed data for generating the monthly reliability report. The report is to be distributed for internal and external users. Dispatch Reliability Also dispatch reliability reports to be generated and provided for internal usage to assess PIA Engineering performance. NFF Reports The No Fault Found (NFF) after component/ system test to be notified. Statistics and analysis to be performed in order to reduce the NFF rate. Reports to be generated as well. MTBUR Replacements Section H Requirements Compliance Matrix Page 328
Statistics to be performed to analyze the unscheduled removal rate and the reasons behind it. The system engineer shall get the needed data for maintain and adjust the MPD. Engine, APU Performance Results of engine condition monitoring, oil consumption to be stored and monitored in the system. CofM, CofA, Renewal & Reporting Also the aircraft certificates such as the Certificate of Airworthiness (CofA) to be monitored and the renewal process to be supported. Monitor ETOPS, RVSM Compliance The aircraft configuration to be checked against the minimum requirements concerning ETOPS and RVSM. Flight Incidents, Pilot Reports Flight incidents and pilot reports to be stored and classified with some parameters in the system Aircraft Utilization The aircraft/fleet utilization to be stored into the system. The information to be received via interface. 1.3 Document Management Upload OEM Manuals The system shall ensure an airworthy update and revision management of all OEM documents used for aircraft maintenance and engineering. But also airframe structure drawing to be up-loaded via internet access. Upload And Register SB s All Service Bulletins (SB s) and Airworthiness Directives (AD s) to be registered in the system Revise Aircraft Manuals The revision management process shall ensure, the revisions are applied at the central library but also, that all revised documents receive by all end users. Distribute Manuals Electronic documents are most preferable distributed electronically. But functionality for distributing paper based documents shall be available as well. Maintain PIA Manuals PIA own manuals to be maintained, approved and revised. The system shall support this process. 1.4 Task Card Management Upload OEM Task Cards (TC) Section H Requirements Compliance Matrix Page 329
PIA is widely using the Task Cards provided by the OEM. A functionality to be provided to upload and revise master Task Cards. The system shall have functionality to store and manage those document types for further use. Create/Update/ Modify TC Beside pre defined TC s there must be a functionality to write, maintain and revise PIA own TC s. For structural damages and major repairs, creation and approval of TC to be supported. Copy & Paste Of Procedures From AMM By enhancing the TC s with more detailed instructions, text and graphical elements of the OEM manuals to be used by copy and paste into the TC s. Reference to be made to original documents. In case of further OEM Manual revisions, revision support to be given to revise the respective TC. The reference information to be used for selecting TC Some inspection TC must report the result back to Engineering. Release Master TC For Service. Once the master TC is finally edited and/ or revised. This TC to be get approval (final check by second person). This could be supported by a workflow solution. When the approval is granted, the TC to be released for using in the production. The old version to be replaces. When the master TC is released for production, The TC content is reduced to the concerned tail sign, the order number is added to the TC and the TC attached to a Work Package. The TC if required on coloured paper with bar code, tail sign text and graphic. Also the required material to be on the TC and will create the BOM by turning the master TC into production. 2.0 Required functionality for Aircraft Phase-in/-Out 2.1 Aircraft master data Create aircraft/ engine master data when a new aircraft is to be introduced, the Aircraft/ Engine master data to be created. Create Aircraft/ Engine Master Structure & Locations When a new aircraft type to be introduced in the fleet a new structure of this aircraft or variant to be defined. Based on this fleet structure, the aircraft/ engine master structure and location to be defined. The technical locations shall consist of ATA chapters and Zonal information in a hierarchical structure in assays and sub assay. 2.2 Initial Data Entry Initial provisioning, upload Recommended Spare Parts List (RSPL) For the induction of an new aircraft type the recommended spare parts list is to be uploaded. An editing functionality shall allow producing versions of this Section H Requirements Compliance Matrix Page 330
RSPL file. Based on the final agreed parts list, the procurement process to be initiated. Upload And Maintain Readiness Log Also the readiness log to be uploaded to complete the as is configuration. Upload A/C, Engine, Component History The aircraft, engine and component history to be updated. Upload MPD, MEL In case of a new aircraft type, the respective MPD and the Minimum Equipment List (MEL) to be updated and customized according to the PIA needs. Upload TechLog, MEL Status, Open Defects The actual aircraft status concerning technical logbook, MEL related items and deferred defects to be uploaded into the system. Upload Modification Status The modification status to be uploaded. Maintain Status/ Letter Checks Performed The due date and the history of the letter checks performed to be updated. Enter Flown Flight Hours, Block Hours, Landings Cycles, Days. The flown flight hours, clock hours, cycles and days to be updated for the aircraft, engine and leach Line Replaceable Unit (LRU). 2.3 Aircraft Phase Out Create Readiness Log By phasing out an aircraft, a readiness log to be provided. But also concerned stock to be reviewed for surplus. Create Mod Status A report to be created of the entire aircraft/ engine modification status Create Maintenance Status A report to be created of the current maintenance status and the entire maintenance history. Create TechLog, MEL status, Deferred Defects A report to be created concerning the actual open items, such as Technical Logbook entries, MEL related items and deferred defects. 2.4 Engine Change Remove & Extract Complete Data Set Section H Requirements Compliance Matrix Page 331
By engine removal, all engine related data to be removed from the aircraft data set. In case of foreign repair, a report to be created and transferred to the vendor, with all concerned engine information. Upload Complete Data Set Engine overhaul, repair and modifications concerned data to be uploaded to the system. At engine installation all concerned data to be linked with the concerned aircraft. 3.0 Required Functionality for Line Maintenance 3.1 Line Maintenance Planning Long / Medium-Term Planning (summer/winter/hajj) Based on the PIA flight schedule and the PIA maintenance program (Preamble) in the long term planning a first schedule of the letter checks (A-Check and below) are done. Together with the expected non routine work, the needed component changes and the modifications, to ground time and the needed man hours are defined. In the medium term planning each ground time will be adjusted, the bill of work will be finalized and the bill of material defined. The total load will be mapped against the available capacity. Short-Term Planning The deferred defects will accomplish the Bill of Work. All needed manpower, tools, spares & documents are prepared and assigned to the planned job. Work Load/ Capacity Planning The expected workload will be balanced against the available capacity. Further actions to be arranged such as additional capacity or postpone of work packages. Also flexible shift pattern to be arranged by the system. Hangar/ A/C Visit Plan As a result of the long/ medium term planning, the hangar visit plan is defined. It represents the needed hangar slots of all PIA & client letter checks. Assign Work Package To Work Center/ Shift/ Individual Staff The defined work packages to be assigned to a particular work center and shift. In case some work packages cold not completed in a shift, it will be rescheduled by production planning and again assigned to a work center and shift. The major criteria is a priority/ alert list showing the latest due date of a job and also the aircraft availability. For flights, a Ground Engineer to be attended, the flight coverage planning shall be possible. Individual Ground Engineer shall be assigned to a particular flight. Dispatch Spares, Tools, Documentation To Line Station The spares, defined at the Bill of Material (BOM) is already blocked by a reservation functionality. Also the needed tools. When Production planning assigns a work package to a work center/ shift, the due date and the location is defined. Production Planning (PP) will also create a transportation order for providing the needed spares and tools at the needed location. When the work Section H Requirements Compliance Matrix Page 332
packages are performed a dispatch order will return the tools to the tolls store and location, the replaced components to be dispatched to the salvage store. Provision Of Line Stations The provision of line stations with staff, tools, document and spare kit to be planned and renewed. 3.2 Scheduled Maintenance Bill of Work (BOW) The BOW is a list of work packages (WP) to be performed in Line and Base maintenance. Each WP consist of a number of job cards (JC). Each WP has a unique identification number. Bill of Material (BOM) The BOM defines the needed routine material (rotables and consumables) for performing the WP. This list is a master file attached with the BOW master file. Needed routine material can be part of the master JC and the BOM to be extracted from it. Same with the needed tools and equipment. Needed Tools and Equipment The needed tools and equipment, such as remedies, stairs, GSE to be planned by PP and dispatched to the WC. The list of required tools and equipment is part of the WP. Execute Work Package and Task Cards Planned TC and WP to be performed are stored in the system as master documents. They consist of all needed field such as a unique ID, A/C type and effectivity, ATA chapter and Zone the needed MH and qualification. When WP and TC are transformed from planning stage and turned into operation, the tail sign, the due date and an unique order number is added. A bare code is printed at the JC representing the order number. A cover sheet representing the WP and showing all JC within the WP. Section H Requirements Compliance Matrix Page 333
Schedule Major Component Change (MIC) PP will create out of an forecast of hard times and regular inspections. Out of this list, the needed tasks for the coming shift are to be defined. The needed JC are selected and will be part of the WP. Release A/C to Service After performing the planned maintenance services, the A/C will be release to service. This is noted in the system. Any limitations such as remaining life due to MEL items will also noted and are the base for planning new maintenance activities. Shift Hand Over The shift hand over to be supported by providing a list of open items. LRU Software Update LRU software updates to be provided by the OEM to be installed in the PIA fleet. The system shall support the update process by reporting the task completion of each aircraft. 3.3 Unscheduled Maintenance Record Defects Und Corrective Action. The defect description and a number of describing filed including tail sign, ATA chapter und location, to be entered. The functionality shall also indicate repetitive defects. When the repair strategy is already defined during the investigation, it is noted in the corrective action field but also as a deferred defect. When the corrective action is completed, the open case will be closed. The defect notification to be used for further fleet analysis and for the fleet Reliability Report. Trace Deferred Defects Tracing functionality shall locate deferred defects for further actions. An open defect notification will also create a Maintenance Repair Order. Indicate MEL Items The system shall display the MEL list. An attribute shall declare the deferred defect as a MEL item and define the remaining life, if appropriate. In case of MEL item for each fight a report to be produced for pilot briefing. The MEL item to be traced on the alert list for high priority maintenance actions. 3.4 Post Maintenance Process Update A/C, Component Records When component change is performed, the respective S/N will be posted in the System. The replaced S/N (U/S part) will keep the accumulated counters. The new serviceable unit located in the A/C will accumulate counters to its remaining life. With the component change, the A/C will get an update of the as is configuration. In case of a modification (performing AD or SB) the new Section H Requirements Compliance Matrix Page 334
mod status of this A/C is noted. Subsequent changes in the system concerning MPD and TC are initiated. Also the mod campaign will get notice of accomplishment of this A/C. By accomplishing the WP, the related A/C counters are set to zero. When the A/C starts again operation, all A/C counters and the subsequent Engine/ APU/ Component counters will continue to collect the operational counts. The rescheduling of the next maintenance activities will start. Report Performed Tasks The performed WP s are reported as complete, when the WP cover page is clocked-out by bare code scanning. The WP will be deleted from the WP backlog and transferred to the performed tasks. All dirty finger prints are archived by using the WP ID as the leading discriminator. Archive Task Cards After performing the TC, the documents are archived for legal purposes for a minimum of two year or for tracing A/C, Component history back-to-birth. 4.0 Required Functionality for Cabin Maintenance 4.1 Maintenance Planning Define/Update Maintenance Program For CM, Also For A/C Exterior Cleaning. Regular schedule to be defined for cabin maintenance & aircraft external cleaning. Define Instruction Cards For CM Instruction card to be defined for cabin maintenance. Plan CM According To The Maintenance Program According to the defined maintenance program, the CM work packages are planned and scheduled. Plan Capacity According To Work Load According to the maintenance schedule, the capacity to be assigned. 4.2 Customer Feedback Interface To Customer Complaint System An interface to be created between the system and the PIA customer feedback system. All Cabin related items to be transferred. Do Corrective Action The corrective actions to be recorded and reported back to the customer feedback system. Statistics According Customer Feedback Statistics are generated concerning customer feedback and cabin maintenance activities. Section H Requirements Compliance Matrix Page 335
4.3 Unscheduled Maintenance Record defects from CBL or inspection and report corrective action see also Line Maintenance (LM) defect management Trace deferred defect same as LM Indicate MEL items same as LM 5.0 Required Functionality for Base Maintenance 5.1 Base Maintenance Planning Long/ Medium-Term Check Planning Base Maint. Events In the long term planning a forecast is given by the system for letter check due date and ground time based on standards parameter. This forecast in used for ground time staggering, budget planning and hangar capacity planning. In the medium planning the bill of work to be defined, the bill of material, together with planning adjustments, load and capacity planning. The routine and non-routine work packages are defined. The required tools are defined. Work Package Management The standards Work Packages consist of several Job Cards are compiled and edited according to production planning and work optimization criteria. JC to be linked to WP s and WP to be liked to a project plan. Hangar/ A/C visit plan see Line Maintenance Wok Load Planning see Line Maintenance Job Card creation/ update/ revise see Aircraft Engineering Event Project Planning With Flow Charts And Mile Stones The project plan shall be a graphical representation of WP along a time line. By meeting the external time criteria, the Production Planner shall have the possibility of shifting the WP s along the time line to match with the available capacity. Also an automated planning using capacity and load planning shall be possible. Forward/ Backward Event Planning (Incl. Gantt-Chart). Various planning scenarios to be possible such as forwards planning by using a fixed start date and backward planning by using a fixed end date. Progress Monitoring, Monitor Costs By using shop floor data collection and the JC completion note, the work progress to be monitored. With the shop floor data collection the consumed man hours to be collected. Also consumed parted and exchanged LRU s to be posted to the Work Order. Monitor Consumed Man Hour (MH) & Spares The consumed spared and respective costs, the repair abroad costs and the consumed man hour to be monitored on daily basis to control the costs. Section H Requirements Compliance Matrix Page 336
5.2 Base Maintenance Operation Interface Deferred Defects From LM The deferred defects to be transferred to the base maintenance event at the time of aircraft roll in. The deferred defect to be transferred into a Repair Order. Shop Floor Data Collection. All Job Cards to be submitted will be assigned to an Order Number. By using a bar code beginning and end of the work to be done is registered. Also when a component change is due, the in and out Serial Number (S/N) to be notified und subsequent processes to be triggered. But also queries at the Material Master and available stock to be done. Entering Snags, Planning Rectification. When visual inspections and system checks are required by the WP, upcoming discrepancies to be notified. Attributes to be added concerning the location, the nature of defect and the causing document (eg. CPCP). A repair order to be generated with some production planning attributes such as expected man hours, needed spares and tools. The closure of the defect notification to be recognized by the system. Some observations to be notified and transferred to Engineering work place, such as CPCP. Shift Hand Over A functionality to support shift handover in case the open WP or JC could not completed within the current shift. Capacity Planning Functionality offered to balance workload and available capacity. Close Loop Repair Parts replaced for A/C and returned from shops after repair to be traced and planned in a close loop parts management. 5.3 Post Maintenance Process Transfer Defect To LM When the aircraft roll out after the base maintenance is due, the open items are to be transferred to line maintenance and kept as Repair Orders. Update A/C Configuration & Counters Modifications, and component changes reflects changes in the aircraft configuration. Configuration update shall be most preferable done automatically by posting a component change. Manual update to be provided as well. Archive Documents Section H Requirements Compliance Matrix Page 337
All major activities are recorded as database transactions. But also the used and stamped documents (dirty finger prints) to be archived according to the legal requirements. A logic link with the respective data base entry leads to a powerful knowledge base. Post Check Analysis Analysis functions to be provided to allow reviewing and analyze performed checks. Also the recorded Mh to be available for updating the standard Mh per TC. 6.0 Required Functionality for Component Overhaul Shops 6.1 Maintenance Planning Medium-Term Capacity Planning/ Shop Visit Forecast Based on the shop visit history, but also on removal forecast for scheduled and unscheduled removals, the shop workload to be predicted. The Shop budget and needed capacity to be defined from this data. Maintenance Backlog, Priority Management Based on Aircraft Demand, Manpower and stock level. The Shop/ Workplace backlog to be controlled by priority management. The system shall generate a transparent view about the work orders in the shop with various selection criteria. Generate Repair Order Components to be registered in the Shop will get a Work Order attached. When after cleaning and testing no defect is detected, they leaves the Shop with an serviceable tag and NFF notification to be generated. In the alternate cases the Work Order to be transferred in to a repair order, the defect notification generated and needed consumables requested. Capacity/ Workload Planning Based on the orders in the shop the workload and capacity planning to be performed with standards parameters. Monitor Costs, Monitor Consumed Mh & Spares. The consumed man hours and spars recorded to monitor costs and performance in the shop. Repair Abroad Request If the component repair is not possible in the shop, for various reasons, a request for repair abroad to be generated. LRU Status And Location At any time, the current status and location of an LRU to be displayed. For dispatching an LRU from one location to the next, a transportation request to be generated. This information to be used to locate the LRU. Section H Requirements Compliance Matrix Page 338
LRU Repair Status Notwithstanding there is an in-house repair or an repair abroad request was generated, the actual repair status and an forecast concerning the serviceability is given by the system. Component Exchange Program In case of an exchange program, the complete LRU history to be generated and sent with the component. The history and data of the new LRU to be uploaded automatically by using EDI technology. Scrap Procedure The scrap procedure to be supported by the system. The LRU to be deleted from the system and a valuation adjustment generated. 6.2 Shop Operation Shop-In/ Out Registration All components arriving or leaving the shop to be registered. This to be done by acknowledge the dispatch order (arriving) or generating the dispatch order when the LRU shall leave the shop. Also the repair abroad request to be used for this purpose. Clock-In/ Out, Record MH. The LRU shop order to be used for recording the man hours. The shop order bare code to be used for clocking in and clocking out. Post Consumables To Repair Order. The needed consumable to be posted to the repair order. This is for recording repair costs but also to generate a knowledge base for better future planning. Defect Notification. LRU defects to be described in a defect notification. The data are used for the component reliability report, for production planning and as knowledge base for better future planning. 6.3 Post Shop Maintenance Process Dispatch LRU, Store/ Aircraft After repair/ overhaul a dispatch order to be generated for transporting the LRU to store or to the aircraft. Update LRU Status & Counters After repair, the LRU status and counter information to be updated. This to be done automatically when the repair order to be completed and the serviceable tag to be printed. Print Tracking Tag And Forms Section H Requirements Compliance Matrix Page 339
The system shall generate all needed tags and forms automatically as part of the repair process. 6.4 Component Engineering Update/ Revise CMM. Functionality to be provided to control CMM upload and the revision process. Work Instruction Card Creation/ Update/ Revise Also the work instruction card to be created, updated and revised. SB, AD s Component Modification Processes The component modification process to be supported by the system. Also when a modification campaign is started, a staggering plan for all LRU s to be generated and the mod status of all LRU s to be displayed. The Mod kits to be planned and surplus material to be marked of no longer needed after modification. After modification, the interchangeability to be up-dated. Also the aircraft master parts list to be updated. Archive Documents All working papers to be archived, either for legal purposes or to accomplish the component life record. Component Reliability Report. The component reliability to be reported and analyzed. Define Equivalency Of Chemicals Chemicals used in the shop, the equivalency are to be documented by the system, with the valid reference. This functionality to be available for any user. Section H Requirements Compliance Matrix Page 340
7.0 Required Functionality concerning Quality Assurance 7.1 Auditing Process Define Auditing Program The auditing program defined by Quality Assurance to be mapped in new system. Scheduling Auditing Visit Based on the auditing program a auditing schedule to be developed. In calendar weeks and months the auditing schedule generates a forecast of departments to be audited. Record And Follow Up Non-Compliance The auditing results to be recorded in the system. The items of noncompliance are notified in several categories and a time limit is given for reaching the compliance. Conduct Audit Of Internal And External Units Beside internal audits, also external business partners and vendors to be audited. The audit results to be recorded and a schedule for the next audit to be given. Also non-compliance is recorded and corrective actions demanded. Define Approve Vendor List Approved vendors to be displayed in the approved vendor list. Define Blacklisted Suppliers When business partners and suppliers do not meet the minimum criteria, the supplier to be blacklisted. This information to be noted in the system and shall affect the procurement process. Rate Supplier Quality And Performance. Also performance and supplier quality is recorded upon several criteria. The information will influence the procurement process. Spot Inspections unscheduled inspections at the aircraft to be supported by the system. Discrepancies reported corrective actions requested, the unit/ person to be named for correction. Section H Requirements Compliance Matrix Page 341
8.0 Required functionality concerning Material Management 8.1 Material Planning Upload Readiness Log As a major source for the aircraft configuration the Readiness Log to be uploaded. The functionality support a comfortable automated upload / semiautomatic upload of data notwithstanding is the first A/C of a fleet or a subsequent one. Upload And Maintain Initial Provisioning Data The initial provisioning to be supported by uploading the RSPL file notwithstanding it is the first A/C of a fleet or a subsequent one. A comfortable editing functionality shall support material planner by modifying the recommended and to actual Part Number (P/N) and quantity. Maintain Aircraft Structure/ Location The aircraft master structure and location to be defined. This to be done by uploading the readiness Log, and/ or by editing the master structure. Maintain Material Master Data The material master parts list to be uploaded and edited. Also the interchangeability and the PIA internal master P/N to be defined. Plan Consumable Based On Planning Parameters & Past Consumption Beside the initial provisioning the subsequent material consumption of consumables and repairable to be planned. Functionality shall support this process by providing statistical data concerning past consumptions, calculations based on planning parameters but also an event forecast and the respective routine materials. Calculations concerning the reliability of on condition components and failure rates to be provided. Material Provision For Planned Maintenance. Based on the PIA fleet maintenance forecast for letter checks, material planner shall get all needed information for planning provision of planned and unplanned material. Also the derived from the standard BOM for letter checks budgeting information to be derived for financial planning for future checks. Monitor Consumption And Stock Level Material planner also need information on stock consumption in a given time frame. Based on this and on procurement parameters the reorder level to be defined. The system (ERP) shall provide automated and non automated reordering capabilities. Material Request. Consumables and demanded to requested by the users to be requested by the system. The request shall have several level of urgencies and the expected delivery date. When a material request s handled automatically the service level and the material budget to be updated. Section H Requirements Compliance Matrix Page 342
8.3 Rotable Control (LRU) Plan LRU Float The LRU float to be calculated, based on the net requirements for the fleet, the needed Turn Around Time (TAT) for overhaul and the logistic times. The needed information such as MTBUR to be provided for the float calculation. Control Lifetime The system shall monitor the life time of LRU s and Life Limited Parts (LLP s) no matter if it is an hard time item or to be monitored on condition. If an assay is replaced from the aircraft, all subsequent sub-assay s to be also removed automatically. Component History The complete component history to be tracked and traceable in the system. Working papers to be attached to this information in an electronic format. Component Tracking The actual location to be traced in the system whether it installed in the aircraft, dispatched, at store or in an repair cycle. Shelf Life. Some component may have a shelf life. Those components to be monitored. A report will inform about reaching the end of a shelf life. 8.4 Loan/ Borrowing Administrate Loan Of Parts/ Equipment / Tools When PIA loan parts/ equipment and tools to other airlines, the loan and the return of the goods to be monitored by the system. Administrate Borrowing Of Parts/ Equipment / Tools Also when PIA will borrow parts/ equipment / tools from other airlines. The borrowing and return of the goods to be monitored. The system shall also display LRU s installed in the aircraft on loan basis. Handle Parts On Exchange Basis In case parted to be handled on a exchange program, the component history shall go with the component to the supplier. The exchanged part to be returned shall come with its documentation. The information deleted from the system and transferred to the supplier and received from the supplier and uploaded to the system in an electronic format. Support Component Pooling Concept In case of a component pooling concept. The system shall support exchange parts based on a pooling contract. 8.5 Asset management (ERP only) Define And Categorize Assets Section H Requirements Compliance Matrix Page 343
Major PIA assets such as engines, APU s, Landing Gears to be categorized and treated as major assets. Calculate Asset Value (ERP) As part of the asset management, the actual value of assets to be defined. 9.0 Required Functionality concerning Business Development 9.1 Client Contract Define Client Master Agreement The Client General Agreement with all general terms to be stored in the system. This agreement is the client master document for the client maintenance order. Define Client Maintenance Order The Client Maintenance Order defines the actual terms for the actual client order. The terms could be a fixed price order, based on time and material, a flat rate or on condition. The actual operation and the cost data collection to be mapped with the client orders and the respective terms. Client Contact Details Data Base A client data base shall contain all needed client master data, but also the client history including performed order but also lost proposals in a bidding process. 9.2 Order Management Define Client Order System According To The Contract Terms A client order system according to the contract terms to be defined. The client order covering all relevant sub order to be defined. The sub order are defined related to the various order types such as routine and non-routine maintenance, modifications, defect rectifications, subcontracting, engineering services and others. According to production needs, those orders may have suborders. Alls orders are linked together. Collected data such as MH and consumed materials shall be displayed on each level in the hierarchical order system. Monitor Client Order Progress The progress of the client order to be monitored displaying the order start date and the expected completion date. This to be done also for all sub-orders. Also the consumed MH and materials to be displayed, as well as the subcontract orders. Monitor MH & Parts Costs The MH & consumed parts to be monitored for client orders. This functionality shall ensure and monitor profitability of the client order. Monitor Repair Abroad Costs And Progress Especially for client orders but also for the PIA operation the Repair Abroad Orders to be monitored concerning progress and completion date but also concerning the accumulated costs. Section H Requirements Compliance Matrix Page 344
Order Progress Information Accessible By The Client The client shall have the capability to access via web PIA production system and monitor the progress of his orders 9.3 Proposal Management Define Master Proposal. Proposal Masters are defined and used as text modules for an actual proposal to be submitted. The modules represent the scope of services of PIA Engineering Store Customized Proposal According to the client needs and the PIA Engineering capability a proposal has to be designed. The proposal to be stored in the system, the proposal status to be monitored: such as pre proposal, submitted, in negotiation, agree.. also no longer valid proposal to be kept to follow the client history. The calculation scheme also to be attached to the proposal Monitor Proposal Success Rate Some functionality is needed to monitor the hit rate in the sales process. Capability List A capability list based on fleet, engines and part numbers and the respective activity type to be stored in the system. This is to be displayed to the market, but also used to calculate the scope of service and the costs for subcontracting. 9.4 Profitability Analysis Calculate Client Order Profitability The client proposal is calculated with a particular profitability perception. This is to be monitored during performing the client order. Finally after completion of the client order, the profitability of this order to be calculated. Calculate Complete Client Profitability By maintaining the client relationship, further contracts to be performed by PIA Engineering. A profitability analysis along with the client history to performed. Section H Requirements Compliance Matrix Page 345
Profitability Analysis By Region & Products PIA Engineering Sales and Marketing needs further information for strategic and tactic decisions. For that reasons contract volume and profitability analysis to be performed by region and offered products. Also an analysis concerning the target budget and actual performed volume per region and product to be monitored. 10.0 Required Functionality concerning Power Plant Overhaul 10.1 Production Planning Long-Term Planning Engine/ APU/ Component Shop Visits Based on the LLP, hard time, on condition, engine removals and shop visits to be planned. Also engine condition monitoring (ECM) and defect notification may cause a shop visit. Based on the available information, the first scope of work to be defined. Also the LLP history is needed. Production/ Capacity Planning The planned work load and the available capacity to be balanced according various requirements such as trade and work place capacity. Create/ Update/ Revise Shop Work Sheet In the Engine Shop and Component overhaul master Work Sheets to be created, revised and updated by the system. The system shall provide a library functionality for maintaining and storing the documents. Forward/ Backward Event Planning (Incl. Gantt-Chart) The engine/ landing gear shop visit to be planned on a project chart to show the duration of subsequent steps in a Gantt-Chart. A forward and backward planning to be provided. By getting real time data and feedback by production the chart shall be updated. Tracking & Tracing Repair Abroad Items By sending the piece parts abroad for repair, a tracking and tracing of the parts is requited. This shall be done by using EDI functionality. Create/ Update BOW & BOM The Bill of Work (BOW) and subsequently the Bill of Material (BOM) to be defined in several steps according to the several inspections to be performed. Variants concerning the BOW and BOM is needed. Also a full integration between BOM and the subsequent material planning processes are essential. Available parts locked others to be procured. Engine/ Module Disassemble Management For engine disassembly the as is hierarchical parts list with part number, serial number and mod status to be provided. This list to be provided at the disassembly table to check the as is parts list and mark those parts to be removed from the engine. The parts to be removed, a tag to be provided by the system Section H Requirements Compliance Matrix Page 346
Engine/ Module/ Component Build-Up Control By building-up the engine a new hierarchical parts list to be defined by using disassembly parts list as a master. The new parts to be installed also to be notified in the parts list. A final check to be done by mirroring the new parts list against the former one and check modification status and the compatibility of parts. 10.2 Engine Engineering Modification Status/ Control The engine/ APU/ landing gear/ component modification status to be displayed for a single unit, but also for all P/N within PIA. In case of larger assays also the mod status of all sub-assays until the piece part to be displayed. Modification Management In case a management decision is made for modifications a staggering plan for all units plan to be made and the follow-up modifications similar to the fleet modification to be made. Update/ Revise OEM Manuals Engine/ APU/ Component manuals to be updated and revised equal to the aircraft manuals. Update Engine/APU/ LRU Counters & Status Each unit and also the respective sub-assay to be monitored, the Fh/ cycles/ days counters to be updated along with the aircraft. When the unit to be removed from the aircraft, the counters of the unit and the sub-assay to be kept as well. By installation of a unit into an assay and finally into the aircraft the current counter status to be updated together with the daily aircraft utilization. Update Engine/ APU/ LRU History Any repair or modification to be added to the unit life record should be kept directly out of the production information. The related documents are also attached to the record. Update Serialized Components The master parts list and the As Is parts list including the LLP s to be maintained, kept and updated. Scrap Rejection Certificate Scrap decisions, the reason for defect and the scrap process to be supported by the system. Also the price information to be given for repair and purchase. Archiving Performed Work And All Related Documents. All working documents and certificates to be archived and linked with the related unit. The LLP s and related component history to be updated 10.3 Shop/ Work Place Control Section H Requirements Compliance Matrix Page 347
Work Center Monitoring Production planning shall monitor work load and performance at each work center. The backlog to be displayed. In case of abnormalities corrective actions to be given. Performance Monitoring Of Each Sections Above the work center level, the performance of each section to be monitored. Backlog Priority Management At Work Center A priority management to be available for the work order backlog. Especially the priorities between close loop parts and repair for stock to be well balanced. MH and Machine Hour Recording For each work order, the man hours and machine hours to be recorded by using base code: clock-in and clock-out Tracking & Tracing Parts In The Shop Using the clock-in and clock-out information, parts to be traced and tracked in the workshop by acknowledge arrival & departure of the part at the work center (WC). Shop Finding Reports Defects and discrepancies identified by inspection to be entered in the system. The defect notification shall use a thesaurus, in order to allow statistical analysis. In case of parts the leading discriminator shall be the part number, in other cases the ATA chapter. The defect notification to be used for the reliability management, but shall also trigger the repair or scrap process. Multi Stage Component Routing In case a unit to be overhauled consists of several assays and sub assays, a multi stage routing and component tracking to be available. The system shall provide support to define time limits for each work order to optimize the turn around time of the complete unit. 10.4 Budgeting & Financial Control (ERP) Budget Planning For Engine / APU / Component OH Based on the flight plan and the fleet flight program for the coming year, the engine/ APU component removal rate and the number of the number of shop visits to be defined. Based on these key figures, the needed recourses for spare parts and needed MH for in-house repair and the expected budget for subcontracting repair abroad to be calculated. Repair/ Overhaul Cost Control The repair/ modification of each engine/ APU component to be monitored by posting the spares / subcontracting costs and the consumed MH on the Repair/ overhaul order. Monitor Performance Section H Requirements Compliance Matrix Page 348
The performance of the shop to be monitored by key figures. 11.0 Required Functionality for Tools Managements 11.1Tools Master Data Define Tools, GSE And Figures Locations & Quantity All tools GSE and other units to be registered with location and quantity Define Tools Master Data The master data to be maintained Functionality For Reservation, In-Use, Available A requisition functionality to be in place with availability status and to block the required tool for a period. Transportation Order For Tools A dispatch order to be defined for transport the tools Statistics Concerning Utilization Statistical function for concerning usage of tools. Maintenance Planning Of Tools & Repair Maintenance plan for fools and repairs. Also a repair order to be submitted. 11.2 Calibration of Tools Register Tools All tools to be calibrated to be registered in the system. Schedule Tools Calibration A scheduling functionality to be available for calibration purposes. The forecast for calibration is given to concerned department by providing a report. Report Compliance A calibration report is given and the calibration results are notified. The serviceable or unserviceable status of the tools is marked. This status will have a impact to the tools reservation system. 12 General Requirements of the MRO System 12.1 Ability for Integration with ERP The PIA ERP system will control all major PIA resources. A smooth integration between the ERP, existing application running in PIA and the MRO system is required. Section H Requirements Compliance Matrix Page 349
The following areas for integration are highlighted: Financial Accounting, Financial Control, Budgeting, Purchasing, Logistic, HR. 12.2 MIS & Reporting Key Performance Indicators (KPI) to be reported for all major sections in PIA Engineering on regular basis. The KPI to be defined by PIA. The PIA Engineering Management shall get regular reports concerning the regular and un-regular operation. 12.3 The System will control the day-by-day work All work packages, tasks and business activities will be initiated and controlled by the system. Subsequently all Labels, Orders and Certificates are to be printed by the System. 12.4 Drill down option and flexible reporting From the top to the bottom it must be possible to generate more details if required. From the individual A/C to a BOW, to the individual WP, to the JC and finally to the details of each JC must be possible. Beside a number of regular used reports, a flexible report generator shall prepare reports on occasional basis. Tracing of information Within the system, it should be possible to trace information along a logical path. It should be possible to see a component removal order, follow the PIA intern dispatch order of the part, see the request for proposal, the repair order, the customs clearance, the QA reports, the invoice, the invoice verification process, the final payment posting etc. 12.5 Required Interfaces of the new MRO System The Aircraft log data (Fh, Cyles, Landings) shall be entered at one location at PIA. - Or automated upload of the SITA telex. This shall be done within PIA- Operations. The MRO System shall have an interface for an real time data upload. ACARS shall be used where possible. The Aircraft Rotation Plan shall be available online for PIA-Engineering. LM Production Planning shall actively use the displayed ground time for the medium and short term maintenance task planning. The Aircraft rotation plan will show interactively the planned A/C assignments to routes and the slots maintenance events. Section H Requirements Compliance Matrix Page 350
The Commercial Flight Schedule shall be online available for long and medium term planning. PIA Engineering will request online slots for letter checks (A,B,C,D). PIA Operations will monitor operational performance and A/C dispatch reliability. An online interface will provide the data for PIA Engineering PIA Finance is responsible for the Financial Budget and Financial Accounting. The data are shared with PIA Engineering on online basis for performance monitoring and planning purposes. Automated upload of all OEM manuals, such as AMM, IPC, SRM, EMM, TSM and others using the SPEC 2100 format. Also the incremental revisions shall be up-loaded and linked to respective document content. The Service Bulletins (SB s), AD s, etc shall be automated up-loaded from CD, via Internet access or with direct Internet access. Material Master data shall be up-loaded using the AMTOSS and SPEC 2000 data format. Automated upload and consequent processing of MPD data Upload of the readiness log. Upload of Vendor capability list, price list, availability status and others (ERP) Online request for quotation, delivery terms and others Electronic exchange of agreements, purchase order, delivery/ repair status, invoice, payments. Supported formats shall be EDI, XML, SPEC2000 and others. A international B2B communication platform to be interfaced for exchanging procurement and repair status information. The new System shall support a WEB Portal to provide major information and data for production to an Intranet Web Portal. It is the target, to avoid time consuming and outdated paper based distribution of information. Selected key figures and production plans shall be available on Web Portal by online access of real time data. The system to be ready for RFID applications to be integrated. Also the PIA employee ID card to be read for for employee acknowledgement. The working papers such as Job Cards and parts tags to be printed with barcode. Bare code readers to be integrated for man hour recording and parts tracking. Section H Requirements Compliance Matrix Page 351
SECTION D SERVICES REQUIREMENTS Section H Requirements Compliance Matrix Page 352
D1. Implémentation 1. As part of its proposal, the Bidder must submit an Implementation Strategy and Plan which caters for the following, to be performed by the Bidder: - 1.1 Installation of the Interim Server(s) including the Operating System. 1.2 Installation of all supplied application software, RDBMS software, Development/Query and Report Writer/Database Administration Tools and any other required Utilities, on the Interim Server/s. 1.3 Installation of all supplied application software, RDBMS software, Development/Query and Report Writer/Database Administration Tools and any other required Utilities, on the Permanent Servers. 1.4 Implementation of Database security features 1.5 Development of Business Requirement Document for each functional area, which maps the business process for the parameterization of MRO Package. This document should be based on PIA s reengineered business processes that would be made available to the Contractor. PIA will review and approve this document within ten working days of submission before Contractor can start work on parameterization / configuration of the MRO. 1.6 Development of business case scenarios for testing MRO package. 1.7 Parameterization of supplied Software i.e. the configuration of application software via selection of in-built values, setting up of tables, etc. to meet the business requirements. 1.8 Software modifications, where required, to supplied Application software and development of extensions and/or modules to meet the business requirements. 1.9 Design and development of customized reports, screens, workflows, etc. PIA will try to maximize the use of standard reports, screens and workflows available in the proposed solution; however the Contractor cannot set an upper limit to the number of customization that it will undertake. 1.10 Integration with PIA s other applications such as AIMS, Aeroexchange, forthcoming ERP Package, Corporate e-mail, PIA website, etc. 1.12 Unit, Integration and System testing prior to User Acceptance testing. 1.13 Data conversion activities. Section H Requirements Compliance Matrix Page 353
1.14 Design and implementation of Online and Batch job operational procedures until implementation is successfully completed at all locations. 1.15 Bidder will provide regular progress reports of the project pinpoint obstacles/short comings if experienced well in time. 1.16 Quality Assurance for Bidder related activities. 1.17 Any other tasks required in successful delivery of the supplied products and services. 2. The Contractor must utilize airline industry specific rapid implementation templates to ensure quick implementation. Details of such templates should be submitted with the Technical Proposal. 3. A detailed comprehensive project plan is to be prepared by Contractor and submitted as a part of the proposal. The plan shall be mutually approved and incorporated as part of contract and reviewed at regular intervals. 4. The Contractor must submit a detailed project organization structure identifying, by name, the specific individuals who would be assigned different tasks of this project. The Contractor must assign a full time Project Manager to manage this Project. This person must be from the list of Lead Consultants submitted by the Contractor in response to the EOI. He / she must have the experience of implementing the proposed MRO in at least two airlines. A personnel roster containing detailed responsibilities of Contractor staff who shall be assigned by the Contractor to perform duties or services under the contract should also be provided. The roster should include estimated number of hours to be worked on the project for each person broken down in different phases of the project; it should also clearly identify the start and end dates for each phase. These staff members should be from the list of implementers provided in response to the EOI. If additional members are assigned to the project their detailed CVs should be submitted as part of the proposal. PIA recognizes that occasional substitution of Contractor staff may be necessary after an apparent bid winner is determined and during the project. Staff proposed as substitutes must have qualifications equivalent to or better than those being replaced and must be approved by PIA. 5. The Contractor must submit a detailed Testing Methodology. The Bidder may perform Unit, Integration, and Systems Tests off-site; however, the official Systems Test and all User Acceptance Tests must be performed on-site using PIA s testing environment. 6. The Contractor must provide, by phase, the proposed number of personnel to be based on-site at PIA s premises, and space and other requirements to be provided by PIA during Implementation. 7. The Contractor will develop a system turnover plan which indicates the conditional criteria required to fully turn over the daily operation of the system Section H Requirements Compliance Matrix Page 354
to PIA technical staff. At a minimum, the turnover plan must include the state of readiness required for system turnover and all required documentation. 8. The Contractor s implementation plan must take into consideration the business priority areas and applications. 9. System Performance: During system installation the Bidder will evaluate performance factors including, but not limited to, transaction volumes, response times, CPU utilization, and input/output activity. The Bidder will be responsible for tuning the application to meet acceptable response times. 10. Space and other logistical requirements to be provided by PIA to the Bidder s Implementation Team should be specified. 11. Project Management and Reporting: The Bidder is required to maintain a project plan covering its components of the project and each individual phase. The plan shall include project organization, work break down structures, schedules, critical path determination, and other features required to track and manage this project. 12. Project Quality Management: In its proposal, the Contractor must describe its approach for assuring the quality of its components on this project. The proposal must demonstrate an understanding of the Contractor s ultimate responsibility for quality and define a comprehensive set of reasonable and effective practices for fulfilling that responsibility. Contractor must also specify whether third party audit / quality assurance visits will be undertaken and who will bear the cost of these visits. 13. Acceptance Testing: PIA s Consultant will conduct a rigorous acceptance test of the system. PIA user staff and information system specialists will exercise all system functional aspects using PIA s Consultant-developed test data to assure that the system meets defined business and technical performance requirements. During this test, PIA s consultant will identify required modifications and document them through the problem resolution or change management processes (described below) as appropriate. The Contractor shall modify the system as required and provide new versions of modified components to PIA for testing. PIA will notify the Contractor in writing when it determines that the system is acceptable. 14. Problem Resolution: The Contractor and PIA and PIA s consultant will cooperate to resolve system problems found during acceptance testing and production use, including the warranty period. PIA will prioritize and report problems in a written format. The Contractor shall track these problems to closure and report their status. The Contractor shall evaluate each reported problem, estimate the time needed to resolve the problem, identify potential impacts on the system and the project, and report to PIA. If PIA decides to proceed, the Contractor shall resolve the problem according to its assigned priority. 15. Change Management: PIA s consultant and Contractor will cooperate in managing changes to previously agreed upon system functional capabilities. Section H Requirements Compliance Matrix Page 355
PIA s contractor will identify potential functional changes and propose these to the Contractor in writing. The Contractor shall evaluate each proposal, identify potential impacts on the system and the project timeline, and report to PIA. If PIA decides to proceed, it will prioritize the change and authorize the Contractor in writing to perform the work. The Contractor shall track the status of in-progress change orders and report to PIA upon request. However, cost escalation will not be allowed under any circumstances. 16. Configuration Management: The Contractor shall manage version releases of all contract deliverables and certain other critical documents as determined by PIA. This process shall assure that the status of all deliverables is known, that only approved versions are released for production use, that prior released versions can be recreated, and that changes are made to released deliverables only when authorized by PIA. The final release of each controlled deliverable must reside in a library (preferably computer based) under PIA control. 17. The Bidder must assign a full time Project Manager to manage this Project. His/Her detailed CV including experience of managing MRO and other Projects, MRO Package Certification, if any, the number of MRO projects managed and the number of years on each project, etc. must be submitted along with the Proposal. D2. Training 1 Training is required in three main areas: (a) Technical Support Staff, and (b) System Users and (c) PIA project team member. Technical Support staff will comprise of System Operators, System Administrators, Database Administrators, and Developers. For the System Users, there are three distinct users, Key Users (responsible for System Parameterization), and End Users and Senior Management (who are expected to be provided System Overview). The PIA project team member to be trained at the beginning of the project in the respective module he or she is assigned in. 2 As a part of the proposal, the Bidder must describe in detail its approach to meeting the training requirements for each audience. The description must include methods proposed to deliver both training and documentation. The Contractor should describe the general content of all training materials, training courses, and documentation proposed. 3 The Training Strategy should include a training solution to support the training of end users throughout PIA in the functionality of the various MRO Package and Add-on (if supplied) components. The Bidder will be required to develop formalized classroom training sessions for each of the user groups identified to ensure that the trainees become familiar with all the system features of the implemented applications. In addition, where required, for technical staff, informal training should also be included. The Training Strategy will address, at a minimum, the following: Section H Requirements Compliance Matrix Page 356
a) Description of the Course, the Course outline, specifications of the number and appropriateness of staff who will attend, probable dates of classes, etc. b) Proposed content of all training materials. c) A description of the proposed software / tools (these may include training aids, manuals, on-line references, quick reference guides or templates, or computer based training), and their use during the training. d) Details of the physical locations to be used for training. e) Training evaluation methodology f) The names, qualification and Formal Training experience in manmonths, of the instructors for each training course 4 PIA will prefer the training material on CD s. All training materials provided by the Bidder can be reproduced and used as needed by PIA. a) The cost of Foreign Training, if proposed, should be included in the Bidder s Commercial Proposal and include all expenses related to travel, living and tuition fees. D3. Data Migration 1 The Bidder should include, as a part of its proposal, a Detailed Data Migration Plan which includes description of its general approach to the automated data migration process for historical and cutover data. 2 The Data Migration Strategy must address, at a minimum, the following: Migration overview with objectives, approach, impact, and resources Migration data (source and volume) Migration process (automated or manual, verification procedures) Migration support (system, policy and hardware) Migration schedule Migration preparation task outline 3 The Detailed Migration Plan must address the following tasks: Identify data elements to be migrated. Identify necessary computer processing workloads. Identify any special forms and procedures. Identify any control procedures and evaluation criteria. Identify, with the assistance of the PIA, the personnel needed to participate in the migration of the data. Plan any special training for migration activities. Plan any interim file maintenance requirements. Develop migration programs (This includes specifications, program coding, test plans, and complete testing). Section H Requirements Compliance Matrix Page 357
Present Migration Plan, Procedures, and Programs to PIA for approval. 4 PIA expects the Bidder to perform the following tasks:- Study the existing application and databases. Design and develop a solution including intermediate utility (if any) to migrate the data from existing databases to the new databases. Demonstrate and test this data migration on sample test data from existing live applications. Develop and document all operational and technical areas for above solution D4. Documentation 1 As part of its Technical Proposal, the Contractor must describe the level and types of documentation that will be delivered. This documentation must cover each level of operation, for example: user, security administrator, database administrator, operator, developer, etc. 2 Two complete hardcopy sets of documentation for all Bidder supplied components for this Project must be furnished, in addition to softcopies on CDs. 3 The Manuals should feature clear organization of content, easy to understand language, useful graphic presentations, and a thorough index and glossary. These will under the following categories: Detailed process manuals User manuals Operational manuals 4 These manuals must address the view of the system required by business unit staff (end users). It must contain sufficient information to enable the user to independently operate the system, troubleshoot simple problems, and correct problems. The manual must be able to serve as a reference guide and a teaching aid. It must cover all facets of system functions and operations, including: Complete instructions for the users, completely explaining the use of each system function; System usage scenarios, based on real world examples drawn from the day-to-day workloads of typical users, that fully describe and explain the salient features and operation of the system; How input data are stored and related between system records; How to generate/suppress standard and ad hoc reports; Normal report distribution; Prioritization processing, system determined priorities, and user override procedures; System log-on, log-off, and security features; Error messages and error correction procedures; Help features and usage; Section H Requirements Compliance Matrix Page 358
System troubleshooting; Mandatory data fields and default data values; Traversing system menus; Screen layouts and contents; Inquiry functions 5 In conjunction with the Users Manual, Quick Reference cards will be produced by the contractor, which will be an immediate aid to the user and quickly describe operations. 6 The Technical Manuals must address the view of the system required by developers, administrators and other technical personnel. It should provide an understanding of the application; database design and file structures; relationships between programs, security; troubleshooting; special constraints; and other operational guidelines. 7 Copies of all licenses, warranties, maintenance agreements and similar materials for all Bidder delivered components of the project must be furnished separately. 8 Contractor must submit sample copies of all documents that it will prepare / deliver to PIA during the course of this project. D5. Warranty and Maintenance Support 1 The Bidder will provide warranty services for a period of at least one year for software and a minimum of three years for hardware by ensuring that the system in every way meets the specifications stated in this RFP. The warranty begins upon PIA s written final acceptance of the system. All warranty support services, whether on- or off-site, are to be rendered free-of-charge to PIA; the Bidder shall be responsible for any travel costs associated with warranty support services. The warranty to be also given for the underlying RDBMS. 2 Separate and apart from the warranty support services, the Bidder shall provide support ( Maintenance ) services for Applications, and RDBMS beginning upon the end of the warranty services and extend up to three (3) year thereafter. 3 The Bidder must describe in detail in the Technical Proposal its User and Technical Support Plan for the warranty and maintenance periods, covering the resources, timing and procedures that will be available to provide this support. The plan must include identifications of procedures for on-site and off-site maintenance during normal hours of operation, for: On site fault diagnostic techniques; Remote or tele-diagnostic fault diagnostic techniques; Average time to arrive on-site; Mean time to fix major system components; Section H Requirements Compliance Matrix Page 359
Fault escalation procedures; Maintenance of error logs. 4 The Bidder must specify the various categories of problems it will support and describe the severity levels of problems. The escalation process must assure appropriate management contacts can be made in the event that the support response is not effective. PIA would like to sign a Service Level Agreement (SLA) (that would include penalties for non-performance or poor delivery) for maintenance support with the Contractor. 5 Details of the establishment of an effective Hot Line Telephone and Support Desk service should be provided. Internet enabled support, if available, should be highlighted. 6 PIA may require the Contractor to develop additional customized reports, screens, workflows, etc. during the maintenance and support period. Contractor must specify in its Technical Proposal a solution to accommodate PIA s requirement. The Price Proposal must contain the pricing mechanism for additional development / customization. 7 The Bidder should provide a list of clients for which MRO Package Maintenance Support is, or has been provided during the past three years. Details of the modules supported should be included. D6. Version and Upgrades 1. Contractor must ensure that training material / software / process documents are duly licensed for the purpose of implementation and use by PIA of the MRO. These are to be of latest version and Contractor must ensure upgradation of all modules / material / process documents during the warranty period and as part of after-warranty maintenance support. 2. During the implementation and subsequent rollout Contractor would be responsible to arrange and provide free version upgrades of all components under its responsibility. Contractor must ensure that at the time of handing over the solution to PIA all components are of the latest release and that the total solution is certified by the Contractor for completeness. 3. As part of the software maintenance services to be provided by the vendor, software upgrades and revisions including API and XML enhancements to be delivered at no extra costs to PIA. D7 Information Needs and Application Requirements PIA requires management information systems that support its decision makers by fulfilling their daily information needs and also assisting them in creating different scenarios and providing what-if analysis. Section H Requirements Compliance Matrix Page 360
Some of PIA s operations are centralized at the Engineering department while many are distributed at its various stations both online and offline domestic and international. Contractor must analyze these functions and provide a solution that will best fit this model. The business information needs of PIA have been defined / identified at various levels of governance and management starting with those of its Board of Directors and then of its individual functional areas. 4 Information Requirements of Board of Directors An analysis of the past and present can help set growth targets and make informed decisions with regards to the future direction of PIA. Based on this notion the Board of Directors may want an analysis of operational and financial performance that should also help derive a future prognosis of PIA. The information and analytical demands at this level call for speed and accuracy though less of this information fits a predefined format or structured model. The broad-based information needs of PIA s Board of Directors may be classified as follows: Familiarity with the mission, vision, goals and objectives of PIA to be able to deliberate and decide on its business plans and strategies short-, medium- and long-term Awareness of the trends in the international airline industry to be able to assess its impact on the business of PIA Understanding of the competitive (and investments) scenario in the local, regional and international airline industry to be able to reposition PIA, if necessary Analysis of flight safety, security and performance standards for formulating future strategies Awareness of PIA s current market position vis-à-vis competition Status of ongoing and planned investment projects as well as of other projects that are significant and important to PIA Analysis of the operational and financial well-being and strengths and weaknesses of PIA Attentiveness to the corporate image of PIA in both the local and international markets 5 Information Requirements of Senior Management The Chairman and CEO and other key senior management personnel are responsible for managing the day-to-day operations of PIA. Their information needs pertain to monitoring, controlling and directing the operational and financial management activities of PIA. In disseminating information to management, one needs to avoid information overload. The need is for the right amount of information and at the right time. The information requirements of PIA s management pertain to: Section H Requirements Compliance Matrix Page 361
Close and thorough monitoring of progress on ongoing and planned projects Awareness of inventions, innovations, new markets, new vendors and geographical changes Historical, current and projected status of each activity performing in engineering department. Monitoring of actual expenditures against budgets Assessment of current and future manpower requirements derived from PIA s operating plans and business strategies Evaluation of the strengths and weaknesses of existing manpower resources which among other things assist in determining the training and development needs, management succession planning, etc. Monitoring the status of aircraft maintenance for line and bas maintenance. Tracking fixed assets and materials inventory Section H Requirements Compliance Matrix Page 362
SECTION E PRODUCT REQUIREMENTS (OTHERS) Section H Requirements Compliance Matrix Page 363
E1 RDBMS and Database Administration Tools The Contractor is required to supply the latest version of RDBMS that effectively supports the proposed MRO Package. To this extent certification of MRO manufacturer that the particular version of the RDBMS is supported by the MRO should be provided. 1 Database schema definition, management, query and reporting facilities must be provided. 2 Historical transactions must be maintained by the RDBMS. Facilities for reviewing transactions, multiple transaction roll back and transaction log reporting are required. 3 Database update facilities must include features such as the use of working copies and status reporting on query and update operations. 4 The system must provide locking mechanisms for update and delete operations. 5 The system must maintain concurrent control mechanisms to ensure the correctness of transactions and to detect and resolve deadlocks on the network. 6 The system must support authorization lists and groups for create, read, update and delete. 7 The provision of on-line facilities to manage transactions and overall on-line system performance is desirable. 8 The system must provide users and applications with distribution independence. Users do not need to know where database objects are located. 9 The system must operate in a distributed environment where different nodes of the network run at different functional levels. 10 The system must have the ability to automatically recover and restore the database fully to the last consistent state after a media or system or database failure. 11 The ability to notify users as to what transactions were being processed but not written to the database during a crash is highly desirable. 12 The system should have archive logs and checkpoint facilities and the capability to roll back / undo to any one checkpoint. 13 The system must continue to be available to users during any backup process or alteration of the database schema s and definitions. 14 The system must support one-to-one, one-to-many and many-to-one relationships. Section H Requirements Compliance Matrix Page 364
15 The system must be capable of working in a multi-tier environment, and provide the appropriate tools for partitioning the location of the processing. All tuning must be independent to the user. 16 All information in the database must be represented as values in the table. 17 Null value support (as opposed to empty character strings, blank characters or zero) must be available for all data types. 18 Database recovery must be made in minimum acceptable downtime. Acceptable downtime is to be negotiated and agreed upon 19 RDBMS should have a support for ELT 20 RDBMS should have support for SAN storage and cluster environment 21 Load balancing and failover must be supported to minimize down time 22 RDBMS should support DR sites and automatic standby configurations. It must be capable of operating in the DR environment and support synchronous as well as asynchronous data replication at remote DR site 23 RDBMS should be capable of supporting large amounts of data in terra bytes 24 RDBMS should have support for transmission of data from other new systems as well as exiting legacy systems 25 It should support libraries to enable backup on tape and disk drives 26 It should have support for new firewalls and n-tier network architecture 27 It should have support for OLAP, OLTP and DSS systems For effective monitoring and management of the database, the Contractor is required to provide, as part of its solution, Database Administration Tools that will help database administrators in database monitoring, storage analysis, capacity planning and performance monitoring and including trend analysis, size estimation and table creation. E2 Application Development Tools All application development and maintenance will be carried out on the centrally located development server. The Contractor will be required to propose and supply application development tools, consistent with the proposed MRO package. It is expected that the proposed solution comes with a built-in 4GL development environment tool set. Section H Requirements Compliance Matrix Page 365
E3 Query and Report Generator Tools The Contractor must provide complete query and report generator functionality, preferably within the provided system. The report generator functionality must include a scheduling or production process for routine reporting. The report generator functionality must be robust and oriented to the skills of "average" desktop systems users and should support SQL. Formatting and statistical capabilities such as averaging, multi-level sub-totaling, percent change comparisons, standard mathematical operations and financial calculations is required. Generated reports must be able to be saved in several output formats, at a minimum: MS Word, MS Excel, Text, PDF, HTML and XML. The Contractor must describe its query and report generator systems in detail in the Technical Proposal. E4 Interim Servers and Operating System 1. PIA intends to purchase, the Server hardware and Operating System software required for the MRO Application and Database. 2. PIA s purchase of the required Server Hardware and Operating System software will depend on the selected Contractor s recommended architecture in accordance with details provided in Section E Subsection E4. 3. However, in order to avoid any delay in meeting the Project completion milestone, and to cater for the lead time required by PIA in the procurement process, the Contractor is required, as part of its proposal to provide, without any cost to PIA, an Interim Server and Operating System Software, as follows: 3.1 The Server, (or Servers) will be installed by the Contractor at PIA s Computer Centre. 3.2 The Server(s) will be used for the purpose of configuration of the MRO Package, development of Add-on applications, training of staff, and testing the system. 3.3 All necessary hardware components such as CD-ROM drives, tape drives (for back up purposes), etc. should also be provided on an interim basis. 3.4 Software components, such as RDBMS, Development tools, 3rd party software, etc. provided by the selected Contractor will be initially used on the Interim Server. 4. It is anticipated that the Server(s) will be required for a period of approximately six to nine months from the date of supply of Server Hardware, Operating System Software and MRO Package Software. Section H Requirements Compliance Matrix Page 366
5. Subsequent to PIA purchasing and installing the required Permanent Server Hardware and Operating System software, the Contractor will be required to reinstall all MRO, Add-on applications, RDBMS, database administration tools, application development tools, query / report generating tools, 3rd party software, etc. on the Permanent Server(s). 6. The details of the proposed Interim Server(s) hardware Configuration and Operating System software are to be provided by the Contractor in its proposal. 7. The configuration of these machines should be capable to support the number of users as specified by the Contractor in its plan. 8. In its proposal, the Contractor will provide site specification requirements for the installation and operation of the Interim Server(s). It will be the responsibility of PIA to cater to the prescribed site specifications. 9. PIA - at the end of implementation and rollout - may at its discretion, decide to purchase the interim servers provided by the Contractor. In this regard, the Contractor should, as part of its Price Proposal, separately mention the cost at which it would offer these machines for sale to PIA. However, this cost component should not be added to the total bid price, nor should it be used to calculate the bid bond amount. E5 3 rd Party Software 1. In order to effectively manage and run the complete solution some other 3 rd party software and application programming interfaces (APIs) may also be required to integrate various applications and execute and monitor the complete solution. 2. Contractor will be responsible to ensure that all required 3 rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration tools, disaster recovery and business continuity tools, APIs / interfaces, etc. are made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed MRO solution. 3. It is the responsibility of the Contractor to offer PIA a complete solution in all respects delays or costs arising out of any shortcoming will have to be borne by the Contractor. Section H Requirements Compliance Matrix Page 367
SECTION F BIDDER S QUALIFICATION & EXPERIENCE Section H Requirements Compliance Matrix Page 368
F1. Bidder s Qualifications And Experience Technical Proposals shall provide the following information (referencing the subsections in sequence) to evidence the Bidder s qualifications to deliver the services sought under this RFP: 1. A brief, descriptive statement indicating the Bidder s qualifications and solution to deliver the supply and services sought under this RFP. This should cover at least the following topics: 1.1. MRO solution providers should have verifiable Airline / Aviation references for proposed solution of their MRO package. Minimum two complete verifiable MRO references are to be provided 1.2. Reference based on individual modules shall not be considered towards MRO reference. 1.3. Experience with the relevant target platform(s) and architectural components. 2 A brief description of the Bidder s background and organizational history including: 1.1. Years in business; 1.2. Location of offices and local Infrastructure; 1.3. Form of business (i.e., individual, sole proprietor, corporation, partnership, joint venture, Limited Liability Company, etc). 3 A personnel roster and resumes of key people who shall be assigned by the Bidder to perform duties or services under the contract. The resumes shall detail each individual s title, education, current position with the Bidder, MRO Package Certification and employment history. Bidders must include a brief commentary on each individual s experience and suitability related to the services to be performed. The lead consultants must have sufficient airline experience and completed at least one MRO implementation cycles. The top consultant/ project manager must have sufficient airline experience and completed at least two MRO implementation cycles. Top and lead consultant to be assigned for the complete project duration and must be full time onside at the project location in KHI. Also the other team members must have sufficient airline background and functional knowledge accepted by PIA. 4 Where applicable, a letter from its Principal or Supplier, as the case may be, that it is authorized to represent, acts as agent, and/or provide the products or services required under this RFP. 5 A statement as to whether there is any pending litigation against the Bidder; and if such litigation exists, attach an opinion of counsel as to whether the pending litigation will impair the Bidder s performance in a contract under this RFP. Section H Requirements Compliance Matrix Page 369
6 Documentation of financial responsibility, financial stability, and sufficient financial resources to provide the scope of services (and any related equipment) to PIA in the volume projected and within the time frames required; said documentation shall include: A description of the Bidder organization s size, longevity, client base; A statement as to whether, in the last ten (10) years, the Bidder has filed (or had filed against it) any bankruptcy or insolvency proceeding, whether voluntary or involuntary, or undergone the appointment of a receiver, trustee, or assignee for the benefit of creditors; and if so, an explanation providing relevant details; and Other pertinent financial information by which PIA may reasonably formulate an opinion about the relative stability and financial strength of the Bidder. This information must include the most recent audited financial statement. Last 5 years earnings in IT Projects. 7 The Proposal should provide the following details of each MRO client in tabular form. Client Name and Address Nature of Assignment MRO Package and list of modules implemented Date of Assignment Completion Nature of Client s Business Type of Service provided Contact Person s Name and Contact details. Section H Requirements Compliance Matrix Page 370
SECTION G HARDWARE REQUIREMENTS Section H Requirements Compliance Matrix Page 371
G1 Hardware The Contractor must evaluate and prepare an appropriate configuration to run the proposed MRO solution. PIA is looking for a high-availability solution including servers, clustering design, and disaster recovery recommendations besides maintenance / repair options needed for the associated infrastructure. 1 Contractor should submit details of the proposed configuration, including layout diagram detailing model designation(s), memory size, number of CPUs, type of drives with capacity and counts. 2 The offered solution should comply with the Open Systems Architecture and latest technology trends. 3 The solution should be scalable, both horizontally and vertically. 4 The hardware should be sized keeping in view the operational requirements of the MRO and associated applications. 5 The hardware should be fully capable of hosting the MRO certified database. 6 The hardware must allow each partition of the MRO environment to be isolated in such a way that a software fault in one partition will not have an impact on another partition. 7 All software required for clustering of servers and implementation of DRP should be included in the solution. 8 The solution should be fully supported by the Contractor for not less than ten years from the date of supply. It should remain capable of being supported, upgraded and extended by the Contractor during this period. 9 The solution provided should be accompanied with complete documentation, operating manuals, system diagrams, startup and recovery procedures and all other information required for proper and efficient operation. 10 Contractor should provide all technical material and verifiable benchmarks related to the proposed solution. The hardware should be certified by the MRO principal vendor for the operation of the MRO and be reasonably expected to be certified for future versions of the MRO during the expected life of the hardware. 11 Contractor should provide information on warranties on the equipment and any options regarding warranty extension. Principal s assurance is required for parts availability after expiry of warranty period. 12 The Contractor must provide a thorough and contemporary 3rd party testing software for acceptance and load testing. The testing should be done according to system equipment specifications as well as generally accepted practices. Section H Requirements Compliance Matrix Page 372
13 All test results should be completely documented by the Contractor. Complete test documentation including results of the 3rd party load / stress testing software should be provided to PIA. 14 Based on PIA s high availability requirements, failover design should be based on protecting single point of failure. 15 For high availability on the application layer, the solution should implement log on load balancing between the application servers. It should not need any form of reallocation of resources between servers. The application environment should be sized and designed such that upon failure of an application server (based on single point of failure), minimum degradation of performance is experienced. 16 A Disaster Recovery (DR) design should be provided which provides a seamless, pragmatic DR process. It should integrate within the overall design of the MRO landscape. 17 The DR process should be simple to execute. A step-by-step process and procedure is required to minimize the potential for human error in a time of crisis and disaster. Additionally, the DR design must be easily tested with minimal impact on day-to-day operations. Section H Requirements Compliance Matrix Page 373
SECTION H REQUIREMENTS COMPLIANCE MATRIX Section H Requirements Compliance Matrix Page 374
H1 GLOBAL REQUIREMENTS GENERAL S. No. Detailed below are the global requirements applicable for the entire solution. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Response 1. S = Standard feature available 2. E = Enhancement through Addon / 3 rd party utility 3. N = No / Cannot be provided Nil Remarks Module / standard feature of the proposed solution Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 375
GLOBAL REQUIREMENTS - GENERAL Sr. No. Requirement Response (S / E / N) Remarks 1 Common Characteristics 20.2 Common characteristics are shared by all areas of the MRO Solution 21 Integration 21.1 21.2 Software supports modern best business practices, with data located in one integrated system shared across all organizational units It will also be integrated with future modules using the same development language / platform 22 Configuration 22.1 Software will require minimum software modification to meet its business requirements. It will allow for easy configuration to meet those requirements without changing software code or requiring Add-ons 23 Technology Interfaces Standard application programming interfaces, tools and methodologies that allow future releases to accommodate interfaces without re-programming. A standard approach to interfaces should be employed to avoid multiple, unique 23.1 approaches for different systems. The Bidder will have to ensure, at its own cost, availability of APIs for both its proposed system as well as system running in PIA. Bidder must ensure to provide XML-based APIs wherever these are available. A standard approach to interfaces is 23.2 available to avoid multiple, unique approaches for different systems 24 User Interface 24.1 The system will have a common look and feel across all applications Section H Requirements Compliance Matrix Page 376
Sr. No. 24.2 24.3 24.4 24.5 24.6 24.7 24.8 24.9 GLOBAL REQUIREMENTS - GENERAL Requirement Screen labeling will be available in English Online help will be available for all applications and will allow for customization The system will be accessible using standard personal computer through browser System will allow opening multiple sessions System will allow for switching between different programs without first having to exit from the system. System will allow defining navigational menus that can be created by end-users according to their job requirements Business rules will be incorporated into the system such that the rules are applied at the time information is entered into the system The system will have validation routines / parameters to identify errors, inconsistencies or additional requirements at the time data is entered 25 Security & Authorization 25.1 25.2 25.3 25.4 The system supports multiple levels of security while providing single sign-on facility to the users Individual fields will be protected from unauthorized access Access to certain functions and data will be protected until they are approved by PIA s concerned policy makers Application security will be integrated with database security. Data files / tables will only be accessed through the MRO; direct access through different query languages will not be possible Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 377
Sr. No. 25.5 25.6 25.7 25.8 25.9 25.10 25.11 25.12 GLOBAL REQUIREMENTS - GENERAL Requirement Templates or group functions will be provided to facilitate maintenance Changes in assignment (employee transfers) or termination / retirement will automatically trigger a review of the employee s security privileges Comprehensive logs of transactions and security incidents will be maintained for auditing purposes. System will be capable to maintain audit trails and logs System will provide authorization, authentication, integrity and nonrepudiation facilities for critical transactions Password length and acceptable character combination as per industry standards are supported System will allow setting up of password change frequency and the number of previous passwords that could not be repeated System will force users to change their passwords after pre-defined intervals System will allow secure remote login and will support digital signature and time stamp, etc. 26 Reporting / Inquiry 26.1 26.2 26.3 26.4 The system will include comprehensive inquiry / reporting tools that allow for easy access to authorized data Drill down capability to examine details will be available It will also be possible to create reports that reflect status as of a specified point in time Standard reports will be included to serve as models for customized reporting and to provide for basic functional reports Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 378
Sr. No. 26.5 26.6 26.7 26.8 26.9 26.10 26.11 26.12 26.13 GLOBAL REQUIREMENTS - GENERAL Requirement Report wizards or similar techniques will be available to guide users through report creation The system will be such that reporting activities do not compromise responsiveness of the interactive system Reports will be formatted to print on local PC and LAN attached printers, centralized high-speed printers as well as over internet and intranet It will be possible to deliver fixed reports to users on a pre-determined schedule to be reviewed online, to be retained online or to be printed at the user s discretion System will be able to deliver the reports using its own messaging / workflow engine as well as PIA s email system, Lotus Notes The system will be able to demonstrate useful demographic and forecasting capabilities The system will support text-based, parameterized and wild-card searches System will provide users the ability to develop ad hoc reports at their discretion The system will include a data dictionary or similar provision to allow non-technical users to identify the appropriate data elements for inclusion in their reports 27 Analytic Tools 27.1 PIA desires decision support tools and information bases that are fully integrated with the system to facilitate strategic planning, tactical operations and organization-wide analysis these will be available Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 379
Sr. No. 27.2 27.3 GLOBAL REQUIREMENTS - GENERAL Requirement The system will support the easy movement of data to common packaged PC-based applications such as Microsoft Office The system will be capable of producing what if scenarios to support decisionmaking 28 Communication 28.1 28.2 The system will foster information sharing at all levels of the organization. For example, policy directives and goals will be incorporated into the budget planning process; departments will be able to share purchasing intentions and specifications and best business practices will be readily available for consultation The system will provide a single place for users to quickly access information and updates on organizational news and policies 29 Flexibility 29.1 29.2 The system will be easily reconfigured to respond to changes in business practices, policy directives, organization structure, statutes and regulations Flexibility will extend both to enterprise-wide as well as industry specific practices 30 System Availability 30.1 30.2 30.3 Overall it will be a highly available solution The system will be available for access by authorized personnel from anywhere at any time of the day or night (24 x 7 availability) The system will be equally usable from remote locations as from the Head Office Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 380
Sr. No. GLOBAL REQUIREMENTS - GENERAL Requirement 30.4 Web-based access will be supported 31 Transaction Timing 31.1 31.2 31.3 31.4 The system will support real time operations. Changes to data or the status of processes will be immediately available in the system System operations will not constrain the business processes supported by the system The system will support effective dating for transactions, including both future and retroactive changes. The authority for such transactions will be included in the security capabilities of the system The assignment of a retroactive date will generate the changes required to bring the system up to the current date 32 Online Documentation and Training 32.1 The system will include customizable online documentation and training materials such as context-specific help, search capability, business process documentation and process maps 32.2 Context sensitive help will include: 32.2.1 Menu options 32.2.2 Tabs 32.2.3 Data entry fields 32.2.4 Buttons 32.2.5 Icons 33 Storage / Record Retrieval 33.1 33.2 Record collection and retention is an important organizational requirement. The ability to easily archive, retain and access records is required Records retention procedures will allow information to be stored in a way that can be accessible indefinitely Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 381
Sr. No. 34 System Security 34.1 34.2 34.3 GLOBAL REQUIREMENTS - GENERAL Requirement System provided is secure and meets all standard security requirements i.e. Identification, Authentication, Authorization and Integrity System allows implementation of industry standard security policies and is capable to evolve to meet security challenges Details of the proposed security tools is provided Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 382
H2 GLOBAL REQUIREMENTS TECHNICAL S. No. Detailed below are the technical requirements applicable for the entire solution. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Response 1. S = Standard feature available 2. E = Enhancement through Addon / 3 rd party utility 3. N = No / Cannot be provided Nil Remarks Module / standard feature of the proposed solution Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 383
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 12 New Technology 12.1 The system is designed in such a way that it easily allows the incorporation of new technologies, as they become available 13 Multiple Environments 13.1 13.1.1 13.1.2 13.1.3 13.1.4 The system supports multiple environments. These environments are sufficiently isolated from each other so that operations in one environment do not affect those of another. The environments are as follows: Production all production processing will be performed in this environment Development all development activities including unit and system testing will be conducted in this environment Quality Control / Test after all development, unit and system testing has been completed, this environment will be used for User Acceptance Testing before the system is accepted into production Training for all in-house implementation and post implementation training activities 14 System Performance 14.1 14.2 The system is responsive and available; it supports rapid fail-over or redeployment in the event of problems or planned maintenance. Ninety-nine percent of all fail-over events will take place in less than five minutes Any volume (batch) processing will not interfere with online responsiveness or availability Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 384
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 14.3 System availability figures of the proposed solution are provided. In case various components have different values, these are specifically mentioned. 15 Archive and Purge 15.1 15.2 15.3 16 Recovery 16.1 16.2 16.3 17 17.1 17.2 The system supports periodic archival and purging of unused or obsolete information Archived information is available for historical reporting in such a manner that queries can be performed on archived data using automated data retrieval functions A complete data archival plan is provided The system automatically recovers to the last complete prior transaction in the event of a failure The system clearly indicates to the user that a transaction failed and that it must be re-entered. Recovery occurs without operator intervention Contingency and backup recovery procedures with guaranteed Service Level Agreements (SLAs) have been provided Backup / Recovery and Reorganization The system provides for the unattended daily backup of all information and data to a media that can be stored offsite for disaster recovery purposes System supports different types of backups such as: 17.2.1 Full backup 17.2.2 Incremental backup 17.2.3 Online backup Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 385
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 17.2.4 Offline backup 17.3 17.4 17.5 17.6 Backups do not prevent the system from being available at all times and do not disrupt system operations There is no performance degradation during data backup Database reorganizations do not significantly impair system availability The calculation of time taken to backup data with respect to data size increase has been provided. 18 Print Management 18.1 The system provides a method for managing the print environment for report distribution so that reports are directed to the appropriate print facility. It caters to both high speed centralized printing facilities as well as local LANbased printing facilities that will be employed in addition to printing over internet / intranet 19 Fallback Solution 19.1 System Should support functionality, if system or parts of the system is not operative, a manual or semi-manual fallback solution to be developed, to continue the MRO operation. After restart of the system. It must be possible to update the system accordingly. 20 Ability for system and license updates 20.1 Provided MRO Package s customization or modification shall be ready for any future updates. This guarantee shall also be given for any underlying software such as RDBMS, Operating System, Network Management and other tools. 21 Technology Architecture Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 386
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 21.1 21.1.1 Recommendations of the technology architecture under which the proposed MRO Package will operate are provided, with the following features preference: N-tiered Client/Server architecture incorporating thin presentation-logicclient communicating with clientneutral, server-based applications, communicating with the database 21.1.2 Thin client, for remote users 21.1.3 21.1.4 21.2 21.2.1 TCP/IP 21.2.2 DHCP 21.2.3 WINS 21.2.4 DNS 21.2.5 NetBEUI 21.2.6 LDAP 21.2.7 FTP 21.2.8 DLC 21.3 Applications distributed at servers located at Head Office Centralized database, located at Head Office Able to support different network based services / protocols such as: System is able to support open specifications for APIs / middleware applications such as: 21.3.1 COM / DCOM 21.3.2 CORBA 21.3.3 RMI 21.3.4 ALE 21.3.5 MQ Series Link 21.3.6 OLE / COM2 Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 387
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 21.3.7 ODBC 21.4 21.4.1 HTTP 21.4.2 XML 21.5 21.5.1 SMP 21.5.2 MPP It is able to integrate with Internet technologies such as: Scalable architecture is supported, such as: 21.5.3 Clustering 21.6 21.6.1 21.6.2 21.6.3 21.6.4 21.6.5 21.6.6 21.6.7 21.6.8 While designing the technology architecture, the following are kept under consideration: Solution is scalable with complete platform independence without tying down PIA to a single platform Solution is effortlessly portable from one system to another It provides support for different flavors of UNIX; however it is a totally interoperable solution There is open source support. In this context, the current scenario vis-à-vis the solution offered and the future roadmap are provided Optimization of licensing costs for the platform software PIA s existing Local and Wide Area Network, and minimization of Wide Area Network bandwidth requirements Simplicity of System Administration and Operations Ease of business continuity planning and execution 22 Server Hardware Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 388
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 22.1 22.2 22.3 22.4 22.5 22.6 23 23.1 23.1.1 23.1.2 The recommended configuration caters for the existing load as well as annual volume growth of 10-15% for the next five years The configuration is capable of retaining data for at least eleven years (that is, current year plus ten years historical record) The solution is redundant, reliable and consistently available to allow uninterruptible 24x7 operations The production server configuration includes redundant (RAID5) data storage and multiple processors and caters for compatibility with PIA s existing LAN / WAN environment The areas of performance and scalability, reliability and fault tolerance while recommending Server configurations have been taken into consideration Performance guarantees of the solution under different scenarios such as concurrent users during normal working, during data backup, during overload, during partial system failure, etc. have been provided System and Network Management Tools Suitable Systems and Network Management Tools have been recommended. These tools will ensure proper planning, configuration, and problem handling of IT resources and support such tasks as: defining, resolving, and managing problems operating networks and multi-vendor systems Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 389
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 23.1.3 distributing and managing software and data 23.1.4 controlling operations 23.1.5 planning and managing performance 23.1.6 administering security 23.1.7 maintaining asset information 23.1.8 planning for the future capacity of systems 13 Data Support 13.1 13.2 13.3 The solution will support multiple data types text, image, voice, etc. The system will support data upload to and download from different systems in multiple formats Besides simple upload / download facility it will also communicate and support data interchange with mobile devices such as: 13.3.1 cellular phones 13.3.2 handheld terminals 13.3.3 PDAs, etc. 13.4 13.4.1 Scanners System will support other devices such as: 13.4.2 barcode readers 13.4.3 biometric devices 13.4.4 card readers 13.4.5 RFID devices, etc. 13.5 13.5.1 Support for important messaging / data formats / standards will include, as a minimum: Aircraft Communication Addressing and Reporting System (ACARS) 13.5.2 SITATEX Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 390
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 13.5.3 ASCII 13.5.4 EDI 13.5.5 SMS 13.5.6 XML 13.5.7 Spec 2010 13.5.8 UNeDocs 13.5.9 MS-Office 13.5.10 Lotus Notes, etc. 14 System Security 14.1 The system supports authentication methods that will assure that only authorized users are able to access protected data and transactions 14.2 These include support for: 14.2.1 digital signatures 14.2.2 PKI infrastructure 15 Web-enablement 15.1 The proposed system is Internet ready and allows web-enabled access to users from anywhere across the world through a web portal 15.2 The system is compliant with the Service Oriented Architecture (SOA) 35 Workflow 35.1 The proposed system will provide Workflow functionality to users by which information and requests could be automatically routed to the concerned levels for approval 36 Others 36.1 Some other requirements include: 36.1.1 Supporting multi currency 36.1.2 Supporting multi languages 36.1.3 Supporting multiple legal companies Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 391
GLOBAL REQUIREMENTS TECHNICAL S. No. Requirement 36.1.4 Supporting multiple tax structures (that is, supporting individual country tax structure and reporting) 36.1.5 Interfacing with legacy systems 36.1.6 Storing transactions and balances of legacy systems 36.1.7 Supporting user defaults 36.1.8 Supporting user defined screens 36.1.9 Supporting multiple date formats 36.1.10 Supporting multiple decimal formats in amounts simultaneously 36.1.11 Supporting user defined fields 36.1.12 Scheduling of jobs for unattended operations 36.1.13 Maintaining effective dates of master file data Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 392
H3 GLOBAL REQUIREMENTS OTHERS Detailed below are other global requirements applicable for the entire solution. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: S. No. Response Remarks 1. S = Standard feature available 2. E = Enhancement through Addon / 3 rd party utility 3. N = No / Cannot be provided Nil Module / standard feature of the proposed solution Description of Add-on / Utility and the time required to configure / develop / implement it. In such cases Contractor has to ensure that appropriate costs have been incorporated in the Commercial Proposal In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 393
6 S. No. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 GLOBAL REQUIREMENTS - OTHERS Requirement RDBMS AND DATABASE ADMINISTATION TOOLS Database schema definition, management, query and reporting facilities provided Historical transactions will be maintained by the RDBMS. Facilities for reviewing transactions, multiple transaction roll back and transaction log reporting are available Database update facilities include features such as the use of working copies and status reporting on query and update operations. The system provides locking mechanisms for update and deletes operations. The system maintains concurrent control mechanisms to ensure the correctness of transactions and to detect and resolve deadlocks on the network. The system supports authorization lists and groups for create, read, update and delete There is a provision of on-line facilities to manage transactions and overall on-line system performance. The system provides users and applications with distribution independence. Users do not need to know where database objects are located. The system operates in a distributed environment where different nodes of the network run at different functional levels. The system has the ability to automatically recover and restore the database fully to the last consistent state after a media failure. Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 394
S. No. 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 GLOBAL REQUIREMENTS - OTHERS Requirement The ability to notify users as to what transactions were being processed but not written to the database during a crash is available. The system has checkpoint facilities and the capability to roll back / undo to any one checkpoint. The system will continue to be available to users during any backup process or alteration of the database schema s and definitions. The system will support one-to-one, oneto-many and many-to-one relationships. The system is capable of working in a multi-tier environment, and provides the appropriate tools for partitioning the location of the processing. All tuning will be independent to the user. All information in the database is represented as values in the table. Null value support (as opposed to empty character strings, blank characters or zero) is available for all data types. Database recovery will be made in minimum acceptable downtime. Acceptable downtime will be negotiated and agreed upon 6.19 RDBMS has a support for ELT 6.20 6.21 6.22 RDBMS has support for SAN storage and cluster environment Load balancing and failover are supported to minimize down time RDBMS will support DR sites and automatic standby configurations. It will be capable of operating in the DR environment and support synchronous as well as asynchronous data replication at remote DR site Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 395
S. No. 6.23 6.24 6.25 6.26 6.27 7 7.1 8 8.1 8.2 8.3 8.4 GLOBAL REQUIREMENTS - OTHERS Requirement RDBMS will support large amounts of data in terra bytes RDBMS will have support for transmission of data from other new systems as well as exiting legacy systems It will support libraries to enable backup on tape and disk drives It have support new firewalls and n-tier network architecture It will support OLAP, OLTP and DSS systems APPLICATION TOOLS DEVELOPMENT The proposed solution has a built-in 4GL development environment tool set QUERY AND REPORT GENERATOR TOOLS The report generator functionality includes a scheduling or production process for routine reporting The report generator functionality supports Structured Query Language (SQL) It also supports industry standard report generators such as Crystal Reports, Business Objects, etc. Report generator has formatting and statistical capabilities such as: 8.4.1 Averaging 8.4.2 Multi-level sub-totaling 8.4.3 Percent change comparisons 8.4.4 Standard mathematical operations 8.4.5 Financial calculations 8.5 Generated reports are able to be saved in several output formats, such as: 8.5.1 MS Word Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 396
S. No. 8.5.2 MS Excel 8.5.3 Text 8.5.4 PDF 8.5.5 HTML 8.5.6 XML GLOBAL REQUIREMENTS - OTHERS Requirement 9 INTERIM SERVERS 9.1 Specifications are provided for interim servers that will be used for MRO configuration, add-on software development, user training, etc. 9.2 All necessary hardware components are also provided 9.3 The configuration of these machines will support the number of users as specified in the plan. 10 3 RD PARTY SOFTWARE 10.1 All required 3rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration tools, disaster recovery and business continuity tools, APIs / interfaces, etc. will be made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed MRO solution. 10.2 A complete solution in all respects has been offered to PIA delays or costs arising out of any shortcoming will be borne by the Contractor. Response (S / E / N) Remarks Section H Requirements Compliance Matrix Page 397
H4 FUNCTIONAL REQUIREMENTS MRO SOLUTION Detailed below are the functional requirements applicable for MRO. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: S. No. Response Remarks 1. S = Standard feature available Module / standard feature of the proposed solution 2. E = Enhancement The required functionality can be developed by the build-in 4th GL or the report generator. Future releases of the provided system are not affected. 3. M = Modification The required functionality to be developed by modifying the system source code. Future releases of the proposed solution are not ensured. 4. N = No / Cannot be provided Nil In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. In case there is a remark ERP only or ERP, this requirement is just for information and is a requirement for the forthcoming ERP system. Section H Requirements Compliance Matrix Page 398
1.0 Functional Requirement concerning Aircraft Engineering 1.1 MPD Process Read new MPD version/ automated upload Maintain new version and get approval Optimize MPD items Release MPD to service Define MEL 1.2 Reliability Management Reliability Report, A/C, Chapter, Engine, Component Dispatch Reliability NFF Reports MTBUR Replacements Engine, APU performance Monitor ETOPS, RVSM compliance Monitor CofM, CofA renewal & reporting Flight incidents, Pilot Reports Aircraft utilization 1.3 Document Management Upload OEM Manuals Upload and register SB s Revise aircraft manuals Distribute manuals Maintain PIA Manuals 1.4 Task Card Management Upload OEM TC Update/ modify TC Copy & past of procedures from AMM Release Master TC for service 1.5 Modification Process Evaluate & approve SB, AD Create Engineering Order Status Fleet Modification Status Engine/ Component Modification Planning & staggering Fleet Modifications List of performed SB s Configuration control 2.0 Functional Requirements for Aircraft Induction and Phase out Resp onse S/E/ M/N Resp onse S/E/ Remark Remark Section H Requirements Compliance Matrix Page 399
2.1 Aircraft master data Create aircraft/ engine master data Create aircraft/ engine master structure & locations Enter flown flight hours, block hours, landings cycles, days M/N 2.2 Initial data entry Initial provisioning, upload RSPL Upload and maintain readiness log Upload A/C, engine, component history Upload MPD, MEL Upload Tech. Log, MEL status, Open defects Upload modification status Maintain status/ letter checks performed 2.3 Aircraft phase out Create Readiness Log Create Mod Status Create Maintenance Status Create Tech. Log, MEL status, Deferred Defects 2.4 Engine Change Remove & extract complete data set Upload complete data set 3.0 Functional Requirements for Line Maintenance 3.1 Line Maintenance Planning Long/ medium-term planning (summer/winter/hajj) Short-term planning Work load/ capacity planning Hangar/ A/C visit plan Assign Work Package to Work Center/ Shift/ individual staff Dispatch spares, tools, documentation to line station Stagger aircraft modifications (line & base) Aircraft arrival/ Departure plan Provision of line stations 3.2 Scheduled Maintenance Bill of Work (BOW) Resp onse S/E/ M/N Remark Section H Requirements Compliance Matrix Page 400
Bill of Material (BOM) Needed Tools and Equipment Execute Work Package and Task Cards Schedule Major component change (MIC) Release A/C to service Shift hand over LRU software update 3.3 Unscheduled Maintenance Record defects und corrective action Trace deferred defects Indicate MEL items 3.4 Post Maintenance Process Update A/C, component records Report performed tasks Archive task cards 4.0 Functional Requirements for Cabin Maintenance 4.1 Maintenance Planning Define/ update a maintenance program for CM, but also for A/C exterior cleaning. Define Instruction cards for CM Plan CM according the maintenance program Plan capacity according to work load According to the maintenance schedule, the capacity to be assigned. 4.2 Customer Feedback Interface to customer complaint system Do corrective action Statistics according customer feedback 4.3 Unscheduled Maintenance Record defects from CBL or inspection und report Trace deferred defects Indicate MEL items 5.0 Functional Requirements for Base Maintenance Resp onse S/E/ M/N Resp onse S/E/ Remark Remark Section H Requirements Compliance Matrix Page 401
5.1 Base Maintenance Planning Long/ medium-term check planning Base Maintenance Events Work Package Management Job Card creation/ update/ revise Hangar/ A/C visit plan Work Load Planning Event project planning with flow charts and mile stones Forward/ Backward event planning (incl. Gantt-Chart) Progress monitoring, monitor costs Monitor consumed MH & spares M/N 5.2 Base Maintenance Operation Interface deferred defects from LM Shop floor data collection Entering snags, planning rectification Shift hand over 5.3 Post Maintenance Process Transfer defect to LM Update A/C configuration & counters Archive documents 6.0 Functional Requirements for Component Overhaul 6.1 Maintenance Planning Medium-term capacity planning/ Shop visit forecast Maintenance backlog, priority management based on aircraft demand, manpower and stock level Generate Repair & Regular Maintenance Order Capacity/ workload planning Monitor costs, monitor consumed MH & spares Repair Abroad Request LRU status and location LRU repair status Component exchange program Scrap procedure Maintain Component Capability List Resp onse S/E/ M/N Remark Section H Requirements Compliance Matrix Page 402
6.2 Shop Maintenance Operation Shop-In/ Out registration Clock-in/ out, record MH. Post all types of parts to repair order. Defect notification & repair procedure. 6.3 Post Shop Maintenance Process Dispatch LRU, store/ aircraft Update LRU status & counters & subassy Print tracking tag and forms 6.4 Component Engineering Update/ revise CMM. Work Instruction Card creation/ update/ revise. SB s, AD s Component modification process Archive documents Component reliability report Define equivalency of chemicals 7.0 Functional Requirements for Component Overhaul 7.1 Auditing Process Define auditing program Scheduling auditing visit Record and follow up Non-Compliance Conduct audit of internal and external units Define approve vendor list Define blacklisted suppliers Rate supplier quality and performance. Spot inspections 8.0 Functional Requirements for Material Management 8.1 Material Planning Upload readiness log Upload and maintain initial provisioning data Maintain Aircraft structure/ location Maintain Material Master data Plan consumable based on planning parameters & past consumption Material provision for planned Resp onse S/E/ M/N Resp onse S/E/ M/N Remark Remark Section H Requirements Compliance Matrix Page 403
maintenance Monitor consumption and stock level Material request functions 8.2 Rotable Control (LRU) Plan LRU float Control lifetime Component history Component tracking Shelf life. 8.3 Loan/ Borrowing Administrate loan of parts/ equipment / tools Administrate borrowing of parts/ equipment / tools Handle parts on exchange basis Support component pooling concept 8.4 Asset management (ERP only) Define and categorize assets Calculate asset value 9.0 Functional Requirements for Business Development 9.1 Client Contract (ERP only) Define Client Master Agreement Define Client Maintenance Order Client Contact Details data base 9.2 Order Management Define Client Order System according to the contract terms Monitor client Order Progress Monitor MH & parts costs Monitor Repair abroad costs and progress Order progress information accessible by the Client 9.3 Proposal Management Define master proposal Store customized proposal Monitor proposal success rate Capability list 9.4 Profitability Analysis (ERP only) Calculate client order profitability Calculate complete client profitability, profitability analysis by region & Resp onse S/E/ M/N Remark Section H Requirements Compliance Matrix Page 404
products 10.0 Functional Requirements for Power Plant Overhaul 10.1 Production Planning Long-term planning Engine/ APU/ Component shop visits Production/ capacity planning Create/ update/ revise Shop Work Sheet Forward/ Backward event planning (incl. Gantt-Chart) Tracking & tracing repair abroad items Create/ update BOW & BOM Engine/ module disassemble management Engine/ module/ component build-up control 10.2 Engine Engineering Modification status/ control Modification management Update/ revise OEM manuals Update Engine/APU/ LRU counters & status Update Engine/ APU/ LRU history Update serialized components Scrap rejection certificate Archiving performed work and all related documents 10.3 Shop/ Work Place Control Work center monitoring Performance monitoring of each sections Backlog priority management at Work Center MH and Machine hour recording Tracking & tracing parts in the shop Engine/module teardown management Shop finding reports Multi stage component routing 10.4 Budgeting & Financial Control (ERP only) Budget planning for Engine/ APU/ Component OH Repair/ overhaul cost control Monitor performance Resp onse S/E/ M/N Remark Section H Requirements Compliance Matrix Page 405
11.0 Functional Requirements for Tools and Equipment 11.1 Tools Master data Define tools, GSE and figures locations & quantity Define tools master data Functionality for reservation, in-use, available Transportation order for tools Statistics concerning utilization Maintenance planning of tools & repair Resp onse S/E/ M/N Remark 11.2 Calibration of tools Register tools Schedule tools calibration Report compliance 12.0 General Functional Requirements of the MRO System 12.1 Ability for Integration with ERP The PIA ERP system will control all major PIA resources. A smooth integration between the ERP, existing application running in PIA and the MRO system is required. The following areas for integration are highlighted: Financial Accounting, Financial Control, Budgeting, Purchasing, Logistic, HR. 12.2 MIS & Reporting Key Performance Indicators to be reported for all major sections in PIA Engineering on regular basis. The KPI to be defined by PIA. The PIA Engineering Management shall get regular reports concerning the regular and un-regular operation. 12.3 The System will control the day-by-day work All work packages, tasks and business Resp onse S/E/ M/N Remark Section H Requirements Compliance Matrix Page 406
activities will be initiated and controlled by the system. Subsequently all Labels, Orders and Certificates are printed by the System. 12.4 Drill down option and flexible reporting From the top to the bottom it must be possible to generate more details if required. From the individual A/C to a BOW, to the individual WP, to the JC and finally to the details of each JC must be possible. Beside a number of regular used reports, a flexible report generator shall prepare reports on occasional basis. Tracing of information Within the system, it should be possible to trace information along a logical path. It should be possible to see a component removal order, follow the PIA intern dispatch order of the part, see the request for proposal, the repair order, the customs clearance, the QA reports, the invoice, the invoice verification process, the final payment posting etc. 12.5 Flexibility Organizational changes shall be easily addressed in the System by reconfiguration. In case of outsourcing parts of the production (e.g. Base Maintenance, Engine OH), the system shall be able to be customized accordingly. 12.6 Required Interfaces of the new MRO System The Aircraft log data (Fh, Cyles) shall be entered at one location at PIA. - Or automated upload of the SITA telex. This shall be done within PIA- Operations. The MRO System shall have an interface for an real time data upload. ACARS shall be used where possible. The Aircraft Rotation Plan shall be available online for PIA-Engineering. LM Production Planning shall actively use the displayed ground time for the medium and short term maintenance task planning. The Aircraft rotation plan will Section H Requirements Compliance Matrix Page 407
show interactively the planned A/C assignments to routes and the slots maintenance events. The Commercial Flight Schedule shall be online available for long and medium term planning. PIA Engineering will request online slots for letter checks (A,B,C,D). PIA Operations will monitor operational performance and A/C dispatch reliability. An online interface will provide the data for PIA Engineering PIA Finance is responsible for the Financial Budget and Financial Accounting. The data are shared with PIA Engineering on online basis for performance monitoring and planning purposes. Automated upload of all OEM manuals, such as AMM, IPC, SRM, EMM, TSM and others using the SPEC 2100 format. Also the incremental revisions shall be up-loaded and linked to respective document content. The Service Bulletins (SB s), AD s, etc shall be automated up-loaded from CD, via Internet access or with direct Internet access. Material Master data shall be up-loaded using the AMTOSS and SPEC 2000 data format. Automated upload and consequent processing of MPD data Upload of the readiness log. Upload of Vendor capability list, price list, availability status and others (ERP) Online request for quotation, delivery terms and others Electronic exchange of agreements, purchase order, delivery/ repair status, invoice, payments. Supported formats shall be EDI, XML, SPEC2000 and others. A international B2B communication platform to be interfaced for exchanging procurement and repair status information. The new System shall support a WEB Portal to provide major information and data for production to an Intranet Web Portal. It is the target, to avoid time Section H Requirements Compliance Matrix Page 408
consuming and outdated paper based distribution of information. Selected key figures and production plans shall be available on Web Portal by online access of real time data. The system to be ready for RFID applications to be integrated. Also the PIA employee ID card to be read for for employee acknowledgement. The working papers such as Job Cards and parts tags to be printed with barcode. Bare code readers to be integrated for man hour recording and parts tracking. Section H Requirements Compliance Matrix Page 409
H5 SERVICES REQUIREMENTS Detailed below are the services requirements. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Sr. No. 1. Y = Yes 2. Response N = No / Cannot be provided Remarks Details of how the services would be provided Nil In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 410
Sr. No. SERVICES REQUIREMENTS Requirement 7 IMPLEMENTATION 7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 An Implementation Strategy has been submitted that covers: Installation of the Interim Server(s) including the Operating System. Installation of all supplied Application software, RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Interim Server(s). Installation of all supplied Application software, RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Permanent Servers. Implementation of Database security features Development of Business Requirement Document for each functional area which maps the business process for the parameterization / configuration of MRO Package. This document will be based on PIA s reengineered business processes provided by PIA. 7.1.6 Development of business case scenarios 7.1.7 7.1.8 Parameterization of supplied Software i.e. the configuration of application software via selection of in-built values, setting up of tables, etc. to meet the business requirements. Software modifications, where required, to supplied Application software and development of extensions and / or modules to meet the business requirements. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 411
Sr. No. 7.1.9 7.1.10 7.1.11 7.1.12 7.1.13 7.1.14 7.1.15 7.1.16 7.1.17 7.2 7.3 7.4 SERVICES REQUIREMENTS Requirement Integration with PIA s other applications such as Sabre, AIMS, SITA Cargo, Aero-Exchange, Forthcoming ERP solution, QUASAR, Recipe Management, Corporate e-mail, PIA website, etc. Design and development of customized reports, screens, workflows, etc. There is no upper limit to the customization that will be undertaken Design, development and initial set up of databases. Testing Strategy. Unit, Integration and System testing prior to User Acceptance testing. Data migration activities. These include preparation of data migration strategy and plan and undertaking data migration activities based on the plan Design and implementation of Online and Batch job operational procedures until implementation is successfully completed at all locations. Progress reporting on Contractor related activities. Quality Assurance for Contractor related activities. Any other tasks required in successful delivery of the supplied products and services. Airline industry specific rapid implementation templates will be utilized to ensure quick implementation. Details of such templates are submitted with the Technical Proposal A detailed comprehensive project plan is prepared and submitted as a part of the proposal. A detailed project organization structure has been submitted: Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 412
Sr. No. 7.4.1 7.4.2 7.4.3 7.4.4 7.5 7.6 SERVICES REQUIREMENTS Requirement Identifying the specific individuals who would be assigned different tasks of this project. Assigning a full time Project Manager to manage this Project. This person is from the list of Lead Consultants submitted by the Contractor in response to the EOI. He / she has the experience of implementing the proposed MRO in at least two airlines. Containing a personnel roster containing detailed responsibilities of Contractor staff assigned to perform duties or services. The roster includes estimated number of hours to be worked on the project for each person broken down in different phases of the project clearly identifying the start and end dates for each phase. These staff members are from the list of implementers provided in response to the EOI. Substitutes to the nominated staff will have qualifications equivalent to or better than those who will be replaced. A system turnover plan will be developed that will indicate the conditional criteria required to fully turn over the daily operation of the system to PIA technical staff. At a minimum, the turnover plan will include the state of readiness required for system turnover and all required documentation. During system installation the Contractor will evaluate performance factors including, but not limited to, transaction volumes, response times, CPU utilization, and input / output activity. The Contractor is responsible for tuning the application to meet acceptable response times. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 413
Sr. No. 7.7 7.8 7.9 7.10 7.11 SERVICES REQUIREMENTS Requirement The Contractor will conduct a Capacity Test that will include stress and volume testing. Capacity testing shall include a stress test that includes simulation of at least 30% of the system workload and volume tests that test the database activity against at least 30% of the data volume. The Contractor will document, the conclusions resulting from the test. The Contractor will maintain a project plan covering its components of the project and each individual phase. The plan shall include project organization, work break down structures, schedules, critical path determination, and other features required to track and manage this project. The Contractor will prepare and submit weekly progress reports to PIA on each component of the Project under which it is responsible. The Contractor has described its approach for assuring the quality of its components on this project. Contractor has also specified whether third party audit / quality assurance visits will be undertaken and who will bear the cost of these visits. The Contractor will manage version releases of all contract deliverables and certain other critical documents as determined by PIA. 8 TRAINING 8.1 8.2 8.3 Training Strategy has been submitted as part of the Technical Proposal It describes in detail the approach to meeting the training requirements for each type of audience The general content of all training materials, training courses, and documentation proposed has been described in the Technical Proposal Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 414
Sr. No. SERVICES REQUIREMENTS Requirement 9 DATA MIGRATION 9.1 9.2 9.2.1 A description of the general approach to the data migration process (manual and automated) for historical and cutover data has been provided. Migration approach / strategy addresses the following: Migration overview with objectives, approach, impact, and resources 9.2.2 Migration data (source and volume) 9.2.3 9.2.4 Migration process (automated or manual, verification procedures) Migration support (system, policy and hardware) 9.2.5 Migration schedule 9.2.6 Migration preparation task outline 9.3 Migration Plan addresses the following tasks: 9.3.1 Identify data elements to be migrated. 9.3.2 9.3.3 9.3.4 9.3.5 9.3.6 9.3.7 9.3.8 9.3.9 Identify necessary computer processing workloads. Identify any special forms and procedures. Identify any control procedures and evaluation criteria. Identify, with the assistance of the PIA, the personnel needed to participate in the migration of the data. Plan any special training for migration activities. Plan any interim file maintenance requirements. Develop migration programs (this includes specifications, program coding, test plans, and complete testing). Present Migration Plan, Procedures, and Programs to PIA for approval. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 415
Sr. No. SERVICES REQUIREMENTS Requirement 10 DOCUMENTATION 10.1 10.1.1 10.1.2 10.1.3 10.1.4 Contractor will provide user manuals that will cover as a minimum the following: Complete instructions for the users, completely explaining the use of each system function; System usage scenarios, based on real world examples drawn from the day-today workloads of typical users, that fully describe and explain the salient features and operation of the system; How input data are stored and related between system records; How to generate / suppress standard and ad hoc reports; 10.1.5 Normal report distribution; 10.1.6 10.1.7 10.1.8 Prioritization processing, system determined priorities, and user override procedures; System log-on, log-off, and security features; Error messages and error correction procedures; 10.1.9 Help features and usage; 10.1.10 System troubleshooting; 10.1.1 Mandatory data fields and default data values; 10.1.12 Traversing system menus; 10.1.13 Screen layouts and contents; 10.1.14 Inquiry functions 10.2 10.2.1 Contractor will provide technical manuals that will cover as a minimum the following: Addresses the view of the system required by developers, administrators and other technical personnel. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 416
Sr. No. 10.2.2 10.3 11 11.1 11.2 11.3 SERVICES REQUIREMENTS Requirement Provides an understanding of the application; database design and file structures; relationships between programs, security; troubleshooting; special constraints; and other operational guidelines Contractor has submitted sample copies of all proposed documents that it will prepare / deliver to PIA during the course of this project. WARRANTY AND MAINTENANCE SUPPORT Contractor will provide warranty services for a period of three years by ensuring that the system in every way meets the specifications stated in this RFP Separate and apart from the warranty support services, the Contractor shall provide support ( Maintenance ) services for Applications, and RDBMS beginning upon the end of the warranty services and extended up to three (3) year thereafter Contractor has provided its User and Technical Support Plan detailing the following: 11.3.1 On site fault diagnostic techniques; 11.3.2 Remote or tele-diagnostic fault diagnosing techniques; 11.3.3 Average time to arrive on-site; 11.3.4 Mean time to fix major system components; 11.3.5 Fault escalation procedures; 11.3.6 Maintenance of error logs. 11.4 Contractor will establish Hotline and Helpdesk support Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 417
Sr. No. 11.5 SERVICES REQUIREMENTS Requirement Contractor has specified a solution to accommodate PIA s requirement of additional customized reports during the maintenance and support period. 12 VERSIONS AND UPGRADES 12.1 12.2 Contractor has assured that training material / software / process documents will be duly licensed for the purpose of implementation and use by PIA for the ERP. These will be of latest version and Contractor will ensure up-gradation of all modules / material / process documents during the warranty period and as part of after-warranty maintenance support. During the implementation and subsequent rollout Contractor will be responsible to arrange and provide free version upgrades of all components under its responsibility. Contractor will ensure that at the time of handing over the solution to PIA all components are of the latest release and that the total solution is certified by the Contractor for completeness. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 418
H6 HARDWARE REQUIREMENTS Detailed below are the hardware requirements. Contractors must provide their responses in the Response column and provide additional information / clarification in the Remarks column. Vendor response must be restricted to: Sr. No. 1. Y = Yes 2. Response N = No / Cannot be provided Remarks Details of how the hardware requirements will be fulfilled Nil In case the Contractor does not provide a response, it will be considered as N. The Contractor should provide the response by filling up the columns "Response" and "Remarks" only. Any changes, such as addition, deletion, or modification of row contents in the RFP document, will be considered as an invalid response to the RFP. Section H Requirements Compliance Matrix Page 419
S. No. 2 HARDWARE 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 HARDWARE REQUIREMENTS Requirement Contractor has submitted details of the proposed configuration, including layout diagram detailing model designation(s), memory size, number of CPUs, type of drives with capacity and counts. The offered solution complies with the Open Systems Architecture and latest technology trends. The solution is scalable, both horizontally and vertically. The hardware is sized keeping in view the operational requirements of the MRO and associated applications. The hardware is fully capable of hosting the MRO certified database. The hardware allows each partition of the MRO environment to be isolated in such a way that a software fault in one partition will not have an impact on another partition. All software required for clustering of servers and implementation of DRP is included in the solution. The solution will be fully supported by the Contractor for not less than ten years from the date of supply. It will remain capable of being supported, upgraded and extended by the Contractor during this period. The solution provided will be accompanied with complete documentation, operating manuals, system diagrams, startup and recovery procedures and all other information required for proper and efficient operation. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 420
S. No. 2.10 2.11 2.12 2.13 2.14 2.15 2.16 HARDWARE REQUIREMENTS Requirement Contractor will provide all technical material and verifiable benchmarks related to the proposed solution. The hardware is by the MRO principal vendor for the operation of the MRO and is reasonably expected to be certified for future versions of the MRO during the expected life of the hardware. Contractor has provided information on warranties on the equipment and any options regarding warranty extension. Principal s assurance for parts availability after expiry of warranty period is also provided. The Contractor has to provide thorough and contemporary 3rd party testing software for acceptance and load testing. The testing will be done according to system equipment specifications as well as generally accepted practices. All test results will be completely documented by the Contractor. Complete test documentation including results of the 3rd party load / stress testing software will be provided to PIA. Based on PIA s high availability requirements, failover design is based on protecting single point of failure. For high availability on the application layer, the solution will implement log on load balancing between the application servers. It does not need any form of reallocation of resources between servers. The application environment is sized and designed such that upon failure of an application server (based on single point of failure), minimum degradation of performance will be experienced. A Disaster Recovery (DR) design is provided which provides a seamless, pragmatic DR process. It integrates within the overall design of the MRO landscape. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 421
S. No. 2.17 HARDWARE REQUIREMENTS Requirement The DR process is simple to execute. A step-by-step process and procedure is provided to minimize the potential for human error in a time of crisis and disaster. Additionally, the DR design can be easily tested with minimal impact on day-to-day operations. Response (Y / N) Remarks Section H Requirements Compliance Matrix Page 422
SECTION I COMPLETION AND COMPLIANCE CHECKLIST Section I Completion and Compliance Checklist Page 423
I1 PROPOSAL COMPLETION CHECKLIST Sectio n RFP Reference Sub section Item B B3 Completed All Forms B1 8.2.2 B1 9 Bid Bond B1 5.2 Requirement Description Declaration of accepting responsibility for the successful integration and interoperability of all proposed products and other PIA systems as required by the RFP documents Original plus One hardcopy of Technical and Commercial Proposals B1 5.2.A Softcopy of Technical Proposal B1 5.2.1.1 B4 21.2 Technical and Commercial Proposals provided separately, clearly marked and sealed, as required Proposal in Format, as specified in Section B3 Format and Contents of Proposal Declaration of not inducing or influencing the bidding / evaluation process D D1 3 Comprehensive Project Plan 4 Project Organization Structure and Personnel Roster. Please specify also the needed functional experts to be provided by PIA Engineering E E1 RDBMS And Database Administration Tools F F1 Bidder s Qualifications And Experience G G1 Hardware specifications and design layout H H1 Requirements Compliance Matrix A draft contract between PIA and the Vendor concerning all services requested in this RfP is requested. I I1 Completion and Compliance Checklist Yes / No Section I Completion and Compliance Checklist Page 424
I2 PRODUCTS AND SERVICES Section E RFP Reference Sub section E1 E2 E3 E4 Item 3 4 5 6 7 8 Requirement Description RELATIONAL DATABASE MANAGEMENT SYSTEM AND DATABASE ADMINISTRATION TOOLS APPLICATION DEVELOPMENT TOOLS QUERY AND REPORT GENERATION TOOLS INTERIM SERVERS The Contractor is required, as part of its proposal to provide an Interim Server and Operating System Software. It is anticipated that the Server(s) will be required for a period of approximately six to nine months from the date of supply of Server Hardware, Operating System Software and MRO Package Software. The Contractor will be required to re-install all MRO, 3 rd Party, Custom-built software, RDBMS, Database, Development tools, etc. on the Permanent Server(s). The details of the proposed Interim Server(s) hardware Configuration and Operating System software are to be provided by the Contractor in its proposal. The configuration of machines should be capable to support the number of users as specified by the Contractor in its plan. In its proposal, the Contractor will provide site specification requirements for the installation and operation of the Interim Server(s). Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 425
Section RFP Reference Sub section Item Requirement Description PIA - at the end of implementation and rollout - may at its discretion, decide to purchase the interim servers provided by the Contractor. In this regard, the Contractor should, as part of its Price Proposal, 9 separately mention the cost at which it would offer these machines for sale to PIA. However, this cost component should not be added to the total bid price, nor should it be used to calculate the bid bond amount. E5 3 RD PARTY SOFTWARE Contractor will be responsible to ensure that all required 3rd party software, operating systems, system management and monitoring tools, backup and recovery software, database administration 2 tools, disaster recovery and business continuity tools, APIs / interfaces, etc. are made available, documented, designed, implemented and operational to meet PIA s requirements in the proposed MRO solution. It is the responsibility of the Contractor to offer PIA 3 a complete solution in all respects delays or costs arising out of any shortcoming will have to be borne by the Contractor. D D1 IMPLEMENTATION 1.1 Installation of the Interim Server(s) including the Operating System. Installation of all supplied Application software, 1.2 RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Interim Server(s). Installation of all supplied Application software, 1.3 RDBMS software, Development / Query and Report Writer / Database Administration Tools and any other required Utilities, on the Permanent Server(s). 1.4 Implementation of Database security features. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 426
Section RFP Reference Sub section Item Requirement Description Development of Business Requirement Document for each functional area which maps the business 1.5 process for the parameterization / configuration of MRO Package. This should be based on PIA s reengineered business processes that would be made available to the Contractor. 1.6 Development of business case scenarios Parameterization of supplied Software i.e. the 1.7 configuration of application software via selection of in-built values, setting up of tables, etc. to meet the business requirements. Software modifications, where required, to supplied 1.8 Application software and development of extensions and / or modules to meet the business requirements. 1.9 Design, development and initial setup of databases. Integration with PIA s other applications such as 1.10 Sabre, AIMS, SITA Cargo, Aero Exchange, MRO Solution, QUASAR, Recipe Management, Corporate e-mail, PIA website, etc. Design and development of customized reports, screens, workflows, etc. PIA will try to maximize 1.11 the use of standard reports, screens and workflows available in the proposed solution; however the Contractor cannot set an upper limit to the number of customization that it will undertake. 1.12 Unit, Integration and System testing prior to User Acceptance testing. 1.13 Data conversion activities. Design and implementation of online and batch job 1.14 operational activities until implementation is successfully completed at all locations. 1.15 Progress reporting on Contractor related activities. 1.16 Quality Assurance for Contractor related activities. 1.17 Any other tasks required in successful delivery of the supplied products and services. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 427
Section RFP Reference Sub section Item 2 3 4 5 Requirement Description Contractor must utilize airline industry specific rapid implementation templates to ensure quick implementation. Details of such templates should be submitted with the Technical Proposal. A detailed comprehensive business plan is to be prepared by Contractor and submitted as a part of project. The business plan shall be mutually approved and incorporated as part of contract and reviewed at regular intervals. The Contractor must submit a detailed project organization structure identifying, by name, the specific individuals who would be assigned different tasks of the project. The Contractor must assign a full time Project Manager to manage this Project. This person must be from the list of Lead Consultants submitted by the Contractor in response to the EOI. He / she must have the experience of implementing the proposed MRO in at least two airlines. His / her detailed CV including experience of managing MRO and other projects; MRO certification, if any; number of MRO projects managed; number of years on each project; etc. must be submitted along with the Technical Proposal. A personnel roster containing detailed responsibilities of Contractor staff should also be provided. It should include the estimated number of hours to be worked on the project for each person broken down in different phases of the project; it should also clearly identify the start and end dates for each phase. These staff members should be from the list of implementers provided in response to the EOI. Detailed CVs of additional members should be provided. The Contractor may perform Unit, Integration, and Systems Tests off-site; however, the official Systems Test and all User Acceptance Tests must be performed on-site using PIA s testing environment. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 428
Section RFP Reference Sub section Item 6 7 8 9 10 11 12 Requirement Description The Contractor must provide, by phase, the proposed number of personnel to be based on-site at PIA s premises, and space and other requirements to be provided by PIA during Implementation. The Contractor will develop a system turnover plan which indicates the conditional criteria required to fully turn over the daily operation of the system to PIA technical staff. At a minimum, the turnover plan must include the state of readiness required for system turnover and all required documentation. The Contractor s implementation plan must take into consideration the business priority areas and applications. System Performance: During system installation the Contractor will evaluate performance factors including, but not limited to, transaction volumes, response times, CPU utilization, and input / output activity. The Contractor will be responsible for tuning the application to meet acceptable response times. Capacity Evaluation: The Contractor will conduct a Capacity Test will include stress and volume testing. Project Management and Reporting: The Contractor is required to maintain a project plan covering its components of the project and each individual phase. The Contractor will be required to prepare and submit weekly progress reports to PIA on each component of the Project under which it is responsible. Project Quality Management: In its proposal, the Contractor must describe its approach for assuring the quality of its components on this project. Contractor must also specify whether third party audit / quality assurance visits will be undertaken and who will bear the cost of these visits. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 429
Section RFP Reference Sub section D2 Item 13 14 15 16 17 Requirement Description Acceptance Testing: PIA will conduct a rigorous acceptance test of the system. During this test, PIA will identify required modifications and document them through the problem resolution or change management processes (described below) as appropriate. The Contractor shall modify the system as required and provide new versions of modified components to PIA for testing. PIA will notify the Contractor in writing when it determines that the system is acceptable. Problem Resolution: The Contractor and PIA will cooperate to resolve system problems found during acceptance testing and production use, including the warranty period. PIA will prioritize and report problems in a written format. The Contractor shall track these problems to closure and report their status upon request. Change Management: PIA and Contractor will cooperate in managing changes to previously agreed upon system functional capabilities. PIA may identify potential functional changes; however cost escalation will not be allowed under any circumstances. Configuration Management: The Contractor shall manage version releases of all contract deliverables and certain other critical documents as determined by PIA. The Bidder must assign a full time Project Manager to manage this Project. His/Her detailed CV including experience of managing MRO and other Projects, MRO Package Certification, if any, the number of MRO projects managed and the number of years on each project, etc. must be submitted along with the Proposal. TRAINING Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 430
Section RFP Reference Sub section D3 D4 Item Requirement Description As a part of the proposal, the Contractor must describe in detail its approach to meeting the training requirements for each audience. The description must include methods proposed to 1 deliver both training and documentation. The Contractor should describe the general content of all training materials, training courses, and documentation proposed. The Training Strategy should include a training solution to support the training of end users throughout PIA in the functionality of the various MRO and Add-on applications components. 2 The Contractor is required to develop materials for training users in central and remote offices. The Contractor must provide material for training Technical Staff such as database administrators, system administrators, operators, and developers. Cost of Foreign Training, if proposed, should be included in the Contractor s Financial Proposal and 3 include all expenses related to travel, accommodation, tuition fees and other incidentals. DATA MIGRATION The Conversion Strategy must address, at a 1 minimum items a) to f) 2 The Conversion Plan must address tasks a) to i) DOCUMENTATION As part of its Technical Proposal, the Contractor must describe the level and types of documentation that will be delivered. This documentation must 1 cover each level of operation, for example: user, security administrator, database administrator, operator, developer, etc. Two complete hardcopy sets of documentation for 2 all Contractor supplied components for this Project must be furnished, in addition to softcopies on CDs. The manuals should feature clear organization of 3 content, easy to understand language, useful graphic presentations, and a thorough index and glossary. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 431
Section RFP Reference Sub section D5 Item 4 5 6 7 8 1 2 Requirement Description These manuals must address the view of the system required by business unit staff (end users). It must contain sufficient information to enable the user to independently operate the system, troubleshoot simple problems, and correct problems. In conjunction with the Users Manual, Quick Reference cards will be produced by the contractor, which will be an immediate aid to the user and quickly describe operations. The Technical Manuals must address the view of the system required by developers, administrators and other technical personnel. It should provide an understanding of the application; data base design and file structures; relationships between programs, security; troubleshooting; special constraints; and other operational guidelines. Copies of all licenses, warranties, maintenance agreements and similar materials for all Contractor delivered components of the project must be furnished separately. Contractor must submit sample copies of all documents that it will prepare / deliver to PIA during the course of this project. WARRANTY AND MAINTENANCE SUPPORT The Contractor will provide warranty services for a period of at least one year for software and a minimum of three years for hardware. The warranty will begin on PIA s written final acceptance of the system. All warranty support services are to be rendered free of charge to PIA. Contractor will be responsible for all related costs during this period. Separate and apart from the warranty support services, the Contractor shall provide Maintenance services for Applications, and RDBMS beginning upon the end of the warranty services and extended up to three (3) years thereafter. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 432
Section RFP Reference Sub section D6 Item 3 4 5 6 7 1 2 Requirement Description The Contractor must describe in detail in the Technical Proposal its User and Technical Support Plan for the warranty and maintenance periods, covering the resources, timing and procedures that will be available to provide this support. The Contractor must specify the various categories of problems it will support and describe the severity levels of problems. Details of the establishment of an effective Hot Line Telephone and Support Desk service should be provided. PIA may require the Contractor to develop additional customized reports, screens, workflows, etc. during the maintenance and support period. Contractor must specify in its Technical Proposal a solution to accommodate PIA s requirement. The Price Proposal must contain the pricing mechanism for additional report development / customization. The Contractor must provide a list of clients in Pakistan and abroad for which MRO Maintenance Support is, or has been provided during the past three years. Details of modules supported should be included. VERSION AND UPGRADES Contractor must ensure that training material / software / process documents are duly licensed for the purpose of implementation and use by PIA of the MRO. These are to be of latest version and Contractor must ensure up-gradation of all modules / material / process documents during the warranty period and as part of after-warranty maintenance support. During the implementation and subsequent rollout Contractor would be responsible to arrange and provide free version upgrades of all components under its responsibility. Contractor must ensure that at the time of handing over the solution to PIA all components are of the latest release and that the total solution is certified by the Contractor for completeness. Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 433
Section G RFP Reference Sub section Item 1 Requirement Description HARDWARE The Contractor must evaluate and prepare an appropriate configuration to run the proposed MRO solution. PIA is looking for a high-availability solution including servers, clustering design, and disaster recovery recommendations besides maintenance / repair options needed for the associated infrastructure. The response must address all items 1) to 17) Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 434
I3 BUSINESS INFORMATION AND APPLICATION NEEDS RFP Reference Section Sub section Item Requirement Description D D7 1 Information Requirements of Board of Directors D7 2 Information Requirements of Senior Management H4 Functional Information Requirements 1.0 Functional Requirement concerning Aircraft Engineering 2.0 Functional Requirements for Aircraft Induction and Phase out 3.0 Functional Requirements for Line Maintenance 4.0 Functional Requirements for Cabin Maintenance 5.0 Functional Requirements for Base Maintenance 6.0 Functional Requirements for Component Overhaul 7.0 Functional Requirements for Component Overhaul 8.0 Functional Requirements for Material Management 9.0 Functional Requirements for Business Development 10.0 Functional Requirements for Power Plant Overhaul 11.0 Functional Requirements for Tools and Equipment 12.0 General Functional Requirements of the MRO System Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 435
I4 MRO PACKAGE REQUIREMENTS Section RFP Reference Sub section A A4 1. Item Requirement Description OVERVIEW OF SOLUTION REQUIREMENTS Contractor Proposal Ref. & Page A A4 2 GENERAL REQUIREMENTS 2.1 Common Characteristics 2.2 Integration 2.3 Configuration 2.4 Technology Interfaces 2.5 User Interface 2.6 Security & Authorization 2.7 Reporting / Enquiry 2.8 Analytic Tools 2.9 Communication 2.10 Flexibility 2.11 System Availability 2.12 Transaction Timing 2.13 Online Documentation and Training 2.14 Storage / Record Retrieval 2.15 System Security A A4 3. TECHNOLOGY REQUIREMENTS 3.1 New Technology 3.2 Multiple Environments 3.3 System Performance 3.4 Archive and Purge 3.5 Recovery 3.6 Backup and Reorganization 3.7 Print Management 3.8 Fallback Solution 3.9 Ability for system and license updates Section I Completion and Compliance Checklist Page 436
Section RFP Reference Sub section Item Requirement Description 3.10 Technology Architecture 3.11 Server Hardware 3.12 System and Network Management Tools 3.13 Data Support 3.14 Web-enablement 3.15 Workflow 3.16 Others Contractor Proposal Ref. & Page Section I Completion and Compliance Checklist Page 437
J1 EVALUATION CRITERIA AND WEIGHTAGE The evaluation criteria and their weights to be used are as follows: 1. Technical Proposal 65 percent 2. Financial Proposal 35 percent J 1.2 Technical Proposal Technical evaluation will be performed against the requirement compliance matrix in Section H of the Request for Proposal and instructor to bidder submitted in response to Section F of the Request for Proposal. Following numerical scoring scale will be adopted to assess the Technical Proposal: Evaluation Criteria Weightage Project Organization and Work Plan 10 Governance Model 2 Project Plan 2 Rapid Implementation Templates 2 Audit Checkpoints from Principals 2 Project Management Tools 2 Implementation Team 20 Staff Allocation (Man days Commitment) Full Time On-site Project Manager* 7 Full Time On-site MRO Module Track Leaders* 2 MRO Implementers** 2 Airline experience MRO Implementers*** 2 MRO Functionality 35 Global Requirements (General) 2 Global Requirements (Technical) 2 Global Requirements (Others) 2 Functional Requirements (Line Maintenance) 3 Functional Requirements (Base Maintenance) 3 Functional Requirements (Engineering) 3 Functional Requirements (Engine Overhaul Shop) 3 Functional Requirements (Shops) 3 Functional Requirements (Material Planning) 3 Integration with the ERP System and other PIA Applications 5 Services Requirements 4 7 & Section I Completion and Compliance Checklist Page 438
Evaluation Criteria Solution Roadmap 2 Weightage Qualification marks for technical bid 45 & Man-days of MRO Implementers with one MRO implementation experience (2%) + Man-days of MRO Implementers with one airline MRO implementation experience (5%) - The Project Manager must have full life cycle MRO implementation experience in a reputable airline (this is mandatory requirement) *At least one full life cycle MRO implementation experience in an airline **At least one full life cycle MRO implementation experience *** At least one partly life cycle MRO implementation experience - Other than Track Leaders The Evaluation Criteria Weights will be multiplied by corresponding scores to calculate a weighted score for each criterion. Total Weighted Score for each vendor will be determined by totaling the weighted scores obtained against each of the eight criteria. J2 Financial Proposal All proposals will be financially assessed for the following three cost components: 1. Product costs 2. Implementation / training (one-time) costs 3. Recurrent costs for five years The proposal with the total lowest cost will obtain the maximum weightage of 35 points. Financial scores of the other proposals will be reduced in proportion to their total costs. J2.1 Evaluation and Scoring The top scoring vendor with the highest techno-commercial composite score will be recommended as the successful vendor. J2.1.2 Evaluation Report The evaluators will prepare an Evaluation Report that will summarize the evaluation process and include the evaluation scores and comments, and give their recommendations. J3 Evaluation Approval by MRO Implementation Committee The Evaluation Report and recommendations will be presented to and approved by the MRO Implementation Committee. Section I Completion and Compliance Checklist Page 439
INTEGRITY PACT / DISCLOSURE CLAUSE (To be submitted on Company s Letterhead) Declaration of Fees, Commissions and Brokerage Etc. Payable by the Suppliers, Vendors, Distributors, Manufacturers, Contractor & Service Providers of Goods, Services & Works the Seller / Supplier / Contractor hereby declares its intention not to obtain the procurement of any Contract, right, interest, privilege or other obligation or benefit from Government of Pakistan or any administrative sub-division or agency thereof or any other entity owned or controlled by it (GOP) through any corrupt business practice. Without limiting the generality of the forgoing the Seller / Supplier / Contractor represents and warrants that it has fully declared the brokerage, commission, fees etc., paid or payable to anyone and not given or agreed to give and shall not give or agree to give to anyone within or outside Pakistan either directly or indirectly through any natural or juridical person, including it affiliate, agent, associate, broker, consultant, director, promoter, shareholder sponsor or subsidiary, any commission, gratification, bribe, finder s fee or kickback whether described as consultation fee or otherwise, with the object of obtaining or including the procurement of a contract, right, interest, privilege or other obligation or benefit in whatsoever form from Government of Pakistan, except that which has been expressly declared pursuant hereto. The Seller / Supplier / Contractor certifies that it has made and will make full disclosure of all agreements an arrangements with all persons in respect of or related to the transaction with Government of Pakistan and has not taken any action or will not take any action to circumvent the above declaration, representation or warranty. The Seller / Supplier / Contractor accepts full responsibility and strict liability for making any false declaration, not making full disclosure, misrepresenting facts or taking any action likely to defeat the purpose of this declaration, representation and warranty. It agrees that any contract, right, interest, privilege or other obligation or benefit obtained or procured as aforesaid shall without prejudice to any other right and remedies available to Government of Pakistan under any law, contract or other instrument, be void-able at the option of Government of Pakistan. Notwithstanding any rights and remedies exercised by Government of Pakistan in this regard, the Seller / Supplier / Contractor agrees to indemnify Government of Pakistan for any loss or damage incurred by it on account of its corrupt business practices and further pay compensation to Government of Pakistan in any amount equivalent to ten time the sum of any commission, gratification, brief, finder s fee or kickback given by the Seller / Supplier / Contractor as aforesaid for the purpose of obtaining or inducing the procurement of any contract, right, interest, privilege or other obligation or benefit in whatsoever from Government of Pakistan. Section I Completion and Compliance Checklist Page 440