punjab health foundation request for proposals · 1.1 ppra rules to be followed: punjab health...

RFP: Procurement of ERP Solution, Loan Management System and Implementation Services

Punjab Health Foundation

Request for Proposals

For

Procurement of ERP Solution, Loan Management System and Implementation Services

Issue Date: April, 2019

Closing Date: May, 2019

Punjab Health Foundation

GOVERNMENT OF THE PUNJAB

Poonch House, 38- Multan Road, Lahore

Ph: # (042) 99210953, 99210956 Fax:(42) 99211982 Exchange (042) 99210984-85 Web Site: www.phf.punjab.gov.pk E-mail: [email protected]

Key Information Sheet

Sr # Key Information Details

1. RFP Document Issue Date

http://www.phf.punjab.gov.pk/

mailto:[email protected]


Page 1 of 36

2. Availability of RFP Document RFP documents will appear in Punjab

Procurement Regulatory Authority (PPRA)

website www.ppra.punjab.gov.pk and

Punjab Health Foundation’s website

www.phf.punjab.gov.pk

3. Last Date of Submission of Bids

4. Mailing Address Punjab Health Foundation

Poonch House, 38-Multan Road Lahore.

5. Phone Number +92(42) 99210953

6. PHF’s Website www.phf.punjab.gov.pk

http://www.ppra.punjab.gov.pk/



Page 2 of 36

Table of Contents

1. Invitation to Bids

2. PHF’s Overview

3. Key requirements

4. Proposal Submission and Evaluation Criteria

5. Executive Summary

6. Scope of Work

7. Functional Requirements

8. Loan Management System Workflow

9. Cloud Specifications

10. System Specifications

11. SLA for cloud services

12. Support


Page 3 of 36

1. Invitation to Bid

1.1 PPRA Rules to be followed:

Punjab Health Foundation (PHF), (The Purchaser), invites bids for the “Procurement of Enterprise Resource

Planning (ERP) Solution, Loan Management System and Implementation Services”.

PPRA rules will be strictly followed. These may be obtained from PPRA’s website: http://ppra.punjab.gov.pk

1.2 MODE OF ADVERTISEMENT

As per PPRA rules, this Tender is being placed online at PPRA's website and PHF website, as well as being

advertised in print media. The bidding document carrying all details can be downloaded from PPRA’s website

http://ppra.punjab.gov.pk and www.phf.punjab.gov.pk.

As per PPRA rules, this Tender is being placed online at PPRA's website, as well as being advertised in print media.

1.3 TYPE OF COMPETITIVE BIDDING

As per PPRA rules, Single Stage - Two Envelope Procedure shall be followed for the bidder. This is as

follows:

The bid shall comprise of a single package containing two separate sealed envelopes. Each

envelope shall contain separately the financial proposal and the technical proposal;

The envelopes shall be marked as “FINANCIAL PROPOSAL” and “TECHNICAL PROPOSAL” in bold

and legible letters to avoid confusion;

Initially, only the envelope marked “TECHNICAL PROPOSAL” shall be opened.

The envelope marked as “FINANCIAL PROPOSAL” shall be retained in the custody of the

procuring agency without being opened;

The technical proposal will be evaluated in a manner as per the clauses mentioned in this

document; and proposals, which do not conform, to the specified requirements as listed in said

document will be rejected.

During the technical evaluation no amendments in the technical proposal shall be permitted;

The financial proposals of technically qualified bidders shall be opened publicly at a time, date

and venue announced and communicated to the bidders in advance;

After the evaluation and approval of the technical proposal the procuring agency, shall at a time

within the bid validity period, publicly open the financial proposals of the technically accepted

and qualified bids only. The financial proposal of bids found technically non-responsive shall be

returned un-opened to the respective bidders.

Technical Bids will carry 70 % weightage and Financials bids will carry 30% weightage. The

bidder scoring highest marks based on the above mentioned weighted average would be awarded

the project as the foundation competent to accept the tender, Purchaser reserves the right to

cancel the tender, accept or reject one or all bids without assigning any reason thereof.

1.4 BIDDING DETAILS (INSTRUCTIONS TO BIDDERS)

All bids must be accompanied by tender security as part of financial proposal in favor of “Punjab Health

Foundation”. The bids along with the Call Deposit Receipt / Demand Draft / Bank Draft/ Bank Guarantee, must

be dropped at Punjab Health Foundation, Poonch House, 38-Multan Road, Lahore. up to 1100 hours on 16-05-

2019.

The Technical Proposals shall be opened in PHF’s Committee Room the same day at 1130 hours, in the presence

of bidders or their authorized representatives who may wish to be present. A softcopy of Technical need to be

submitted in the form of USB flash drive in the respective envelopes.

Queries of the Bidders (if any) for seeking clarifications regarding the required products and services and scope

mentioned in this document, may be queried date of Tender advertisement to closing date. All interested bidders

can participate in the pre-bid meeting of the date and time given. The bidder must submit bids on the basis of

complete tender. Failure to meet this condition will cause disqualification of the bidder. The bidder shall submit

bids which comply with the Bidding Document. Alternative bids will not be considered. The bids will be rejected

which are not substantially responsive to the requirements of this Document.

http://ppra.punjab.gov.pk/


Page 4 of 36

Pre-Bid Meeting 30-04-2019 at 11:00 am

Last date of purchase of bidding documents 16-05-2019

Time for submission of proposal 11:00 am

Time for opening of Technical proposal 11:30 am

Procurement Method Single stage two envelop

Bid Security (2% of estimated cost) 39,000/-

The contact detail for technical details:

Manager (IT&MIS)

Punjab Health Foundation,

[email protected]

For bid submission related issues:

Assistant Manager (Procurement)

Punjab Health Foundation,

[email protected]

Bidders should note that during the period from the advertisement of the tender till the receipt of the bid, all

queries should be communicated to the above contact in writing or via e-mail or letter at the above contact detail.

Bidders are also required to state, in their proposals, the name, title, fax number and e-mail address of the

bidder’s authorized representative through whom all communications shall be directed until the process has been

completed or terminated.

Purchaser will not be responsible for any costs or expenses incurred by bidders in connection with the preparation

or delivery of bids.

2. PHF’S OVERVIEW

The Punjab Health Foundation (PHF) was established in 1993 with the prime mandate to provide financial

assistance, interest free loans, and technical support to the private sector healthcare providers so that they

could share the burden of public sector in provision of healthcare services to the general public. The Foundation

is an autonomous body, governed by a Board of Directors. The basic role of the Foundation is to encourage the

concerned Health Professionals for establishing and upgrading health institutions and allied projects. This was a

milestone step of the Government of Punjab towards proactively assisting and promoting the private sector in

broadening the overall health coverage to the people of this province.

2.1 PROJECT OVERVIEW

PHF is looking to contract a reputable vendor to implement various solutions that are stated in the later part of

this document. The overall goal of this project is to devise an automated system for enterprise

resource planning and loan management system on the Cloud. An ERP System which can simplify,

standardize and automate business processes, helping PHF to take full advantage of growth opportunities. The

ERP cloud system should enable the workforce to collaborate, analyze and work on the move to accelerate

performance.

PHF would like to restate and re-emphasize that considering that personnel who are expected to be the end users

of this ERP system, there must be special emphasis on the usability and the functionalities should be easy to use,

web accessed, fully automated and scalable. Applicants who can demonstrate innovative solution implementation

approach and simplistic graphical layout.

PHF requires an automated system for enterprise resource planning, which can work on managing new processes

and it should be able to easily add sub branches if need arises. It has been noted that much of the inefficiency

in operational work stems from improper reporting within the organization, the system needs to have possibility

of eliminating such errors and should automate system to correct those errors. As compared with manual

recordkeeping or other traditional approaches, the system needs to be able to provide an improved data quality

by improving the underlying processes that gets highlighted within the organization. We wish to introduce

fundamental innovation in managing resources, which will in return eliminate delays and reduce cost of

operations, the system should have the capability to manage resources. Having high-quality data allows

businesses to use the power of intelligent analytics tools to arrive at better business decisions. An ERP system

should have a built-in analytics functionality to allow easier data analysis. Controlling data access properly is




Page 5 of 36

always a challenge in organizations; the system should have the capability to overcome with the use of advanced

user management and access control.

We need a system, which provides low level of complexity of a business and should have a streamline of

workflows, which is followed by approvals from top management.

PHF intends to procure ERP and loan management cloud solution, which can simplify, standardize, and automate

business processes, helping PHF to take full advantage of growth opportunities. The ERP cloud system should

enable a workforce to collaborate, analyze, and work on the move to accelerate performance. It should be noted

that the ERP cloud system and loan management system should be able to interact. ERP cloud system should be

