245050 RFP.pdf

RFP NUMBER: 245050

CLOSING DATE: August 9, 2024 AT 4:00 PM (LOCAL TIME)

Enterprise Resource Planning

(ERP) Software and

Implementation Services

RFP for ERP Software and Implementation Services

City of Salem, Oregon

REQUEST FOR PROPOSALS (RFP) NUMBER: 245050

ENTERPRISE RESOURCE PLANNING (ERP) SOFTWARE AND IMPLEMENTATION

SERVICES

INTRODUCTION

The City of Salem, hereinafter referred to as “City”, is seeking proposals from qualified Proposers for Enterprise Resource Planning (ERP) Software and Implementation Services.

Proposals will be received until, but not after 4:00 PM (local time), August 9, 2024.

Completed proposals must arrive electronically via Equity Hub’s Bid Locker at https://bidlocker.us/a/salem_or/BidLocker. The City will not accept proposals submitted in any other manner.

NO LATE PROPOSALS WILL BE ACCEPTED.

Your proposal must be uploaded prior to the Closing Date and Time. The City strongly recommends that you give yourself sufficient time and at least ONE (1) day before the closing date and time to begin the uploading process and to finalize your submission. The City accepts no responsibility for non-receipt and/or delays in receipt caused by transmission and reception problems, equipment failure, or any other similar cause. Each Proposal is instantly sealed and will only be visible to the City after the closing date and time. Uploading large documents may take significant time, depending on the size of the file(s) and your internet connection speed. You will receive an email confirmation receipt once you finalize your submission.

Contact Equity Hub at help@equityhub.us or (267) 225-1407 for technical submission questions.

The Proposer Guide for Bid Locker can be found at Proposer Guide for Bid Locker.

Prospective proposers may obtain these solicitation documents by registering on the OregonBuys website and downloading them. Proposers shall consult the OregonBuys system regularly until closing date and time to avoid missing any notices. To register on OregonBuys go to https://oregonbuys.gov. The City shall advertise all Addenda on OregonBuys. Prospective proposers are solely responsible for checking OregonBuys to determine whether or not any

Addenda have been issued. RFP documents will not be mailed to prospective proposers.

Any objections to or comments upon the RFP specifications must be submitted in writing to the office of the Contracts and Procurement Manager, by email sself@cityofsalem.net.

They must be received no later than July 17, 2024 at 5:00 PM (local time).

Proposals received will be held confidential until a recommendation for award has been approved by the Department Director. Thereafter, all Proposals will be available for public inspection by submitting a Public Records Request through the City Recorders Office Public Records Request |

Salem, Oregon (cityofsalem.net).

https://bidlocker.us/a/salem_or/BidLocker mailto:help@equityhub.us https://bidlocker.us/files/Vendor%20Guide%20-%20Bid%20Locker%20Base.pdf https://oregonbuys.gov/bso/view/login/login.xhtml https://oregonbuys.gov/bso/view/login/login.xhtml https://oregonbuys.gov/bso/view/login/login.xhtml https://oregonbuys.gov/ https://oregonbuys.gov/bso/view/login/login.xhtml https://oregonbuys.gov/bso/view/login/login.xhtml mailto:sself@cityofsalem.net https://www.cityofsalem.net/government/public-records-request https://www.cityofsalem.net/government/public-records-request

The City is the sole judge in determining Agreement award and reserves its right to reject all

Proposals.

Human Rights: It is the express policy of the City that no person shall be excluded from participation in, be denied the benefits of, or be otherwise subjected to discrimination under any program or activity on the grounds of race, religion, color, national origin, sex, marital status, familial status or domestic partnership, age, mental or physical disability, sexual orientation, gender identity or source of income as provided by Salem Revised Code Chapter 97, Title VI of the Civil Rights Act of 1964, and other federal nondiscrimination laws. The City’s complete Title

VI Plan may be viewed at Equity & Accessibility | Salem, Oregon (cityofsalem.net). Proposer agrees to comply with all applicable requirements of federal, state, and local civil rights and rehabilitation statutes, rules, and regulations if awarded an agreement by the City.

Solicitations for Subcontracts, Including Procurements of Materials and Equipment: In all solicitations, either by competitive bidding or negotiation made by the successful proposer for work to be performed under a subcontract, including procurements of materials or leases of equipment, each potential subcontractor or supplier shall be notified by the successful proposer of the successful proposer’s obligations under this Agreement and the Salem Revised Code Chapter

97, Title VI of the Civil Rights Act of 1964 and other federal nondiscrimination laws.

Note: Errors and Omissions Liability Insurance Coverage will be required.

The City is an Equal Employment Opportunity employer.

Questions regarding the City’s RFP process may be addressed to Shawna Self, CPPB, Contracts and Procurement Manager, who may be reached at (503) 588-6445 or by email at sself@cityofsalem.net during City business hours.

The City operates and maintains Americans with Disabilities Act compliant facilities.

Reasonable accommodations are available upon request.

Shawna Self, CPPB, Manager

Contracts and Procurement

FIRST DATE OF SOLICITATION: July 1, 2024

