Section 00003, Table of Contents - City of PeterboroughAssets/eTenders/Clos… · Web viewFailure to provide the items required may result in the rejection of the Proposal ... Are

P-07-14 City of Peterborough Budgeting Software Solution Page 1

Attachment 1 - Representation, Warranty and Acknowledgement Regarding Accessibility Training

Insert Company Name _______________________________________________

Hereby represents and warrants that:

My/Our employees, agents, volunteers, or others for whom I/We are responsible, will have successfully completed Accessibility Training as required in this RFP prior to commencement of the Project on behalf of the Corporation of the City of Peterborough, in accordance with the award of RFP # P-07-14 City of Peterborough Budgeting Software Solution

Acknowledgement

I/We, the undersigned, acknowledge and agree that this representation and warranty will be relied upon by the Corporation of the City of Peterborough and as such I/We solemnly provide this representation and warranty as if it were given under oath.

I/We have the authority to bind the company:Company Name:

Signature(s):

Name(s):

Title(s):

Date:


Appendix A - Submission Cover Page and Checklist

Request for ProposalsDocument No. P-07-14

City of Peterborough Budgeting Software Solution

Submit To:City of PeterboroughCorporate Services, Tenders and ProposalsMain Floor, City Hall500 George Street NorthPeterborough, Ontario K9H 3R9Attn: Sandra Clancy,Director of Corporate Services

Submitted By:

Company Name

Address


Appendix A - cont’dChecklistThe Proponent shall include all items with an “X” in the "City Required" column in their Proposal submission and in the order shown below. Failure to provide the items required may result in the rejection of the Proposal submission as incomplete. “N/A” shall mean not applicable to this RFP and not required in the Proposal submission. The Proponent shall mark an “X” in the “Proponent Included” column to indicate the items that are included in their Proposal submission.

City Required

Requirement Proponent Included

X One Original and five copies of Proposal Submission - Items 5.3.2 and 5.3.3

Provide the Following with Original and all Copies in the order stated

X Submission Cover Page and Checklist - Appendix A - Items 5.3.1 and 5.10.1

X Acknowledgements - Appendix B - Item 5.10.1

X Pricing - Appendix C - Item 5.10.1 and Item 6.6

XSub-Contractors/Suppliers/Sub-Consultants - Appendix D - Item 5.10.1 and Item 6.4

X References – Appendix E - Item 5.10.1

X User Requirements for Budgeting Software - Appendix F - Item 7.5

X Proponent Information - Item 5.10.2

X Project Understanding and Approach - item 5.10.3

X Methodology and Work Plan - Item 5.10.4

X Schedule - Item 5.10.5

X Project Manager - Item 5.10.6

X Project Team - Item 5.10.7

X Value Added Services - Item 5.10.8


Appendix B - Acknowledgments

I/We Acknowledge that this Proposal is made without any connection, knowledge, comparison of figures or arrangements with any other company, firm or person making a Proposal for the same goods/services and is, in all respects, fair and without collusion or fraud.

I/We Acknowledge that all matters stated in the said Proposal are, in all respects, true.

I/We Acknowledge that, having read RFP #P-07-14, I/We have satisfied ourselves as to the Terms, Conditions and Specifications and do hereby submit a Proposal, including Pricing as set out in Appendix C, for City of Peterborough Budgeting Software Solution.

I/We Acknowledge that addenda have been issued for this RFP and that I/We understand it is the Proponent’s ultimate responsibility to ensure all addenda issued have been received. NOTE: failure to include the correct number of addenda in this Appendix may, at the discretion of the City, result in disqualification of the Proposal submission.

I/We Acknowledge that acceptance of this Proposal and the issuance of a Purchase Order shall be considered a binding contract upon both parties. If specified at any time by the City, it is agreed that the terms and conditions and any representations made in reference to this RFP shall be incorporated in a Contract to be executed by the parties once the City has formally accepted the Proposal.

Dated at ____________________ this _____ day of ______________ 2014.

Firm or Organization Name Signing Authority

Street Address Signature

City Postal Code Telephone and Fax Number

Email


Appendix C - Pricing

Please submit a detailed pricing sheet that includes a full breakdown of all your costs. Pricing will be compared based on five year cost of ownership.

Part 1.0 Hardware Line Description Quantity Price1.1 $

1.2 $

1.3 $

1.4 Hardware Sub-Total Sum of Lines 1.1 to 1.3

$

Part 2.0 SoftwareLine Description Quantity Price2.1 $

2.2 $

2.3 $

2.4 Server Software Sub-TotalSum of Lines 2.1 to 2.3

$

Part 3.0 Maintenance/WarrantyLine Description Quantity Price3.1 $

3.2 $

3.3 $

3.4 Maintenance/Warranty Sub-Total Sum of Lines 3.1 to 3.3