able to provide integration with system and its services. The loan management system should be accessible

through Mobile Application.

PHF’s management can have access to dashboards they can use to monitor and view their most pressing concerns

and system should have the ability to integrate with existing applications like Microsoft Excel to leverage cloud

ERP analytics and allow users to easily collaborate within the applications to complete tasks faster.

2.2 HIGH LEVEL ERP FUNCTIONALITIES

The broader overview of the required Functionalities in the Cloud ERP and Loan Management System but not be

limited to:

Cloud based ERP solution and Loan Management System

Process automation and Monitoring

Multi-Dimensional Reporting

Improved User Experience

Mobile APP for Site Inspections and Monitoring

Provision of Source Code

Training Sessions should be part of the implementation systems so that the knowledge gets transferred to

end-users. ERP solution and loaning system should continually be upgraded by the provider to make sure the

latest, and bug free.

3. Key Requirements

The proposed Cloud ERP and Loaning System should cater to requirements of key business functions of the

organization with finance management and loaning system. The major key requirements are following:

Complete solution on cloud for Finance covering the following business areas

General Ledger

Account payable

Account receivable

Fixed Assets

Cash Management

Consolidate reporting for analysis

Facility to book invoices and track payables

Bank payments and collections

Loaning System with following features:

Loan Application Receiving

Loan Application Screening

Loan Approval

Loan Disbursement

Loan Recovery

The elaborative details follow in the coming sections. The solution must be on cloud and all components should

be integrate-able with modules to be deployed in future. The solution must provide advanced features for securing

data and also keeps track of audit trail.

Cloud ERP solution and loaning system should have the below enterprise grid functionalities:

Deployment model with easy, predictable pricing

Complete ERP services, including financials, planning and budgeting

Version upgrade should be responsibility of the vendor

Provision of source code


Page 6 of 36

The selected Applicant is expected to conduct their own investigations and analysis and should check the

accuracy, reliability and completeness of the information in this RFP document. For any queries regarding any

information in this RFP, Applicants communications with PHF’s focal person.

3.1 CONFIDENTIALITY

The Tenderer (whether or not he submits a Proposal to the RFP) shall treat this RFP document and its details as

strictly private and confidential. No information pertaining to this RFP or the examination, clarification, evaluation,

comparison and award of this RFP shall be disclosed to other Tenderers or any other persons not officially

connected with the RFP process, including, but not limited to, the Tenderer’s own affiliate companies and

subsidiaries. The Tenderer is not permitted to make any public announcement or release any information

regarding this RFP without PHF’s prior written approval.

PHF reserves the right to share the Tenderer’s response to this RFP with its advisors and affiliates.

In the event the Tenderer commits a breach of confidentiality, PHF reserves the right to disqualify the tenderer

from this RFP process and furthermore not include the Tenderer in any future similar exercises.

PHF is not responsible for declaration of the short listed supplier(s). PHF has the right to accept or reject any

offer as it deems fit or cancel this RFP process at any stage without assigning any reason whatsoever.

The Tenderer shall state clearly those elements of its response that it considers confidential and/or proprietary.

Failure to properly identify and mark confidential or proprietary information may result in all information received

being deemed non-confidential, non-proprietary, and in the public domain.

3.2 RFP RESPONSE OWNERSHIP

All material submitted regarding the RFP becomes the property of PHF and will not be returned to the Tenderer.

Please submit the softcopies of technical and financial proposals in a USB drive along with hard copies.

3.3 ADDENDUM OR SUPPLEMENT TO RFP

At any time prior to the deadline for submission of the Tender, PHF may, for any reason, whether on its own

initiative or in response to a clarification request by prospective vendor, modify the RFP by issuing addenda.

A summary of all questions and responses as well as any adjustments regarding the scope of this tender - if any

- will be prepared and distributed to all potential vendors that submitted their intent to bid. It is the responsibility

of tenderer, prior to bid date, to inquire as to addenda issued and to ensure their bid reflects any and all changes.

3.4 CLARIFICATIONS AND QUESTIONS

To ensure fair consideration for all Proposers, PHF prohibits communication to or with any department, officer or

employee during the submission process except as provided below. If the Proposer should be in doubt as to the

meaning of any of the Proposal documents, or is of the opinion that the plans and/or specifications contain errors,

contradictions or reflect omissions. Proposers shall email a written request for interpretations or clarification.

Any interpretation will be made only by an addendum. No oral explanation or instruction of any kind or nature

whatsoever given before the award of a contract to a Vendor shall be binding.

3.5 CONTACT INFORMATION AND COMMUNICATION

Prospective Participants may make inquiries concerning this RFP to obtain clarification of requirements. For

Technical and Financial Clarification. Please include the following reference as the subject of your email: ERP

System - RFP

3.6 ADVICE OF OMISSION OR MISSTATEMENT

In the event it is evident to a Vendor responding to this RFP that PHF has omitted or misstated a material

requirement to this RFP and/or the services required by this RFP, the responding Vendor shall advise the contact

identified in the RFP Clarifications and Questions section above of such omission or misstatement.

3.7 TENDER PRESENTATION

The Tenderers are expected to present their proposal as per the terms and conditions listed along with the

announcement of this tender. The Tenderer is required to include a high level project management plan in the

proposal and will be required to provide and present a detailed and comprehensive project management plan

that will become the sole source for determining implementation tasks and completion time of each task.

The tenderers are expected to present the technical proposal and the various components fitment within the

overall proposal. The Tenderer must be able to answer all queries and question of the evaluation committee

within the presentation. Failure to do so will render lower points to the tenders’ proposal.

3.8 MODIFICATION OR WITHDRAWAL OF PROPOSALS

Proposal modification and withdrawal terms and conditions are governed by The PHF/PPRA tender laws and

regulations. Such laws and regulations shall always prevail at all times. Under no circumstances shall a Tenderer

be allowed to modify or withdraw his proposal if such actions are prohibited by the relevant Tender laws.


Page 7 of 36

3.9 ACCEPTANCE

A proposal submitted in response to this RFP shall constitute a binding offer. Acknowledgment of this condition

shall be indicated by the signature of the Participant or an officer of the Participant legally authorized to execute

contractual obligations. A submission in response to this RFP acknowledges acceptance by the Participant of all

terms and conditions including compensation, as set forth herein. A Participant shall identify clearly and

thoroughly any variations between its proposal and the PHF’s RFP. Failure to do so shall be deemed a waiver of

any rights to subsequently modify the terms of performance.

3.10 TENDER SCHEDULE

Last Date of Submission of Proposals: As per the advertisement in the newspapers.

Opening of Bids: As per the advertisement in the newspapers.

Selection of Qualified Bidders as per the Selection criteria.

Presentation from the Selected Bidders qualifying the criteria on the proposed solution.

Opening of Financial Proposals: After Technical evaluation of all the Vendors.

Award of contract to selected Vendor: After one week of the opening of financial proposals.

3.11 Costing

An estimated costing, including all fees required to complete this project and any associated and recurring costs,

such as support or licensing, shall be included in the proposal. Pricing should be in Pak Rupees inclusive of

all taxes, PHF will consider pricing as part of the evaluation criteria. However, it is not essential to

bid the lowest price to win. Withholding Tax, sales Tax and Other Taxes: The Respondent Vendor is hereby

informed that PHF shall deduct tax at the rates prescribed under the Tax Laws of Pakistan, form all payments for

services rendered by any Respondent Vendor who signs a contract with PHF.

3.12 BID SECURITY/EARNEST MONEY DEPOSIT (EMD)

As per PPRA procurement rules of bid security, the bidder will submit a bid security which shall be 2%in shape

of Bank Draft / Pay order in favor of Punjab Health Foundation. The bid security issued by any scheduled bank

of Pakistan will be acceptable. Cheques will not be acceptable in any case. Bid Security will be returned to all

vendors once project is awarded or annul due to any reason. Validity of the Bid Security should be 120 days

minimum.

Within (15) days of the receipt of notification of award from the Purchaser, the successful Bidder shall furnish

the Performance Security. The value of Performance Security shall be 10% of the bid value to be issued by any

scheduled bank of Pakistan having “A” rating. The Performance Security will be valid after the six months of

completion of the assignment or any such extended period as decided by PHF.

3.13 BID VALIDITY PERIOD

Bid should be valid for a period of 90 days from the date of opening of financial proposal.

3.14 ADDITIONAL CHARGES

No additional charges, other than those listed on the price breakdown sheets, shall be made. Prices quoted will

include verification/coordination of order, all costs for shipping, delivery to site, unpacking, setup, installation,

operation, testing, cleanup, training and Vendor travel charges.

3.15 EVALUATION INQUIRIES