REQUEST FOR PROPOSAL NUMBER: 245050

REQUEST FOR PROPOSAL CLOSING: August 9, 2024 at 4:00 PM (Local Time) https://www.cityofsalem.net/government/equity-accessibility mailto:sself@cityofsalem.net

RFP # 245050

City Manager Legal

Community Services Community and Planning Development

Enterprise Services Police

Fire Public Works

Finance

Table 1

Background Statistics

Current Population 177,723

Budget (All Funds) $756,268,290

Full-Time Employees (Career) 1,345

Part-Time Employees (Career) 20

Part-Time Employees (Exempt) 53

Seasonal Employees 17

Total Employees 1,435

Fiscal Year End June 30

ENTERPRISE RESOURCE PLANNING (ERP) SOFTWARE AND IMPLEMENTATION

SERVICES

The City of Salem (“City”) is a municipal corporation serving a community with a population of approximately 177,700. It is the capital of the State of Oregon and the county seat of Marion

County. The City has a Council-Manager form of government with an elected mayor and council.

The City has approximately 1,300 employees and nine operating departments (listed below).

SECTION 1: ABOUT THE PROJECT

1.1 Project Background

The City initiated this project in the second half of 2023 as a result of an internal review of its current financial application (FIMS), which is based on the Oracle EBS platform. The City has been on the same platform for over 20 years and is able to maintain it sufficiently. However, business users want more functionality than is currently configured. Desired functionality requires upgrading to the cloud solution, which means a project with similar costs and efforts as a new ERP solution. As a result, the City made the strategic decision to assess the full ERP market before investing in a long-term ERP solution.

The Government Finance Officers Association (GFOA) was selected by the City to guide them through the ERP selection process. GFOA is a professional membership organization representing over 20,000 public sector professionals cross the United States and Canada. GFOA has no ties to any ERP technology.

As part of the scoping activities for this project, GFOA and the City worked together to review existing business processes. The City was divided into Process Improvement Teams (PITs) lead by a process leader (PIT Leads). Each PIT met with GFOA to identify any potential gaps in their current processes when compared to best practices and modern ERP functionality. The PIT Crews and PIT Leads will remain intact during selection and implementation.

Areas for improvement were logged into an Action Plan that is reviewed regularly by project management. Opportunities for improvement ranged from changing existing practices without regard to technology to preparing for change when technology is available. Most of the Action

Plan items are to be addressed by the time implementation begins. The remaining improvement opportunities consist of items to be implemented as a result of the ERP Technology. Action items are based on the following goals:

1.1.1 General

The ERP will serve as the central hub for enterprise data addressing employee records, financial accounting, procurement, and enterprise reporting. As such, any ancillary solution will need to comply to the standards of the configured ERP business solutions.

General business rules will also be defined in ERP; meaning workflow processes are defined in the ERP solution for most transactions related to human resources, payroll, financials and procurement. Workflow rules related to detailed processes, such as work order approvals, will remain in the respective solution unless they need to leverage a process that is managed in ERP.

For example, replenishment of inventory managed in work order systems will utilize the ERP purchasing process to acquire inventory.

Any new technologies introduced into the City technology infrastructure will need to comply with the ERP governance requirements. To guarantee flexibility and scalability in the future, the City prefers commercially available and proven technology.

1.1.2 Accounting

The City’s main financial ledger is housed in Oracle EBS and maintained by the City’s Department of Budget and Finance. City leadership follows priority based budgeting paradigms. A shortcoming of the current Oracle EBS configuration is that the chart of accounts is not currently configured for this type of management and reporting. Enhancing the chart of account structure to accommodate priority based budgeting requires the addition of a program field and a project and grants field. The City recognizes that altering the structure of the chart of accounts is a major effort.

The City conveyed that the future ERP solution should be functionally scalable to accommodate

Governmental Accounting Standards Board (GASB) changes. Reporting tools should be flexible to accommodate Annual Comprehensive Financial Report (ACFR) requirements. This includes being able to accommodate multiple accounting views simultaneously.

Finally, the City desires an accounting ledger and transaction system capable of acommodating multiple business units at the same time. The City is responsible for the financial accounting of the federally-funded Salem Housing Authority (SHA) and will continue to provide accounting services to the SHA in the future. The SHA follows the same accounting and business rules as the

City, but operates on a different fiscal cycle. Security, workflow approvals, and reporting are segmented from the City.

1.1.3 Budget

As a result of the business process analysis for this project, the City determined that it may keep its current budget preparation application (BOARD) and integrate it to the future ERP solution, but the City is also open to exploring the budget offerings provided by the future ERP.

Budget control is not enforced in the current ERP application but will be enforced in the future solution. The City has been discussing various methods for budget control in modern ERP applications with GFOA. Although not currently settled, future budget control will most likely be enforced at the fund, cost center, project, and line item category (e.g., salaries). Programs for performance budgeting will be tracked.

Position control is important to management. It is currently difficult to track vacancies accurately and estimate cost savings based on open positions. The City seeks a future ERP solution that budgets and tracks authorized positions, accounts for underfilled positions adequately, and integrates with Board performance reporting.