$


Appendix C – cont’d

Part 4.0 Installation ServicesLine Description Quantity Price4.1 $

4.2 $

4.3 $

4.4 Installation/Incidental Sub-TotalSum of Lines 4.1 to 4.3

$

Part 5.0 TrainingLine Description Quantity Price5.1 $

5.2 $

5.3 $

5.4 Training Sub-TotalSum of Lines 5.1 to 5.3

$

Part 6.0 Incidentals - please describeLine Description Quantity Price6.1 $

6.2 $

6.3 $

6.4 Incidentals Sub-TotalSum of Lines 6.1 to 6.3

$

Part 7.0 Project TotalLine Description Price7.1 Protect Sub-Total

Sum of Lines 1.4 + 2.4 + 3.4 + 4.4 + 5.4 + 6.4$

7.2 HST for Line 7.1

$

7.3 Project TotalSum of Lines 7.1 + 7.2

$

Note: Lowest or any Proposal not necessarily accepted.


Appendix D - Sub-Contractors/Suppliers/Sub-Consultants

Submit a list of sub-contractors/suppliers/sub-consultants to be used for the supply of the goods/services, or indicate “Not Applicable”.

Contact DetailsName: Company Name:

Type of Goods/Services provided:

Phone: Address:

Email: Years in Business:

Name: Company Name:


Phone: Address:


Name: Company Name:


Phone: Address:


Note:If insufficient space is provided in this Appendix, please provide the required information in the same format on a separate form and attach to this Appendix.


Appendix E - References

Please list a minimum of three references where your company has provided similar goods or services within the last two years and indicate the goods/services provided.

Company Nameand Phone Number

Contact Person(s) Type of Goods/Services Provided

1. Goods/Services:

Dates:

2. Goods/Services:

Dates:

3. Goods/Services:

Dates:

4. Goods/Services:

Dates:

Note:If insufficient space is provided in this Appendix, please provide the required information in the same format on a separate form attached to this Appendix


Appendix F – User Requirements for Budgeting Software Solution

Note: See Item 7.5 for additional information on the requirements of Parts 1.0 to 8.0.

Note: Priority High is to be considered mandatory, medium/low are levels of criticality that may be considered optional.

Note: If there is insufficient space in the Appendix to provide information, the Proponent may attach additional information to Appendix F, referencing the appropriate Part # and Line #.

Part 1.0 – Technical

Line # Required Information Internally Hosted SaaS

1.1 Specifications for servers required to run software. Indicate whether a virtual server and Storage Area Network; or “SAN” environment will meet your specifications.

1.2 Specifications for workstations required to run software.

1.3 Specification for any hardware peripherals required to run or integrate with software.

1.4 Additional software or licenses required to run application; e.g. operating systems, database licenses, reporting software, etc.

1.5 Can PTS create a copy of the database and application software for testing, training, etc. purposes?


Appendix F, Part 1.0 – cont’d


1.6 Is a test site available for testing, training, etc.?

1.7 Available system integration interfaces; e.g. application programming interface/API, web services, text file import/export, etc. Please indicate format(s) supported.

1.8 System architecture diagram.

1.9 Provide any firewall configuration requirements.

1.10 A description of target uptime and the frequency of emergency outages for the past 12 months.

1.11 Frequency of data backups.

1.12 Country data is hosted in.

1.13 Country backups are located in.

1.14 Disaster recovery plan including any associated fees.

1.15 Indicate recommended amount of client Internet bandwidth for running application.

1.16 Provide a copy of the standard Service Level Agreement; or “SLA”.

1.17 Confirm the City retains legal ownership of their data.




1.18 Description of the product warranty(ies).

1.19 Descriptions of the services included in the basic support plan, including response times. If other support plan options exist, please provide details and costing.

1.20 Description of after hours support plan.

1.21 Location of support centre and hours of operation.

1.22 Routine for upgrades and whether they fall into the category of any of the above support plans. Indicate if upgrades typically require professional services to complete and whether additional fees are associated with them.

1.23 Can PTS determine or influence when upgrades are applied to the software?

1.24 Provide a copy of the software's product roadmap and/or lifecycle plan.

1.25 Can PTS staff access the back end database for things like custom report development?

1.26 Is a data dictionary available?

1.27 Can data be exported from the software?




1.28 Describe process for exporting a copy of the entire database for on-site backups, loading data into another application, etc.

1.29 Description of user security options available in the software; e.g. security roles, types of access, etc.

1.30 Describe the logical security measures in place to protect data in vendor's data centre.

1.31 Security measures used to protect data during transmission.

1.32 Does application support LDAP for user authentication?

1.33 Does the software keep an audit log of data changes? If so, please describe. Can audit logs be viewed/ searched?