PHF reserves the right to request any additional information that might be deemed necessary during the

evaluation process.

3.16 RIGHT TO REQUEST ADDITIONAL INFORMATION

PHF reserves the right to request any additional information that might be deemed necessary during the

evaluation process as per rules.

3.17 RIGHT OF REFUSAL

As authority competent to accept the tender, Purchaser reserves the right to cancel the tender, accept or reject

one or all bids without assigning any reason thereof.

3.18 TURNKEY SOLUTION

PHF is seeking a comprehensive turnkey proposal covering Software licensing subscription, Implementation,

Configuration and Training of ERP solution and Loaning System. All prices quoted must include all software and

necessary services to make the system specified fully operation for the intent, function and purpose stated herein.

3.19 TIMELINES

PHF is expecting from the successful vendor to complete the project within 04 Months (120 days) from the date

of Letter of Award (LOA). Delay in project will result to penalty as defined under penalty clause.


Page 8 of 36

3.20 PAYMENT CLAUSE

Payments will be made by PHF against the invoice/s raised by the Vendor by following the procedure in vogue

against each milestone on production of following documents:

a. Sales tax invoice duly signed and stamped by the organization.

b. A certificate by the Vendor to the effect that he had not claimed the relevant payment in his previous

claims.

c. A certificate issued by standing Purchase Committee of PHF certifying that the relevant claim is correct

and the Vendor has successfully accomplished the task against respective milestone.

d. Partial payments will be allowed and payment shall be released only after achievement of milestone/s as

described in the project document/control book.

e. There will be no Advance payment against any task of the project other than mobilization advance, which

will be against Bank guarantee of the same amount.

f. Payments will be divided into different segments.

3.21.1 Cloud Licensing Subscription Fee for 1ST Year

Vendor to propose Quarterly or yearly model

Vendor to quote fixed quarterly /yearly prices for Cloud based ERP and Loaning System

First payment will be made on Provisioning of cloud services as defined in the payment schedule

3.21.2 Implementation Services

Professional Services for ERP implementation (Milestone based payment, as defined in the payment schedule).

Timelines of the project will be agreed before the contract signing and has to be within 02 months (60 days).

PHF reserves the right to change the payment terms with the consultation of the successful bidder at the time

of the contract signing. Once the contract is signed, bidder will be bound to invoice as per performed services

agreed in the contract.

3.21.3 Training

Training will be divided into 2 different sections.

(1) End User Or System Users

(2) Technical Staff

Payment will be made after the completion of End User training. All the trainings should end up with a proper

test/exam to certify that staff member has successfully passed the test/exams.

3.22 Payment Schedule

Description Payment %

Business Requirements Gathering and Analysis (Control Book) 40%

Build and Conduct UAT, End-User Training and Readiness Technical

Trainings

30%

Project Go-Live 20%

Satisfactory Report by Inspection Committee of PHF 10%

Recurrent Costs (Cloud Hosting Services, initially up-to 01 year which may

be extended on satisfactory performance)

Per quarter basis

*PHF reserves the right to change the payment schedule at the time of contract signing with mutual consent

with the successful bidder.

3.23 PENALTY CLAUSE

The contract to be executed between PHF and the selected Vendor will contain penalty clauses for delay in

the implementation schedule as well as failure to comply with the provision of providing the required services

during the post-approval phase. The maximum penalty to be imposed against delay would be equal to 10%

of the contract value. In case, implementer touches the maximum penalty that is 10% of the contract value,

PHF reserves the right to cancel the contract.

3.24 Implementation Services

Timelines of the project will be agreed before the contract signing. Delay will be subject to 0.2% penalty of

implementation value of specific milestones per month.

3.25 Training Services


Page 9 of 36

To be completed before Go Live. Delay will subject to 0.2% penalty of Training value per month.

3.26 SUBCONTRACTING ERP

Vendor shall not be permitted to sub-contract any part of its obligations under the Contract with PHF subject

to prior approval of PHF, However Consortium of two companies only is allowed.

3.27 COMMENCEMENT OF ASSIGNMENT

As per Letter of Award of Contract

4. PROPOSAL SUBMISSION AND EVALUATION CRITERIA

The deadline to submit the proposal is mentioned at the bid schedule.

4.1 EVALUATION AND QUALIFICATION CRITERIA

This Section contains all the criteria that the Purchaser shall use to evaluate a bid and qualify the Bidders.

4.2 GENERAL CONSIDERATION - PRE-QUALIFICATION

Documentary evidence that interested bidders must either be Principal or an authorized partner of Principal

(Preference Letter from OEM in the name of PHF in case of authorized Partner)

Vendors should have sound experience in deploying solution in Public organizations of Pakistan (Documentary

evidence in the shape of Purchase Order/Contract/NOC) (minimum 2 public sector organizations

PO/Contract/completion letter)

Copy of registration certificate of organization, the Income Tax and Sales Tax Registration Certificate.

ERP and Loan Management Solution should be Cloud based and the principal should manage Cloud including

patches, updates and upgrades.