1.1.4 Procure to Pay

The City expects the most benefits from a modern ERP application in this process area. The City envisions a solution that supports supplier and vendor self-service functions. The solution supports modern procurement functions such as bid analysis, complex workflows, and punch out functions.

The procurement process can also accommodate external requisition requests (i.e., inventory replenishment) from integrated work order applications.

Since budget control in ERP applications is a newer concept to the City, stakeholders will need careful guidance from the implementers regarding encumbrances and best practice processes for recognizing expenses in modern applications. Key to this understanding will also require a detailed understanding of the payables matching process, particularly the proper handling and accounting of partial receipts.

The future procure to pay solution will define the City’s procurement standards. External work order applications that utilize their own purchasing and accounts payable process will need to accommodate the future ERP solution. This means that the procurement process will be accommodated by the future ERP solution. The external applications will only initiate a requisition and receive data from the ERP solution to accommodate their own processes but the future ERP solution will run the purchasing and accounts payable detailed processes.

1.1.5 Receivables

The City plans to run miscellaneous receivables through the future ERP solution. Specialized receivables systems, such as the permitting systems will remain but will need to send summarized accounting data to the ERP solution, since it serves as the official record for accounting. The City is currently in the process of standardizing all of its payment portals on Paymentus and prefers an

ERP solution that can leverage this technology.

The City’s expectations for a future receivables system is not unusual for modern applications.

The City expects to be able to trace payments to open receivables. Management desires a system that can accommodate a central customer database to allow users to drill down from a customer record to the source receivable, even if the receivable is in an external application. Eventually, the

City wants to use this ERP project to establish standardized receivable and billing processes that reflect best practices and that can be applied to any receivables application operating in the City.

1.1.6 Treasury

Cash management and forecasting is important to the City. The Treasurer and staff involved in cash management seek a solution that can provide good cash activity reporting without requiring a great deal of overhead. Their ideal solution is an integrated cash reporting and forecasting tool that can pull data from various subledgers (e.g., receivables, accounts payable) and provide good cash position data. Their current process involves large, complex spreadsheets that need to be reconciled with the accounting system and the banks on a daily basis. The vision is to eliminate these spreadsheets and incorporate the functions into a future ERP solution.

Reconciling bank data with lower overhead is also a goal for the Treasury team. Currently, it is difficult to research payables and receivables data. Reconciling bank data can also be burdensome without automation and recording of data in outside spreadsheets. Automating the reconciling process, accounting for bank adjustments in a centralized ledger, and easier access to receivables and payables data are all functions that will help achieve their vision.

1.1.7 Asset Management

As a result of the business analysis process, the City made the strategic decision keep its specialized work order systems and integrate the solutions with the future ERP solution. This decision lead to a re-thinking of how the City maintained its assets. Currently, assets are maintained in the various work order systems and in the current ERP. Some assets are accounted for in FIMS and in the work order solutions simultaneously. Other assets may only be accounted for in the work order solution and not in FIMS. This project will be used to establish centralized policies and procedures addressing assets.

The future vision is to establish the ERP solution as the centralized asset management record. Cost data from ERP will be fed to the external work order solutions to be used for work order cost basis.

The work order cost accounting will be fed back to ERP to maintain proper asset value. Other accounting processes, such as calculating depreciation and disposition costs will also be accommodated in ERP with any work order impact data being sent to the Work Order solutions.

1.1.8 Human Resources

The vision for a new human resources solution is to establish a comprehensive employee record system that follows the career path of an employee, supports career growth, and helps management with succession planning.

Hiring managers should be able to view their vacancies and submit personnel requisitions with relative ease. Approvers should have a comprehensive view of the job that is being filled.

Customer service is important to obtaining the human resources vision. It is important that potential employees have access to an intuitive recruitment system. Hiring Managers and other

Human Resources staff should also have intuitive tools to analyze employee candidates.

As new employees are onboarded, data obtained during the recruitment process should carry over into the employee record. Employees should be guided through the onboarding process.

Onboarding managers should be able to track and manage the employee as they complete the process and the employee record should be updated accordingly.

As employees progress in their career, they should be assured that accurate data is being collected during their employee evaluation process, certification process, and training processes. The employee self service experience during their career should be similar to the recruitment experience so that an employee has comprehensive view of their employment history. Employees can also make certain changes to their records. Human Resources staff can be assured of data integrity through comprehensive workflow approval processes.

Human Resources managers should have a comprehensive view of the employee record.

Accessing data should not be cumbersome and should be able to be regressed or anonomyzed for analytical purposes.

1.1.9 Time Entry and Payroll

Key to performance budgeting and management is being able to rely on complex and accurate time entry and payroll data. The City requires solutions that support labor data collection related to programs and projects in particular. The City further expects technology to support scalable and flexible solutions that can accommodate the City’s multiple labor contracts.

City management recognizes that accurate labor data collections corresponds to user experience.

The future solution will need to have easily accessible time entry portals ideally on employee preferred devices. When possible, the assumption should be that time entry is exception based.