1.34 Does the software have the ability to archive/purge data, audit logs, etc.?

1.35 Does the software support a retention policy; e.g. employee training records are to be maintained for X years and then archived or purged?

1.36 Description of training available during system implementation.




1.37 Description of training materials available for Users and system Administrators.

1.38 Description of processes and solutions in place to manage, monitor, and respond to data centre and software performance.

1.39 How long does it take to respond to data restore requests?

1.40 How often are security audits/assessments completed at the data centre by internal staff? By an external auditor?

1.41 Can Proponent provide a certificate of assessment for their last security audit(s).

1.42 Describe the physical security measures in place.

1.43 How is backup data protected logically and physically?

1.44 Is Proponent's security posture supported by policies and processes?

1.45 Provide a security incident response plan.

1.46 Are actions performed by the Proponent's employees logged and reviewed?

1.47 Are background checks completed for Proponent's staff?




1.48 What is the turnover rate of support staff?

1.49 If the software has any externally facing/Internet accessible components, provide evidence of a formal security assessment/penetration test and an indication of the current software status with regards to this testing. Are security assessments on these components completed on a regular basis?

1.50 Would you be willing to have a member of PTS tour your data centre?


Appendix F – cont’d

Part 2.0 – SystemLine # Needs Priority

(H)igh(M)edium(L)ow

Comments Meets Requirement Yes/No/Partial

2.1 Web-based application for ease of access and maintenance.

H

2.2 Support of a back-end database would be preferable, in order to store data and provide a more robust and flexible system.

H

2.3 System should support 100 users initially. H

2.4 System should allow for additional users to be added beyond the initial 100 if required.

H

2.5 System allows for different levels of security to be set for different users – preferably “role” based.

H

2.6 System allows administrator to change security settings on a user-to-user basis as needed.

H

2.7 System integrates to LDAP; e.g. e-Directory or Active Directory; for user authentication; or sign-on.

H

2.8 Quick calculation and response times. H


Appendix F, Part 2.0 cont’d

Line #

Needs Priority(H)igh(M)edium(L)ow


2.9 System should be flexible to allow for automated or manual upload of data.

H

2.10 System should be flexible to allow for automated or manual download of data.

H

2.11 The system should automate the flow of information from one budget level to the next, eliminating the need to copy information manually.

H

2.12 Must support a minimum 25 year Capital budget.

See Attachment 9

H

Part 3.0 – Input

Line #



3.1 Software interface allows for download of statistical, payroll and G/L account information as well as upload of completed budgets.

H



Line #



3.2 Downloads from Financials systems, like Cayenta FMS, should be “on-demand”; e.g. payroll or YTD data can be loaded to master when required as opposed to automatic updates.

H

3.3 System should have a departmental interface, where total revenues, recoveries, expenses and net requirements are calculated as data input

*See Attachment 4

H

3.4 System should offer historical; e.g. year over year; data to users for variance and change analysis.

H

3.5 System should offer historical data to users during input so users have some sense of the data.

H

3.6 System should allow for input of statistical data; e.g. tonnes of garbage; in similar format to input of monetary data. Statistical accounts will be used, in many cases, as the driver for operating budget revenues and/or expenses.

See Attachment 6

H



Line #

Needs Priority(H)igh(M)edium(L)ow)


3.7 System should be flexible to allow input of FTEs for positions; not employee specific; for single or multiple departments. System should allow for expansion to individual employee data should that be required in the future.

See Attachment 5

H

3.8 Prior year budget and YTD actual information should be available during input.

H

3.9 System must allow for creation of vacant positions to allow for expansion; or “place holders” and make these identifiable.

See Attachment 5

H

3.10 Ability to link or embed supporting documents; e.g. justifications for expenses, etc.; either directly within the program, through interface with Excel, Word or interface with our records management software, FileNexus by LORIS corporation.

See Attachment 8

H


Appendix F, Part 3.0 – cont’dLine #



3.11 System must have ability to distribute inter-department charges with associated recoveries and ensure a zero net balance; for instance, applicable when one department contracts another.

H

3.12 The system should allow for the configuration of workflow, including approval on budgets from the next level, sending notification for changes if not approved and locking it down to prevent changes once approved.

H

3.13 System should allow for users to define how multiple entries to the same account are dealt with; e.g. aggregation, elimination, etc.

M

3.14 System should provide configurable drop-down style data-entry to improve accuracy/quality of data-input.

See Attachments 4 and 9

H

3.15 Application should be able to accommodate part-time, temporary and shared positions when calculating labor costs.

H





3.16 Application should minimize clerical data-entry wherever electronic sources for budget information are made available; e.g. account structures, additions/deletions, etc.

H

3.17 System should allow for the creation of “roll-up” or statistical accounts that only exist for budget and reporting purposes.