ERP cloud solution should have at least 05 deployments. (Original Equipment Manufacturer (OEM) Letter

mentioning the names of the references and reference-able documentary evidences (websites).

Proposed Loan Management Solution will also be having integration with Cloud ERP Modules.

Solution should be out of the box/product of having presence and acceptance in market.

For authorized partner documentary evidence of Gold or equivalent level of partnership with proposed technology

solution in Pakistan for will be required. (Manufacturer Authorization Letter from OEM in the name of PHF).

4.3 COMPANY STRENGTH AND RELEVANT PROJECTS (TOTAL MARKS 100)

Points will be awarded, based on the bidder’s strength

Company Strength & Relevant Projects

S No Description Marks

1 ISO 9001 certified for sales of IT solutions and Equipment. 20

2 Experience in Proposed ERP (Oracle, SAP or Equivalent) implementation

10+ Years = 20

5+ years = 10

20

3 Proven track record of ERP (Oracle / SAP or Equivalent) implementation in

Government organizations.

10

4 Number of permanent technical resource persons relevant to this project (having ERP

(Oracle / SAP or Equivalent)

50 + employees =20

30+ employees = 10

20 + employees = 5

20

5 Successful Implementation letter of ERP (Oracle / SAP or Equivalent) projects.

90% compliance = 20

70-90% compliance= 10

Less than 70% = 5

20


Page 10 of 36

6 Lahore based implementation setup. 10

Minimum 70% points would be required on each category. Technical part will carry 70% weightage overall and

Financials will have a 30% weightage. Only technically qualified vendor’s financial bids will be opened.

4.4 EVALUATION OF FINANCIAL PROPOSAL

A two-stage procedure is utilized in evaluation of the Bids, with evaluation of the technical proposal being

completed prior to any Financial Proposal being opened and compared.

The Financial Proposal of the Bids will be opened only for submissions that passed the minimum technical score

of 70% of the obtainable score in the evaluation of the Technical Proposals. If the technical component achieves

70% points, the Bid will be taken into account in the following manner:

Weightage of the financial scoring is 30% and Firm’s Score will be calculated using following formula.

Firm’s Score= (Minimum Bid Value / Bid in Consideration) * 30

4.5 Financial Bid Summary Format

Financial bid will be submitted in the below format. Please add an extra page if necessary to add line item pricing

where needed.

Description Amount in PKR with

Taxes and Duties

Remarks

Software Cost Please mention detail breakup

Implementation Services Please mention detail breakup

Cloud Hosting Services Please mention detail breakup

Training Cost (if any) Please mention detail breakup

Total Fee in PKR (Total Fee in Words)

*After sales services (maintenance & support) for first 06 months of initial period after deployment will be

complementary explicitly.

4.6 Technical Proposal

Vendor will furnish the technical proposal in the below format.

Proposal must Furnish following Details

S.

No.

Description

1. Detailed Project Execution Plan

2. Implementation Approach/Methodology

3. Solution Deployment Architecture on Cloud

4. Training Methodology including Schedule & Plan

5. Responsibility Area Matrix for Project Execution

6. Details of Collaborative Workspace for the Project

7. Application Backup Plan

8. Security Features on the Proposed Cloud

9. Details of Required Hardware Solution

10. Any Other Hardware or Software Necessary to run the System for Integration Purpose

4.7 Documentary Evidence

D1. Certificate of Incorporation or registration

D2. Memorandum and Articles of Association

D3. Audited financial statements (last 3 years)

D4. National Tax Number (NTN) certificate

D5. Tax returns of last 3 years

D6. Sales Tax Registration certificate

D7. Reference letters confirming successful completion of the projects

D8. ERP (Oracle / SAP or Equivalent) partner certificate


Page 11 of 36

D9. List of clients with respect to implementation of ERP solution (at least 20 or more)

5. EXECUTIVE SUMMARY

This part of the response to the RFP should be limited to a brief narrative describing the proposed solution. The

summary should contain as little technical jargon as possible and should be oriented toward non-technical personnel.

The executive summary should not include cost quotations.

5.1 COMPANY BACKGROUND

Vendors must provide information about their company so that PHF can evaluate the Vendor’s stability and ability

to support the commitments set forth in response to the RFP. Information that Vendors should provide in this

section are as follows:

The company’s background including a brief description (e.g. past history, present status, future plans,

company size, etc.) and organization charts.

Audited financial information for the past Three (3) completed fiscal years that includes income

statements, balance sheets, and statement of cash flows.

Privately-held companies wishing to maintain confidential financial information must provide information

detailing the company’s long-term stability as part of the Vendor proposal response.

Any pending litigation.

Statement that company is not blacklisted.

List of the project awarded in Public sector in Pakistan.

List of ERP projects completed locally and internationally.

5.2 PROPOSED SOLUTION

As PHF is contemplating a mix of multiple solutions, aspects of the proposed solution to be provided should be

clearly delineated where they vary between these approaches in the sections below.

5.2.1 Application Software

The Vendor is required to provide a general description of the application program product and how it will

meet requirements of this RFP. This section must address, at a minimum, the following items:

Describe your overall proposed technology solution on cloud.

Describe the solution architecture on proposed cloud solution.

Describe the up time and security on cloud solution.

Describe the format of Source code

Describe the backup strategy.

Describe the mechanism for the deployments of updates and version upgrader not only limited to

application but also database, middleware.

Describe the product direction for the company, including time frames.

Describe unique aspects of the Vendor’s solution in the marketplace.

Describe components of the solution that are industry standards versus being proprietary to the Vendor.

Describe workflows for each module/components.

Describe your portal or single sign on strategy.

For third party products proposed that are integrated with the Vendor’s solution provide the following for

each product:

o Reason that this product is a third-party product versus being part of the software Vendor’s

solution.

o Extent to which this third-party product is integrated with the Vendor’s solution.

5.2.2 Cloud Services

The Vendor shall provide the information described in this section. This information will be used in the

evaluation process.

What is unique about proposed Cloud?

What services are available via Cloud?

Are Cloud Services available globally?

Can Cloud applications be used from mobile devices?

Can Cloud be used for production workloads as well as development and testing?

Can Cloud handle volume and scale with your business?

How secure are the Cloud Services?

Does Cloud support high availability and disaster recovery?


Page 12 of 36

How is system maintenance and upgrades performed in Cloud?

Can applications be moved from Cloud to on-premises or third party service providers?

Can PHF retrieve artifacts and data if PHF cancel Cloud Service?

What kind of support is provided with proposed Cloud?

What Services/modules are available on the cloud?

How does integration work with different proposed modules on cloud?

Is Financials integrated with Project Portfolio Management and Procurement?

What reporting tools are available with Financials on cloud?

5.3 IMPLEMENTATION PLAN

The Vendor is to provide an implementation plan in narrative format supported by an activity-level project plan

using Microsoft Project with details how the proposed solution is to be implemented. This implementation plan

should include the following elements:

General Implementation Approach

Project Management Approach

Cloud implementation through principal (In case proposed)

Data Conversion Plan

Report Development

Integrations and Interfaces

Training

Change Management Approach

Testing

Operational Redesign Approach

System Documentation and Manuals

Disaster Recovery Plan

Knowledge Transfer

The Vendor should not be constrained to only include the above items in the Vendor’s proposal response if the

Vendor feels that additional elements may add value to the overall implementation. PHF requests that the Vendor

provide their work plan propels.

It is expected that the Vendor will lead the efforts in each of the implementation areas described below unless

stated otherwise. Further details on what is to be provided as part of the Vendors proposed implementation plan

are included in the following subsections.

5.3.1 Hardware, Software and Storage Design and Installation Consulting

The Vendor is expected to specify, furnish, deliver, install and support all application and system software

that may include pre-installing or equipment staging. Development or test instance on the cloud would be

the responsibility of the vendor. Additionally, PHF expects the selected Vendor to conduct a test of the system

backup and recovery solution prior to go-live.

5.3.2 Data Conversion Plan

PHF has got existing system contained data of loanees in its legacy data. In case data conversion is required,

the Vendor is expected to assist PHF in the conversion of both electronic and manual data to the new system.

It is expected that vendor will be responsible for data extraction from current systems and data scrubbing

and data preprocessing and that the Vendor will also be responsible for data import and validation into the

ERP and Loaning System.

5.3.3 Report Development

For specific reporting requirements, it is anticipated that the Vendor will take the lead on developing any

reports required as part of the initial deployment of the system. The Vendor is expected to provide specialized

knowledge and information to PHF staff during the development of needed reports, via technical training on

the tools used for report development and architecture etc.

Provide information on your reporting approach including:

Description of various methods of reporting (suggest Business Intelligence tool)

Methods for PHF to identify, specify, and develop required custom PHF reports during the

implementation.

5.3.4 Integrations and Interfaces:


Page 13 of 36

It is expected that information generally would need to be entered only once into the system. Modules within

the system should be integrated in real-time with each other such that batch processes are not required to

transfer information from one area of the system to another unless that is the preference of PHF.

Describe the extent to which the various modules are integrated together versus being purchased

separately and interfaced.

Describe your approach towards interfacing and integration with other solutions including use of

specific tools, methods and standards.

Describe data exchange standards (e.g. XML, Web Services, or EDI) supported or provided by your

product.

Identify potential issues for integrating with specific technologies.

If local customizations are made, do you provide any tools or assistance to easily incorporate

customizations into new version/releases of your software?

5.3.5 Training

Training is required in two main areas:

(a) Technical Staff, and

(b) Systems Users.

Three levels of System 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).

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.

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.

The Contractor is required to provide materials for training users. The User Staff training materials must

cover, at a minimum, the following topics:

Systems Overview

Systems benefits.

Data inputs.

Outputs and reports produced.

Major systems business

Functions User Manual contents and usage.

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.

Systems Operation

Job recovery

Job scheduling

Job cycles (daily, monthly, quarterly, annual and special)

Special forms usage;

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;


Page 14 of 36

Application structure and module / sub-module / program / subroutine relationships; Application

start-up / shut-down procedures;

Application back-up, recovery, and restart procedures;

Application security features;

Audit and testing procedures;

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/off-line and batch processing procedures;

Unique processing procedures;

Report generation procedures;

Menu structures, chaining, and system command mode operations.

PHF requires the training material on electronic media. All training material provided by the Contractor will be

reproduced and used as needed by PHF.

5.3.6 Change Management Approach

PHF recognizes that a movement from the current environment to a new solution will present change

management challenges. The Vendor should clearly identify their approach towards Change Management

including any unique approaches or tools that will be used.

5.3.7 Testing

The Vendor should describe their recommended approach to the following types of testing that are anticipated

to be performed on the project and the type of assistance they anticipate providing to PHF related to such

testing:

System Testing

Integration Testing

Stress/Performance Testing

User Acceptance Testing (UAT)

Automation Testing Approach

Usability Testing

Integration Testing

Data Migration Testing

Testing environment on cloud (other than production environment on cloud) would be responsibility of the

vendor.

5.3.8 System Documentation and Manuals

Vendor is expected to provide user manuals and online help for use by PHF as part of the initial training (these

are different from the training material for the trainings) and on-going operational support. Additionally, the

Vendor is expected to provide technical documentation.

Describe what documentation (user guide, technical guide, training materials, etc.) is available on the

system proposed and any related costs.

Describe what types of documentation you anticipate developing during the course of the project.

Disaster Recovery Plan Please describe the services you provide around disaster recovery, if any, as

part of your proposed solution.

5.4 Knowledge Transfer

Vendor should describe their processes for ensuring that a transfer of knowledge occurs back to PHF staff such

that staff is capable of supporting and maintaining the application in the most proficient manner once the Vendor

implementation engagement is complete. The complete source code will be also be provided.

5.5 EXCEPTIONS AND DEVIATIONS

If the Vendor finds it impossible or impractical to adhere to any portion of these specifications and all attachments,

it shall be so stated in its proposal, with all deviations grouped together in a separate section entitled,

“exceptions/deviations from proposal requirements.” This section will be all-inclusive and will contain a definition

statement of each and every objection or deviation with adherence to specific RFP sections. Objections or


Page 15 of 36

deviations expressed only in other parts of the proposal, either directly or by implication, will not be accepted as

deviations, and the Vendor in submitting a proposal, will accept this stipulation without recourse.

5.6 ADDITIONAL MATERIALS

Use this section to include any additional information or materials that are relevant to PHF, but not specifically

requested in another section of this RFP.

5.7 ADDENDA

Include all original, signed copies of addenda in this section.

5.8 COST PROPOSAL

One (1) original cost proposal, one (1) copy of the cost proposal.

Any errors providing an accurate price response due to inaccuracies in the provided excel are the sole

responsibility of the responding vendor.

Costs should include the complete and all components.

For each item, indicate if the cost is one-time, annual, or other. In the event the product or service is provided

at no additional cost, the item should be noted as “no charge” or words to that effect.

6. SCOPE OF WORK

6.1 OPERATIONAL REQUIREMENT – ERP SYSTEM

The design and implementation should consider the following features:

Operational efficiency

Improved consistency and accuracy

A helping hand for employees

Self-Services and published portals

We will be able to provide imagery, but apart from this we are open to receive input from the vendor regarding

best practices and designs.

6.2 FUNCTIONAL REQUIREMENTS

We are targeting out of the box solution providers and, as such, we expect to be provided with Industry

standard solutions. We expect the respondents to dilate upon the general features of their product: reporting capabilities, documentation, on-line support, software architecture and advantages thereof, etc.

We would also like for the vendors to specifically mention and recommend third-party solutions where the

proposed solution does not support that requirement. Following are the functional requirements for the ERP financial system and loaning system that we intend to

implement in the first wave and is of immediate interest to us. Vendors must complete this section and additional information has to be produced where necessary.


Ref. # Requirement Description Response

7.3 General Ledgers (GL)

7.3.1 Global settings

7.3.1.1 Able to enter the foreign currency exchange rates for automatic translation of

foreign currency balances:

Manually

Automatically (e.g. via the internet)

7.3.2 Accounting Period

7.3.2.1 Different fiscal reporting calendars must be available.

7.3.2.2 Able to control the posting periods centrally for all account types (e.g. assets,

debtor, creditor, etc.)

7.3.2.3 Allow for special periods to facilitate year-end closing by dividing the last posting

period into several closing periods (at least 12 standard accounting periods plus 1

to 3 accounting periods for adjustments).

7.3.2.4 Able to control users to access past period for adjustments (e.g. to re-open a

period that has been closed).

7.4 Chart of Accounts

7.4.1 Flexible to accommodate current and any proposed chart-of-accounts structures

and organization structure.

Able to provide facility to define and relate the following logical grouping

structure and numbering convention to the chart of accounts (7 Levels):

Company

Department / Division

Location / Branches

Business Unit

Cost Center Profit Center

7.4.2 Able to provide facility to amend the entities (e.g. department, division) and its

relationship to reflect changes in the organization structure.

7.4.3 Multiple companies and multiple divisions with different chart-of-accounts must

be supported

7.4.4 Provide for numerical and alphanumeric chart of accounts

7.5 GL Master Record

7.5.1 Able to maintain the following master data record to store control information on

how

postings into the General Ledger account.

Name of account

Description

Type of account (e.g. revenue, asset)

Currency (local, foreign)

Tax posting

Reconciliation account in nature

Level of transaction details to be maintained within the GL account

Automatic posting to prevent manual posting to account (e.g. gain/ loss

on disposal)

Specify templates to capture details of recurring transactions. (e.g. fixed

prepayments and accruals) Allow amendment or deletion to recurring transactions prior to posting.


Perform the posting automatically according to user-defined specification.

7.5.2 Allow for multiple account entries (debits and/or credits) for each transaction

type.

7.5.3 Provide running total of debit/ credit amount.

7.5.4 Provide running total of transactions in each batch.

7.5.5 Handle user-defined base currency GL processing for all accounting entities.

7.5.6 Handle multi-currency processing.

7.5.7 Provide a journal edit listing on screen or printed. The information should

contain, but not limited to the following:

Batch number

Journal posting date

Journal creation date

Journal type

Source of journal (e.g. via interface system)

Journal text

G/L account code, G/L account name and description

Debit/ credit amount

Batch total

Number of transactions

7.6 Periodic Processing

7.6.1 Able to perform month-end and year-end closing.

7.6.2 Able to automatically / manually initiate a new financial year.

7.6.3 Able to automatically update the closing balance of the previous period and

opening balance of the current period with prior period transaction postings for

all ledger balances. (e.g. actual, budget, statistical).

7.6.4 Able to automatically transfer net balances of the current year to retained

earnings account. (for year-end closing)

7.7 General Ledger Integration

7.7.1 Able to integrate with the following modules on real time basis, but should not

be limited to:

Accounts Receivable (Loan Management)

Accounts Payable

Cash Management

Fixed Assets

7.8 Reporting

7.8.1 Provide flexible Report Writer with the following minimum features

Specify the format and layout of reports;

Summarize and total the information to be reported;


Select records to be included in the report;

Select details from each record to be included;

Sort the information to be reported as one level within another;

Perform arithmetic calculation on the information selected or totals

thereof;

Ability to add narrative comments to reports

Ability to show financial data in thousands, millions etc. without creating

rounding problem

Store the report format for later use; and

Produce reports in graphical form for presentation

purposes.

7.8.2 Standard reports as being used in industry should be required in each module.

7.8.3 Consolidation:

Ability to:

Consolidate in multi levels

Consolidate actual and budget at balance sheet, profit/ loss account,

cash flow statement, expenses and revenue account levels

Automate generation of elimination transaction

7.9 Accounts Receivable: Generation of loan schedule, loanee alerts for

system

7.9.1 Customer Master Data

7.9.2 Flexibility to provide account numbers: Automatic Preferred

Automatically

Manually (by the user)

upon creation of new customer account.

7.9.3 Able to control the creation and change of customer’s master data according to

user authorization.

7.9.4 Able to maintain the following master data, but should not be limited to, as

follows:

Account name

Account address

Customer classification (type)

Credit worthiness rating

Surcharge/ Dunning specification

Incoming/ outgoing payment specification

Customer’s agreement details

Customer contact details

7.9.5 Able to allow for specified fields in the master data to be made mandatory (e.g.

ID number) or optional entry.

7.9.6 Able to perform a consistency check on the account balance based on user

defined specification (e.g. customer has moved out, balance is zero, no

remaining open item) before account is marked for deletion.

7.9.7 Able to change all fields in the master data on line with real time update to the

customer account.


7.9.10 Able to maintain audit trail of changes such as the time of change, the user ID,

old and new field values.

7.10 Incoming Payments including recovery of loan

7.10.1 Able to:

Accept various payment methods cash, cheque, bank draft, money/

postal order from a walk-in customer or via post (except for cash) credit

card, bank transfer by telephone or the internet

Update the customer account immediately.

7.10.2 Able to automatically calculate any surcharge / penalty / Misutilization / waiver

due to customer and post the amounts to customer account.

7.10.3 Able to provide fast entry template to enter incoming payment details manually

in the system to update the customer accounts, able to take upload from excel

sheets.

7.10.4 Able to issue a receipt or validate upon payment and intimation via SMS and

Email accordingly.

7.11 Document Posting

7.11.1 Able to provide for electronic notification to make posting into the customer

account such as:

Track status of work

Delegate work to user

Prioritize work

Define activities involved for each stage

Track time taken to complete tasks

Enter transaction information

7.12 Dishonored Cheque Processing

7.12.1 Able to capture reasons for dishonored and maintain the customer’s payment default history.

7.12.2 Able to charge penalty to the customer account based on PHF’s policy.

7.12.3 Surcharge on overdue balances 7.13.3 Able to print reminder letters that contain the following information, but should

not be limited to, as follows:

Reference

Date of reminder letter

Customer account number

Name of customer

Location of premise

Amount overdue

Other remarks

7.14 Customer Account Enquiry 7.14.1 Able to locate a customer account using powerful search engines. Common

search fields

include ID number, name (first name, last name), address, customer account number.

7.14.2 Able to: Analyze customer balance via multiple views – outstanding

balances, payment items, statistical items, all paid and unpaid

items

Search, sort by fields, total, sub-total

Drill down to document details

Drill down to master data information (includes technical data such as

type of meter)


Inquire payment history, dunning history, installment history

7.15 Account Payable

7.15.1 Payment Processing

7.15.2 Able to create a proposal list by determining:

What is to be paid- items to be paid are selected and grouped for

payment based on user-defined rules

When payment is carried out. – based on user needs (e.g. due date of

the items)

To whom the payment is made - by specifying the payee

How the payment is made –based on the payment method (e.g. cash,

cheque) foreign or local currency) according to rules defined by the user.