However, time entry should also be detailed to accommodate different pay incentives, when appropriate. Finally, employees should be able to access their leave balances and pay history through intuitive self-service portals.

Payroll Administrators also expect flexible and scalable solution. To improve efficiency, the new solution should be able to accommodate processes without halting others (e.g., stopping processes while payroll is running). Complex transactions, such as retropay, should be as automated as possible. When research is required, intuitive reports should be available to aid in the assessment.

Adjustments and other similar transactions should be auditable.

1.1.10 System-Wide

Integrated, secured access to the ERP platform is high priority for the City. Internal and external users should be assured that the systems they are accessing and that the data is secured. To maintain integrity of the data and related process, the future solution should be able to accommodate varying degrees of workflow approvals.

To minimize training, user interfaces and transactions should be as intuitive as possible. When complexity is necessary, documentation or online help should be easily accessible. Report tools should be based on no code/low code interfaces. Business configuration should not require programmer intervention.

1.2 Governance

The ERP Selection Project is being managed by the City’s Department of Budget and Finance, with the Enterprise Strategy Department co-sponsoring the Project. The City’s Budget Manager is serving as the Project Manager during selection and implementation. A Steering Committee has been established to provide guidance regarding project scope, funding, and business processes and city policies impacted by the project. The Project is also supported by multiple Process

Improvement Teams (PIT) Crews. Each PIT consists of City stakeholders representing various stages of a functional process. For example, the Payroll PIT Crew consists of payroll staff, timekeeping staff, managers, and ad-hoc employees.

Figure 1

Governance Structure

Table 2

Project Roles

Role Definition Duties Project

Sponsor

Serves as a member of the

Steering Committee. Resolves conflict within the Steering

Committee or on the project and is the final decision-maker during Steering Committee impasses.

• Act as project champion

• Secure necessary resources and remove obstacles for the project.

• Provide strategic direction for the project.

• Promote the project to City leadership and department staff.

• Participate on the Steering Committee.

Steering

Committee

Provides ongoing leadership to the ERP Project.

• Provide strategic direction for the project.

• Obtain funding approval for the project.

• Ensure on-going commitment throughout the project.

• Provide advisory and consultative direction.

• Provide support to the project team.

• Resolve conflicts over policy or objectives.

• Make decisions on scope, schedule, and budget.

Project

Manager

Coordinates day-to-day activities on the project and serves as primary point of contact for the City’s vendor partners.

• Monitor the scope, schedule, and budget of the project.

• Manage project staff and contracts.

• Recommend appropriate project resources.

• Provide coordination of all internal resources.

• Serve as project liaison to external consultants.

• Monitor project tasks to ensure the timely delivery of work products.

• Make decisions on items elevated to the

Project Manager within a single project.

• Escalate decisions to the Steering

Committee when necessary.

GFOA

Consultants

Serves as the ERP program advisor to the City.

• Provide general guidance on ERP selection practices.

• Provide guidance on best practices in public sector.

• Facilitate and guide the City through scoping, solicitation, selection, and contracts for the future ERP solution.

• Complete tasks outlined in the contract, including project planning, businesses process analysis and improvement, and project readiness plan.

Process

Investigation

Teams Leads

Process Investigation Team

Leads (PIT Leads) have a general understanding of their functional process. Leads provide functional expertise, coordinate stakeholders, and coordinate tasks and assignments.

• Identify mapping and data requirements.

• Review and validate functional and technical requirements.

• Make recommendations and assist in the development of policies and procedures for best practice business processes.

• Assist GFOA with documenting current processes.

• Identifies potential opportunities for improvement.

• Assists the ERP Project with change management by serving as “project champions” within their department.

Subject

Matter

Experts

Subject Matter Experts (SMEs) have deep knowledge of a particular process or sub-process within a functional area. SMEs are called periodically to provide information.

• Provides information and recommendations about their defined area of expertise.

1.3 Team Commitment

The City will make every effort to staff the project appropriately and understands that staffing a project is important to its success. The City has identified the following resources for the project:

Table 3

Team Commitment

Assumed Role (City Staff) Maximum Participation (City Staff ― FTE)

Project Sponsor .10

Steering Committee .10

Project Manager 1.00

Accounting Lead .50

Budget Lead .50

Procurement Lead .50

Accounts Payable Lead .50

Customer Billing Lead .50

Treasury Lead .50

Asset Management Lead .50

Human Resources Lead 1.00

Learning Management Lead .50

Payroll/Time Entry Lead 1.00

Change Management Lead .50

Technology Lead .25

Technology Resource 1.00

Subject Matter Experts .50 (as needed)

SECTION 2: SCOPE OF REQUESTED SERVICES

2.1 Overview

The City seeks an integrated ERP solution and a qualified professional services provider to implement the proposed ERP solution, including overseeing the implementation of any proposed third-party software. The scope of the project, including the milestones, will be defined by the statement of work that describes both the Functional Requirements of the software and business process expectations.

2.2 Contract Scope