See Attachment 8

H

Part 4.0 – Calculating

Line #



4.1 Compensation costing should be based on FTEs and actual payroll information depending upon configuration; e.g. system uses FTEs entered and pulls from salary grid.

See Attachment 5

H



Line #



4.2 System should allow for use of embedded worksheets to calculate data and upload to database.

See Attachment 4

H

4.3 System should offer a dynamic interface to provide year-to-date or Budget to Actual reporting.

H

4.4 System should provide multiple level roll-ups that are User defined.

See Attachment 2

H

4.5 Application should allow benefits to be charged out as an overhead percentage OR the actual benefit rates if required.

H



Part 5.0 – Reporting

Line #



5.1 Application should have built in report builder. H

5.2 System offers easy to use report building tools. H

5.3 The system should be able to accommodate and store multiple iterations of a budget; e.g. requested/recommended/approved.

H

5.4 Ability to export reports/data directly to Excel. H

5.5 Must have the ability to interface with Crystal Reports and/or other report generation tools for future expansion.

M+

5.6 Must have ability to dynamically link monetary and statistical budget accounts to narrative text reports.

See Attachment 10

H

5.7 Must offer the ability to generate ad-hoc reports and queries. Many departments need these, for various purposes, and at both random and pre-defined times.

H





5.8 System should be able to accommodate the reporting of monetary and statistical values, either separately or combined.

See Attachments 4 and 6

H

5.9 System must be able to produce reports that conform to Accessibility Standards Formatting Guidelines.

H

5.10 Reports should offer the ability to link other tables and information to provide detail; e.g. “drill down” about accounts and figures.

See Attachment 3

H

5.11 The system should offer reports in a columnar format and layout that is familiar to our users, allowing for ease of integration to our current budgeting system. Currently, users are familiar with an Excel style layout.

See Attachment 3

H

5.12 Forecasting - at various points, the ability for Departments to dynamically forecast status to year-end.

H





5.13 Standardized queries/templates to facilitate analysis of prepared budgets; e.g. FTE costing, estimates and forecasts.

H

5.14 Ability to report “differences” between budget versions.

H

5.15 Ability to add comments to final reports. Comments could provide clarity on “differences”, as mentioned above, for instance.

M



Part 6.0 – Account Structure

Line #



6.1 System should accommodate the level of complexity that the GL requires, without necessarily mirroring it.

H

6.2 The chart of accounts must be able to accommodate several layers of roll-up codes; e.g. from account to department to division.

See Attachment 2

H

6.3 The system should have a separate chart of statistical accounts that reflects the look and feel of the monetary accounts.

See Attachment 7

H

6.4 System must be able to track multiple sources or categories of financing and revenue and how they are distributed.

See Attachment 9

H

6.5 System must be able to handle Capital Budget and Operating Budget simultaneously as these are not mutually exclusive.

H



Part 7.0 – Other

Line #



7.1 Vendor should create templates for input and reporting that follow our current guidelines.

H

7.2 Vendor should provide maintenance on the product and offer this on an on-going basis.

H

7.3 Vendor should make security practices and features readily available and offer some guarantee of integrity and security of data.

H

7.4 Vendor should provide some examples or cases where their system has been successfully deployed on a medium-large scale. Please provide other customer references.

H

7.5 Vendor should provide training and documentation on the use and features of the system.

H

7.6 Clear application support agreement that covers on-going software maintenance, support and upgrades.

H



Part 8.0 – Accessibility

Line # Needs Priority(H)igh(M)edium(L)ow


8.1 Internet based components should comply with international standards for web accessibility, WCAG 2.0 at Level AA.

M

8.2 Software functions shall have the option to be executable from a keyboard.

H

8.3 Software shall not disrupt or disable activated features of other products used to enhance accessibility; e.g. zoom text magnifier.

H

8.4 Software shall be well designed to show on-screen indication of the current focus; e.g. black bold border around current cell.

H

8.5 Images or icons for controls such as toolbars shall also be available in text; e.g. screen tips.

H

8.6 Software shall not override user selected contrast and colour selections and other individual display settings.

H



Line # Needs Priority(H)igh(M)edium(L)ow


8.7 Colour coding shall not be used as the only means of conveying information, indicating an action, prompting a response or distinguishing a visual element.

H

8.8 Software shall not use flashing or blinking text, objects or other elements with a flash or blink frequency greater than 2 Hz and lower than 55 Hz.

H

8.9 Product support documentation shall be made available in alternate formats upon request, at no additional charge or be formatted to meet the City’s Guide to Accessible Documents. www.peterborough.ca/GuideToAccessibleDocuments

H

http://www.peterborough.ca/GuideToAccessibleDocuments

http://www.peterborough.ca/GuideToAccessibleDocuments