From where the payment is made – based on specified bank and a

bank account for the payment.

7.15.3 Able to make payment via various payment methods such as:

Cash

Cheque – manual and pre-printed

Bank notification (transfers)

Foreign currency

Credit Card

Internet payment

7.15.4 Able to store other deposit information such: type of collateral

start and expiry date of guarantee

bank guarantee information (e.g. bank guarantee reference number)

7.15.5 Able to update the initial deposit request with bank guarantee information such

as:

Guarantee reference number

Type of guarantee

Name of guarantor

Amount

Start and expiry date

7.15.6 Able to generate recurring payment voucher.

Recurring payment information are:

Name of vendor

Invoice number;

Recurring amount;

Accounting information;

Start and end payment date;

Frequency of payment indicator to identify the frequency of the

recurring payment (e.g. weekly, monthly, quarterly, biannually, annually).

7.15.7 Allow recurring payment to be deleted within its period of payment.

7.15.7 Able to make payment in foreign currency:

Specify the bank account to which the payment is made from.

Specify whether it is possible to use the payment method to pay in

foreign currency

Specify particular currencies per payment method


7.15.8 For paying bank account, able to:

Bank account selection based on payment method and currency

Check whether the selected bank accounts have sufficient funds for

payment

7.15.9 For receiving bank account (if payment method used requires vendor bank

details, e.g. bank transfers), able to:

Specify bank details during the payment run

Retrieve bank details from the vendor master data

7.15.10 Able to print the vendor name on cheque for payment of miscellaneous invoice,

where vendor records have not been created.

7.15.11 Ability to amend payment or payment batches with record of amendment /

deletion.

7.15.12 Able to display changes made and by whom.

7.15.13 Able to allow invoices to be released for payment prior to due date.

7.15.14 Able to manage part payment of invoice.

7.15.15 Able to display or print exception listing. The exception listing should contain

blocked items and all outstanding items which the payment program did not

propose for payment (items that could not be settled despite being due)

7.15.16 Able to divide the task of editing the payment proposal between various users

and enable several users to edit large payment runs at the same time.

7.15.17 Able to perform payment approval functions to enable certain payments to have

prior approval.

7.15.18 Able to provide the ability to offset balances of vendor accounts in AP with

balance of customer accounts in AR (for vendors who are also customers).

7.15.19 Able to integrate payments to a cash management system.

7.15.20 Able to perform various display functions within a vendor account such as

search, sort, display additional details (e.g. vendor master information), total,

view by currency, obtain total purchase per posting period etc.

7.15.21 Able to display check payment information on-screen based on check number or

payment document number. The information includes:

Details on the check recipient

Details on the check issuer

Corresponding payment and invoice documents

7.15.22 Able to provide online enquiry capability to vendor information via user defined

selection and sorting criteria (e.g. all vendors that are on-hold).

7.16 Reporting

7.16.1 Built in / User defined reports as required.

7.17 Asset Accounting

7.17.1 Fixed Asset Organization

7.17.1.2 Able to define fixed assets at different levels such as:

Group asset (main and components)

Asset class (Group asset belongs to an asset class)

Asset type (e.g. tangible and intangible)

Balance sheet (asset class is assigned to GL account code. This forms

the balance sheet item)


7.17.1.3 Able to assign an asset to a specific reporting unit or business area (e.g. region/

branch offices) for internal reporting purposes.

i.e. When an asset is assigned to a specific reporting unit, the system should

automatically post the transactions such as depreciation and gain or loss on

disposal, to the account related to this asset to this reporting unit.

7.17.2 Fixed Asset Master Data Maintenance

7.17.2.1 Able to maintain the following information in the fixed asset master, but should not be

limited to:

Asset number

General information (e.g. description, make/ model, quantity)

Posting information (e.g. capitalization date and amount, asset expiry

date)

General ledger account assignment

Accumulated depreciation

Depreciation

Gain/ loss on disposal

Revaluation

Time-dependent assignments (e.g. cost center reporting)

Information on the origin of the asset (vendor information)

Physical inventory data

Insurance data/ warranty

Depreciation data – asset useful life, depreciation method

Asset location

Project/ job number

7.17.2.2 Examples of information required to be maintained within the Fixed Asset

system are as follows:

Responsible unit (e.g. region, station)

Physical location of asset

Usage (e.g. building – staff quarters, power station)

Quantity

Unit measurement

Description/ additional information (e.g. land title number, capital

project number)

Source of funding (e.g. capital contribution, own funds)

7.18 Integration

7.18.1 Able to provide for automatic integration with General Ledger, Accounts Payable,

Accounts Receivable, Project Management and Budget, including the following

capability:

Automatic posting to G/L account;

Drill-back capability to Account Payable (e.g. Invoice, Purchase Order etc)

7.19 Reporting and Enquiry

7.19.1 Able to display asset description at individual asset level, summarized levels (e.g.

asset class, by balance sheet) and by particular asset (e.g. asset number).

7.19.2 Able to provide drill-down from asset descriptive details to:

Balances

Depreciation

GL account code


7.19.3 Able to provide asset information, but should not be limited to :

By date, year (e.g. by year of capitalization, year of disposal)

By type of transaction (e.g. acquisitions)

By asset location – for small assets which are portable

By responsibility unit (e.g. department, region, station)

By asset class (main asset group, sub group, asset number)

By user-specified rules (e.g. list asset greater than Rp100,000,000)

7.19.4 Able to provide searches and look-ups to search for a particular asset (e.g. asset

number).

7.19.5 Able to produce reports for various reporting, flexible report writing tools and on-

line enquiry facilities for (but not limited) to the following:

Financial reporting (e.g. audit and taxation)

Management reporting

7.19.6 Examples of standard reports are listed, but should not be limited to, as follows:

Assets at gross separately from accumulated depreciation – for period

and year-to- date

Asset master at summary and detail level

Asset additions

Asset retirements

Asset valuation – gross asset values, accumulated depreciation and NBV

Assets by source of funds (e.g. capital contribution, own funds)

Depreciation expense using flexible user selection criteria

Depreciation schedule showing opening, movements and closing written

down values

Depreciation forecast

GL posting summary

Assets not received inventory count

Asset found at location other than that assigned in the asset record

7.19.7 Able to to): provide ad hoc listings based on user defined specifications such as

(but not limited Select and sort by asset category

Select or exclude fully depreciated assets

Select or exclude retired assets

Select by GL account codes

Select by business units

Select by asset status

Select by asset location

Select by asset life within asset book

7.19.8 Able to provide reports that can analyze asset information:

By responsibility unit (e.g. region, branch offices)

By time period (e.g. year)

By company, asset type, department and location.

By movement (such as addition, transfer or disposal) by account, current

month or year-to-date activity.


7.19.9 Provide for complete asset history, for example:

depreciation, depletion and amortization current period, year-to-date,

accumulated

net book value and residual value for finance and tax

remaining life

transaction history with line-item

repair and maintenance tracking

warranty

insurance

acquisition and retirement date.

7.19.10 Reconciliation of fixed asset movements

Opening balance

Additions

Disposals

Transfer in/ out

Adjustments

Qualifying costs

Non-qualifying costs

Closing balance

7.20 Cash Management

7.20.1 Bank Reconciliation

7.20.1.1 Ability to enter bank statement details: Bank Statements are received in

Excel/Acrobat format

manually

by electronic means

to match bank transaction information with receipts and payments in the system

to produce an electronic bank reconciliation.

Bank statement transactions that can be recorded include, for example:

8 Loan Management System Workflow

8.1 The process consists of following distinct components. Moreover, the system has to

be flexible enough to incorporate any new rules / initiatives launched by PHF. The

procedures and checklists of various loaning schemes are also available at

www.phf.punjab.gov.pk. Any further information can be obtained from the focal

person of the ERP project.

Loan Application Receiving

Loan Application Screening

Loan Approval

Loan Disbursement

Loan Recovery

Redemption of Loan guarantees

8.2 Loan Application Receiving:

Design and Development of Customers (Loanees) Registration with following

features:

Profile Creation of customers



Customers Personalized environment to view the status of their application

according to the activities at PHF loan processing.

Confirmation of Registration through Email and SMS

Documents (pdf / doc / jpg) Upload screen with storage provision in system

8.3 Loan Application Screening:

Contact Management of customers (Applicants)

Reports and Dashboards.

Customers data analytics.

GIS Map of the customer’s location

Site Inspection record keeping

Provision of upload of Inspection report

Template for Working Paper

8.4 Mobile APP (Android based) for Site Inspections:

Development of mobile APP to capture the GIS coordinates

Capture the photos of sites being inspected

8.5 Application Approval Matrix:

The loan application at PHF goes through certain audit drill. The system has to

capture data and relevant documents at each stage.

8.6 Guarantee / Collateral Management:

There are various loaning schemes for various categories of health

professionals. The details are available at the www.phf.punjab.gov.pk with

corresponding checklists. The System has to automate the process of capturing the

documents electronically (in various formats pdf/jpg/doc) accordingly.

8.8 Loan Disbursement:

Automation of approval process.

Disbursement of loan installments through cheques or through Automatic

Fund Transfer system.

8.9 Loan Recovery Process:

Maintenance of recovery installments in the system.

It includes the generation of automatic alerts pre and post-dates of due

installment date.

The alerts will be generated through email and SMS.

Late payment surcharge calculations

Misutilization Penalty

8.10 Loan Redemption Process:

The process of redeeming the bank guarantees on completion of loans.

8.11 Reports:

Development of all relevant reports in the loaning system.

8.12 Email and SMS Alerts:

As per the policy of PHF.

9 Cloud Specifications

The Foundation intends to deploy the ERP system and loaning system on cloud

based environment.

9.2 Cloud Server for deployment of ERP (Minimum):

CPU (cores) : 4

Memory : 16 GB

Network : 1 Gbps



Storage : 100 GB

10.1 System Specification

10.1.1 ERP Implementation Environment 10.1.1.1

Should be able to cater for the following implementation environment:

Production

The following are optional:

Test

Development

Training

10.2 User management 10.2.1 Should be able to manage ERP users across the centralize user management).