The City shall enter into a “Single Contract” with one “Proposer” for all implementation services as described under this RFP. Therefore, it is the Proposer's responsibility to partner as necessary and assemble the team, skills, assets, and other qualifications to meet all requirements as laid out in the RFP. The selected Proposer shall assume all contractual responsibilities and obligations and comply with all contract terms and conditions. The City understands that software contracts and third-party solution contracts may be handled separately; however, a comprehensive Statement of

Work will be developed to integrate all of the contracts.

2.3 Organization Scope

The scope for this project includes all departments within the City, the Elected Official Offices, Boards and Commissions, Enterprise Operations, and the Urban Renewal Agency.

2.4 Functional Scope

The City’s functional scope for this project is listed below:

Table 4

Functional Scope

Function Function

Accounts Payable Inventory

Accounts Receivable Project Accounting

Asset Management Purchasing

General Ledger System

Grants Accounting Treasury

Human Resources Payroll

2.5 Process Scope

The expected scope of the project will cover the functional areas listed in the table below. For all functions, the City expects to have reporting, workflow, business intelligence, and integration capabilities. Future process maps attached to this RFP as an Exhibit to serve as conceptual process goals for the government. Proposers will be expected to meet the Functional Requirements

(Attachment 17), as well as the future process maps that have been mapped to the Functional

Requirements.

Table 5

Process Scope

Function Process Function Process

Accounts Payable • Payment

• Receiving

• Reporting

• Vendor Self-

Service

• Void and Cancel

Inventory • Cycle Count

• Fulfillment

• Replenishment

• Reporting

Accounts Receivable • Customer

• Dunning

• Invoice

• Lien

• Miscellaneous

• Receipts

• Reporting

Project Accounting • Administration

• Budget Control

• Closing

• Reporting

• Transactions

Asset Management • Acquisition

• Asset Change

• Asset Tracking

• Depreciation

• Disposition

• Lease

• Reporting

Purchasing • Blanket Contract

• Contract Admin

• Informal Quote

• Limited Purch.

Order

• P-Card

• Proposal Selection

• Purchase Order

• Reporting

• Requisition

• Sourcing

General Ledger • Budget Control

• Chart of Accounts

• Financial Closing

• Integration

• Reporting

System • Accessibility

• Attachments

• Audit

• Reporting

• Security

• Transactions

• Workflow

Grants Accounting • Administration

• Cost Allocation

• Funding Source

• Reporting

• Transactions

Treasury • Bank Recon.

• Cash

• Reporting

Function Process Function Process

Human Resources • Benefits Admin.

• Employee Record

• Employee

Relations

• Employee Self-

Service

• Evaluation

• Job Class

• Learning

Management

• Onboarding

• Personnel Action

• Position Control

• Recruitment

• Separation

• Reporting

Payroll • Calculations

• Garnishments

• Leave

• Payroll Processing

• Reporting

• Salary

Administration

• Tax Administration

• Time Entry

2.5.1 New Functional Requirements

The undocumented requirements are new requirements that City staff can introduce during the business analysis, design, development, and validation phases. During the implementation, it is expected in the Proposer’s sessions with users, additional requirements might come up and/or existing requirements may be further expanded or deleted. The City expects that additional clarity will develop during the implementation phases, and therefore, it is the responsibility of the

Proposer to update the RFP baseline requirements continuously throughout the implementation phase. As part of the implementation phase, the City can identify and introduce new business requirements until the end of the Design milestone, at which point the implementation requirements will be frozen. As long as these new (undocumented) requirements can be met via the proposed software modules as demonstrated and/or described within the RFP response, during interviews and/or presentations, the implementation of these new requirements will be within the

Proposer’s fixed-fee implementation scope. Only requirements that are not included in the City’s requirements, demonstrated and/or described within the RFP response, during interviews and/or presentations are subject to the same City review/approval process.

2.6 Report Scope

The Proposer shall develop the necessary ad-hoc queries and reports to satisfy the City’s reporting requirements identified in Schedule 1 of Attachment 12 - Reports. Insert any custom reports that are assumed to be built during implementation in Schedule 2 of Attachment 12 - Reports.

Customization of stock reports for changes in report field labels, insertion of client logos, and report page formatting is part of the fixed cost for the Project Scope of Work. Reports that require extensive customization shall be evaluated for scope change requests.

Proposers should include cost estimates based on the following assumptions for custom report development estimations in Schedule 2 of Attachment 12 - Reports:

1. High complexity reports (requiring 80 hours or more of configuration and development) for each major process.

2. Medium complexity reports (requiring between 10 hours and 80 hours of configuration and development) for each major process.

3. Low complexity reports (requiring less than 10 hours of configuration and development) for each major process.

2.7 Interface Scope

Interfaces to the City’s existing systems are critical for project success. Proposers must provide responses to the interface requirements described in Attachment 13 - Interfaces.

2.8 Conversion Scope

Proposers must provide responses to the conversion requirements Attachment 14 - Conversions.

Proposers will be expected to assist the City with working with each of its legacy application vendors as part of the conversion effort.

2.9 Implementation Scope

The tasks described below represent the project tasks, activities, and completion requirements for the implementation scope. The tasks and deliverable requirements herein, as presented in this RFP, are for guidance purposes and it is up to the Proposer to carefully review and meet these requirements. The City recognizes that the Proposer may have its own implementation methodology and the City highly encourages the Proposer to propose its own methods. Therefore, it is the responsibility of the Proposer to map its implementation methodology with the specified project’s requirements and tailor the proposed methodology to comply with the task and activity requirements as described under this section.

2.9.1 Project Management Methodology

The Proposer must implement strong project management methodology practices that will enable the Proposer to conform to the proposed project delivery schedule. Project management activities shall address:

1. Oversight for overall project guidance and direction.

2. Approach for project status reports and meetings.

3. Approach to issue tracking and resolution processes (including response/resolution time) ensuring consistency and quality of project deliverables.

4. Maintaining project documentation, procedures, issues tracking process, project plan updates, developing and updating project dashboards, executing financial documents and deliverables for invoicing, preparing reports, updating project and associated spend plans, and arranging meeting logistics.

Re-Engineer Business Processes

The Proposer must make a sincere effort to propose business practice changes to the City through the new software solution, as well as practice improvements based on the Functional Requirements that may be associated with processes surrounding the use of the new software.

Implementation Requirements

The Proposer is expected to propose a structured implementation methodology that would accomplish, at a minimum, the following tasks as outlined below.

1. Continuous Tasks (throughout the Project):

Under the Start-up Phase, the focus will be on all the planning level tasks, activities, and deliverables. The project preparation work includes the following: detailing project scope, implementation methodology, implementation sequence, baseline project schedule, staffing requirements, and the project management plan.

2. Design

The Proposer shall use the business requirements and process maps from this RFP to develop the “To-Be” business practices for the City.

The City expects the Proposer to document analysis of any functional gaps and recommendations of potential solutions.

3. Configuration

The Proposer shall configure and customize the proposed solution by incorporating recommendations and approvals from the design effort. This entails technical development work such as configuring “To-Be” business practices, including workflow and development of reports, integration/interfaces, data conversion, security setup, and approved customizations. The City expects the Proposer to provide knowledge transfer opportunities to the City’s Project Team.

4. Testing/Validation

The Proposer shall implement all system validation and fixing tasks to ensure a smooth transition for deployment. A testing/validation cycle will not be considered complete until the Proposer has provided a fix, or a City-agreed resolution plan for all test issues. The testing strategy must address the following:

a. Roles and responsibilities for testing

b. Unit testing

c. Integration testing

d. User acceptance testing

e. Regression testing

f. Parallel testing

5. Deployment & Post-Production Phase

In this phase, the Proposer prepares the City for solution deployment, which includes end-user training, assessing system go-live readiness, assembling a go-live user support plan, system cutover plan to production that includes contingency planning, and go-live activities.

Proposers should include a post-implementation support period to include the first period closing after Go-Live, as well as providing support for the first year-end close.

2.10 Training Scope

The training approach shall address the following:

1. Fully developed written training guides for all processes, including integrations.

2. A robust help file structure within the software addressing FAQ’s.

3. Overall training methodology, including recommended delivery approach (e.g., classroom, online, blended delivery).

4. Description of all assumptions addressing the availability of City resources, including staff, necessary training tools, and physical space. Include any assumptions about whether any training would be held on-site (i.e., a City facility) or off-site.

5. Recommendations for training requirements for:

a. Pre-implementation training for Project Team members

b. Train the trainer

c. End-user training

d. Post-implementation training

2.11 Price Scope

2.11.1 Software

Pricing for all proposed software products must be presented as five-year costs. The City prefers that annual costs remain fixed during the five-year term. The City also prefers enterprise license costs.

2.11.2 Services

Pricing for services must be submitted on a fixed fee basis upon completion of pre-identified

“milestones.” For implementation services under a milestone arrangement, the Proposer shall invoice the City when the City has accepted the Services included as requirements for each milestone.

SECTION 3: PROPOSAL SUBMITTAL REQUIREMENTS

Organization of the Proposal

Proposers must organize and present their proposal materials in the same order as presented below and include page numbers. Proposals received without following this format or received after the deadline and stated place of delivery may be rejected as non-responsive.

3.1 Proposal Section 1.0 – Introduction

The introductory material should include a title page with the RFP name, name of the proposer, address, contact information (including email address), the date, a Letter of Transmittal, and a

Table of Contents. The executive summary should be limited to a brief narrative summarizing the proposal.

1. Complete Attachment 2 – Request for Proposal Coversheet

2. Complete Attachment 1 – Submittal Checklist

3. Complete Attachment 3 – Proposer Statement

3.2 Proposal Section 2.0 – Proposer Team

This section of the proposal should identify all firms included in the proposal and any necessary third-party products/firms required or recommended for the City.

1. Identify and provide a concise summary of all firms providing software or professional services as part of this proposal.

3.3 Proposal Section 3.0 - Functional Requirements

This section describes the software and implementation scope of the overall project and the requirements for each functional area. Responses to the Functional Requirements should be completed to identify the capability of the software and the scope of the implementation.