10.2.2 Should be able to create, change, delete, cancel, track or monitor:

User IDs

User groups

User Accounts

Track Users

10.3 Print Management 10.3.1 Should be able to integrate with printers across the LAN & WAN.

10.4 System Monitoring 10.4.1 Should provide tools to provide system monitoring such as:

Display server’s status

Display & controlling of work processes

Controlling user sessions

10.5 System Memory 10.5.1 Should provide tools for memory management.

10.6 System Backup & Restoration 10.6.1 Should be able to perform backup and restore on:

Full Backup

Incremental Backup

Online backup

Recovery purposes

Data Compression

10.7 Security Standards 10.7.1 Should be able to support industry standard network security and management

protocols.

10.8 Master Data 10.8.1 Should have a single master data as a key piece of information that can be seen

from a

number of views corresponding to different functional modules.

10.9 Data Access 10.9.1 Should be able to provide real time data access to the centralized database

10.10 Firewall Technology 10.10.1 Deployment of reliable and dependable firewall technologies

10.11 Data Export & Import 10.11.1 Should be able to export and import data.

10.12 Data Entry


10.12.1 The input of data can be by:

On –line data entry

Scanning

EDI

Bar code

10.12.2 Should be able to select:

Profiles from user maintained tables

Populate data entry fields

10.12.3 The system should be able to provide:

Escape or cancel facility provided on all data entry screens.

Scroll bar facility for any data displayed exceeds the capacity of the window.

Optional or mandatory data entry fields.

Copy existing records as templates but override any of the values for:

o The creation of transactions

o Records for static data (e.g. vendor & debtor etc.)

10.13 Data Validation 10.13.1 Should be able to perform the below functions for data validation:

Common validation tables for all modules

Data reasonable checks

Data range checks

10.13.2 Should be able to:

Define business rules for transaction updates

Define validation rules to any user-defined data entry field.

Change validation rules for any standard data-entry field

Maintain a log of any changes to business and validation rules.

10.14 Data Integrity 10.14.1 Should be able to rollback to the last synch point upon abnormal termination

avoiding data corruption

10.15 Data Interfaces 10.15.1 Should be able to accept input from a variety of media, but not limited to:

CD-Writer (CD-RW)

USB Supported Devices

10.16 Data Archiving 10.16.1 Should be able to provide a facility within the application to archive data.

10.16.2 Should be able to support archiving data to an external media, but not limited to:

CD ROM


10.16.3 Should be able to restore archived data easily from:

CD ROM


10.16.4 Should be able to provide user-defined control over the archive process with respect to:

The timing of archiving

Data item selection

Compression of data

10.17 Archive Listing 10.17.1 System has the provision to view the archived data


10.18 Date & Time 10.18.1 Should be able to facilitate:

System should support multiple date and time formats.

10.19 User On-line Help 10.20 Should be able to provide context sensitive help for:

Data entry fields

Menu items

Buttons

Icons

The application server should be able to provide search facility on all

help and user documentation within any open window. The application server should be able to tailor help information. The application server should be able to provide on-line help via Internet.

10.20 Re-confirm task 10.20.1 Should provide a facility for the user to confirm or deny action to be taken before:

Critical functions such as deletion of data

Updating key transactions

10.21 Wild cards 10.21.1 Should allow wild card searches.

10.22 Case Sensitive 10.22.1 The system should provide optional case sensitive searches.

10.23 Authorization 10.23.1 The system should only allow authorized users to update system tables. 10.23.2 Any menus and menu options displayed are determined by user access privileges. 10.23.3 Should be able to extend the security to access:

Report writing facilities

The production of standard reports

10.23.4 Existence of a screen displaying the list of users logged on to the system.

10.24 Password

10.24.1 Should have the following criteria for password settings and restrictions:

Encrypted

Passwords can be changed by:

o End user

o IT Management team User-defined enforced periodic password changes

Password changes requires user to re-confirm or key in the new password

twice

o Prevention the re-use of a previous password

10.25 User Access 10.25.1 Should be able to perform the option to activate/deactivate automatic logoff after:

A specified period of screen inactivity.

A pre-determined number of unsuccessful attempts to logon.

10.25.2 Should be able to allow user access privileges in terms of:

Application modules

Menu options accessible to the user

Read or update access

Specific type/s of update access (i.e. add, change, delete)

Accessing specific records of each record type

Values for a field the user can/cannot use


Access to data can be controlled to each component of the organization structure

10.25.3 Should be able to generate report to list for: Users who have accessed the system and what they have accessed

Users and their security access

Attempts at unauthorized access

10.26 Security Maintenance 10.26.1 System security can be maintained on – line and updated in real – time.

10.27 Optional Settings 10.27.1 Can optionally delegate nominated security functions to other authorized users.

10.28 Database Management 10.28.1 Able to provide an easy-to-use and standard call interfaces for the main

programming

languages

10.28.2 Able to provide object oriented features 10.28.3 Able to supports the industry standard structured Query Language (SQL) 10.28.4 Able to provide tools with which to analyze/optimize the data access paths needed

to

process a SQL command

10.28.5 Able to communicate transparently with other copies of the same or different DBMS running

on other machines via a network to gather the requested information regardless

of where the required data resides

10.28.6 Able to support multiphase commits to ensure the integrity and correct sequencing of

updates across multiple databases

10.28.7 Able to provide the facilities to recover the database in the event of a disk or system crash.

Recovery will be automatic, fast and reliable

10.28.8 Able to perform remote database synchronization facility by automatically and transparently sending update images to be applied to the remote database periodically

10.28.9 Able to provide tools and utilities to maintain and manage the database, e.g. tools to

unload/reload, expand, repair and recover the database

10.28.10 Able to perform database utilization statistics and performance measurement statistics

10.28.11 Able to expand easily without having to unload/reload or rebuild any database structures.

Any expansion would only involve a change in the database definition without

affecting the physical files

10.29 Backup and Recovery 10.29.1 Able to perform for on-line, off-line and end-of-day back up. In the event of

disaster, the system is able to recover up to the last transaction processed. An automatic recovery

process that is easy to implement is to be provided should the system or the hard

disk crash.

Vendor should provide formal Business Continuity Strategy and Plans that describes

the approach that will be taken to adhere to requirements and perform business

disaster recovery activities, which shall include:


10.29.2 Able to maintain data consistency and accuracy across database(s) to ensure data integrity

10.29.3 Able to perform on-line data retention for five (10) years is anticipated 10.29.4 Plan for a backup and recovery to create an automated backup of the ERP server. 10.29.5 Contingency and backup recovery procedures with guaranteed Service Level

Agreements (SLAs).

10.29.6 Option to specify the frequency of backups to be taken for:

Transaction Data

Master Data

Static data files / reference files

10.29.7 Able to have facility for on-line back-up while users are logged on 10.29.8 Backups do not prevent the system from being available at all times and do not

disrupt system operations.

10.29.9 There is no performance degradation during data back-up.

10.29.10 Briefly describe the recovery process after a system failure during on-line processing

10.29.11 Briefly describe the recovery process after a system failure during batch processing

10.30 Configuration Management Requirements 10.30.1 Able to provide the following:

Document Configuration Items:

o Customer functional specifications

o System design documentation

o Database schema

o Program sources

Software Configuration Items:

o Application Software

o System Software

10.30.2 Control Procedures: Able to perform software change management. Describe any software