Table 6

Functional Requirements Responses

Available

Response

Definition

Y Requirement Met and Proposed (Standard features in the generally available product)

Y-ND Requirement Met and Proposed (Features that are not offered as a generally available product or require custom development)

N Requirement Not Met with Proposal

1. Complete Attachment 17 – Functional Requirements

Failure to provide some requirements or excluding some requirements from scope may NOT eliminate the proposer from contention. The City will evaluate the proposal as a whole, including price/value comparisons when evaluating proposals.

a. The requirements responses submitted will become part of the agreement. Proposers are expected to warrant the delivery and configuration/implementation of all positive responses (every response except “N”).

b. For requirement responses other than “N”, proposers should indicate the module or product that is required to meet the requirement.

c. For requirement responses other than “N” proposers should indicate the phase of the project that the functionality will be implemented.

d. All responses which are marked Y, or Y-ND may be considered to be included in the scope, and the cost proposal and all other information submitted in this proposal should reflect this.

e. For functionality that is not currently available and not available for viewing at a demo, but that may be in scope for the project either as generally available features in a future release or as a customization, modification, or enhancement specific for this project, Proposers should indicate a response of Y-ND based on the Attachment instructions.

3.4 Proposal Section 4.0 – Software Products

This section should provide information on the proposed software scope, and functional description of the software.

1. Complete Attachment 4 – Product Background for each software product included in the proposal.

2. Complete Attachment 7 – Software Reference for each proposed product.

3.5 Proposal Section 5.0 – Technical Requirements

This section of the proposal should identify any technical requirements for operating the system and describe the key attributes of the Proposer’s proposed delivery services.

1. Complete Attachment 5 – Technology Deployment

2. Describe any managed services that are provided along with hosting/SaaS offerings including:

a. Information on the specific hosting services provided

b. Service desk support services

c. User Setup, Authentication and Management processes

d. Application security

e. Data security

f. Application support

g. Operational support services

h. Technology infrastructure services

i. Disaster recovery

3.6 Proposal Section 6.0 – Implementation Team

This section should describe the proposed project team including the consultants proposed to provide services for the City.

1. Complete Attachment 6 – Services Background for each firm involved with the project.

2. Complete Attachment 8 – Services References for each implementation firm involved in the project.

3. Identify the proposed project team including the firms responsible for implementation, and any key consulting team members that will be providing services to the City.

a. How many staff will the Proposer have assigned to the project?

b. Approximate dedication to the project of each resource and approximate time work will be completed on-site vs. off-site.

c. Major roles and responsibilities for each resource

4. Complete Attachment 9 – Work Effort. This should include the number of hours required per resource per task area. Be sure to include the phase, resource type, and role for each resource for both the Vendor and the City. Please refer to the Team Commitment found in

Section 1: 1.3 for the City’s anticipated available resources.

3.7 Proposal Section 7.0 – Implementation Approach

This section should describe the proposed implementation plan. Provide a description of your implementation methodology for the City. Special emphasis should be placed on how the City’s project characteristics are taken into account. Proposers should reference Section 1:1.1 for more information on the project scope, goals, and implementation effort.

1. Provide a detailed plan for implementing the proposed system. This information should include:

a. Confirm completion of key tasks and deliverables as defined in Section 2: Scope of

Requested Services

b. Description of implementation tasks and activities

c. Description of key deliverables (and how they relate to the implementation approach and activities).

2. Complete Attachment 10 – Project Expectations

3. Complete Attachment 11 – Deliverable Expectation Document

4. Explain proposed project management services including:

a. Role of the Proposer project manager

b. Expected role of the City’s project manager

c. Proposed quality assurance procedures

5. Identify proposed data conversions

Proposers should provide responses to the conversion requirements (Attachment 14 -

Conversions). If additional items to be converted are proposed, please add them to the spreadsheet. The following answer key should be used when responding to the conversion requirements.

Table 7

Conversion Responses

Item Response Response Description

Agree Y/N Proposers should identify whether or not your firm agrees that this item needs to be converted.

Included in Price Y/N If your firm agrees that this item needs to be converted, indicate with a Yes or No whether your firm's work effort to complete the conversion is included in the pricing schedule.

Estimated

Consulting Hours

Number of

Hours

Include the number of estimated consulting work hours to complete the conversion.

Comments Text Include any comments or assumptions relevant to the answers above.

6. Identify interfaces

The City has provided anticipated interfaces in Attachment 13 - Interfaces. Proposers should indicate their plan for the interfaces using the key presented below. If additional interfaces are proposed, please add them to the form and indicate how they will be implemented using the same key.

Table 8

Interface Responses

Interface Plan Permanent, Temporary, Go-Away

Permanent – permanent interface, even after the complete ERP solution is installed.

Temporary – interface that is only required during implementation.

Go-Away – interface that is no longer required as a result of the new ERP solution.

Type of Solution C, P C - Configurable Solution

P - Customized developed program

Estimated

Consulting Hours

Number of

Hours

Include the number of estimated consulting work hours to complete the interface.

Included in Price Y, N Indicate with a Yes or No whether or not the interface is in included in the price.

Type of Support S

TPS

NS

S - Requirement and Feature Supported by Software Developer

TPS - Requirement and Feature Supported by Third Party

NS - Requirement and Feature Not

Supported

Comments Text Include any comments or assumptions relevant to the answers above.

7. Identify Customizations/Enhancements

All responses in the Functional Requirements that were identified as “Y-ND” (and are not workflow requirements) should be listed in Attachment 15 - Enhancements. Reference

Table 9 (Customizations/Enhancements Requirements Key) below when completing the form.

Table 9

Customizations/Enhancements Requirements Key

ID Requirement ID Provide the Functional Requirements

ID for which the customization/enhancement applies.

Name Text Provide the name of the enhancement

Purpose Text Provide a brief description of the enhancement

Included in Price Y, N Indicate Yes (Y) or No (N) whether or not the enhancement is included in your price estimate.

Estimated

Consulting Hours

Number of Hours Include the number of estimated consulting work hours to develop the enhancement.

Estimated Client

Hours

Number of Hours Include the number of estimated client work hours to develop the enhancement.

Comments Text Include any comments or assumptions relevant to the answers above.

8. Reporting

Proposers must identify the number of reports and their complexity that is included in scope by completing Attachment 12 – Report Requirements. The City expects the Proposer to complete the number and type of reports based on experience. Also, report the total number of work effort hours that are required to complete each category of reports. Reference

Table 10 (Report Assumptions Key) when completing the report assumptions form.

Table 10

Report Assumptions Key

Item Response Description

High Complexity Development or configuration of report (including testing) exceeds 80 hours of work effort.

Medium

Complexity

Development or configuration of report (including testing) is between 10 hours and 80 hours of work effort.

Low Complexity Development or configuration of report (including testing) is below 10 hours of work effort.

3.8 Proposal Section 8.0 – Price Proposal

Proposers should submit price proposals using the format provided in Attachment 16 – Costs.

1. Complete and submit Attachment 16 – Costs

a. All pricing should be submitted as fixed by milestone. Costs listed as “to-be-determined” or “estimated” may not be scored.

b. Identify major milestones as part of the project. Costs should be invoiced upon completion of major milestones. Please provide a schedule of all payments necessary to complete the proposed scope.

c. All service costs should be provided on a task or completion basis with costs assigned to each milestone, deliverable and/or task. Proposers are required to fill in deliverables and tasks under the provided headers (project initial knowledge transfer, process analysis/system design, system build, testing, training, and closure) Additional detail may be provided to further explain deliverable/task costs.

d. Proposers should include all software modules and state any limitations on module use.

If no limitations are listed, the City will consider that pricing is based on full enterprise-wide access for the City.

e. Proposers should submit implementation costs as fully loaded rates that include all necessary travel or other expenses. By submitting a proposal, all proposers acknowledge that all pricing (including travel) should be a fixed fee or included in the implementation milestones.

3.9 Proposal Section 9.0 ― Implementation Terms and Conditions

Proposers may take exception to certain requirements in this RFP. All exceptions should be clearly identified in this section, with a written explanation of the exception and an alternate proposal (if applicable). The City, at its sole discretion, may reject any exceptions or specifications within the proposal. Alternative proposals that do not materially adhere to the stated term may be subject to evaluation deductions.

SECTION 4: PROPOSAL EVALUATION CRITERIA AND SELECTION PROCESS

4.1 Evaluation Criteria

Although cost of services is important, the City will not necessarily select the lowest cost proposal for the award. The City reserves the right to award a contract based on initial proposal submittals or, at the sole discretion of the City, to conduct interviews with any or all of the proposers. In addition to submitted proposal information, the City reserves the right to use any information that it is aware of, independent of the submitted proposals, in determining consideration of contract award.

The City will not pay for any costs incurred by proposer in responding to this RFP to include costs to the proposer to conduct interviews and presentations.

The evaluation criteria to be used for this RFP are summarized below:

Criteria Max. Points Weight

Written Proposal Analysis

Overall Understanding of City Needs (§3.2) 5 5

Cost (§3.8) 5 20

Functionality (§3.3 and §3.5) 5 35

Implementation Methodology/Approach (§3.6 and

§3.7)

5 20

Software and Implementation References (§3.4 and

§3.6)

5 15

Compliance with Contract Terms and Conditions

(§3.9)

5 5

Subtotal 30 pts. 100

Software Demonstrations and Interviews

Software Demonstrations 5 50

Interviews 5 50

Subtotal 10 pts. 100

Total 40 pts.

The evaluation team may assign half points to the criteria.

The Proposer’s response will be scored by Committee members in accordance with the following scale:

Points Criteria

0 No information was provided for the specific criteria. Proposer failed to address the criteria. No documentation was provided.

1 “Poor”: Proposal is lacking or inadequate in most basic requirements for the specific criteria.

2 “Below Average”: Proposal meets many of the basic requirements for the specific criteria but is lacking in some essential aspects.

Points Criteria

3…