change and release management facilities provided. Indicate how these facilities

support development of new software, maintenance of production system and

new versions of software

10.30.3 Describe any document change and release management facilities provided. Indicate how

these facilities support development of document (e.g. User manuals, specification, etc.)

10.30.4 Ability of the system to support standardized development and production environment for

the following:

Naming convention Database architecture

Program design

System navigation

10.31 Conversion 10.31.1 Able to provide conversion method and describe the methods and tools available

for the

conversion of legacy system data to the proposed system.

10.32 Cross Modules 10.32.1 The Loan Management System must be integrated to ERP solution.

10.33 Data Entry Screen 10.33.2 Screen labels displayed in English. 10.33.3 Able to perform scroll, tab or valid list options facility to guide users through data

entry.

10.33.4 Able to perform multi session facility to allow ease of movement the system and functions,


user can use several screen sessions to perform the job.

10.33.5 Able to create a user menu that reflected their job description. It will hide all un-authorize

functions and tasks.

10.34 Executive Information Module (EIM) 10.34.1 Able to generate the requested reports of all modules. 10.34.2 Able to print control reports regardless whether there are transactions/activities 10.34.3 Able to sort reports into the various wings, regions, business operating units, cost

centers, etc.

10.34.4 Able to provide a flexible report writer/generator for the user to:

Specify the format and layout of report

Summarizes information to be reported

Select information to be included in the report

Sort information to be reported according to user selected fields

Create user defined graphical display of reports

10.34.5 Able to have all outputs produced for on-line viewing or printed (hard copy) output based on user request

10.34.6 Able to route the report using standard e-mail system. 10.34.7 Able to allow users to print reports that have been routed for on-line viewing on

request

10.34.8 Able to ensure that all reports are uniquely identified, appropriately numbered and all pages

contain period dates and times when the reports were created

10.34.9 Able to identify clearly the last page or end of all reports

10.35 Uploading/Downloading data

10.35.1 Able to perform upload/download of data of systems 10.35.2 Able to perform upload/download of data to PC in text format or PC Application

e.g.

Microsoft EXCEL, Microsoft WORD for analysis and graphical report/presentation.

10.36 Navigation and Data Access

10.36.1 Able to access and use the on-line system functions 24 hours per day, 7 days per week, including during batch processing cycles, database logging and database back-up cycles.

10.36.2 Able to switch to different programs and modules without interrupting the existing application

10.36.3 Able to perform all navigation to subsystems and functions using Microsoft Windows or

above navigation standards, including:

Controls panel lists and sub-lists

Icons

Tabs

Buttons

10.37 Transaction Validation and Management

10.37.1 Able to indicate which fields are mandatory and optional, prompting users in advance for

required data

10.37.2 Able to perform all edits and validations on-line at time and point of entry for all input

10.37.3 Able to present error messages that clearly indicate the exact nature of the error and the field in the error and possible solutions

10.37.4 Able to allow transactions that are in error to be saved in a transaction recycle file that can be accessed on-line to correct errors and re-submit the data

10.38 Transaction Controls 10.38.1 Able to check for duplicate document or data entry


10.38.2 Allow to validate field entry to the valid master data 10.38.3 Prevent storage of in-valid transaction

10.39 Run Controls 10.39.1 Able to execute all jobs from menu options, including scheduling batch job runs 10.39.2 Able to run specific transaction processing, posting, reporting and other processes

on

specific defined update cycles:

Daily transaction processing cycle and postings

Periodic and monthly interface update cycles.

Monthly update and posting

Monthly archive cycles

Quarterly closing and reporting cycles

Annual closing and reporting cycles

10.40 Identification Management 10.40.1 Able to require the user to perform valid identification for all accesses

10.40.2 Able to provide an on-line, real-time facility for the system administrator to:

Define the security and privacy of information

Add and remove users in the system

Change the security profile of users

10.40.3

10.41

Able to control security profiles of their users at various levels of authorized officers apart

from the security administrator

Access Controls

10.41.1 Able to define an expiry date for an user IDs 10.41.2 Able to provide automatic log off of user ID after a certain time period 10.41.3 Able to prevent passwords from being viewed or printed by any user including the

security

Administrator

10.41.4 Able to set maximum number of password attempts 10.41.5 Able to have different levels of access within a system. Restrictions should apply

to:

Business units

Functions

Fields

Screens, etc.

10.41.6 Able to specify read-access only of some fields of some users based on the access profile

10.42 System Controls 10.42.1 Able to encrypt the security database, password and data across data

communication media

10.42.2 Able to perform the functionality to inhibit unauthorized operators printing hard copies of

restricted reports

10.42.3 Able to perform the functionality to inhibit unauthorized operators execute of restricted

functions/transactions

10.42.4 Able to control the distribution of reports

10.43 System Monitoring & Performance 10.44.1 Able to register any attempts (successful and unsuccessful) to access restricted

resources

codes identifying the operator, terminal, date and time

10.44.2 Able to maintain a log of log-on, log-off and security violations


10.44.3 Able to complete audit trail for tracking transactions through the system showing who entered the transaction, who authorized the transaction, when they were entered and terminal entered

10.44.4 Able to facilitate immediate notification of violation on highly restricted resources 10.44.5 Able to notify networking operator on any attempted system hacking (attempted

access from unknown locations)

10.44.6 Able to produce reports which show all allowable accesses for users including systems,

locations and access level within system

10.44.7 Able to produce a variety of audit reports giving details of sensitive transactions, including

date, time, User ID, old and new values for changes

10.44.8 Able to perform on-line audit trail for a specified period of time before being archived

10.44.9 Able to produce Access Control Report which shows all unauthorized or irregular access to

systems including date, time, User ID, location workstation ID and any sensitive

transactions (e.g. Password rejected, user not allowed in system, job submitted

to update master file)

10.44.10 Able to define frequency, types and details of exception reports 10.44.11 Able monitor system performance and produce performance reports

10.45 Input Controls 10.45.1 Able to minimize data entry by providing standard data from master files,

parameter files and through the use of pre-defined defaults at the field level

10.45.2 Able for error correction facilities to:

Correct fields during current data input session

Highlight of all errors on input screen

Perform for transactions not being posted if errors are encountered

-posted to rejects file and later reconciled Details error messages describing type of error

Modify/amend information on an ad-hoc basis (e.g. without having to

page through a large number of screens in order to access desired

screen)

10.46 Data Security and Integrity 10.46.1 Able to allow data access only through the application data inquiry, update and

reporting

processes, e.g. prevent data access outside of the application

10.46.2 Able to limit inquiry, update and reporting access to data base in user application security

level or group, e.g. limit access to sensitive data items to the assigned group

responsible for management of that data

11. SLA FOR CLOUD SERVICES

PHF is considering cloud services for ERP solutions. Tenderer must include it in this section of the Vendor's

proposal:

1. Describe your vendor Cloud model, including: hosting, integration, help desk, provisioning and desktop

management capabilities, deployment model (dedicated servers, shared environment, etc.), impact to the

PHF’s network and bandwidth, and any partners that may be involved in service delivery.

2. Describe your proposed service level agreement ("SLA") for cloud services, including any tiered levels of

service, response times and standard metrics. Provide a sample of the SLA Cloud services.

3. Describe your support model, including: cost structure for support calls.

4. Describe your data center and storage facilities, including: locations, staffing, physical security,

environmental controls (including redundant power), redundancy/load balancing capabilities, data backups

and disaster recovery capabilities.


5. Describe your logical security, including: firewall security, authentication controls, and data encryption

capabilities.

6. Describe your change management, upgrade, and patch management policies & practices.

7. Describe your systems administration/management capabilities including: monitoring of performance

measures, intrusion detection, and error resolution.

8. Describe how you will help PHF move to a new operation at the end of the Agreement term or if the

Agreement is terminated, including the process for notifying of termination.

12. SUPPORT

Vendor shall provide Help Desk Services for reporting errors and malfunctions and for trouble shooting

problems. Vendor’s Help Desk Services shall be web-based and/or by telephone lines and/or via e-mail. Vendor’s

Help Desk Services shall include, but are not limited to, the following services:

Assistance related to questions on the use of the software solution;

Assistance in identifying and determining the causes of suspected errors or malfunctions in the software

solution;

Advice on detours or workarounds for identified errors or malfunctions, where reasonably available; and

Information on errors previously identified by PHF and reported to Proposer and detours to these where

available;


Annexure – ‘A’

Licenses / User Specifications

S No Description Number of Users*

1 ERP 5 / 10 (in-house users)

2 Loan Management System 10 / 30 (in-house Users) and 100

Concurrent users through online

portal

* Subscription based licensing may be quoted