HomeMy WebLinkAbout08-15-2017 Item 05 - Authorization to Issue an RFP for an Enterprise Resource Planning (ERP) System Meeting Date: 8/15/2017
FROM: Xenia Bradford, Finance Director
Prepared By: Vinay Jathanna, Technology Projects Manager
SUBJECT: AUTHORIZATION TO ISSUE AN RFP FOR AN ENTERPRISE RESOURCE
PLANNING (ERP) SYSTEM
RECOMMENDATION
1. Approve the issue of an RFP for an Enterprise Resource Planning (ERP) software system;
and
2. Authorize the City Manager to execute agreements with selected ERP software vendor and/or
software implementer based on the software vendor/implementers selected if proposal is
within approved total implementation budget; and
3. Authorize the Finance Director or their designee to execute Purchase Orders to software
vendor and/or consulting services based on the software selected and contracts negotiated in
an amount not-to-exceed the authorized project budget.
DISCUSSION
Background
In 2015 the City contracted with the GFOA to conduct an assessment of the Finance Department.
In their key recommendations, GFOA identified a variety of necessary upgrades and
organizational and process modifications in order to provide more efficient and accurate work
product. GFOA noted that these deficiencies often resulted in a “ripple effect” to other parts of
the organization which negatively impacted those departments’ work product and level of
efficiency as well. More specifically, the “ripple” effect creates redundant process and additional
work required in other departments. It identified the use of inadequate systems driving an over-
reliance on manual or “side” systems, complicated business processes, and confusion around
assignment of duties as responsibilities and expectations expanded without additional staff (e.g.
new or additional work is given to a person because of availability not skill set or work flow) and
a lack of processes and tools to effectively communicate with the public. Following
recommendations were made by GFOA:
1) Immediately address the lack of a complete financial system, 2) Align a chart of
accounts with business requirements and system capabilities, 3) Streamline ineffective
business policy and process, 4) Clarify roles and responsibilities and implement service
level agreements for all central functions.
Packet Pg 31
5
GFOA concluded that these core issues represent the most significant problems faced by the
City’s Finance function and cause ripple effects throughout all City departments. In other words,
over time, the Finance Department has blurred lines of responsibility as staffing levels have
decreased and responsibilities have increased.
This combined with an outdated financial system inhibits the department’s ability to improve
efficiency and effectiveness even with temporary resources.
The GFOA report was presented to Council on April 19, 2016 with the above 4
recommendations. Based on the GFOA recommendation and Council approval, the Motion
project was initiated as a citywide initiative to implement an Enterprise Resource Planning
(ERP) software.
ERP is a management software suite of integrated functions that enables an organization to
automate its business processes on one platform. It is a standard best practice and a hallmark of
efficiency to have integrated systems that can provide real time data to both staff and the
community about the financial aspects of the City. Similar ERP implementations have been
completed by City of Paso Robles and City of Santa Barbara.
The ERP implementation consists of core functions in Finance, Budgeting, Procurement, Human
Resources and Payroll/Time, supporting the design of new and/or redesign of current business
processes to achieve the 4 GFOA recommendations above.
The implementation will be accomplished in three phases:
1. Readiness, Requirement Gathering/RFP
2. Implement Core Finance and Procurement Applications
3. Implement Core Human Resources and Time/Payroll Applications
A full-time project manager was engaged in September 2016 to manage the implementation. The
project is organized of 4 core teams for each of the functional areas, consisting of members from
Finance and Human Resources, augmented by extended department teams of subject matter
experts who will contribute during all the phases of implementation.
As part of the efficiency and effectiveness initiative, the City recently implemented Questica as
the operating budget solution for the 2017-19 financial plan.
The readiness and requirement gathering phase was managed in two steps. The first step was to
identify the “in-scope” processes within each functional area, and document the “As-is”
processes flows, meaning what are the business processes today.. GFOA was engaged for the
“To-be” step to conduct workshops with the Motion Core Team members to analyze the As-is
report and identify weaknesses and recommend “best practices” for each process so that future or
“To-be” processes reflect best practices. The core team along with GFOA, conducted workshops
with key stakeholders from all City Departments.
Packet Pg 32
5
The output from these workshops is the attached RFP package consisting of:
• Main Request for Proposal (RFP) document
• To-be business Processes
• ERP System requirements
• Current Applications
• Inventory of Data Conversion
The RFP and Procurement Schedule is listed on page seven of the Main RFP document.
A Software Selection Panel, with representatives from all departments, has been created to
participate in reviewing the RFP responses and vote on the finalist vendors. The evaluation
criteria is listed in A.12 – Evaluation Criteria section of the RFP document and GFOA will guide
the panel through the selection process.
CONCURRENCES
It is the concurrence of the Department Head Team that the implementation of an ERP software
is required as part of City’s Organizational Efficiency, Effectiveness & Transparency Initiative.
Department Head team approved the project charter. The project charter and this Request for
Proposals has been reviewed and approved by Information Technology City staff.
ENVIRONMENTAL REVIEW
The recommended actions are not a project as defined under the California Environmental
Quality Act.
FISCAL IMPACT
No Fiscal impact. The budget was approved in the 2015-17 Supplemental Financial Plan as per
below:
2016-17 2017-18 2018-19 Total
ERP Acquisition (2015-17
Supplemental Financial Plan)
$1,900,000 $350,000 $2,250,000
Business Systems Analyst - SOPC
Approved (2017-19 Financial Plan)
($90,464) ($90,472) ($180,936)
Total $2,069,064
ALTERNATIVES
If the RFP is not issued, there are no alternative option to continue with Motion project. The
project team will have to be disbanded and continue using the current finance system along with
side systems. This option is not recommended as evidenced b y GFOA recommendations.
Packet Pg 33
5
Attachments:
a - RFP document
b - Software Requirements
c - Data Conversion
d - Business Process
e - Vendor Estimated Staffing Proposal
f - Vendor Cost Proposal
Packet Pg 34
5
Request for Proposal (RFP)
for an
Enterprise Resource Planning (ERP) System
for
The City of San Luis Obispo, CA
RFP# 91621
Release Date 08/16/2017
Pre-Proposal Conference 08/22/2017
Due Date 09/14/2017
Packet Pg 35
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 2 OF 38
CITY OF SAN LUIS OBISPO
Table of Contents
SECTION A: RFP INTRODUCTION ............................................................................ 4
A.1 Purpose of the RFP ...................................................................................................................................... 4
A.2 About the City .............................................................................................................................................. 4
A.3 Project Background – “Motion Project” .................................................................................................... 5
A.4 Notice to Proposers ...................................................................................................................................... 5
A.5 Conditions ..................................................................................................................................................... 5
A.6 City’s Rights Reserved ................................................................................................................................. 6
A.7 Communication Regarding this RFP ......................................................................................................... 6
A.8 Register as a Proposer.................................................................................................................................. 7
A.9 Inquiries and Requests for Clarification .................................................................................................... 7
A.10 Pre-Proposal Conference ........................................................................................................................... 7
A.11 Procurement Schedule ............................................................................................................................... 7
A.12 Evaluation Criteria .................................................................................................................................... 8
A.13 Proposal Submission Instructions ............................................................................................................. 9
A.14 Organization of Proposal ......................................................................................................................... 10
A.15 Format of Electronic Submission ............................................................................................................ 10
SECTION B: DETAILED SUBMITTAL REQUIREMENTS ....................................... 11
B.1 Executive Summary and Introductory Materials .................................................................................... 11
B.2 Scope of Services ......................................................................................................................................... 11
B.3 Functional Requirements ........................................................................................................................... 11
B.4 Implementation Plan .................................................................................................................................. 12
B.5 Ongoing Support and Hosting Services .................................................................................................... 13
B.6 Exceptions to the RFP ................................................................................................................................ 14
B.7 Deliverables and Project Outcomes .......................................................................................................... 14
B.8 Sample Documents ..................................................................................................................................... 15
B.9 Price Proposal ............................................................................................................................................. 15
SECTION C: SCOPE OF PROJECT ........................................................................... 17
C.1 Project Scope - Software ............................................................................................................................ 17
C.2 Project Scope – Implementation Deliverables ......................................................................................... 18
C.3 Project Schedule ......................................................................................................................................... 18
C.4 Project Staffing ........................................................................................................................................... 18
C.5 Statement of Work ..................................................................................................................................... 19
C.6 Number of Users ......................................................................................................................................... 19
C.7 Interfaces ..................................................................................................................................................... 20
C.8 Data Conversion ......................................................................................................................................... 20
C.9 Current Applications ................................................................................................................................. 20
C.10 Business Process Improvement ............................................................................................................... 22
C.11 On-Site Expectations ................................................................................................................................ 22
SECTION D: CONTRACT TERMS AND CONDITIONS............................................ 23
D.1 Key Personnel ............................................................................................................................................. 23
D.2 Implied and Express Warranty................................................................................................................. 23
D.3 Express Warranty Remedy ....................................................................................................................... 23
D.4 System Acceptance ..................................................................................................................................... 23
D.5 Additional Users and Modules .................................................................................................................. 24
D.6 Accuracy of Proposal Fees ......................................................................................................................... 24
D.7 Independent Contractor ............................................................................................................................ 24
D.8 Interests of Proposer .................................................................................................................................. 24
D.9 Intellectual Property .................................................................................................................................. 25
Packet Pg 36
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 3 OF 38
CITY OF SAN LUIS OBISPO
D.10 Confidentiality .......................................................................................................................................... 25
D.11 Hold Harmless and Indemnification ....................................................................................................... 25
D.12 Insurance Requirements .......................................................................................................................... 25
D.13 Business Tax ............................................................................................................................................. 27
SECTION E: ATTACHMENTS .................................................................................. 28
E.1 Attachment 1 (RFP Submittal Checklist) ................................................................................................. 28
E.2 Attachment 2 (Signature Page) ................................................................................................................. 29
E.3 Attachment 3 (Proposer Statement) ......................................................................................................... 30
E.4 Attachment 4 (Scope of Proposal) ............................................................................................................. 31
E.5 Attachment 5 (Company Background) ..................................................................................................... 32
E.6 Attachment 6 (Reference Form) ................................................................................................................ 33
E.7 Attachment 7 (Technical Specifications) .................................................................................................. 34
E.8 Attachment 8 (Software-as-a-Services / Hosting) .................................................................................... 35
E.9 Attachment 9 (Proposed Service Level Agreement) ................................................................................ 36
E.10 Attachment 10 (Maintenance and Support) ........................................................................................... 37
E.11 Attachment 11 (Conversions) .................................................................................................................. 38
E.12 Attachment 12 (Staffing) .......................................................................................................................... 38
E.13 Attachment 13 (Functional Requirements) ............................................................................................ 38
E.14 Attachment 14 (Cost) ............................................................................................................................... 38
E.15 Attachment 15 (Business Process Documentation) ................................................................................ 38
Packet Pg 37
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 4 OF 38
CITY OF SAN LUIS OBISPO
Section A: RFP Introduction
A.1 Purpose of the RFP
With this Request for Proposals (RFP) the City of San Luis Obispo, CA (the City desires to purchase or
otherwise acquire rights to use an Enterprise Resource Planning (ERP) System that meets the
requirements identified in this RFP. The City requires that any proposal for an ERP also include
professional services necessary to implement the system. Proposers offering hosted services or software
as a service (SaaS) systems are encouraged to propose.
A.2 About the City
The City of San Luis Obispo serves as the commercial, governmental, and cultural hub of San Luis
Obispo County. One of California’s oldest communities, it began with the founding of Mission San Luis
Obispo de Tolosa in 1772, by Father Junípero Serra as the fifth mission in the California chain of 21
missions. The mission was named after Saint Louis, a 13th century Bishop of Toulouse, France. The City
was first incorporated in 1856 as a General Law City, and became a Charter City in 1876.
The City has a population of 47,339, and is located eight miles from the Pacific Ocean midway between
San Francisco and Los Angeles at the junction of Highway 101 and scenic Highway 1.
San Luis Obispo is the County Seat, and a number of federal and state regional offices and facilities are
located here, including Cal Poly State University, Cuesta Community College, Regional Water Quality
Board and Caltrans District offices. The City’s ideal weather and natural beauty provide numerous
opportunities for outdoor recreation at nearby City and State parks, lakes, beaches and wilderness areas.
While San Luis Obispo grew relatively slowly during most of the 19th century, the coming of Southern
Pacific Railroad in 1894 opened up the area to the rest of California. The City’s distance from major
metropolitan areas to the north (San Francisco Bay Area) and south (Los Angeles) have allowed it to
retain its historic and scenic qualities, which contribute to the superb quality of life residents enjoy, and
attract visitors from many other areas. In fact, in 2010, the City was dubbed the “Happiest City in North
America” by National Geographic Author Dan Buettner.
The City operates under the Council-Mayor-City Manager form of government. Council members are
elected at-large and serve overlapping, four-year terms. The Mayor is also elected at-large but for a two-
year term, and serves as an equal member of the Council. The Council appoints the City Manager and
City Attorney. All other department heads are appointed by the City Manager. San Luis Obispo is a full-
service city that provides police, fire, water, sewer, streets, transit, parking, planning, building,
engineering, and parks & recreation services to the community.
Background Statistics
Background Summary
Operating Budget (2017-18) $103.745M
Total Revenue (2017-18) $119.021M
Approximate Number of Employees (FTE) 390
W-2s Issued 807
Fiscal Year (City) July 1 – June 30
Packet Pg 38
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 5 OF 38
CITY OF SAN LUIS OBISPO
A.3 Project Background – “Motion Project”
The City’s Motion Project is a citywide initiative to improve efficiency, effectiveness, and transparency
through the implementation of an Enterprise Resource Planning (ERP) System. The ERP implementation
consists of core functions as defined in this RFP and the design of new and/or redesign of current
business processes to achieve these goals. The project was initiated based on the assessment of the
Finance Department conducted by the Government Finance Officers Association (GFOA) and their key
recommendations.
The project was approved by the City Council in April 2016, and is one of the major initiatives supported
by the City Manager. As per the recommendation of GFOA, the project will be accomplished in 3 phases:
1. Readiness, Requirement Gathering/RFP
2. Implement Core Finance and Procurement Applications
3. Implement Core Human Resources and Time/Payroll Applications
A full-time project manager was engaged in September 2016, to manage the implementation. The project
is organized of four core teams for each of the functional areas, consisting of members from Finance and
Human Resources, augmented by extended department teams of subject matter experts who will
contribute during all the phases of implementation.
A Project Charter was presented and endorsed by the department heads in November 2016. As part of the
efficiency and effectiveness initiative, the City recently implemented Questica as the operating budget
solution for the 2017-19 financial plan.
The requirement gathering sessions for requirements found in this RFP included business process
redesign workshops that were facilitated by GFOA and attended by the subject matter experts from all
departments. As described in Section C.10, the City expects that the finalist vendor will be able to
leverage documentation and reduce time and effort on the ERP implementation.
A.4 Notice to Proposers
Failure to carefully read and understand this RFP may cause the proposal to be out of compliance,
rejected by the City, or legally obligate the proposer to more than it may realize. Information obtained by
the proposer from any officer, agent or employee of the City shall not affect the risks or obligations
assumed by the proposer or relieve the proposer from fulfilling any of the RFP conditions or any
subsequent contract conditions. Attempts by or on behalf of a prospective or existing vendor to contact or
to influence any member of the selection committee, any member of the City Council, or any employee of
the City with regard to the acceptance of a proposal may lead to elimination of that vendor from further
consideration. Only the format described in the RFP and the attachments included with this RFP will be
accepted as compliant for the submitted proposal. Failure to completely fill out all required attachments
may result in disqualification.
A.5 Conditions
A.5.1 In the event that all RFP requirements are not met with products and services provided by one
firm, proposers are encouraged to partner with another firm to submit a joint proposal. Failure to
meet all requirements will not disqualify a firm. However, the City will evaluate each proposal
to determine its overall fit in the best interests of the City.
A.5.2 In the event that multiple firms partner to submit a joint proposal, the proposal must identify one
firm as the primary contact. This primary contact will be the primary point of contact throughout
Packet Pg 39
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 6 OF 38
CITY OF SAN LUIS OBISPO
the procurement process and will be held responsible for the overall implementation of all
partners included in the joint proposal.
A.5.3 All third-party solutions or firms proposed as part of a joint proposal are subject to the same
requirements of this RFP, unless otherwise stated.
A.5.4 Pricing must be submitted on a “milestone” basis. For services under a milestone arrangement,
the City compensates the vendor a fixed amount for the completion of major milestones.
Proposers are to provide all work effort and assumptions used to calculate a fixed fee for each
milestone.
A.5.5 The scope of the project will be defined by a statement of work mutually agreed upon between
the City and successful proposer focused on completion of the detailed functional requirements
included as Attachment 13 (Functional Requirements).
A.5.6 All proposals and any subsequent clarification or response to the City’s questions shall be valid
for a minimum of 120 days.
A.6 City’s Rights Reserved
A.6.1 The City reserves the right to select the proposal(s) which in its sole judgment best meets the
needs of the City. The lowest proposed cost will not be the sole criterion for recommending the
contract award.
A.6.2 The City reserves the right to award multiple contracts from this RFP.
A.6.3 The City reserves the right to reject any or all proposals and to waive technicalities and
informalities when such waiver is determined by the City to be in the City’s best interest.
A.6.4 The City may modify this RFP by issuance of one or more written addenda. Addenda will be
posted on BidSync and sent electronically to all proposers registered with the City. (See Section
A.8)
A.6.5 The City reserves the right to meet with select proposers at any time to gather additional
information. Furthermore, the City reserves the right to remove or add functionality (i.e.,
modules, components, and/or services) until the final contract signing.
A.6.6 This RFP does not commit the City to award a contract. All proposals submitted in response to
this RFP, and any subsequent clarifications, communications, and the resulting agreement will
become the property of the City and public records, and as such, may be subject to public
review.
A.6.7 The City shall not be liable for any pre-contractual expenses incurred by prospective vendors,
including but not limited to costs incurred in the preparation or submission of proposals. By
submitting a proposal, each proposer agrees that the City shall be held harmless and free from
any and all liability, claims, or expenses whatsoever incurred by, or on behalf of, any person or
organization responding to this RFP.
A.7 Communication Regarding this RFP
All communication from prospective proposers regarding this RFP must be made as required in sections
A.9 and A.10 of this RFP. Communication by telephone or in person will not be accepted.
Attempts by or on behalf of a prospective or existing vendor to contact or to influence any member of the
selection committee, any member of the City Council or any employee of the City with regard to the
acceptance of a proposal may lead to elimination of that vendor from further consideration.
Packet Pg 40
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 7 OF 38
CITY OF SAN LUIS OBISPO
A.8 Register as a Proposer
All firms interested in receiving further correspondence regarding this RFP are required to register using
BidSync (www.BidSync.com).
A.9 Inquiries and Requests for Clarification
A.9.1 In an effort to maintain fairness in the process, inquiries concerning this procurement , including
questions related to technical issues are to be directed through Bidsync. In the event a
prospective vendor has difficultly submitting questions through BidSync, the prospective vendor
should contact BidSync support (support.BidSync.com)
A.9.2 All questions concerning the RFP must reference the RFP page number, and section heading and
must be submitted on the date indicated in section A.11 of this RFP. Questions will be answered
and posted to BidSync.
A.9.3 Inquiries or requests for clarification submitted prior to the pre-proposal conference will be
addressed at the pre-proposal vendor conference. Additional inquires or requests for clarification
will be accepted until the deadline specified in Section A.11.
A.10 Pre-Proposal Conference
A pre-proposal vendor conference will be held on August 22, 2017 at City Hall and by conference call.
Attendance at the pre-proposal conference is not mandatory. Proposers intending to participate in the pre-
proposal conference should request meeting access information when registering. Answers to questions
submitted prior to the conference and answers to all questions asked at the pre-proposal meeting will be
officially answered by addendum after the meeting.
A.11 Procurement Schedule
The expected procurement schedule is listed below. The City reserves the right to change the procurement
schedule. If changes are made, proposers will be notified by the City in the form of an addendum to this
RFP.
Procurement Schedule
August 16, 2017 RFP released
August 22, 2017 Pre-proposal conference – 10:00 AM (PDT)
August 28, 2017 Last day to accept questions and requests for clarification on the RFP -
4:00 PM (PDT)
August 30, 2017 Answers to submitted questions provided
September 14, 2017 Proposals due – 2:00 PM (PDT) & Public Opening 2:15 PM (PDT)
October 2, 2017 Up to three proposers elevated and notified for software demonstrations
Week of October 16,
23, 30 Software demonstrations and Implementation Presentations
November 3, 2017 Elevate and notify semifinalist or finalist proposer(s)
Packet Pg 41
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 8 OF 38
CITY OF SAN LUIS OBISPO
Procurement Schedule
Week of November 27 Discovery sessions completed (1-2 days per elevated proposer, if
necessary)
December 2018 Complete contract negotiations and Statement of Work (SOW)
Mid January 2018 Award of contract by City
February 2018 Implementation Begins
A.11.1 Software demonstrations and implementation presentations will be held on-site at the City’s
offices and can cover all functional areas listed in this RFP. The City expects to elevate up to
three (3) proposers for demonstrations. Demonstrations will include both presentations on
software and implementation services. It recommended that key member’s proposer’s
implementation staff proposed for this project be present at the demonstration and lead
presentation of any implementation topics. To avoid unnecessary delays, the City expects that
proposers will be available for software demonstrations and on-site Discovery sessions on the
dates identified on the procurement schedule and to identify any potential issues or conflicts in
their response to this RFP using Attachment 2 (Signature Page). Proposers that cannot
demonstrate their software during the dates identified or make key members of their proposed
project team available may be eliminated. The agenda and software demonstration scripts will be
distributed to proposers that have been short-listed for software demonstrations approximately
two weeks in advance of the interviews.
A.11.2 Discovery sessions will consist of an additional on-site meeting with elevated proposers to focus
on implementation issues and development of a statement of work. It is expected the City will
elevate either one (1) or two (2) proposers. Each elevated proposal team will receive a Request
for Clarification (RFC) letter that will ask proposers to clarify any necessary parts of the initial
proposal. In addition, the RFC letter will identify a schedule for the on-site Discovery session
that will include a detailed discussion of implementation issues. It is the expectation of the
City that all key project team members will be available for the on-site Discovery sessions.
A.11.3 The City expects that the implementation project will commence in early February 2018.
Prospective vendors are required to ensure that all proposed resources will be available to begin
work at the appropriate time to facilitate completion of the City’s schedule as identified in
Section C.3.
A.12 Evaluation Criteria
The City will review all proposals received as part of a documented evaluation process. For each decision
point in the process, the City will evaluate proposers according to specific criteria and will then elevate a
certain number of proposers to compete in the next level. Proposers not previously elevated may be
elevated at a later date.
The sole purpose of the proposal evaluation process is to determine which solution best meets the City’s
needs. The evaluation process is not meant to imply that one proposer is superior to any other, but rather
that the selected proposer can provide and has proposed the best software and implementation approach
for the City’s current and future needs based on the information available and the City’s best efforts of
determination.
Packet Pg 42
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 9 OF 38
CITY OF SAN LUIS OBISPO
The proposal evaluation criteria, which will be developed by the City prior to opening of proposals,
should be viewed as standards that measure how well a proposer’s approach meets the desired
requirements and needs of the City. The criteria that will be used to evaluate proposals may include, but
are not limited to the following:
▪ Cost
▪ Response to Attachment 13 (Functional Requirements)
▪ Qualifications of Proposed Project Team
▪ Software Demonstrations
▪ Implementation Approach
▪ Project Management Approach
▪ Past Experience with Similar Organizations and References
▪ Proposed Integration to Other Modules / Systems in RFP Scope
▪ Technical Compatibility
▪ Service Level Guarantees
▪ Overall Understanding of the City’s Needs and Project Risk Mitigation
▪ Compliance with Contract Terms and Conditions
The City reserves the right to determine the suitability of proposals on the basis of any or all of these
criteria or other criteria not included in the above list. The City’s evaluation team will then make a
recommendation to be approved by the City’s steering committee to elevate proposals for software
demonstrations, discovery, and final contract negotiations.
A.13 Proposal Submission Instructions
A.13.1 Proposals are to be submitted in sealed packages by September 14, 2017 at 2:00 PM PDT. Late
submissions will not be accepted.
Submittal Address:
City of San Luis Obispo
Attn: Kristin Eriksson - Finance
990 Palm Street
San Luis Obispo, CA 93401-3249
Public Opening Address: 990 Palm Street, Council Hearing Room @ 2:15 PM PDT
A.13.2 Failure to comply with the requirements of this RFP may result in disqualification. Proposals
received subsequent to the time and date specified above will not be considered. Please note the
following as part of the submittal process.
A.13.3 Signature of the proposal by the proposer constitutes acceptance by the proposer of terms,
conditions, and requirements set forth herein.
A.13.4 Proposers are required to separate their proposals into two sections, a technical proposal and a
price proposal.
▪ Proposers are required to submit TWO (2) electronic copies (external hard drives or flash
drives) of the technical proposal in a sealed package that is clearly labeled with the proposer’s
company name, the RFP name and the words “Technical Proposal”. Technical proposal must
include a submittal letter signed by an authorized agent of each firm involved in the proposal.
The letter should include appropriate contact information for each firm.
Packet Pg 43
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 10 OF 38
CITY OF SAN LUIS OBISPO
▪ Proposers are required to submit TWO (2) electronic copies of the price proposal in a sealed
package, clearly labeled with the proposer’s company name, the RFP name and the words
“Price Proposal”.
A.13.5 Emailed and faxed proposals will not be accepted.
A.13.6 Use Attachment 1 (RFP Submittal Checklist) to ensure that all required documents, forms, and
attachments have been completed and submitted as instructed.
By submitting a proposal, the proposer is providing a guarantee to the City that, if chosen, it will
be able to provide the proposed products and services during the period of time discussed in the
RFP. Upon submission, all proposals shall be treated as confidential documents until the
selection process is completed. All proposals and supporting documents become public
information after an award has been made and are available for public inspection by the general
public in accordance with State of California public records statutes.
A.13.7 In the event that a proposer desires to claim portions of its proposal exempt from disclosure, it is
incumbent upon the proposer to clearly identify those portions with the word “Confidential”
printed on the top of each page for which such privilege is claimed. Each page shall be clearly
marked and readily separable from the proposal in order to facilitate public inspection of the
non-confidential portion of the proposal. The City will consider a proposer’s request for
exemptions from disclosure; however, the City will make its decision based upon applicable
laws. An assertion by a Proposer that the entire proposal, or large portions, is exempt from
disclosure will not be honored and vendor may be asked to re-submit proposal for consideration.
Prices, makes and models or catalog numbers of the items offered, deliverables, and terms of
payment shall be publicly available regardless of any designation to the contrary.
A.14 Organization of Proposal
The proposal must be organized into major sections defined in Section B. Specific instructions for each
section are provided in Section B of this RFP. Any required attachments must be included in the proper
section as indicated by the instructions.
A.15 Format of Electronic Submission
Proposers must provide electronic copies of all files on a USB flash drive or similar device using the
following file formats. Attachments not listed in the table below do not have a required file format and
may be supplied in either the original file format or PDF.
RFP Section Attachment/Document Required File Format
E.11 Attachment 11 (Conversions) Microsoft Excel (.xls or .xlsx)
E.12 Attachment 12 (Staffing) Microsoft Excel (.xls or .xlsx)
B.8.1 Sample agreements Microsoft Word (.doc or .docx)
E.13 Attachment 13 (Functional Requirements) Microsoft Excel (.xls or .xlsx)
E.14 Attachment 14 (Cost) Microsoft Excel (.xls or .xlsx)
* NOTE: Attachment 13 (Functional Requirements) is password protected to prevent responders from
making changes to the functional requirements.
Packet Pg 44
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 11 OF 38
CITY OF SAN LUIS OBISPO
Section B: Detailed Submittal Requirements
So that competing proposals can be compared equally, proposers must assemble their proposals in strict
adherence to the submittal requirements identified in Section A.14. Failure to follow all proposal
organizational requirements may result in disqualification. Proposals should be prepared as simply as
possible and provide a straightforward, concise description of the proposed products and services to
satisfy the requirements of the RFP. Attention should be given to accuracy, completeness, relevance, and
clarity of content. Proposals must address the following questions and contain the following sections.
B.1 Executive Summary and Introductory Materials
(Proposal Section 1.0) The introductory material should include a title page with the RFP name, name of
the proposer, address, telephone number, the date, a letter of transmittal, and a table of contents. The
executive summary should be limited to a brief narrative (less than 3 pages) summarizing the proposal.
B.1.1 Complete Attachment 1 (RFP Submittal Checklist)
B.1.2 Complete Attachment 2 (Signature Page)
B.1.3 Complete Attachment 3 (Proposer Statement)
B.2 Scope of Services
(Proposal Section 2.0) This section of the proposal should include a general discussion of the proposer’s
overall understanding of the project and the scope of work proposed including the following:
B.2.1 Complete Attachment 4 (Scope of Proposal)
B.2.2 For each firm identified on Attachment 4 (Scope of Proposal), explain the following:
▪ Complete the Attachment 5 (Company Background)
▪ Complete Attachment 6 (Reference Form).
▪ Role of the firm in the project
B.2.3 List and describe all proposed software products that will be delivered as part of the project and
if the City will need to maintain/host the software on its servers. If software is sold by module,
proposer must explicitly state the software module name and versions that are proposed.
▪ All functional requirements that are responded to with a positive response (anything
except “N”) are considered to be in scope. Proposed software and any necessary services
required to meet the requirements of the RFP or implement the proposed software should
be included in the proposal.
B.3 Functional Requirements
(Proposal Section 3.0) 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, the scope of the implementation plus if the
Packet Pg 45
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 12 OF 38
CITY OF SAN LUIS OBISPO
requirement will be include under the scope of any proposed support agreement. Responses to the
functional requirements shall use the following response codes:
Functional Requirements Responses
Column E: Available Responses
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
I Need More Information/Discussion
B.3.1 Submit Attachment 13 (Functional Requirements)
• Failure to provide some requirements or excluding some requirements from scope will NOT
eliminate the proposer from contention. The City will evaluate the proposal as a whole
including price/value comparisons when evaluating proposals.
• The requirements responses submitted will become part of the agreement. Proposers are
expected to warrant both software and implementation of all positive responses (every
response except “N” and “I”).
• The City will clarify any requirements with the response of “I” during software
demonstrations. Immediately following software demonstrations, proposers would be
expected to re-submit Attachment 13 (Functional Requirements).
• For requirement responses other than “N” or “I” proposers must indicate the module or
product that is required to meet the requirement.
• For requirement responses other than “N” or “I” proposers must indicate the phase of the
project that the functionality will be implemented.
• All responses which are marked Y, or Y-ND will be considered to be included in the scope,
and the cost proposal and all other information submitted in this proposal should reflect this.
Furthermore, the module necessary to perform that functionality must be included in the
scope and cost of this proposal.
• Proposers must be ready to demonstrate any requirements listed as “Y” during software
demos.
B.3.2 Identify any licenses, hardware, or other products not included in this proposal that would be
required to operate any of the proposed solutions contained in this proposal.
B.3.3 Describe the technical environment necessary for this software for any products that are to be
hosted by the City by completing Attachment 7 (Technical Specifications) (if applicable).
B.4 Implementation Plan
(Proposal Section 4.0) This section should describe the proposed implementation plan. Proposers should
reference Section C.4 for listing of likely City resources that will contribute to this project.
B.4.1 Provide a detailed plan for implementing the proposed system. This information must include:
• Proposed phasing for roll-out of proposed system
• Schedule of key dates
Packet Pg 46
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 13 OF 38
CITY OF SAN LUIS OBISPO
B.4.2 Explain the proposed plan for implementation. This information must include:
• Description of implementation tasks and activities
• Description of key deliverables (and how they relate to the implementation approach and
activities). Please note the required deliverables listed in Section C.
B.4.3 Explain the proposed vendor staffing for the project including:
• Approximate dedication to the project of each resource and approximate time work will be
completed on-site vs. off-site
• Identify how the vendor plans to control costs by utilizing remote meetings
• Major roles and responsibilities for each resource
B.4.4 Explain proposed project management services including:
• Role of the vendor project manager
• Use of project collaboration site
• Expected role of the City project manager
• On-Site presence of vendor project manager
• Proposed quality assurance procedures
B.4.5 Explain the expected City staffing for the project including:
• Assumed participation in the project (average portion of FTE). This should include all time
spent working on the project (including time spent with and without vendor consultants)
• Assumptions about prior skills / competencies of resources
• Complete Attachment 12 (Staffing). Refer to Section C.4 of the RFP for project staffing
assumptions.
B.4.6 Provide an overview of proposed training plan/strategy, specifying how and when training is to
be delivered for both on-site and off-site training and web training services for the core project
team, end users, and technology personnel (if required).
• Explain any roles and responsibilities the City is expected to provide for the training
effort including (but not limited to) training coordination, training material development,
training delivery, etc.
B.4.7 Complete Attachment 11 (Conversions). The City expects proposers to include all conversions
listed in the RFP.
B.5 Ongoing Support and Hosting Services
(Proposal Section 5.0) The proposal should specify the nature of any post-implementation and on-going
support, including hosting services provided by the vendor including:
B.5.1 Complete Attachment 8 (Software-as-a-Services / Hosting) (if applicable)
B.5.2 Describe proposed services for hosting including:
• Information on the specific hosting services provided
• Help desk support services
• Application support
• Operational support services
• Technology infrastructure services
Packet Pg 47
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 14 OF 38
CITY OF SAN LUIS OBISPO
• Disaster recovery
• Will all products (including third party products) be hosted through the same provider?
• Will the City need to host anything on its servers?
B.5.3 For each of the services proposed explain service levels that are used to guarantee performance
for the City through the proposed hosting agreement. Complete Attachment 9 (Proposed Service
Level Agreement)
B.5.4 Complete Attachment 10 (Maintenance and Support)
B.6 Exceptions to the RFP
(Proposal Section 6.0) All requested information in this RFP should be supplied. Proposers may take
exception to certain requirements in this RFP. All exceptions shall 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.
To avoid the scenario where the City is unable to negotiate successfully with its finalist vendor, any
material exceptions to the RFP including those to the terms and conditions listed in Section D will be
clarified prior to elevation for software demonstrations. City reserves right to negotiate terms at any
point and elevation for software demonstrations does not constitute acceptance of vendor’s alternative
terms.
B.7 Deliverables and Project Outcomes
(Proposal Section 7.0) This section should describe proposed project deliverables and past client
outcomes specifically addressing the following:
B.7.1 Provide a listing of project deliverables (work products) and for each identify:
• Purpose of deliverable
• Expected scope / contents of deliverable
• If deliverable is expected to have value outside the ERP implementation project
B.7.2 Provide an excerpt from project deliverables showing process documentation, configuration
documentation, testing scripts, training materials, and requirements traceability
B.7.3 The City is looking to fully leverage the human resource functionality in the system. Please
describe a past project where you feel your client established an effective system modeled in
“best practice” for managing an employee’s human resources for employee evaluations, training,
skills/certifications, succession planning, and recruiting.
B.7.4 The City desires to automate the exchange of information between the system and various
benefit providers. Please explain specific past client examples where your firm helped establish
these interfaces.
B.7.5 The City’s long term fiscal sustainability depends on ability to make smart budget decisions,
create long-range financial plans, and effective manage its existing capital infrastructure and
equipment. Please describe a past project where the proposed software is used to complete the
following:
• Create a program budget
• Consider multiple scenarios that impact service levels
• Create long term financial projections
Packet Pg 48
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 15 OF 38
CITY OF SAN LUIS OBISPO
• Develop a multi-year CIP
• Create asset replacement schedules
• Identify long term funding needs for capital projects
B.7.6 With the system, the City expects to improve the effectiveness of its purchasing function and a
significant part of that will depend on the ability to collect and report information from p-cards.
Please describe how past clients have used p-card integration to track spending by vendor, type
of purchase, and user.
B.7.7 With modern technology providing greater access to information, City employees and managers
are able to better utilize information for decision making. However, much of this relies on
having technology that is truly accessible. Please identify how a past client used mobile
features, dashboards, reporting tools, and self service capabilities to create a source of
information that is widely used across the organization.
B.8 Sample Documents
(Proposal Section 8.0) Proposers should include sample copies of the following documents.
B.8.1 Any sample agreements that the City would be required to sign upon contract award. This
would include any applicable software license agreements, professional service agreements,
hosting agreements, third party agreements, etc.
B.8.2 Sample Project Plan
B.9 Price Proposal
(Proposal Section 9.0) - TO BE SUBMITTED UNDER SEPARATE COVER. Proposers should
submit their price proposal in a separate and sealed packet according to the format provided in
Attachment 14 (Cost) to this RFP.
B.9.1 Identify major milestones as part of the project. It is required that costs will be invoiced upon
completion of major milestones and cumulative payments should not exceed incurred work.
Please provide a schedule of all payments necessary to complete the proposed scope.
B.9.2 Complete and submit Attachment 14 (Cost)
• It is important that proposers use the format presented in this RFP even if an additional
format is provided. Attachment 16 (Cost) should include total price for all software and
services, including third parties. If third party products or services are included, do not
provide separate version of Attachment 14 (Cost) for each third-party product.
• All pricing must be submitted as fixed by milestone. Costs listed as “to-be-
determined” or “estimated” will not be scored.
• All service costs must 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.
• City requires that milestone payment for final acceptance of each phase (as defined in
Section D) be at least 10% of the total cost for each phase.
Packet Pg 49
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 16 OF 38
CITY OF SAN LUIS OBISPO
• 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.
• Proposers must 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) must be a fixed fee or included in the implementation
milestones.
Packet Pg 50
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 17 OF 38
CITY OF SAN LUIS OBISPO
Section C: Scope of Project
C.1 Project Scope - Software
The project scope for procurement and implementation of software solutions is briefly described in the
chart below. Specific functionality within each category listed below is more thoroughly described in
Attachment 13 (Functional Requirements)
The City expects that the project will result in the following business processes being implemented City-
wide following the process documentation included in the RFP as Attachment 15.
Process List
Process Task / Topics
Accounting • Chart of Accounts
• General Ledger Transactions
• Activity Costing and Budget Monitoring
• Internal Service Charges
• Grant / Project Tracking
• Financial Reporting
Budget • Operating Budget
• Capital Improvement Planning (CIP)
• Capital Budget
• Budget Adjustments / Amendments
Procure – Pay • Vendors
• Purchase Requisitions
• Purchase Orders
• Contract Management
• Change Order
• Receiving
• Accounts Payable
• Inventory
Customer Billing
• Customer File
• Billing
• Accounts Receivable
Treasury • Cash Receipts
• Disbursements
• Interest Allocation
• Bank Reconciliation
• Investments
Asset Management • Asset Acquisition
• Depreciation
• Transfer / Disposal / Retirement
Human Resources • Positions
• Employee File
• Benefit Enrollment
• Personnel Evaluations
• Disciplinary Actions / Grievance
• Risk Management (Injury / Workers Comp)
• Training / Certifications
Packet Pg 51
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 18 OF 38
CITY OF SAN LUIS OBISPO
Process List
Personnel Actions • Recruitment
• New Hire
• Personnel Actions (Salary Adjustment / Position Change)
Time Entry – Payroll • Time Entry
• Time Approval
• Payroll Calculations
• Payroll Processing
• Leave Management (FMLA)
C.2 Project Scope – Implementation Deliverables
To ensure quality throughout the implementation, the City’s project will include, at a minimum, the
following deliverables. Each deliverable will be the responsibility of the vendor and will be formally
presented to the City for review and sign off. For projects with multiple phases, the City expects each
phase to contain each deliverable (unless noted)
1. Comprehensive Project Plan – Detailed listing of tasks for the entire project that includes the
following for each task: due date, responsibility, predecessors. Tasks to itemize on the project plan
will include all implementation activity, deadlines, milestones, sign offs, review periods, and
deliverables. The project plan is also to include County staff resources and tasks.
2. System Design Document – Work product that identifies both the business process decisions as well
as system configuration decisions for each in scope business pr ocess and system feature. System
design documentation will be organized by business process and contain recommendations, City
decisions, and detailed process and system documentation. The City expects that vendors will use
documentation included in Attachment 15 (Business Process Documentation) for initial
process documentation.
3. Testing Scripts – Test scripts based on the functional requirements and system design document that
require successfully completion of each item in scope (functional requirements) and the set-up of
the system (system configuration).
4. Training Documentation – Complete system manual for how to use the configured system. Vendors
should propose services to train end-users on how to use the software and operate within new
business processes
5. Requirements Traceability – Vendor documents that all requirements identified in Attachment 13
(Functional Requirements) are included in the project.
C.3 Project Schedule
The City has identified the schedule below as its proffered project schedule. Unless a prospective vendor
believes its approach is advantageous for the City, all proposals should be consistent with the below
schedule.
Project Schedule
Phase Start Go -Live
1) Finance February 2018 October 2018
2) HR/Payroll February 2018 March 2019
3) Budget TBD September 2019
C.4 Project Staffing
The City will make every effort to staff the project appropriately and understands that staffing a project is
important to its success. The following table lists resources that the City expects to be available for the
Packet Pg 52
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 19 OF 38
CITY OF SAN LUIS OBISPO
project, their applicable areas of knowledge/assumed roles in the project, and the maximum participation
levels in the project. Project staffing will be organized into four main teams (finance, human resources,
payroll/time entry, and budgeting. The City will also make technical staff available to serve any
necessary roles.
City Staff Participation
Assumed Role Maximum Participation
(FTE)
Project Manager 1.0 FTE
Finance Lead .50 FTE
General Ledger / Treasury Lead .50 FTE
Procurement Lead .50 FTE
Accounts Payable Support .25 FTE
Revenue / Accounts Receivable Support .25 FTE
Project Accounting Support .25 FTE
Capital Asset Support .25 FTE
Human Resources Lead .50 FTE
Employee Administration Support .25 FTE
Organization and Position Support .25 FTE
Benefits Support .25 FTE
Payroll / Time Entry Lead .50 FTE
Time Entry Lead .25 FTE
Payroll Lead .25 FTE
Budgeting Lead .75 FTE
Technical Lead .75 FTE
C.5 Statement of Work
The City will require the development of a detailed statement of work, including a high -level project plan,
prior to contract signing. The statement of work will include and describe at least the following and may
include additional items the City deems necessary:
▪ Project scope
▪ Project milestones
▪ Project deliverables
▪ High level project schedule (listing of phases and go-live dates)
▪ Project resources
▪ Project roles and responsibilities
▪ Project change control procedures
C.6 Number of Users
It is difficult for the City to envision exactly who will use the system as implementation of the system will
result in a major change in the way that the City does business. Proposers should plan however on having
all City departments with access to the system for at least a few users to enter transactions. The following
user counts identify expected users within each functional area. Additional users may be required for
extra help and proposers should plan to provide sufficient system access for the City to fully implement
their desired business processes. Proposals should include services to complete implementation and any
appropriate training services to prepare all City staff for using the system. (Note: Employees are counted
in multiple columns).
Packet Pg 53
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 20 OF 38
CITY OF SAN LUIS OBISPO
The City expects that pricing for software will be on an enterprise basis where all City employees will
have access to the software to perform necessary tasks and the City will not encounter issues where
individual employees are not licensed to perform tasks.
City Users
Type of User Estimated Number of Users Estimated Number of Power
Users
Financials 75 35
HR/Payroll 75 20
Budgeting 50 10
Purchasing 75 10
Technical/Administrative Users NA 5
Self Service Access All City Employees NA
C.7 Interfaces
Interface requirements have been included in with the functional requirements. Proposers should respond
to each functional requirement, including the interface requirements, to identify the proposed scope. Any
positive response – “Y” or “Y-ND” is considered to be in-scope and all pricing for the proposed scope
included in the submitted milestone pricing. Interfaces to the City’s existing systems and/or third party
vendors are critical to the project success
C.8 Data Conversion
The City understands the level of effort required to convert data and is interested in converting only
essential data required for the new system. Proposers are required to complete Attachment 11
(Conversions) and indicate the proposed data conversions that are included in scope.
C.9 Current Applications
The following applications are used by the organization for major business functions. Information about
their replacement or interface is provided for the proposer’s convenience. The City intends to discuss the
future use of these applications during software demonstrations and contract negotiations.
Function Name Description Interface?
HR Aflac
Section 125
supplemental plan y
HR Carl Warren Claims Administrator y
HR CJPIA
Liability Insurance &
Worker's Com. y
HR Delta Dental
Dental Insurance
provider y
HR ICMA
Deferred Comp
Administrator y
HR Lincoln Financial
SLOCEA's Long-Term
Disability Administrator y
HR Mass Mutual
Deferred Comp
Administrator y
Packet Pg 54
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 21 OF 38
CITY OF SAN LUIS OBISPO
Function Name Description Interface?
HR MES Vision
MESVision (Medical Eye
Services) vision care
provider y
HR MHN Provider Portal
Healthcare provider
network y
HR myCALPERS
California Public
Employees' Retirement
System agency y
HR Nationwide
Deferred Comp
Administrator y
HR NeoGov
Government and Public
Sector software used for
recruitment y
HR John Hancock
PARS 401(a) deferred
comp y
HR The Standard Life Insurance provider y
HR York
Work Comp
Administrator y
HR DMV
Department of Motor
Vehicles y
HR CDT
Pre-Employment/Drug
Testing y
HR AMC
Pre-Employment/Drug
Testing y
HR DOJ Department of Justice y
HR/Payroll Intellitime
Timekeeping and
Scheduling Solutions for
the Public Sector TBD
HR Target Solutions
Fire Safety Training
Management System y
HR Lexipol
Policy Management
Software for Public
Safety y
HR Spillman
Spillman Technologies:
Public Safety Software
Solutions y
Asset Cityworks
Asset management/work
orders y
AR Springbrook Utility Billing y
Projects
CIPAce Portfolio
Management Platform
Project Planning and
Management TBD
Finance Pentamation Finance Plus
Finance, Fixed Assets,
Projects, HR & Payroll
N, to be
decommissioned
Finance
Pentamation Community
Plus
Miscellaneous
Receivables
N, to be
decommissioned
Finance HDL Business Licenses Y
GIS/Billing EnerGov GIS and Billing Y
Finance Franchise Tax Board CA State Taxes Y
Asset
AssetWorks: Asset
Management Services &
Software Solutions
Asset Management for
Fleet Management Y
Training Target Safety Training Database TBD
AR
Online Event Registration &
Management Software
Event registration &
booking Y
Packet Pg 55
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 22 OF 38
CITY OF SAN LUIS OBISPO
Function Name Description Interface?
AR GolfNow Golf course booking Y
Time WhenToWork Shift Planning TBD
Time TeleStaff
Time entry and
scheduling TBD
Time
Speedshift staff scheduling
application Scheduling TBD
C.10 Business Process Improvement
The City’s Motion Project has involved City staff working to define improved processes. The City
expects that the finalist vendor will leverage work already completed and not require significant time
spent on understanding current process and working through gap analysis. Expected “to-be” process flows
for many key processes are included in Attachment 15 (Business Process Documentation). The City
expects that vendors will leverage this documentation in project deliverables and make recommendations
on how to best leverage the software to meet these processes – or improve upon processes with features of
the software.
C.11 On-Site Expectations
The City understands all projects are delivered with a mix of on-site and off-site services and requests that
vendors consider both project quality and cost considerations when submitting proposals. The City
expects that certain services, such as training, project management, change manage ment, and other
services where on-site presence is important be delivered onsite, however the City also expects that
vendors explore use of remote service delivery through web meetings, and video conferencing as a
method to reduce project costs.
Packet Pg 56
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 23 OF 38
CITY OF SAN LUIS OBISPO
Section D: Contract Terms and Conditions
Below are important contract terms and conditions that the City expects to be part of an agreement with
the finalist proposer(s). Please indicate your willingness to comply with each condition by noting any
exceptions per the instructions in section B.6 of this RFP. Contract terms in the final agreement should
include but will not be limited to those listed below. The City will carefully evaluate any exceptions to
the terms and conditions listed below.
D.1 Key Personnel
The City requires assurances as to the consistency and quality of vendor staffing for its project. Key
points of the City’s key personnel provision include:
D.1.1 The City shall have the ability to interview and approve key personnel proposed by the vendor.
D.1.2 The City shall have the right to dismiss key personnel from the project.
D.1.3 Vendor key personnel may not be removed from the project without the City’s approval.
D.2 Implied and Express Warranty
The Proposer will expressly warrant that
D.2.1 All work performed in connection with this project be performed in a competent, professional,
and workmanlike manner, and shall be consistent with the accepted practices of leading
providers performing similar services or professional standards referenced in the vendor’s
proposal
D.2.2 All work will be performed by an adequate number of qualified individuals with suitable
training, education, and experience
All work performed shall comply with applicable laws
All work performed and all deliverables, including the System itself will conform to the scope and
specifications as stated in the RFP including the functional requirements identified as Attachment 13
(Functional Requirements) for a period extending no less than 24 months after final acceptance.
D.3 Express Warranty Remedy
The City requires that the vendor commit to repair or replace any function not working in the system
during the life of the warranty. In the event a problem cannot be fixed the vendor will reimburse the City
for costs to acquire and implement an functionally equivalent replacement.
D.4 System Acceptance
For purposes of acceptance of the system (or portions thereof), the City intends to use a two-staged
acceptance procedure for each phase and for the entire project. Key points include:
D.4.1 “Conditional Acceptance” will occur at or prior to go-live. The City will have up to forty-five
(45) days to test the system (“pre-live testing”) before going live.
D.4.2 The City will have a 60-day period after Conditional Acceptance to “live test” the system. Live
testing is the City’s opportunity to verify that the system complies with the functional
requirements and any other written specifications delivered to the City by the vendor during the
course of the project.
Packet Pg 57
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 24 OF 38
CITY OF SAN LUIS OBISPO
D.4.3 If after the live testing the system performs in accordance with the system specifications
(including the design document and functional requirements), and all services identified in the
statement of work are completed, the City will issue “Final Acceptance.”
D.5 Additional Users and Modules
The City will require “price protection” for a minimum of two (2) years from the effective date of the
agreement for additional City users and modules that are listed in the proposal but are not initially
purchased.
D.6 Accuracy of Proposal Fees
The City requires that any proposed licenses or fees to access the software be adequate to allow the City
to use the system unrestricted for all business purposes of the City and the City agencies, departments,
and other third party entities under the control of the City. The City will not be subject to expansion fees,
additional license purchases, or fees for additional users, increases in City employee count, budget size,
population size, or data storage requirements for a period of 6 years from the effective date of the
agreement.
D.7 Independent Contractor
D.7.1 Proposer understands and acknowledges that it is an independent contractor, not an employee,
partner, agent, or principal of City. This Agreement does not create a partnership, joint venture,
association, or employer-employee relationship between the Parties. At its own expense,
Proposeris responsible for providing compensation; employment benefits; disability,
unemployment, and other insurance; workers’ compensation; training; permits and licenses; and
office space for Proposer and for Proposer’s employees and Subconsultants. Proposer has, and
shall retain, the right to exercise full control over the employment, direction, compensation, and
discharge of all persons whom Proposer uses in performing the Services under this Agreement.
D.7.2 Propower shall provide the Services in Proposer’s own manner and method, except as this
Agreement specifies. Proposer shall treat a provision in this Agreement that may
appear either to give City the right to direct Proposer as to the details of doing the work,
or to exercise a measure of control over the work, as giving Propower direction only as to
the work’s end result.
D.7.3 Proposer shall indemnify, defend (including Proposer’s providing and paying for legal counsel
for City), and hold harmless City for any obligation; claim; suit; demand for tax or retirement
contribution, including any contribution or payment to pensions; social security; salary or wages;
overtime, penalty, or interest payment; or workers' compensation payment that City may be
required to make on behalf of Proposer, an employee of Proposer, or any employee of Proposer
construed to be an employee of City, for the work done under this Agreement.
D.8 Interests of Proposer
The Proposer covenants that it presently has no interest, and shall not acquire any interest—direct,
indirect or otherwise—that would conflict in any manner or degree with the performance of the work
hereunder. The Proposer further covenants that, in the performance of this work, no sub-consultant or
person having such an interest shall be employed. The Proposer certifies that no one who has or will have
any financial interest in performing this work is an officer or employee of the City. It is hereby expressly
agreed that, in the performance of the work hereunder, the Proposer shall at all times be deemed an
independent Proposer and not an agent or employee of the City.
Packet Pg 58
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 25 OF 38
CITY OF SAN LUIS OBISPO
D.9 Intellectual Property
D.9.1 If Proposer uses or incorporates patented, trademarked, or copyrighted work, idea, or products, in
whole or in part, into Proposer’s work product, Proposer represents that:
(A) Proposer holds the patent, trademark or copyright to the work, idea or product; or
(B) Proposer is licensed to use the patented, trademarked or copyrighted work idea or product.
D.9.2 Unless City states otherwise in writing, all proprietary rights or intellectual property rights,
including copyrights, that arise from creation of the work under this Agreement vest in City.
Proposer waives and relinquishes all claims to proprietary rights and intellectual property rights,
including copyrights, in favor of City.
D.9.3 Proposer shall indemnify, defend (including COntrator5’s providing and paying for legal counsel
for the City) and hold harmless City, its officials, officers, agents, employees, and representatives
from and against all liability, claims, suits, demands, dama ges, royalties, fines, penalties, costs or
expenses arising out of or alleging any infringement or misappropriation of a patent, copyright,
trade secret, trade name, trademark or other intellectual property right or proprietary right.
D.10 Confidentiality
Proposer shall not use any information that it obtains from performing the Services for any purpose other
than for fulfillment of Proposer’s Scope of Work. Without City’s prior written authorization, Proposer
shall not disclose or publish, or authorize, permit or allow others to disclose or publish, data, drawings,
designs, specifications, reports or other information relating to the Services or the work that City assigns
to Proposer or to which Proposer has access.
D.11 Hold Harmless and Indemnification
Proposer agrees to defend, indemnify, protect and hold the City and its officials, agents, officers and
employees harmless from and against any and all claims asserted or liability for damages or injuries to
any person or property, including injury to Proposer's employees, agents or officers which arise from or
are connected with or are caused or claimed to be caused by the acts or omissions of Proposer, and its
agents, officers or employees, in the performance of all obligations under this Agreement, and all
expenses of investigating and defending against same; provided, however, that Proposer's duty to
indemnify and hold harmless shall not include any claims or liability arising from the proven sole
negligence or willful misconduct of the City, its agents, officers or employees.
D.12 Insurance Requirements
D.12.1 Upon notice of intent to award contract, the Proposer shall provide proof of insurance in the form,
coverages and amounts specified in these conditions as a precondition to contract execution. The
Proposer shall procure and maintain for the duration of the contract insurance against claims for
injuries to persons or damages to property which may arise from or in connection with the
performance of the work hereunder by the Proposer, its agents, representatives, employees or sub-
consultants.
D.12.2 Minimum Scope of Insurance. Coverage shall be at least as broad as:
A. Insurance Services Office Commercial General Liability coverage (occurrence form CG
20 10 Prior to 1993 or CG 20 10 07 04 with CG 20 37 10 01 or the exact equivalent as
determined by the City).
Packet Pg 59
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 26 OF 38
CITY OF SAN LUIS OBISPO
B. Insurance Services Office form number CA 0001 (Ed. 1/87) covering Automobile
Liability, code 1 (any auto).
C. Workers' Compensation insurance as required by the State of California and Employer's
Liability Insurance.
D.12.3 Minimum Limits of Insurance. Proposer shall maintain limits no less than:
A. General Liability: $1,000,000 per occurrence, $2,000,000 general aggregate for bodily
injury, personal injury and property damage. The policy must include contractual liability
that has not been amended. Any endorsement restricting standard ISO “insured contract”
language will not be accepted. Agency, its officers, officials, agents, employees, and
volunteers shall be added as additional insureds on the policy.
B. Automobile Liability: $1,000,000 per accident for bodily injury and property damage.
C. Employer's Liability: $1,000,000 per accident for bodily injury or disease.
D.12.4 Deductibles and Self-Insured Retentions. Any deductibles or self-insured retentions must be
declared to and approved by the City. At the option of the City, either: the insurer shall reduce or
eliminate such deductibles or self-insured retentions as respects the City, its officers, officials,
employees and volunteers; or the Proposer shall procure a bond guaranteeing payment of losses
and related investigations, claim administration and defense expenses.
D.12.5 Other Insurance Provisions. The general liability and automobile liability policies are to contain,
or be endorsed to contain, the following provisions:
A. The City, its officers, officials, employees, agents and volunteers are to be covered as
insureds as respects: liability arising out of activities performed by or on behalf of the
Proposer; products and completed operations of the Consultant; premises owned,
occupied or used by the Proposer; or automobiles owned, leased, hired or borrowed by
the Proposer. The coverage shall contain no special limitations on the scope of protection
afforded to the City, its officers, official, employees, agents or volunteers.
B. For any claims related to this project, the Proposer’s insurance coverage shall be primary
insurance as respects the City, its officers, officials, employees, agents and volunteers.
Any insurance or self-insurance maintained by the City, its officers, officials, employees,
agents or volunteers shall be excess of the Proposer’s insurance and shall not contribute
with it.
C. The Consultant's insurance shall apply separately to each insured against whom claim is
made or suit is brought, except with respect to the limits of the insurer's liability.
D. Each insurance policy required by this clause shall be endorsed to state that coverage
shall not be suspended, voided, canceled by either party, reduced in coverage or in limits
except after thirty (30) days' prior written notice by certified mail, return receipt
requested, has been given to the City.
Acceptability of Insurers. Insurance is to be placed with insurers with a current A.M. Best's rating
of no less than A:VII.
Verification of Coverage. Proposer shall furnish the City with a certificate of insurance showing
maintenance of the required insurance coverage. Original endorsements effecting general liability
and automobile liability coverage required by this clause must also be provided. The
endorsements are to be signed by a person authorized by that insurer to bind coverage on its
behalf. All endorsements are to be received and approved by the City before work commences.
Packet Pg 60
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 27 OF 38
CITY OF SAN LUIS OBISPO
D.12.6 Waiver of Subrogation. The Vendor grants the City a waiver of any right to subrogation which
any insurer of Vendor may acquire against the City by virtue of the payment of any loss under
such insurance. This provision applies regardless of whether or not the City has received a waiver
of subrogation endorsement from the Vendor’s insurer.
D.13 Business Tax
The Proposer must have a valid City of San Luis Obispo business tax certificate before execution of the
contract. Additional information regarding the City's business tax program may be obtained by calling
(805) 781-7134.
Packet Pg 61
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 28 OF 38
CITY OF SAN LUIS OBISPO
Section E: Attachments
E.1 Attachment 1 (RFP Submittal Checklist)
Submittal Checklist
Section Item Submitted
B.1 Executive Summary and Introductory Materials
E.1 Attachment 1 (RFP Submittal Checklist)
E.2 Attachment 2 (Signature Page)
E.3 Attachment 3 (Proposer Statement)
B.2 Scope of Services
E.4 Attachment 4 (Scope of Proposal)
E.5 Attachment 5 (Company Background)
E.6 Attachment 6 (Reference Form)
B.3 Functional Requirements
E.13 Attachment 13 (Functional Requirements)
E.7 Attachment 7 (Technical Specifications)
B.4 Implementation Plan
E.11 Attachment 11 (Conversions)
E.12 Attachment 12 (Staffing)
B.5 Ongoing Support and Hosting Services
E.8 Attachment 8 (Software-as-a-Services / Hosting)
E.9 Attachment 9 (Proposed Service Level Agreement)
E.10 Attachment 10 (Maintenance and Support)
B.6 Exceptions to the RFP
B.7 Deliverables and Project Outcomes
B.8 Sample Documents
B.9 Price Proposal (under separate cover)
E.14 Attachment 14 (Cost)
Packet Pg 62
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 29 OF 38
CITY OF SAN LUIS OBISPO
E.2 Attachment 2 (Signature Page)
The undersigned proposer having examined this RFP and having full knowledge of the condition
under which the work described herein must be performed, hereby proposes that the proposer
will fulfill the obligations contained herein in accordance with all instructions, terms, conditions,
and specifications set forth; and that the proposer will furnish all required products/services and
pay all incidental costs in strict conformity with these documents, for the stated prices as
proposed.
Submitting Firm: _______________________________________________________________
Address: ______________________________________________________________________
City: ___________________________State:_______________ Zip:________________
Authorized Representative (print):________________________ Title: _____________________
Authorized Signature: ____________________________ Date: __________________________
Contact Information:
Name: ________________________________________________________________________
Title: ________________________________________________________________________
Address: ______________________________________________________________________
City: ___________________________State:_______________ Zip: ______________________
Email: ____________________________________
Phone: ____________________________________
Cell Phone: ____________________________________
Fax: ____________________________________
Software Demonstrations / Implementation Interviews:
Software demonstrations are currently scheduled for the following dates. Please indicate your availability
and date preference to provide software demonstrations in the event your proposal is elevated to software
demonstrations. Elevated proposers will be notified of the scheduled demonstrate date when elevated.
Week Availability (Y/N) Preference (1,2,3,No Preference)
10/16/17
10/23/17
10/30/17
Packet Pg 63
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 30 OF 38
CITY OF SAN LUIS OBISPO
E.3 Attachment 3 (Proposer Statement)
By submitting a response, the respondent acknowledges that he/she has acquainted themselves with the
terms, scope, and requirements of the project based on the information contained in this RFP and any
addendums. Any failure by the proposer to acquaint themselves with available information will not relieve
them from the responsibility for estimating properly the difficulty or cost of successfully performing the
work available. The City is not responsible for any conclusions or interpretations made by the proposer on
the basis of the information made available by the City.
The following addendums have been acknowledged and are included in our response. Proposals that do
not acknowledge addendums may be rejected.
Addendum# Initials
________________________________________
PRINTED NAME OF AUTHORIZED AGENT (TITLE)
________________________________________________ _________________________
SIGNATURE OF AUTHORIZED AGENT DATE
Packet Pg 64
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 31 OF 38
CITY OF SAN LUIS OBISPO
E.4 Attachment 4 (Scope of Proposal)
Identify the scope of the proposal and if the proposal contains software and services for each scope
option. Scope options are defined in the RFP in section A and Section C.
Software and Implementation Services:
Proposed
Not Proposed
Primary Software Firm ___________________________________________________________
Software Product Proposed _______________________________ Version _________________
Primary Implementation Firm ______________________________________________________
Technology Services:
Hosting Services Proposed
Software as a Service Proposed
Not Proposed
Hosting Provider: ____________________________________________________________________
Ongoing Support
Ongoing Support Provided by Software Vendor
Ongoing Support Provided by Implementation Firm
Ongoing Support Provided by Third Party
Firm Primarily Responsible for Ongoing Support: __________________________________________
Third Party Products/Services
Third Party Products/Services Proposed
No Third Party Products/Services Proposed
Firm _______________________________Purpose ______________________________________
Firm _______________________________Purpose ______________________________________
Firm _______________________________Purpose ______________________________________
Firm _______________________________Purpose ______________________________________
Firm _______________________________Purpose ______________________________________
Firm _______________________________Purpose ______________________________________
Name of Individual / Firm Submitting Proposal:
__________________________________________________________
Signature of Proposer:
____________________________________________________________________________
Packet Pg 65
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 32 OF 38
CITY OF SAN LUIS OBISPO
E.5 Attachment 5 (Company Background)
Complete one form for each firm included in the proposal.
Company Background
Company Name:
Location of corporate headquarters:
Proposer Experience
# of years in business:
# of years providing systems/services to public
sector:
Customer Base:
# of clients using proposed software/services
# of clients using other similar software/services
Market Focus:
Identify other industries serviced (other than
local governments)
If not Primary Proposer
# of past projects partnering with primary
proposer
Official Partnership status/certification (if
applicable)
About the Company
Number of Total Employees:
Number of Employees Providing
Implementation Services (if applicable)
Number of Employees Supporting Product
(Maintenance and Support) (if applicable)
Number of Employees Dedicated to Product
Development (if applicable)
Packet Pg 66
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 33 OF 38
CITY OF SAN LUIS OBISPO
E.6 Attachment 6 (Reference Form)
Please provide at least five (5) references for past projects that include products and services similar in
scope to those proposed for this RFP. Please use the following format in submitting references.
GENERAL BACKGROUND
Name of Client:
Project Manager/Contact: Title:
Phone: E-mail:
Software Program/Version:
Summary of Project:
Number of Employees: Size of Operating Budget:
PROJECT SCOPE
Please indicate (by checking box) functionality installed:
Financials Budgeting
HR
Payroll
TECHNOLOGY INFORMATION
Hosted? Yes_______ No________ If yes, hosting provider_______________
IMPLEMENTATION INFORMATION
Project Duration:
Initial Go-Live:
Describe Role on Project:
Project Challenges:
Major Accomplishments:
Packet Pg 67
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 34 OF 38
CITY OF SAN LUIS OBISPO
E.7 Attachment 7 (Technical Specifications)
Technical Specifications
Required Licenses
Does the Proposed System Require that the City
install software?
Yes/No
Provide full documentation of technical
specifications and requirements necessary to host
the system (vendors can submit documentation in
alternate format and attach to this page.)
Hardware / Server / Database Requirements
Desktop / Client Requirements
Mobile Requirements
Business Intelligence
Describe how business intelligence tools operate
and if the City would be able to leverage tools for
non-ERP data
Does the report writer utilize a separate database?
Security
Describe database security
Describe application security
Is system compatible with single sign on?
Packet Pg 68
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 35 OF 38
CITY OF SAN LUIS OBISPO
E.8 Attachment 8 (Software-as-a-Services / Hosting)
*Attach additional pages if necessary
Alternative Delivery Options
Options
Is system available through a hosted model
(City owns license and system implemented on
dedicated single tenant environment)
Yes/No
Is the system available through SaaS model
(City pays subscription fee and system
implemented in multi-tenant environment)
Yes/No
Is the system available through a managed
services model (City owns and hosts system;
vendor maintains system)
Yes/No
Where is the data center and disaster recovery
data center located?
Network Bandwidth
If ASP or SaaS, what are the internet bandwidth
requirements for optimal performance?
Contract
Describe any minimum contract periods (example:
Minimum of 5 year)
Does vendor contract provide for price increases
above 0% per year for years 2-5
After contract period, is it possible to transition to
self-hosted model? Describe what is required for
transition and cost
Does vendor contract cap price increase to less
than 5% for years 6-10)
Proposed Services
Number of database instances (please list)
Describe proposed disaster recovery services
Describe proposed application availability service
level
Support
Describe operations support
Describe back up procedures and testing of
backups and other quality assurance processes to
ensure the backup is working correctly.
Describe process for installing patches and
updates
Describe process for roll-back of patches and
updates if major functionality is broken as a result
of the patch and/or update
Packet Pg 69
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 36 OF 38
CITY OF SAN LUIS OBISPO
E.9 Attachment 9 (Proposed Service Level Agreement)
If hosting services are proposed, please complete the following table identifying proposed service level
guarantees. For each service, please indicate the metric used to measure the service quality, the proposed
requirement (target for service), and the proposed remedy/penalty if guarantee is not met.
Proposed Service Level Guarantees
Service Metric Requirement/
Guarantee
Remedy if Not Met
System Availability
(Unscheduled Downtime)
System Response
(Performance)
Issue Response Time
Issue Resolution Time
System Data Restore
Implementation of System
Patches
Notification of Security
Breach
Please list other proposed
service levels
Proposed Service Level Guarantees
How is performance against service levels
reported to the City
Describe process for City reporting issue to the
vendor
Packet Pg 70
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 37 OF 38
CITY OF SAN LUIS OBISPO
E.10 Attachment 10 (Maintenance and Support)
Proposed Maintenance and Support
Post-implementation Support:
Days of on-site support after go-live
What is purpose of on-site support?
Other on-site support after go-live (month end,
quarter end, year-end, open enrollment, etc.)
Telephone Support:
Hours available (and time zone)
Problem reporting and resolution procedures
Response time for various levels of severity
Third Parties:
Support provided for third party products?
Upgrades/Patches:
Upgrade Frequency (major and minor releases)
How are upgrades delivered?
Are upgrades required?
How many versions are currently supported?
Third Party Support
Upgrade Frequency (major and minor releases)
How are upgrades delivered?
Are upgrades required?
How many versions are currently supported?
Packet Pg 71
5
REQUEST FOR PROPOSALS
ERP SYSTEM
PAGE 38 OF 38
CITY OF SAN LUIS OBISPO
E.11 Attachment 11 (Conversions)
(See Separate Excel Spreadsheet)
E.12 Attachment 12 (Staffing)
(See Separate Excel Spreadsheet)
E.13 Attachment 13 (Functional Requirements)
(See Separate Excel Spreadsheet)
E.14 Attachment 14 (Cost)
(See Separate Excel Spreadsheet)
E.15 Attachment 15 (Business Process Documentation)
(See Separate PDF document)
Packet Pg 72
5
Attachment 13: Functional Requirements
YY-NDNI
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
1 GL Chart of Accounts System provides chart of account structure with multiple independent segments
2 GL Chart of Accounts
Independent chart of account segments are independent of other segments (do not form hierarchical relationship between segments) of different types (fund, org, program, account, etc.)
3 GL Chart of Accounts Chart of accounts support multiple segments for org unit
4 GL Chart of Accounts Chart of accounts support multiple segments for program/activity
5 GL Chart of Accounts Segments of same type (org unit, program/activity, etc) form hierarchical relationship
6 GL Chart of Accounts Chart of accounts supports project ledger (sub ledger) for detailed cost tracking
7 GL Chart of Accounts General Ledger and project ledger supports alpha numeric accounts
8 GL Chart of Accounts Segments of chart of accounts used in acceptable combinations to form full general ledger account
9 GL Chart of Accounts System supports segments representing programs that can extend across multiple departments
10 GL Chart of Accounts
Segments of the Chart of Accounts can be grouped on a user-defined basis into multiple reporting hierarchies
11 GL Chart of Accounts
System allows reporting at summary level accounts (for example, accounts 5501, 5502, 5503 can be reported together as 5500)
12 GL Chart of Accounts System provides short cut key functionality to allow users to not enter full account characters
13 GL General Ledger Set Up System only allows transactions to post to active accounts within any open period
14 GL Budget Control Budget control can be set to soft error (Warn user but allow)
15 GL Budget Control Budget control can be set to hard error (Do not allow)
16 GL Budget Control
System allows for budgeting at one level and controlling at a different level (Example: budget by account/object but conduct budget control at program level)
17 GL Budget Control System allows budget control at summary roll up of account/object
18 GL Budget Control
System allows budget control at summarized roll up categories (example, transact at 5501, 5502, 5503, but control at level of all 5500s)
Column F: Available ResponsesRequirement Met and Proposed (Standard features in the generally available product)Requirement Met and Proposed (Features that are not offered as a generally available product or require custom development)Requirement Not Met with ProposalNeed More Information/Discussion
Page: 1 of 31 Packet Pg 73
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
19 GL Journal Entry
General ledger transactions record the source of the transaction (e.g., manual entry or automated entry from another module)
20 GL Journal Entry Journal entries are validated against the chart of account structure for valid accounts
21 GL Journal Entry Journal entries are validated against: Available funds (budget check or cash availability check)
22 GL Journal Entry Journal entries are validated against balancing entries (make sure all entries balance)
23 GL Journal Entry Users can import journal entries from spreadsheet (e.g., Microsoft Excel)
24 GL Journal Entry
Imported transactions from spreadsheets are validated using the same business rules as transactions made in the system
25 GL Journal Entry
System allows creation of a journal entry from previously entered journal entry format (copy journal), by: Line item
26 GL Journal Entry System allows users to reverse journal entry with proper security and approvals
27 GL Journal Entry System allows to schedule accrual auto-reversals.
28 GL Journal Entry
Journal entries support "required" data fields and prevents transaction from posting until all "required" fields are completed
29 GL Journal Entry Users can attach files for documentation to journal entry
30 GL Journal Entry
Users can save journal entries that have not yet been posted or cleared for all validation errors online
31 GL Journal Entry System allows posting of transactions for multiple fiscal years at the same time
32 GL Journal Entry When working in multiple fiscal years the detail transactions are maintained for each year.
33 GL Journal Entry
Journal transactions can be entered and scheduled using effective dates (e.g., posting does not occur until effective date)
34 GL Recurring Journal Entry System provides templates and notifications for recurring journal entries
35 GL Recurring Journal Entry System provides templates and notifications for recurring journal entries with the same dollar value
36 GL Recurring Journal Entry
System provides templates and notifications for recurring journal entries with varying dollar amounts
37 GL Recurring Journal Entry Recurring journal entries occur at regular frequency (can set start and stop dates)
38 GL Recurring Journal Entry System allows journal entries to be scheduled (example: lease/debt schedules)
39 GL Annual Close Process System allows more than 12 accounting periods (please specify)40 GL Annual Close Process System closes at end of period by fund
41 GL Cash Management Interface
System allows import of daily bank activity and balances and reconciles to recorded receipts and disbursements
Page: 2 of 31 Packet Pg 74
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
42 GL Cash Management Interface
System reconciles both cash/check transactions as well as credit card payments with potential lag in posting date
43 GL Cash Management
System provides cash flow forecasts projecting outstanding payable, outstanding receivables, recurring payments, and current position44 PG Project Set Up Supports multiple-year projects
45 PG Project Set Up
Supports parent/child relations for projects and sub-projects (list any limitations in the comments column)
46 PG Project Set Up System tracks funding sources (multiple funding sources for each project)
47 PG Project Set Up Funding sources can be grants, city dedicated revenues, other city funds, etc.48 PG Project Set Up System allows decentralized project set up
49 PG Project Set Up
System uses project start date and end date for determining eligible expenditures and doesn't allow transactions outside project eligibility period
50 PG Project Set Up Projects can be established across multiple funds and departments
51 PG Project Set Up
System will identify and track user-defined multiple sub-levels of a project (e.g. design, pre construction, construction, post construction, completed)
52 PG Project Set Up User-defined sub-levels of project can be different for each project
53 PG Project Budget System allows creation of project budget for select projects (not required for all projects)
54 PG Project Budget Project budgets are established for entire project
55 PG Project Budget Project budgets are established by fiscal year within multi-year project
56 PG Project Budget Budget control for a project can be set for calendar year
57 PG Project Budget Budget control for a project can be set for period other than City fiscal year (grantor fiscal year)
58 PG Project Budget Budget control for a project can be set for entire Life of Project (multi-Year)59 PG Project Budget System can control budget at project level
60 PG Project Budget System can control budget at sub-project level (example: phase, task, etc.)
61 PG Project Budget System can set level of budget control differently for each project
62 PG Project Budget Project budget can control to level of project funding (limit project expenses to funding sources)
63 PG Project Budget System can track and control budget for multiple projects using the same funding source
64 PG Project/Grant Tracking System allows for tracking direct costs (encumbrance) to project through purchasing
65 PG Project/Grant Tracking System allows for tracking direct costs (expense) to project through accounts payable
66 PG Project/Grant Tracking
System allows for tracking direct costs and indirect costs (encumbrance and expense) to project through journal entries
Page: 3 of 31 Packet Pg 75
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
67 PG Project/Grant Tracking System allows employees to charge time to projects and sub projects
68 PG Project/Grant Tracking System allows for tracking salary and benefit costs (expense) to project through payroll
69 PG Project/Grant Tracking
System allocates indirect costs to projects based on pre-determined cost drivers and allocation schedules
70 PG Project/Grant Tracking
System identifies eligible expenses for reimbursement based on criteria identified for each project (by account)
71 PG Project/Grant Tracking System identifies and tracks funding sources for projects
72 PG Project/Grant Tracking
System will split the cost of projects across various funding sources by Percentage (e.g. 70% grant, 30% bond)
73 PG Project/Grant Tracking
System will split the cost of projects across various funding sources by Priority (Grant first, local funds next)
74 PG Project/Grant Tracking Interface
Interface to EnerGov for tracking permitting and plan review projects (capture costs entered into EnerGov)
75 PG Project/Grant Tracking Interface Interface to Emergo for tracking permit revenue by project
76 PG Project/Grant Tracking
System will split the cost of projects across various funding sources by priority up to limit (example: Charge grant first up to $10,000 then charge local funds)
77 PG Project/Grant Revenue System allows revenue source to be split across multiple projects
78 PG Project/Grant Revenue System can assign multiple revenues sources to be used for single project
79 PG Project/Grant Revenue
System allows multiple revenue sources to be split across multiple projects (each project has multiple sources)
80 PG Project/Grant Billing Projects link with accounts receivable to provide all billing, aging, and tracking capabilities.
81 PG Project/Grant Billing Generates revenue/receivable transactions from grants expenditure data
82 PG Project/Grant Billing
System can generate invoice to bill for any project costs (bill to contractor, citizen, other government, or grant)
83 PG Project/Grant Billing
System can generate invoice for appropriate billable expenses at any point (end of project, milestone, or any time)
84 PG Project/Grant Billing System tracks expenses that have been billed to date
85 PG Project/Grant Billing Project billing based on actual expenses (using current salary and benefit information)
86 PG Project/Grant Billing
Project billing based on actual expenses (using current salary and benefit information) plus percentage
87 PG Project Capitalization Expenditures for capital project can be identified as capitalized expenses
88 PG Project Capitalization
System will move a project to Capital Assets but allow for any subsequent expenditures to be charged to that project.
89 PG Project Capitalization
Transfers construction-in-progress accounts to capital asset accounts at project close or completion
Page: 4 of 31 Packet Pg 76
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
90 PG Project Capitalization System allows creation of asset before project close
91 PG Project Capitalization One project can be converted into multiple assets
92 PG Project Capitalization System allows users to determine what costs should be capitalized
93 PO Purchase Requisition Each department initiates purchasing process through requisition entry into the system
94 PO Purchase Requisition
Requestor can attach files to requisition at header level, files can be individually printed or printed with document
95 PO Purchase Requisition Requestor can attach files to requisition at line item level
96 PO Purchase Requisition Purchase requisition allows user to add NIGP commodity code to line item
97 PO Purchase Requisition System allows user to record information on competing quotes
98 PO Purchase Requisition Purchase requisition allows user to identify project ledger segments on line item
99 PO Purchase Requisition Purchase requisition allows user to identify work order number on line item
100 PO Purchase Requisition Purchase requisition allows user to identify contract number for requisition101 PO Purchase Requisition Chart of accounts linked to commodity code
102 PO Purchase Requisition Purchase requisition can be saved without submitting for approval
103 PO Purchase Requisition
System provides option for emergency purchase that will bypass workflow approvals and create purchase order
104 PO Purchase Requisition Emergency purchase order provides workflow notification to pre-identified roles/users
105 PO Purchase Requisition - Budget When purchase requisition is submitted, system provides budget check
106 PO Purchase Requisition - Budget System tracks pre-encumbrances (purchase requisitions)
107 PO Purchase Requisition - Budget System records pre-encumbrance when purchase requisition is saved or submitted through workflow
108 PO Purchase Requisition
System routes purchase requisition for approval/notification by chart of account information (object/account code)
109 PO Purchase Requisition System routes purchase requisition for approval/notification by dollar amount
110 PO Purchase Requisition System routes purchase requisition for approval/notification by if it is a capital item
111 PO Purchase Requisition System allows users to cancel requisition before it is approved
112 PO Purchase Requisition Cancelled requisitions or cancelled requisition line items release pre-encumbrance113 PO Purchase Order System links purchase order to requisition114 PO Purchase Order Purchase orders created for specific items
115 PO Purchase Order Purchase orders created for dollar allowance with vendors (blanket purchase orders)
116 PO Purchase Order PO automatically created after req approval based on $ threshold
117 PO Purchase Order Creation of purchase order creates encumbrance
Page: 5 of 31 Packet Pg 77
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
118 PO Purchase Order System provides for approval process for purchase order prior to being sent to vendor:
119 PO Purchase Order Approval process for purchase order can be routed by dollar amount
120 PO Purchase Order
System allows for encumbrance of shipping and freight and allows user to add shipping and freight to purchase order
121 PO Purchase Order Shipping and freight charges distributed to accounts by line item on PO
122 PO Purchase Order
User can attach files to purchase order at header level, files can be individually printed or printed with document123 PO Purchase Order Purchase order sent to vendor through Email
124 PO Purchase Order Purchase order sent to vendor through Hard copy (print and mail)
125 PO Purchase Order Purchase order identifies originator of PO and contact information
126 PO Purchase Order Purchase order identifies alternate contact for PO (other than originator)
127 PO Purchase Order Purchase order prints with default contract terms based on type of purchase and commodity code
128 PO Purchase Order
System allows purchase orders to be re-sent - System identifies re-printed purchase orders as duplicates
129 PO Receiving
System allows user to search for PO by PO#, vendor, description, department, contract #, custom fields, requisition, NIGP code130 PO Receiving System tracks goods or services received
131 PO Receiving User can acknowledge receipt of entire purchase order
132 PO Receiving User can acknowledge receipt of purchase order by individual line item133 PO Receiving User can record partial receipt
134 PO Receiving System tracks vendor performance at receipt (on time, damaged, other comments)
135 PO Receiving
Receipt of a capital asset requires that the receiver complete asset record (serial number, asset tag, other information, etc.)
136 PO Receiving System identifies orders that have not been received by delivery date on PO
137 PO Modify PO/Change Order Any open purchase order can be modified by change order
138 PO Modify PO/Change Order Departments can initiate request for a change to purchase order for increase quantity or amount
139 PO Modify PO/Change Order Departments can initiate request for a change to purchase order for decrease quantity or amount
140 PO Modify PO/Change Order Departments can initiate request for a change to purchase order for canceling line items
141 PO Modify PO/Change Order Departments can initiate request for a change to purchase order for canceling entire PO
142 PO Modify PO/Change Order Departments can initiate request for a change to purchase order for adding line items
143 PO Modify PO/Change Order
Departments can initiate request for a change to purchase order for change of chart of account string
144 PO Modify PO/Change Order Requests to change purchase order routed through workflow
Page: 6 of 31 Packet Pg 78
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
145 PO Modify PO/Change Order Request to change purchase order (for increase) pre-encumbers funds
146 PO Modify PO/Change Order
Request to change purchase order (for decrease) release encumbrance when change request is approved
147 PO Modify PO/Change Order Approval of change to purchase order encumbers funds or releases encumbrance of funds
148 PO Modify PO/Change Order Printing of modified purchase order clearly labels that purchase order has been changed
149 PO Modify PO/Change Order Purchase order identifies information that was changed on header and line item
150 PO Purchasing Cards Interface System provides automatic transfer of information from bank with purchasing card transaction details
151 PO Purchasing Cards System allows users to identify correct account for each p-card transaction
152 PO Purchasing Cards System allows users to identify correct project (including sub-project) for each p-card transaction
153 PO Purchasing Cards System allows users to identify correct contract for each p-card transaction
154 PO Purchasing Cards System allows users to identify correct purchase order for each p-card transaction
155 PO Purchasing Cards System allows users to identify correct NIGP commodity code for each p-card transaction156 PO Purchasing Cards System allows upload of scanned receipt
157 PO Purchasing Cards System allows multiple accounts for each p-card transaction
158 PO Purchasing Cards System allows user to identify p-card vendor (link to vendor file)
159 PO Purchasing Cards System automatically identifies vendor based on file from bank
160 PO Purchasing Cards Interface Any new vendor (not in vendor file) where P-card is used is added to vendor file
161 PO Purchasing Cards System provides workflow approval of p-card transactions
162 PO End of Year Process Any open purchase orders at year end can be rolled to next fiscal year
163 PO End of Year Process
Any open purchase order rolled to next fiscal year can roll associated encumbered budget to next fiscal year
164 PO End of Year Process System prepares budget amendment to authorize roll of encumbered funds for next budget year
165 PO End of Year Process Open purchase orders rolled to next year can encumber next year budget (not roll budget)
166 PO Contract Set Up Purchase requisitions can be converted to contracts
167 PO Contract Set Up
Workflow approval process for establishing contract is determined by chart of accounts (example: department)
168 PO Contract Set Up Workflow approval process for establishing contract is determined by type of contract
169 PO Contract Set Up Workflow approval process for establishing contract is determined by dollar amount170 PO Contract Set Up Contract module can track payment schedules
171 PO Contract Set Up System allows option of encumbering value of contract or not encumbering
Page: 7 of 31 Packet Pg 79
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
172 PO Contract Set Up
System allows encumbrances to be split across multiple fiscal years (user can identify encumbrance in each fiscal year)
173 PO Contract Set Up Contracts can be converted to a purchase order174 PO Contract Set Up System allows users to attach files to contract
175 PO Contract Administration System can apply purchase orders/requisitions against contracts
176 PO Contract Administration Purchase orders encumber funds against a contract
177 PO Contract Administration The system tracks service performance against a contract (e.g., milestones and/or deliverables).
178 PO Contract Administration
The system tracks and auto flag contract expiration dates with sufficient lead time to extend or re-solicit contract.
179 PO Contract Administration
System tracks required insurance, performance bonds, vendor licenses, or other requirements of contract
180 PO Contract Administration System tracks expiration dates of insurance, vendor licenses, or other contract requirements.181 PO Contract Administration System tracks contract renewal options
182 PO Contract Administration System tracks and applies adjust to fees for renewals (example: new fee or increase by %)
183 PO Contract Administration System tracks pricing for contract (unit prices for various items under contract)
184 PO Contract Administration System tracks performance milestones on contract
185 PO Contract Administration System tracks contracts without encumbering PO (for on-call vendors)
186 PO Contract Administration System tracks vendor performance against contract
187 PO Contract Administration Attach copy of contract (or other schedules) and documentation
188 PO Contract Administration Interface System can identify if vendor has valid City business license (interface with HDL)
189 PO Contract Administration Interface System interface with DocuSign for contract execution190POVendor Self Service Interface Interface to purchasing / bid system?191 PO Vendor Self Service System allows vendor to register with the City
192 PO Vendor Self Service System allows vendor to submit required documentation (W-9, insurance)
193 PO Vendor Self Service System provides workflow for approval of submitted vendor information
194 PO Vendor Self Service
Vendor can use self-service for updating vendor information (address, contact, preferred payment, etc.)
195 PO Vendor Self Service Vendor changes go through workflow for approval
196 AP Vendor File Supports Parent/Child relationships for vendor records197 AP Vendor File Maintains multiple address types
198 AP Vendor File Maintains multiple location addresses for each vendor199 AP Vendor File Stores DBA name
Page: 8 of 31 Packet Pg 80
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
200 AP Vendor File
System can accommodate certification information (minority, women owned, dbe, ccb license - type & #)
201 AP Vendor File System records multiple commodity (NIGP) codes to classify vendors
202 AP Vendor File System identifies default payment remittance address
203 AP Vendor File
System identifies preference for electronic payments and for those indicated makes all payments electronically204 AP Vendor File System identifies 1099 vendors
205 AP Vendor File System identifies cumulative purchase history by vendor to identify common vendors
206 AP Vendor File Cumulative purchase history includes p-card purchases
207 AP Vendor File
System identifies one time vendors - vendors set up in normal vendor file but identified as one-time vendor for easier data entry and system search functions 208 AP Vendor File Vendor file stores insurance levels information
209 AP Vendor File Vendor file stores vendor payment preference (ACH or check)
210 AP Vendor File Vendor files can identify terms and conditions that are applied to purchase orders for that vendor211 PO Vendor File Interface Sync vendors with information in BidSync
212 AP Invoice Processing System fills information for invoice from purchase order
213 AP Invoice Processing System allows entering of direct claims without purchase order
214 AP Invoice Processing System provides workflow approval path for Invoices from purchase orders
215 AP Invoice Processing System provides workflow approval path for Invoices without purchase orders
216 AP Invoice Processing Invoices routed through workflow for approval based on amount
217 AP Invoice Processing Invoice routed through workflow based on point of entry (entered by department vs. AP)
218 AP Invoice Processing Invoices routed through workflow for approval based on PO vs no PO
219 AP Invoice Processing Invoices routed through workflow for approval based on chart of account information
220 AP Invoice Processing Supports partial payments (partial payment of invoice)
221 AP Invoice Processing System supports applying credit memo to invoice for incorrect invoices
222 AP Invoice Processing Allow payment of multiple purchase orders from one invoice
223 AP Invoice Processing Allow multiple invoices to be received and processed for one purchase order
224 AP Invoice Processing
System will automatically check for and prevent duplicate invoice numbers for the same vendor (don't pay same invoices twice)
225 AP Invoice Processing System allows files to be attached in the system to the invoice (scanned image of invoice)226 AP Invoice Processing System allows payment of invoice with p-card
227 AP Refunds System processes refunds to one time customers
Page: 9 of 31 Packet Pg 81
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
228 AP Refunds Interface
System allows upload of refund payments from other systems (Energov, parks and rec, Springbrook (UBS), others)
229 AP Refunds Interface
System interfaces to third party system for refund payments (Load check information from processing payment through AP)
230 AP Matching Supports 2 way matching (purchase order, invoice)
231 AP Matching Supports 3 way matching (purchase order, receiving document, invoice)
232 AP Matching System defaults either 2 or 3 way matching based on commodity code
233 AP Matching System defaults either 2 or 3 way matching based on chart of accounts
234 AP Matching
System provide workflow approval for invoice for services and other purchase goods/services without receipt235 AP Matching Matching occurs at line item detail level
236 AP Matching System excludes freight and shipping charges from matching requirements
237 AP Matching System provides notification when match does not occur
238 AP Payment Process
After approval, schedule invoices for payment based on invoice date (example: 45 days after invoice date)
239 AP Payment Process After approval, schedule invoices for payment based on date entered by AP clerk
240 AP Payment Process
After approval, schedule invoices for payment based on grouping of invoices (example: employee reimbursement)
241 AP Payment Process
System will pay vendors electronically (ACH, wire transfer, etc.) using standard NACHA formats (ctx).
242 AP Payment Process The system prints checks based on regular schedule
243 AP Payment Process The system prints on-demand checks (single check printing)
244 AP Payment Process
The system creates/sorts checks based upon chart of account information (example: fund or department)
245 AP Payment Process The system creates/sorts checks based upon vendor
246 AP Payment Process
The system creates/sorts checks based upon payment type (employee reimbursement, one time vendors, need to route to department, etc.)
247 AP Payment Process Interface System provides and sends electronic payment file to bank
248 AP Payment Process System sends electronic remittance advice for EFT payments to vendor through email
249 AP Payment Process
System permits users to select to pay one invoice per check (issue multiple checks to one vendor in a single check run).
250 AP Payment Process
System combines multiple invoice payments onto one check (issue one check for multiple invoices in a single check run)
251 AP Payment Process System itemizes invoices (including the vendor invoice number) on the remittance advice
252 AP Payment Process System allows users to place a payment on hold
Page: 10 of 31 Packet Pg 82
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
253 AP Payment Process Enter broadcast messages which appears on all AP check stubs
254 AP Payment Process Users may enter a message for one specific vendor which appears on that specific check stub255 AP Payment Process System supports positive pay
256 AP Void and Cancel
System allows user to cancel warrant and system makes all correct accounting entries to reverse payment, including contract balances
257 AP Void and Cancel System allows user to void check and re-issue replacement check
258 AP Void and Cancel
System allows users to cancel current and prior fiscal year checks and have the system automatically credit back designated accounts259 AP Tax Reporting Monitors cumulative payments to 1099 vendors260 AP Tax Reporting On-demand 1099 form generation
261 AP Tax Reporting
Collects necessary information for generation of Federal 1099s at year-end (both manually and per IRS approved file) (all types of 1099)
262 AP Tax Reporting System can produce electronic file to send 1099 related forms to IRS
263 AP/Payroll Employee Reimbursement
All employees have access to submit reimbursement for expenses
264 AP/Payroll Employee Reimbursement
System identifies any reimbursements that are taxable for inputted income
265 AP/Payroll Employee Reimbursement
Employees enter pre-travel reimbursement request through self service (prior to travel)
266 AP/Payroll Employee Reimbursement
Pre-Travel reimbursement request is routed through workflow for approval (prior to travel)
267 AP/Payroll Employee Reimbursement
Pre-Travel reimbursement request routed based on employee supervisor
268 AP/Payroll Employee Reimbursement
Actual reimbursement request linked to pre-travel request
269 AP/Payroll Employee Reimbursement
Approval of pre-travel request provides advanced payment for per-diem amounts
270 AP/Payroll Employee Reimbursement
Actual reimbursement request completed in self service and routed through workflow
271 AP/Payroll Employee Reimbursement
Employee uploads images of actual receipts to self service272 CA Asset Set Up System is used to track capitalized items273 CA Asset Set Up System is used to track non-capitalized items
274 CA Asset Set Up Identifies assets based on capitalization threshold (and different threshold for each asset type)
275 CA Asset Set Up Asset can have multiple account distributions (including multiple funds)
276 CA Asset Set Up System accommodates parent child relationships for assets
277 CA Asset Set Up
System must link component units (parent/child relationship) whereby each component maintains its own financial and historical information and depreciable life.
278 CA Asset Set Up If asset is replacement of other asset, it references old asset279 CA Asset Set Up Asset tracks expiration date of asset280 CA Asset Set Up Asset tracks warranty information on asset281 CA Asset Set Up System tracks software licenses
282 CA Asset Set Up
Assets identify custodian for asset (employee linked to asset) (example: cell phone identifies user)
Page: 11 of 31 Packet Pg 83
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
283 CA Asset Set Up Interface
System interfaces to third party system to transfer new assets to system for asset management (CityWorks)
284 CA Asset Tracking Interface
System interfaces to third party asset management system to receive updates to asset initiated in third party system (including transfer, disposal, asset modification, preventative maintenance history costs)
285 CA Asset Tracking Interface System interfaces to bar coding system to bar code assets
286 CA Asset Tracking System provides bar code tracking for capital assets
287 CA Asset Acquisition Allows effective date posting for asset acquisition
288 CA Asset Acquisition
System identifies potential capital assets from purchasing module by chart of accounts (example: purchased from capital account)
289 CA Asset Acquisition System identifies potential capital assets from purchasing module by dollar amount
290 CA Asset Acquisition
System identifies potential capital assets from purchasing module manually (user flags purchase as fixed asset)
291 CA Asset Acquisition
System identifies potential capital assets from accounts payable module by chart of accounts (example: payment from capital account)
292 CA Asset Acquisition System identifies potential capital assets from accounts payable module by dollar amount
293 CA Asset Acquisition
System allows creation of asset manually that does not flow through purchasing or accounts payable (for example: asset below threshold or donated asset)
294 CA Asset Acquisition System is able to copy an asset record to create a similar asset record
295 CA Asset Acquisition
System is able to identify/record all capitalize costs associated with the construction or purchase/acquisition of an asset (from project accounting)
296 CA Asset Acquisition System allows users to identify/classify costs as capitalized costs / non capitalized costs
297 CA Asset Acquisition
System can recognize fixed/capital assets when they are completed, regardless of whether the project has been completed/closed
298 CA Physical Inventory System produces asset list by department for physical inventory
299 CA Physical Inventory System produces asset list by location for physical inventory
300 CA Disposal
Upon disposal, system calculate partial period depreciation and generate appropriate profit/loss calculation301 CA Disposal System tracks reason for disposal302 CA Disposal System stores information on disposed assets
303 CA Disposal System provides workflow approval/notification for disposed assets
304 CA Depreciation
System automatically calculate depreciation in accordance with the depreciation method and convention designated for an asset
305 CA Depreciation System calculates pro-rated depreciation for assets sold mid-year or mid-month
Page: 12 of 31 Packet Pg 84
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
306 CA Depreciation System can designate some assets as non-depreciable (i.e., land, assets not in use)
307 CA Capital Budget System prepares multi-year schedule and forecast for asset replacement costs308 CA Asset Replacement System tracks asset replacement schedules
309 CA Asset Replacement
System allows users to track replacement costs and forecasts asset replacement costs over multiple years
310 CA Asset Replacement Asset replacement forecasts allow for consideration of condition assessment
311 CA Asset Replacement Asset replacement forecasts allows for prioritizing assets
312 AR Customer File Customer file is shared with vendor file used for purchasing and accounts payable
313 AR Customer File Single customer master is used for all receivables in the system
314 AR Customer File Interface System shares customer file with third party billing system315 AR Create Receivable System creates receivable for all general billing
316 AR Create Receivable System allows user to create receivable manually for bill generated outside system
317 AR Create Receivable
System allows for import of receivables (aggregate) from bills generated from external system (income tax billing, parks and rec, permit fees, etc.)
318 AR Miscellaneous Billing Departments will use system to create invoices for various charges319 AR Miscellaneous Billing System accommodates one-time invoices
320 AR Miscellaneous Billing System allows users to create invoices for each type by entering dollar amount
321 AR Miscellaneous Billing
System allows users to create invoices for each type by entering non-financial parameter and having system calculate appropriate fees according to pre-defined business rules
322 AR Miscellaneous Billing Invoice prints with statement balance information
323 AR Recurring Billing
System accommodates recurring invoices (regular invoices to occur at set dates or duration) (example: rent)
324 AR Recurring Billing
System allows recurring invoices to be set up to handle invoices scheduled at set dates for same amount
325 AR Recurring Billing
System allows recurring invoices to be set up to handle invoices scheduled at set dates for different amounts
326 AR Recurring Billing System saves templates for generating invoices (different template for each AR type)
327 AR Receivable Tracking System provides receivable tracking and aging reporting capabilities
328 AR Receivable Tracking System stores schedule of penalties and interest to apply to open receivables329 AR Receivable Tracking Penalties can be flat fee amounts330 AR Receivable Tracking Penalties can be percentage of original amount331 AR Receivable Tracking Interest charges can be applied monthly
332 AR Receivable Tracking System generates customer statement that shows all outstanding bills/receivables
333 AR Payment Receipt System records payments against open receivables334 AR Payment Receipt System generates deposit slip
Page: 13 of 31 Packet Pg 85
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
335 AR Payment Receipt System routes deposit slip for workflow approval
336 AR Payment Receipt System applies one payment to multiple receivables / point of sale transactions
337 AR Payment Receipt System allows using multiple payment types to pay for one invoice (example: cash and credit card)
338 AR Payment Receipt Automatically generate general ledger distribution entries needed to record receipts 339 AR Loans System tracks loans to customer in system
340 AR Loans System tracks declining balance loan programs341 AR Loans System calculates amortization schedules
342 AR Loans System tracks customer payments for loan re-payment
343 AR Cash Receipts
System interfaces with various cash receipt systems in use by City for recording daily deposit amounts
344 AR Cash Receipts System provides cash receipts function for receiving on miscellaneous billing345 AR Cash Receipts Interface Interface with EnerGov to record cash receipts
346 AR Cash Receipts Interface Interface with HDL (business license) to record cash receipts
347 AR Cash Receipts Interface Interface with Springbrook (utility billing) to record cash receipts
348 AR Cash Receipts Interface Interface with Active.net (parks) to record cash receipts
349 AR Cash Receipts Interface Interface with SDL (business license) to record cash receipts
350 AR Cash Receipts Interface Interface with GolfNow (golf course) to record cash receipts
351 AR Cash Receipts Interface Interface with alarm permit vendor for cash receipts
352 AR Cash Receipts Interface Interface with various other systems used to process cash receipts and credit card payments353 POS Position Structure All positions are tied to job classification
354 POS Position Structure System allows multiple positions in each job classification
355 POS Position Structure Each position identified by unique position control number
356 POS Position Structure Positions tied to funding source / chart of account information357 POS Position Structure Positions identify FTE and headcount limit
358 POS Position Structure System allows split funded position (funded from multiple accounts/departments/programs)
359 POS Position Structure System stores default schedule for each position / job classification360 POS Position Structure Security permission tied to position / role361 POS Position Structure Security permission default based on position
362 POS Position Control System requires each regular employee to be placed in a position
363 POS Position Control One employee can have multiple positions but not to exceed 1.0 FTE.
364 POS Position Control Multiple employees can share a single position
365 POS Position Control System can set FTE limit for position (not always 1)
Page: 14 of 31 Packet Pg 86
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
366 POS Position Control System prevents FTE limit from being exceeded without proper approval
367 POS Position Control System prevents headcount limit from being exceeded without proper approval
368 POS Position Control System tracks special assignment (within position) - time limits on special assignment369 POS Position Structure System support direct deposit for payroll
370 POS Position Structure System allows for position reclassification (moving position to different classification)
371 POS Position Structure
System tracks job classification assigned to each position and history of job classification assigned to each position as well as incumbent history for the position.
372 POS Position Structure System provides for online request for re-classification
373 POS Position Structure System supports workflow approach for new and re-classifications
374 POS Position Structure New Positions and re-classifications are effective dated375 POS Position Structure System identified supervisor for position
376 POS Position Structure System shows org-chart with current incumbent
377 POS Position Structure The system is able to track revisions to Job Description.
378 POS Position Structure Job can be created and moved through multiple statuses.
379 POS Position Structure Job can be kept un-published until approval is received.380 POS Position Structure A Job can be defined with its competences.
381
POS
Position Structure
The system can generate Personnel Action based on change in specific Position attributes.
382 POS Position Structure The system can trigger Personnel Actions based on changes in Position attributes.
383
POS
Position Structure
The system can maintain draft/alternate Organizational structures in different statuses and can be published to revise the existing structures.
384 HR Employee Master System allows documents to be scanned and attached to employee records
385 HR Employee Master
System records equipment issued to each employee such as items that would need to be returned upon termination
386 HR Employee Master
System records equipment issued to each employee such as items that have been issued to employee (example: uniform)
387 HR Personnel Actions Departments enter personnel actions directly into the system for workflow approval
388 HR Personnel Actions Each personnel action type can have different workflow approval type
389 HR Personnel Actions
System Effective dates employee transactions (example: add employee, remove employee, promote, etc.)
390 HR Personnel Actions All personnel actions can be effective dated forward or backward
391 HR Personnel Actions
System maintains history of all personnel actions including maintaining all attachments for individual personnel actions.
Page: 15 of 31 Packet Pg 87
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
392 HR Personnel Actions
System allows identifying sequencing for multiple personnel actions that occur on same day, including multiple changes to salary (example: provide % COLA first, and then $.50 per hour merit increase)
393 HR Personnel Actions
Upon approval of the personnel action and effective date reached, changes are automatically made to the employee record.
394 HR Personnel Actions
For personnel actions that require notification to be sent to third party (benefit changes, name change, etc.), system provides notification.
395 HR Personnel Actions
System allows personnel actions and salary changes at any date (mid pay period) and prorates changes correctly.
396 HR New Hire Interface
Interface to NeoGov to transfer information for new hire (from information provided during recruiting process)
397 HR New Hire Interface System/NeoGov initiates new hire personnel action
398 HR New Hire System generates offer letter using information from candidate and position
399 HR New Hire System provides self service portal for new employee to provide necessary information
400 HR New Hire System sends employee email with instructions to access self service portal
401 HR New Hire System stores personal email in ERP (part of interface with NeoGov)
402 HR New Hire
System provides new hire check list which includes notification of various City departments of pending tasks (example: IT for network access, Facilities for prox, benefits for benefit packet, etc)
403 HR New Hire Interface System initiates new hire checklist as soon as information is imported from NeoGov
404 HR New Hire Interface System interfaces to NeoGov/Government Jobs to provide information on open position
405 HR New Hire System tracks completion of important tasks in hiring process (on boarding checklist).
406 HR New Hire System tracks different checklist based on job classification 407 HR New Hire System tracks dates for items in checklist
408 HR New Hire System tracks different checklist based on department/division
409 HR New Hire Provides self service for initial enrollment in benefits
410 HR New Hire Provides self service for on-line completion and auto processing of W-4 form to payroll.
411 HR New Hire Provides self service for on-line completion of direct deposit for payroll
412 HR Self Service Employees access self service to update personal information 413 HR Employee File System tracks electronic employee file
414 HR Employee File System allows attachment of documents to employee file
415 HR Employee File System tracks hours worked for each employee
416 HR Employee File System tracks employee group for each employee
Page: 16 of 31 Packet Pg 88
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
417 HR Separation
Upon separation, workflow notifies all appropriate departments (example: HR, Payroll, IT) of employee separation
418 HR Separation
System provide separation check list that notifies various City departments of pending tasks (example: IT turn off network access; HR conduct exit interview)
419 HR Separation System tracks different checklist based on department/divisions
420 HR Separation Interface System updates benefit carriers/TPAs with termination of benefit information.
421 HR Separation Interface System generates notice to City's COBRA TPA with necessary information
422 HR Disciplinary Actions System tracks disciplinary actions on employees
423 HR Disciplinary Actions System tracks multiple types of disciplinary actions
424 HR Disciplinary Actions System records follow up actions with notification to remind users of upcoming follow up action
425 HR Disciplinary Actions System links disciplinary action to personnel action
426 HR Disciplinary Actions System allows files to be attached to disciplinary action
427 HR Disciplinary Actions System limits access to disciplinary actions to only those with approved access
428 HR Disciplinary Actions System allows reports to be run on disciplinary actions
429 HR Disciplinary Actions
While not discipline, the system's case management system should also be able to track other employee issues such as ADA (Americans with Disabilities Act) and provide appropriate security, notification, and reporting features
430 HR Self Service System provides web self service for employees to change contact information
431 HR Self Service System provides web self service for employees to emergency contact information
432 HR Self Service
All changes/requests made by employees via the self-service module are routed to the appropriate approver/supervisor for review and approval via workflow before the change is posted.
433 HR Self Service
When change requires documentation to be submitted, the system notifies employee that further action is required and change won't occur until that occurs
434 HR Self Service System allows attachments to changes/requests.
435 HR Self Service System allows changes to be initiated by someone other than employee.
436 HR Self Service System notifies employee when certain changes are made.437 HR Job Evaluation Jobs can be tagged as benchmark Jobs.
438 HR Job Evaluation Multiple salary survey results can be stored in benchmark jobs
439
HR Job Evaluation Studies of Salary, Benefits, Retirement, Paid Time off, Job Specifications (Education, Certification) can be made against Benchmark Jobs.
Page: 17 of 31 Packet Pg 89
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
440
HR Job Evaluation Internal salaries can be compared to survey results for benchmark jobs using standard reports.
441 HR Performance Evaluation System allows information to be entered into performance evaluation forms online
442 HR Performance Evaluation System to build in due dates when evaluations are to be completed
443 HR Performance Evaluation Personnel evaluation dates set at anniversary of hire date, promotion date.
444 HR Performance Evaluation Personnel evaluations done quarterly for new hires
445 HR Performance Evaluation
System notifies employee, supervisor and other department staff (example: department head, payroll clerk) of upcoming evaluation
446 HR Performance Evaluation
System notifies employee, supervisor and other department staff (example: department head, payroll clerk) of need to complete goals
447 HR Performance Evaluation Personnel evaluations track goals for management staff
448 HR Performance Evaluation Personnel actions evaluation employees against unique goals
449 HR Performance Evaluation System notifies employee, supervisor and HR of late evaluation
450 HR Performance Evaluation System allows employee to make notes on evaluation form prior to evaluation
451 HR Performance Evaluation System stores multiple evaluation forms based on position, departments, and job
452 HR Performance Evaluation System can link performance evaluation to personnel action (such as merit increase)
453 HR Performance Evaluation System provides scoring for personnel action questions454 HR Performance Evaluation Scoring is weighted by question
455 HR Performance Evaluation System provides dashboard notification of overdue evaluations
456 HR Performance Evaluation
System's performance evaluations are electronically routed to the appropriate users for approval via workflow and electronic signature.
457 HR Professional Development
System tracks performance improvement plan / professional development goals for employees
458 HR Professional Development System has the ability to track City-offered trainings
459 HR Professional Development System allows for user self-enrollment or user-enrollment by supervisor or admin
460 HR Professional Development System can charge fees for course and charge department of employee attending training
461 HR Professional Development System offers current & historical training transcript for view by user, supervisor, admin
462 HR Professional Development System allows users to enter personal learning events
463 HR Professional Development
System allows for administrator to manage, create & update course offerings
464 HR Professional Development
System has the ability to send email notifications for enrollment, cancellations, completion, or changes
465 HR Professional Development System has the ability to manage courses in a catalog which is viewable by users
466 HR Professional Development System would provide the ability to create reports or queries off of training data467 HR Professional Development Interface Interface to Spillman for public safety training
Page: 18 of 31 Packet Pg 90
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
468 HR Professional Development Interface Interface to Target Solutions for Fire Safety Training
469 HR Certifications System tracks required certifications by position / job classification470 HR Certifications System tracks employee certifications
471 HR Certifications System notifies employee, supervisor, other of expiring certifications
472 HR Certifications System tracks ongoing certification compliance (training credits/CEUs)
473 BEN Benefit Set Up System is compliant with and supports ACA eligibility
474 BEN Benefit Set Up System maintains multiple benefit plans each having multiple options
475 BEN Benefit Set Up System tracks benefits and manages payroll deductions for benefits for employees
476 BEN Benefit Set Up Benefit premium amount differs by job classification/bargaining unit/work group
477 BEN Benefit Set Up Benefit premium amount differs by employee election (tiers)
478 BEN Benefit Set Up System offers ability to enroll in domestic partner benefits (both taxable and non-taxable)
479 BEN Benefit Set Up System can calculate taxable value for domestic partner covered under insurance
480 BEN Benefit Set Up System maintains one benefit record for multiple jobs.
481 BEN Benefit Eligibility
System automatically determines employee eligibility by employee status (full time vs. not full time)
482 BEN Benefit Eligibility
System automatically determines employee eligibility by work group (one bargaining unit may be in different plan)
483 BEN Benefit Eligibility System places employee in default benefit based on work group
484 BEN Benefit Eligibility
System provides alert to employees nearing benefit eligibility threshold (for hours worked) in year)
485 BEN Benefit Eligibility System supports ACA open enrollment (track ACA eligible (annual and new)
486
BEN Enrollment System is able to enroll employee in default plans (short term plans for new hires prior to making elections), automatic plans (enrollment in plans without employee having to make elections), electable plans (option for employee to select coverage levels or opt-out) based on their Job Class, Bargaining Unit or Position.
487
BEN Enrollment System is automatically able to determine eligibility for Health, Insurance, Savings/Retirement and Flexible Spending Plans based on their Job Class, Bargaining Unit or Position.
488
BEN Enrollment System is able to create Benefit Program groups based on their Job Class, Bargaining Unit or Position.
489
BEN Enrollment Creation of Hire/Rehire action is able to open New Hire Enrollment in Self Service for a pre-determined period of time.
490
BEN Enrollment System is able to manage Deferred Com based on employee age for age catch up contributions, etc.
Page: 19 of 31 Packet Pg 91
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
491 BEN Enrollment System is automatically able to open enrollment for specified Life Change Events.
492 BEN Beneficiaries/Dependents System tracks history of all dependents changes493 BEN Deductions Benefit deductions to occur for each pay period
494 BEN Deductions Benefit deductions to occur for 1st pay period of the month
495 BEN Deductions Benefit deductions to occur for 2nd pay period of the month
496 BEN Deductions Benefit deductions to occur for 3rd pay period of the month
497 BEN Deductions Benefit deductions to occur for off cycle pay cycles
498 BEN Deductions
System allows user to select each period individually (example: 1st and 2nd of month, but not 3rd.)
499 BEN Deductions System deducts employer paid amount and transfers funds to internal service funds500 BEN Deductions Deduction rate can be set as a flat amount
501 BEN Deductions
Deduction amount/rate can be set as a percentage of eligible pay (not all pay code types would be eligible)
502 BEN Deductions
System tracks maximum deduction amounts and tracks deduction totals against maximum allowed per pay period
503 BEN Deductions
System tracks maximum deduction amounts and tracks deduction totals against maximum allowed per year
504 BEN Deductions
System tracks accumulated payments across multiple plans when comparing against a maximum amount
505 BEN Deductions
System tracks limit to deductions by year (System automatically stops taking deduction after limit is reached)
506 BEN Deductions
System will provide invoice to employees with deductions and garnishments greater than compensation
507 BEN Deductions System will alert and track for employees with net pay less than benefit deductions
508 BEN Deductions Deductions and garnishments can be prioritized
509 BEN Benefit Plan Administration System allows all changes to benefit plans, rates, and eligibility be made through effective dating
510 BEN Benefit Plan Administration System allows changes in premium amounts to be made with effective dating
511 BEN Benefit Plan Administration System automatically creates term row in FSA plan if no annual election made512 BEN Benefit Plan Administration System track history of benefit elections513 BEN COBRA System generates COBRA notification letter
514 BEN Benefit Plan Administration System has the ability to track COBRA and Retirees enrollment
515 BEN Benefit Plan Administration
System provides automated notifications to employees for ineligible dependents (turning age 26)
516 BEN Benefit Plan Administration
System provides annual notifications to employees and Benefits Staff for employees changing age categories (for PTL tiers)
Page: 20 of 31 Packet Pg 92
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
517 BEN Benefit Plan Administration Interface
System provides interface to update benefit carriers of change in enrollment, status, dependents, or other required information518 BEN Benefit Plan Administration Interface Interface to Aflac for Section 125
519 BEN Benefit Plan Administration Interface Interface/Report to Carl Warren (the City's claims administrator
520 BEN Benefit Plan Administration Interface Interface to CJPIA for liability insurance and workers comp521 BEN Benefit Plan Administration Interface Interface to Delta Dental for dental insurance522 BEN Benefit Plan Administration Interface Interface to ICMA RC for deferred comp
523 BEN Benefit Plan Administration Interface Interface to Lincoln Financial for long term disability524 BEN Benefit Plan Administration Interface Interface to Mass Mutual for deferred comp525 BEN Benefit Plan Administration Interface Interface to MES vision for vision care526 BEN Benefit Plan Administration Interface Interface to MHN Provider Portal for Healthcare527 BEN Benefit Plan Administration Interface Interface to CALPERS
528 BEN Benefit Plan Administration Interface Interface to John Hancock for PARS 401a deferred comp529 BEN Benefit Plan Administration Interface Interface to the Standard for life insurance
530 BEN Benefit Plan Administration System provides benefit reconciliation to compare provider billing to deductions
531 BEN Benefit Plan Administration All benefit changes done through effective dating
532
BEN Life Events System is able to open enrollment elections when employee makes changes to their dependent data.
533
BEN Life Events System is able to open enrollment elections based on employee’s change in bargaining unit, Job Class or position.
534
BEN Pension Based on whether the employee has not previously enrolled in CalPERS, the system is able to generate notification at predetermined hours of work to obtain approval for CalPERS enrollment or terminate employee.
535 BEN Pension Able to create request to enroll employee in CalPERS
536 BEN Pension Able to manually make an employee eligible for CalPERS enrollment.
537
BEN ACA, Pension System to track hours worked & notify supervisor when they have hit a certain number of hours (1040 for sup. Employees)
538 BEN Self Service
System allows web portal for employees to select benefit options for initial and open enrollment, including the option to waive coverage
539 BEN Self Service System provides web portal for employees to update benefit elections for qualifying life events
540 BEN Self Service
System determines employee eligibility and only offers eligible benefit packages to employees through self service
541 BEN Self Service Open enrollment indicates employee's current selection (for previous year)
542 BEN Self Service Employees using self service for open enrollment can re-select all benefit elections
543 BEN Self Service
Employees using self service for open enrollment can confirm existing benefit elections (selections from previous year are carried over)
Page: 21 of 31 Packet Pg 93
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
544 BEN Self Service
Employees not entering self service for open enrollment have previous selections applied to next year
545 BEN Self Service
System identifies employees that have not yet re-enrolled and provides notification to RISK and/or employee
546 BEN Self Service Employees can make changes to dependents through self service:
547 BEN Self Service Any benefit changes made through self service are routed through workflow for approval
548 BEN Self Service
Employees are able to attach documentation if necessary to benefit elections, dependent information, or qualifying life events (example: birth certificate), including documentation if Waiving coverage
549 BEN Self Service System generates a configurable annual Total Compensation Statement
550 BEN Self Service System provides check simulation to show take home pay after benefit elections
551 BEN Self Service Upload pictures of birth certificates, marriage certificates, opt out (employee optional)
552
BEN
Self Service System allows employees to utilize self service and provide documentation through mobile device
553 BEN End of Year Process
System gathers information and generates 1095-c forms for annual reporting. This needs to include employees with multiple jobs.
554 BEN End of Year Process System maintains records for ACA reporting - 1095c
555 BEN End of Year Process Interface System generates annual health insurance summary transmittal to IRS - 1094-c
556 BEN Reporting System tracks health care costs for use in W-2 reporting - ACA
557 TE Time Entry Employees can enter time in system by punch-in, punch-out
558 TE Time Entry Employees can enter time in system by exception based hours entry (against pre-defined schedule)
559 TE Time Entry Employees can enter time in system by hours worked per day
560 TE Time Entry Employees can enter time for regular hours (default allocation)
561 TE Time Entry System stores default schedule for each position/job classification.
562 TE Time Entry System allows for multiple unique schedules (4/10, 5/40, 3/12, 9/80)
563 TE Time Entry System will allow for time sheets to be created, reviewed and approved by proxy.
564 TE Time Entry Employees can enter time for projects by overriding the default earnings distribution
565 TE Time Entry Interface System interfaces to time clock device for employee time entry
566 TE Time Entry Interface
System interfaces with third party time entry system for department (police uses e-shift / fire uses InteliStaf)
567 TE Time Entry Interface Interface to scheduling system to get employee schedule
568 TE Time Entry System allows employees to record time not worked (for part time)
569 TE Time Entry System allows managers to view employees currently working
Page: 22 of 31 Packet Pg 94
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
570 TE Time Entry Interface Interface to permitting system to track time for plan reviews571 TE Time Entry System allows for time entry on mobile device
572 TE Time Entry Ability to pay employees different pay rates during one day, week, and pay period
573 TE Time Sheet Approval
System provides workflow for review and approval of timesheets with ability to activate notifications.
574 TE Time Sheet Approval Allow for supervisory approval of time on a pay period basis
575 TE Time Sheet Approval System supports multiple approvals for timesheets or individual timesheet
576 TE Time Sheet Approval System allows for the workflow approval of vacation or requests of time off
577 TE Time Sheet Validation Business rules in timesheet automatically apply correct: Shift differential
578 TE Time Sheet Validation Business rules in timesheet automatically apply correct: Overtime
579 TE Time Sheet Validation Business rules in timesheet automatically apply correct: Holiday Pay
580 TE Time Sheet Validation
City maintains one holiday schedule but employees with normally scheduled off day on holiday receive additional holiday day
581 TE Time Sheet Validation Holiday pay is 8 hours. Employees schedule for more than 8 hours must take leave
582 TE Time Sheet Validation
Overtime rules can identify type of hours to track for overtime calculation (hours worked, all hours (work and leave)
583 TE Time Sheet Validation
Business rules for timesheets can vary by employee type, earnings program, and/or work group
584 TE Time Sheet Validation Time can be entered manually for those cases where business rules cannot be codified
585 TE Time Sheet Validation
Earnings codes, (overtime, special pay, etc.), are applied to each timesheet based on the earnings program assigned to employee
586 TE Time Sheet Validation
System will calculate the FLSA overtime earnings benefit based on the actual work hours by user-defined period by employee.
587 TE Time Sheet Validation System alerts if employees have recorded zero hours
588 TE Time Entry System must allow for negative or positive changes for prior pay periods.
589 TE Time Entry
System will allow for time sheets to be created in different formats which allow ease of entry for different groups of employees.
590 TE Time Entry System allow for multiple In/Out times for a single day.
591 TE Time Entry System allows comments to be added to a timesheet (Line and Timesheet).
592 TE Time Entry System provides information for coordinating timesheets for employees with multiple jobs.
593 TE Time Entry System has ability to deal with mid-pay period job changes for employees.
594 TE Time Entry Ability to print timesheets with log and comments.
Page: 23 of 31 Packet Pg 95
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
595 TE Time Entry
System needs the ability to process two partial timesheets for the same pay period for a single employee.
596 TE Time Entry Interface
Interface to Telestaff for coordinate employees, schedules, time entry, and leave information. Interface should allows for information to be entered in one system and accessed in both
597 TE Time Entry Interface
Interface to WhentoWork for coordinate employees, schedules, time entry, and leave information. Interface should allows for information to be entered in one system and accessed in both598
599 TE Time Sheet Validation System System will prevent the coding of work hours for the same period on multiple timesheets.
600 TE Time Sheet Validation Business Business rules (validation) allow for different processing of timesheets.
601 TE Time Sheet Validation System System accommodates FLSA period that begins halfway through day602 TE Time Sheet Validation System System compares FLSA OT vs. MOA OT
603 TE Time Sheet Approval System System allows for the set up of workflow alternates for either a period on time or on an ongoing basis.
604 TE Time Sheet Approval System
System provides approver the ability to track the status of timesheets of employees that report to the approver.
605 TE Time Sheet Approval System System allow for ability to view timesheets without ability to update.
606 TE Time Sheet Processing System System can provide reports for preparing timesheets for processing.
607 TE Time Sheet Processing Ability Ability to view and sort timesheets that will be uploaded for payroll processing.
608 PAY Salary Administration System System supports step (longevity) and grade (job classification/type) salary structure
609 PAY Salary Administration System System supports salary range (employee salary falls between min and max)
610 PAY Salary Administration System System supports mass change for COLA on step grade and/or salary ranges
611 PAY Salary Administration Changes Changes to salary tables made through effective dating
612 PAY Garnishments System
System records garnishments on employee and can accommodate multiple garnishments with priority order
613 PAY Garnishments Garnishments Garnishments calculated as percentage of disposable income
614 PAY Garnishments Garnishments
Garnishments withheld and paid to appropriate agency/organization through accounts payable (integration between garnishment and accounts payable)
615 PAY Special Pay System System supports rates for special pays, shift differentials, and other add to pays
616 PAY Special Pay System System calculates add-to-pays and special pay amounts every pay period
617 PAY Special Pay Special Special pay/add-to-pay is calculated as flat amount
618 PAY Special Pay Special Special pay/add-to-pay is calculated as an hourly amount.
619 PAY Special Pay Special
Special pay/add-to-pay is calculated as percentage of eligible pay (identify eligible pay for each special pay by pay code)
Page: 24 of 31 Packet Pg 96
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
620 PAY Special Pay System System automatically applies imputed income for employees receiving non-cash benefits
621 PAY Special Pay System System allows payment based on unit rate (commissioners paid per meeting)
622 TE Time Sheet Validation System
System allows user to define eligible pay types applied as hours worked for OT purposes by job classification
623 TE Time Sheet Validation System
System will calculate the FLSA overtime earnings benefit based on the actual work hours by user-defined period by employee.
624 PAY Special Pay System System identifies pensionable earnings vs. non-pensionable earnings.
625 PAY Leave Accruals Leave Leave can be taken in different increments depending on code or bargaining unit contract
626 PAY Leave Accruals System System allows override for employees to be hired with leave (pre-set amount)
627 PAY Leave Accruals Employees Employees leave accrual rate based on: (earn X hours of leave per pay period)628 PAY Leave Accruals System System tracks comp time for employees
629 PAY Leave Accruals Comp
Comp time can be earned at rate equal to 1.5 time hours worked (1 hour of overtime worked = 1.5 hours of comp time). Need to be able to calculate any other rate other than 1:1
630 PAY Leave Accruals Leave Leave balances can be set to roll over depending on leave type at end of anniversary year
631 PAY Leave Accruals Leave Leave balances can be set to roll over depending on leave type at end of calendar year
632 PAY Leave Accruals Leave Leave balances can be set to roll over depending on leave type at end of specified date
633 PAY Leave Accruals Leave Leave balances can be set to not roll over depending on leave type at end of anniversary year
634 PAY Leave Accruals Leave Leave balances can be set to not roll over depending on leave type at end of calendar year
635 PAY Leave Accruals Leave Leave balances can be set to not roll over depending on leave type at end of specified date
636 PAY Leave Accruals Balances Balances can be capped at maximum amount at any time
637 PAY Leave Accruals Balances Balances can be capped at maximum amount at anniversary date
638 PAY Leave Accruals Balances Balances can be capped at maximum amount on specified date
639 PAY Leave Accruals Balances Balances can be capped at maximum amount at end of calendar year640 PAY Leave Accruals Balances Balances can be capped at fixed amount
641 PAY Leave Accruals Ability
Ability to accrue leave can be capped by amount already earned in current year (regardless of current balance)642 PAY Leave Accruals All All leave balances are printed on pay stub
643 PAY Leave accrual/Time Entry System System is able to prohibit use of leave accrual for certain time period, but also allow an override.
644 PAY Leave Accruals System System allows user to have negative leave balance
Page: 25 of 31 Packet Pg 97
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
645 PAY Leave Accruals System System allows comp time to be earned up to limit
646 PAY Leave Accruals If If comp limit is reached, employee forced to take overtime payments
647 PAY
LOA
Based
Based on the total accrued leave (vacation, admin leave, etc.) the employee has accumulated, the system is able to project the duration of paid leave and leave will become unpaid.
648 PAY
LOA
System
System can maintain a Catastrophic Leave Bank, to which employees can donate their paid time credits and can be used by individual employees based on eligibility rules.
649 PAY
LOA
When
When an employee on FMLA extends her leave beyond the eligible 12 weeks and enters unpaid leave, the system is able to continue their benefits coverage.
650 PAY FMLA System System tracks FMLA on rolling 12 month calendar
651 PAY FMLA System System accommodates forward and backward rolling calendars
652 PAY FMLA System System tracks multiple leave periods (multiple FMLA and OFLA periods within rolling calendar)
653 PAY FMLA System
System allows employees to take FMLA/CFRA leave and sick leave (or other leave type) at the same time
654 PAY FMLA System
System tracks FMLA/CFRA leave taken intermittently (example: FMLA leave taken every other day of leave period)
655 PAY FMLA System System provides workflow for notification and approval of FMLA leave656 PAY Payroll Processing Payroll Payroll process bi-weekly
657 PAY Payroll Processing System
System will process pay for one employee with multiple jobs and employee will receive one paycheck
658 PAY Payroll Processing System
System will run pay, deduction, withheld taxes, and net pay calculations as a "proof" run for review prior to final pay run.
659 PAY Payroll Processing System System will cut special or immediate (on-demand) checks.
660 PAY Payroll Processing System
System allows posting new adjustments/corrections for a prior period for tax reporting (overrides)
661 PAY Payroll Reporting System System generates pension earnings and deductions report
662 PAY Retro Pay Retro Retro pay calculation used to back date and correct for personnel actions
663 PAY Retro Pay Retro Retro pay calculation used to back date and correct for corrections to errors
664 PAY Retro Pay Retro Retro pay calculation used to back date and correct for changes to timesheet
665 PAY Retro Pay Retro Retro pay calculation used to back date and correct for back pay
666 PAY Retro Pay Retro Retro pay will automatically correct salary amounts
667 PAY Retro Pay Retro Retro pay will automatically correct tax deductions (additional income tax withheld)
668 PAY Retro Pay Retro Retro pay will automatically correct calculate benefit deductions669 PAY Retro Pay Retro Retro pay will calculate garnishments
Page: 26 of 31 Packet Pg 98
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
670 PAY Retro Pay Retro Retro pay will automatically correct FLSA Calculations (Overtime)
671 PAY Retro Pay Retro Retro pay will automatically correct leave balances
672 PAY Retro Pay System
System will retain previous salary and hours and days worked data and effective dates for use when calculating retroactive pay adjustments
673 PAY Check Printing System System supports positive pay for payroll checks674 PAY Check Printing System System support direct deposit for payroll
675 PAY Check Printing System
System provides set up to provide direct deposit to multiple bank accounts based on amount and percentage
676 PAY Check Printing System System produces electronic files to send to bank for direct deposit
677 PAY Check Printing System System produces electronic file to multiple banks for direct deposit
678 PAY Self Service Employees Employees can use self service to view compensation package
679 PAY Self Service Employees Employees can use self service to view W-2, including history680 PAY Self Service Employees Employees can use self service to view W-4
681 PAY Self Service System
System meets federal and state requirements for accepting online W-4. System must support state withholding
682 PAY Self Service Employees Employees can use self service to view pay stub
683 PAY Self Service Central Central payroll and HR need to be able to view any other pay stub along with pertinent history.684 PAY Self Service System System must allow for a configurable pay stub
685 PAY Self Service Employees Employees can use self service to view pay history
686 PAY Self Service Employees Employees can use self service to view leave balances
687 PAY Self Service All
All changes made by employees via the self-service module is routed to the appropriate approver/supervisor for review and approval via workflow before the change is posted.
688 PAY Self Service Provides Provides self service for on-line completion or update of direct deposit for payroll
689 PAY End of Year Process System System will produce W-2s (and to reprint single W-2)690 PAY End of Year Process System System will store W-2s
691 PAY End of Year Process System System will produce quarterly Form 941 report (IRS)
692 PAY End of Year Process System System will produce amended W-2 for multiple years
693 PAY End of Year Process System System will produce a report showing FICA wages, by individual, W-2 Plan, and in total
694 PAY End of Year Process System System produces electronic files for social security and IRS695 PAY End of Year Process System System provides social security verification file696 RISK Risk Management System System used to track all incidents/injuries697 RISK Risk Management System System used to track general liability claims
698 RISK Risk Management System System provides online form for entering incidents/injuries that all employees can access699 RISK Risk Management System System tracks location of injury/incident
Page: 27 of 31 Packet Pg 99
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment700 RISK Risk Management Location Location tied to City facility or GIS(Map)701 RISK Risk Management System System relates injuries/incidents to claims
702 RISK Risk Management System System allows users to enter notes on claim and incident records
703 RISK Risk Management System System allows users to track actions made on the claim including dates, actions, follow up dates)
704 RISK Risk Management System System allows users to upload documents to incidents/claims
705 RISK Risk Management System System provides notification for follow up actions
706 RISK Risk Management Interface System provides notification to TPA of reported injuries/ incidents
707 RISK Risk Management Interface System uploads file from TPA with claim information to update injury/ incident
708 RISK Risk Management System System provides supervisor report of injury/incident709 RISK Risk Management System System provides incident to injured party710 RISK Risk Management System System generates OSHA log
711 BUD Budget Requests Departments Departments enter budget requests through system including requested budget amount712 BUD Budget Requests Budgets Budgets preparation system accommodates entering budget detail for project budget (over
713 BUD Budget Requests System
System pre-populates budget entry fields with past budget version, and actual expenditures and revenues
714 BUD Budget Requests System System used to prepare budgets for revenues and expenses
715 BUD Budget Requests Departments
Departments enter budget requests through system including changes/additions/deletions of positions
716 BUD Budget Requests Departments
Departments enter department and narrative information along with budget requests (Example: program goals, challenges, highlights of major changes, etc.)
717 BUD Budget Requests Departments Departments enter budget requests through system including attaching documents
718 BUD Budget Requests Departments Departments can enter notes/justification for budget requests
719 BUD Budget Requests Departments Departments enter information on service level (or what is proposed for budgeted program)
720 BUD Budget Requests Budget Budget requests can be grouped into decision packages (multiple line items that go together)
721 BUD Budget Requests Budget Budget requests (decision packages) can be prioritized
722 BUD Budget Requests System System allow users to create different budget projections/scenarios (example: what if 5% cut)
723 BUD Budget Requests Users
Users can flag one-time budget events and the system automatically removes them from the next years' budget
724 BUD Budget Requests System System allows users to budget reoccurring expenditures that do not occur every fiscal year
725 BUD Budget Requests Users Users can create multiple versions of a budget request for "what if" scenario simulation
726 BUD Budget Requests System System allows users to compare multiple scenarios727 BUD Budget Requests System System supports multi-year budgeting
728 BUD Budget Requests System System supports budgeting for one year and forecasting multiple years
Page: 28 of 31 Packet Pg 100
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
729 BUD Budget Requests System
System supports biennial budgeting where 2 years are budgeted and then 2nd year is revised after 1st year.
730 BUD Budget Requests Users Users can view multiple years of actual and budget data while preparing budget request
731 BUD Program Budgeting System System allows users to prepare budgets by program (can be across multiple departments)
732 BUD Program Budgeting City City operating budget is roll up of all accepted program budgets
733 BUD Program Budgeting System System allows program budgets to be prioritized
734 BUD Program Budgeting System System allows program budgets to link to strategic goals
735 BUD Program Budgeting System System tracks performance measures on each program
736 BUD Program Budgeting System System tracks program narrative and goals for each program
737 BUD Budget Development Department Department worksheets are automatically rolled into organization-wide master budget
738 BUD Budget Development System System maintains history of multiple budget versions including requested Budget
739 BUD Budget Development System
System allows budget users to modify all department budget worksheets within allowed permissions for each user
740 BUD Budget Development System System allows budget users to roll budget to new version
741 BUD Budget Development System System maintains history of multiple budget versions including recommended Budget
742 BUD Budget Development System System maintains history of multiple budget versions including adopted Budget
743 BUD Budget Development System System maintains history of multiple budget versions including revised budget
744 BUD Personnel Budgeting System
System projects and budgets tax and benefit costs based on current regular employee salary and current benefit elections
745 BUD Personnel Budgeting System
System projects and budgets tax and benefit costs based on position salary range and default benefit elections
746 BUD Personnel Budgeting System System allows user to propose new position in proposed budget
747 BUD Personnel Budgeting System
System provides ability to propose changing position status as part of budget development (funded - unfunded positions)
748 BUD Personnel Budgeting System System provides ability to request new positions as part of budget process
749 BUD Personnel Budgeting With With changes to salary amounts, system automatically adjusts any benefits/tax amounts
750 BUD Personnel Budgeting System
System allows for the cost of a position to be allocated to multiple segments of the Chart of Accounts (i.e. organizational codes, programs, projects, grants, etc.)
751 BUD Personnel Budgeting System System provides what if forecasting for salary adjustments
752 BUD Personnel Budgeting System System budgets salary with COLA occurring on identified date and prorate salary
Page: 29 of 31 Packet Pg 101
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
753 BUD Personnel Budgeting System
System can assume step change in salary upon employee anniversary date and budget with change in salary mid year
754 BUD Personnel Budgeting System System budget full cost for employee including all salary, benefit, and ARC for pension755 BUD Capital Budgeting Capital Capital budgets prepared by project
756 BUD Capital Budgeting Project
Project budgets created roll up to create department capital budget and overall capital improvement plan
757 BUD Capital Budgeting System System allows individual capital project budgets created in project module to feed budget module
758 BUD Capital Budgeting System
System must allow for the reappropriation of funds from one fiscal year to the next for projects with capital carryover.
759 BUD Capital Budgeting Estimated Estimated operating budget impacts can be captured at the time of project budget entry. 760 BUD Capital Budgeting Multiple Multiple departments view project
761 BUD Capital Budgeting Departments Departments working together on projects (access to view, approve)
762 BUD Capital Budgeting System System allows departments to develop replacement schedule for capital assets
763 BUD Capital Budgeting Information Information for replacement schedule pulled from capital assets to avoid need to re-enter for budget
764 BUD Capital Budgeting Interface Interface to CityWorks (parks, streets, trees, utilities) to provide budget information
765 BUD Capital Budgeting System System tracks project manager for each capital project766 BUD Capital Budgeting Interface Interface New Fleet System
767 BUD CIP System System supports developing 10 year CIP projections
768 BUD CIP System System connects individual projects to City priority
769 BUD CIP Identify Identify funding source by fund/department on projects770 BUD CIP Identify Identify all funding source for department / fund771 BUD CIP System System provides asset replacement schedules
772 BUD CIP Long Long term planning / forecasting for capital replacement
773 BUD CIP System System tracks long range infrastructure needs (long term asset management) for 30 year period
774 BUD Budget Projections System System used to project revenues and expenses and monitor budget throughout year775 BUD Budget Projections Budget Budget projections available through dashboard
776 BUD Budget Monitoring System
System provides alerts and notifications for hitting defined budget thresholds (example: 90% of budget)
777 BUD Budget Adjustments System
System allows departments to propose budget transfers within department authority with workflow approval
778 BUD Budget Adjustments System
System provides workflow based on transfer to/from (example: within department/division/fund or between department/division/fund)
779 BUD Budget Adjustments System
System provides workflow based on transfer based on within or between budget categories (example: salary/supplies/materials/etc.)
Page: 30 of 31 Packet Pg 102
5
Req # Function Process Interface Requirement Implementation Response Module / System Phase for Go Live Comment
780 BUD Budget Adjustments System System allows departments to propose additional budget requests
781 BUD Budget Adjustments System System validates and enforces rule that all budget amendments and transfers must balance
782 BUD Budget Adjustments System System provides funds availability check when entering budget amendments
783 BUD Budget - Other System
System allows restricting access to different budget or forecast versions to specific users or permission levels
784 BUD Budget - Other System System maintains audit trail of which users made changes to any given field over time
785 BUD Budget/Reporting System System provides online transparency portal for viewing budget information
786 BUD Budget/Reporting System System provides online transparency portal for viewing actual expenditure information
787 BUD Budget/Reporting Online Online portal provides summary information for citizens in easy to use format
788 INV Receipt of Inventory Integration Integration with purchasing to automatically create or add inventory items
789 INV Receipt of Inventory System System can accommodate items with zero dollar value and/or zero quantity
790 INV Receipt of Inventory System System allows defective goods that have been received and placed in inventory to be taken out
791 INV Receipt of Inventory Track Track donated items or other items not from purchasing system
792 INV Use of Inventory System System provides on-line requisition form for items in inventory
793 INV Use of Inventory System
System processes partial pick/issue tickets of reserved items while keeping the remaining balance of items on reserve794 INV Use of Inventory System System generates trip/delivery tickets795 INV Use of Inventory System System tracks item usage
796 INV Use of Inventory User User can define, by item, the variables used in determining reorder points and reorder quantities
797 INV Track Inventory System System tracks location of inventory item by warehouse (including multiple warehouses)
798 INV Track Inventory System System tracks location by section of warehouse
799 INV Track Inventory System System provides online form to transfer inventory between warehouse
800 INV Track Inventory System System indicates stock on hand for each location
801 INV Track Inventory System System indicates stock on hand for multiple locations802 INV Track Inventory Identify Identify inventory items as critical spare
803 INV Cost Allocation System System calculates and allocates cost of inventory by: average price
804 INV Physical Inventory System System automatically updates inventory on-order information at the time that a requisition is created
Page: 31 of 31 Packet Pg 103
5
Attachment 11 - Data ConversionsInstructions: Complete yellow shaded cells
Functional Area Data System Description Quantity In Scope?Comments
General Ledger Trial Balance by Fund Finance Plus All balances > $0 for prior and current fiscal years*40 Yes
General Ledger Revenue and expenditures (ACTUALS)Finance Plus Summary balances > $0 for prior fiscal years* All transactions > $0 for prior and current fiscal years*
2300 Yes
General Ledger Revenues and expenditures (BUDGET)Finance Plus Summary balances > $0 for prior fiscal years* All transactions > $0 for prior and current fiscal years*
2300 Yes
General Ledger Balance Sheet Account Finance Plus All accounts with Balances 200 YesPurchasingPurchase Orders Various All balances > $0 for current fiscal year 300 Yes Encumbrances are manually TrackedPurchasingContractsVariousAll open contracts 250 Yes Manually Tracked
Accounts payable Vouchers Various All vouchers from prior calendar year forward for 1099 processing*
5200 Yes Approximately 100/wk
Accounts receivable Customers Community Plus Active records 2000 Yes
Accounts payable Vendors Finance Plus Active records 1000 Yes
Capital Assets Assets Multiple systems All capitalized assets 1300 Yes
Non-Capital Assets Assets Multiple systems Assets under capitalization threshold tracked by departments
Needs analysis Yes Departments are compiling the list
Human Resources Employee personnel data Multiple systems All records for active employees 800 Yes
Human Resources Employee personnel action Multiple systems All records for active employees 2000 Yes
Position Information Job classifications, positions, and salary tables Questica & Excel All records for the prior and current calendar year 600 Yes Job Class, Grades, Pay Scales, Bargainaing Units, etc.
Conversion Scope in RFP
Page: 1 of 2 Packet Pg 104
5
Benefits Beneficiary and Dependent data Finance Plus All records for the prior and current calendar year 500 Yes
Leave Management Leave accrual balances Various All records for the prior and current calendar year*200 Yes
Leave Management Leave of abscence Various All records for the prior and current calendar year*200 Yes
Payroll Salary Tables Finance Plus All records for the prior and current calendar year*225
Payroll W-2 Finance Plus All records for the prior and current calendar year*800
Payroll Direct Deposit information Finance Plus All records for the prior and current calendar year*600
Page: 2 of 2 Packet Pg 105
5
Attachment 15 – Business Process
This attachment contains business process maps for expected process the City plans to
implement as part of this project. Proposers should review these business process descriptions
and consider implementation of these processes to be a key part of the project scope.
During the implementation, the City expects that consultants will review the processes and
make necessary adjustments to best utilize the software and/or improve process efficiency or
effectiveness. Up to this point, the City has invested time and resources into thinking about
revised process and doesn’t expect that a complete as-is/to-be process analysis will be
conducted again.
Packet Pg 106
5
Process Descriptions:
Chart of Accounts ............................................................................................................................ 3
Chart of Account Structure ......................................................................................................... 3
Budget ............................................................................................................................................. 4
Operating Budget ........................................................................................................................ 4
Capital Budget ............................................................................................................................. 5
Budget Amendments .................................................................................................................. 6
Purchasing ....................................................................................................................................... 7
Vendor Registration .................................................................................................................... 7
Vendor Maintenance .................................................................................................................. 8
Purchase Requisition ................................................................................................................... 9
Purchase Order ......................................................................................................................... 10
Receiving / Invoice Entry ........................................................................................................... 11
Capital Assets ................................................................................................................................ 12
Asset Acquisition – Equipment ................................................................................................. 12
Asset Acquisition – Projects ...................................................................................................... 12
Asset Retirement / Disposal ..................................................................................................... 13
Accounts Receivable ................................................................................................................. 14
Billing ......................................................................................................................................... 14
Customer File ............................................................................................................................ 15
Cash Receipts ............................................................................................................................ 16
Human Resources ..................................................................................................................... 17
New Hire ................................................................................................................................... 17
Employee Personal Information Change .................................................................................. 18
Personnel Action ....................................................................................................................... 19
Personnel Evaluation ................................................................................................................ 20
Time Entry / Payroll ...................................................................................................................... 21
Risk Management ......................................................................................................................... 22
Injury / Incident......................................................................................................................... 22
General Liability ........................................................................................................................ 23
Packet Pg 107
5
Chart of Accounts
Chart of Account Structure
The City plans to utilize the following segments in its revised chart of accounts:
Segment Type Segment Digits
Fund Fund 3
Org Unit Department 2
Org Unit Division 3
Program Program 5
Object Object Level 2
Account Account 5
Project/Grant Project/Grant 6
Project/Grant Project/Grant Details TBD
Considerations:
1. The City expects each segment to be an independent segment that could be used on
transactions in combination with other segments to create valid accounts.
2. For segments that exist in the same segment type, segments would be organized hierarchically
or could be reported in roll up categories. For example, programs would roll up to a function.
3. Between segment types, there is no hierarchical relationship. For example, programs could and
will cross multiple org units.
4. The City expects to utilize a sub ledger to account for detailed project data where additional
segments and values could be defined on a project-by-project basis.
5. The City expects to be able to create reporting hierarchies and roll up information in a variety of
ways. For example:
a. Programs can be grouped into functions or by City goals/priority areas
b. Detailed accounts can be rolled up into summary level categories. For example, many
different types of salary accounts could be rolled up into “salaries"
6. All reporting throughout the City would utilize a consistent chart of accounts.
Packet Pg 108
5
Budget
Operating Budget
Budget
Operating Budget
Future
City ManagerFinanceCouncilAdvisory BodyDepartmentsCity ManagerStart
Update advisory
body on goal-
setting process
City
Manager Manual
Complete Revenue
Projects and Long
Term Plans
Staff ERP /
Manual
Conduct setting the
stage and goal
workshop
Council Manual
Provide
recommended
goals
Advisory
Body Manual
Develop
departmental and
program budgets
Staff ERP
Send instructions
and timelines
Staff ERP
Submit
departmental
budget
FO / Dept.
Manager ERP
Review budget with
departments
Staff Manual
Develop budget for
Community Forum
Staff ERP /
Manual
Review budget
City
Manager Manual
Develop budget for
Council
Staff ERP/Manual
Finalize and
approve budget
Staff ERP/Manual
Communicate with
departments and
set targets
Staff ERP /
Manual
Incorporate
Feedback and
Revise Budget
Staff ERP /
Manual
Incorporate
Feedback and
Revise Budget
Staff ERP /
Manual
Host Community
Forum
Staff ERP /
Manual
Conduct setting the
stage and goal
workshop
City
Mangaer Manual
Review budget with
departments
City
Mangaer Manual
Review budget
City
Manager Manual
Considerations:
1. The City’s operating budget process is very collaborative and involves significant public feedback
and comment. The process is based on City priorities.
2. The City desires to implement a program budget where revenue and expenses are budgeted at a
program level that can form a program inventory for the City. Programs could and will be multi-
departmental.
3. Each program will need to track service level and departments will need to use budget to plan
both financial and non-financial goals.
4. Essential to the City’s budget process is having quality long term forecasts and accurate
personnel budgeting.
Packet Pg 109
5
Capital Budget
Budget
Capital Budget
Future
DepartmentFinanceCIP TeamPlan CommissionOperating
Compile capital
needs
Staff ERP
Prioritize / approve
projects
Staff ERP
Review and update
projects
Staff ERP
Enable capital
project
development
Staff ERP
Review and update
equipment
replacement
Staff ERP
Identify Operating
Impact of Projects
Staff ERP
Identify Operating
Impact of Projects
Staff ERP
Compile Proposed
Capital Budget
Staff ERP
Review Budget
Staff ERP
Review Budget
Staff ERP
Considerations:
1. The City’s capital budget involves both capital projects and capital equipment (new and
replacement).
2. The City expects that the system will utilize information entered on a capital project or asset
record to help forecast long term capital needs (for example: asset replacement or long term
funding for capital project).
a. The City expects to be able to create a list of projects and then continue to build cost
estimates or identify funding sources that will become part of capital budget and long
term CIP
b. The City will track capital assets in the ERP system and needs to track replacement
schedules (both replacement cost and replacement timing).
3. The City will need multiple versions / levels of approval for the capital budget.
4. Capital projects need to identify any impact on the operating budget
Packet Pg 110
5
Budget Amendments
Budget
Amendments
Future
DepartmentHuman ResourcesCouncilFinanceStart
Submit budget
adjustment request
Manager /
FO ERP
FTE Change?
Review request
(routed via
workflow)
Staff ERP
Yes
Create Council item
Staff Manual
Review request
(routed via
workflow)
Staff ERP
Review
Council Manual
Create budget
amendment
Staff ERP
End
Approve?No
Approve?
Yes
No
Approve?Yes
No
No
Considerations:
1. Budget amendments for both operating and capital budget are processed online in the system.
2. The City expects that budget amendments will utilize workflow for approvals.
3. Currently, the City utilizes budget amendments to move money between line item accounts as
well as for supplemental requests. In the future, the City plans on allowing individual line items
to be overspent as long as funding is available at higher summary categories. This should reduce
the need for a large volume of amendments.
Packet Pg 111
5
Purchasing
Vendor Registration
Procure to Pay
Vendor Registration
Future
VendorPurchasingPublic Works
Formal
Sol.
Select awarded
vendor
Purchasing Manual /
BidSync
Receive notification
to enter
information and
upload forms
Vendor ERP
Review / approve
Purchasing ERP
Review / approve
FO ERP
Start
Register to receive
opportunity notices
Vendor BidSync
Generate
notification to
vendor to go to
self-service
Purchasing ERP
(interface)
Enter information
and upload forms
Vendor ERP
APCIP?
Yes
PO
Generate
notification for
vendor to go to
self-service
Purchasing ERP
No
Start
Receive vendor
information
Purchasing Manual
Update vendor file
Purchasing Manual /
ERP
Considerations:
1. All vendors that are issued purchase orders will be registered with the City and complete all
necessary forms and documents
2. The system will track interested vendors for bids/RFPs
3. The City will be using Bid Sync for vendor solicitations and other advanced purchasing functions.
The City will need to explore use of interface to provide integration and avoid duplicate data
entry.
4. The City will use self-service for reduce data entry effort for vendor registration
Packet Pg 112
5
Vendor Maintenance
Procure to Pay
Vendor Maintenance
Future
VendorPurchasingPublic WorksAP
Review / approve
Purchasing ERP
Review / approve
FO ERP
Start
Updates record
with new
information / forms
Vendor ERP
APCIP?
Yes
Generate notice to
update info
(license, insurance,
bank, etc.)
Purchasing ERP
Start
Receives
notification to
update information
Vendor ERP
AP
ACH failed or check
returned
Staff Bank / ERP
Notify Purchasing
of vendor record
issue
Staff ERP
(workflow)
No
Considerations:
1. It is expected that purchasing will control the vendor file and make necessary revisions that are
not completed in self-service. Accounts payable would review changes.
Packet Pg 113
5
Purchase Requisition
SLO
Purchase Requisition
To-Be
DepartmentBudgetPurchasingCity ManagerCity Council
Start
Departments Enter
Requisition
End User ERP
Fiscal Officer
Approves
Fiscal Officer ERP
Tier 1
Tier 2 Get 3 Quotes
End User ERP
Department Head
Approval
Department
Head ERP
Fiscal Officer
Approves
Fiscal Officer ERP
Tier 3, 4 and 5
City Manager
Approval
Role System
CIP?
Budget Approval
Role System
No
No
Yes
Yes
Yes
Yes
Tier 4
No
Yes
POBid/RFPNo
Fiscal Officer
Approves
Fiscal Officer ERP
Tier 5
No
City Council
Approval
Role System
Yes
Considerations:
1. All purchases through the system (all without p-card) will go through requisition
2. Requisitions will be entered at the beginning to encumber funds and track status of pending
purchases. For purchases that will require an RFP, the department will enter requisition prior to
going through RFP process with estimate of amount and without a vendor. This will allow the
purchase to be tracked and budget estimate reserved.
3. The City will have 5 tiers of purchase approval each with thresholds based on purchase dollar
amount.
4. Purchases at the Tier 1 level will automatically be converted to PO without involvement from
purchasing department.
5. Purchase requisitions will need an easy to use format focused on end users. The City expects the
software to have features to limit data entry errors, collect detailed information upfront
(account, commodity code, description, etc.), and do so in an efficient way.
Packet Pg 114
5
Purchase Order
SLO
Purchase Order
To-Be
DepartmentCity ManagerPurchasing
Requisition
Complete
Convert Req to PO
Purch Staff ERP
If Tier 3 or 4
Complete RFP
Process
Purch Staff Out of
System
Complete Contract
Process
Purch/
Attorney
Out of
System
Validate Vendor
Reg Complete
Purch Staff ERP
Purchasing Analyst
Approval
Purch
Analyst ERP
Purchasing Sends
PO to Vendor
Purch
Analyst ERP
City Manager
Approval
City
Manager
Out of
System
Complete Contract
Process
Department
Staff
Out of
System
Complete RFP
Process
Department
Staff
Out of
System
Considerations:
1. Purchase orders will be utilized for all purchases (not including p-card purchases). Purchase
orders will be issued centrally by purchasing and automatically issued for Tier 1 purchases.
2. Purchase orders will require additional approval for Tier 3 and Tier 4 process.
3. The City will have a process for emergency purchases where emergency purchases may make
this process prohibitive.
Packet Pg 115
5
Receiving / Invoice Entry
SLO
Receiving
To-Be
DepartmentAP
Start
Departments
Receive Order
Department
Staff Manual
Start
Invoice Received
AP Manual
Enter in Invoice
AP ERP
Match Against
Reciept
ERP ERP
Match
Workflow Notice to
Department
ERP ERP
Invoice Received
Department
Staff Manual
Send Invoice to
Finance
Department
Staff Manual
Start
Approve Invoice in
ERP
Department
Staff ERP
No
Payment Process
AP ERP
Ok to Pay
OK to Pay
Department Enter
Receipt
Department
Staff ERP
Considerations:
1. The city expects to use both 2-way and 3-way matching for invoice approval. Departments
would be either required to enter receipt in the system or to approve invoices in the system.
2. All invoices would be entered by central finance staff.
3. Capital assets would require receipt in the system and completion of capital asset identification
information.
Packet Pg 116
5
Capital Assets
Asset Acquisition – Equipment
Capital Assets
Acquisition (equipment)
Future
DepartmentFinanceStart New or
replacement?
Track replacement
cost for budgeting
Manager/FO ERP
Replacement
Enter requisition
for asset
Manager/FO ERP
New Requisition Receive asset
Requestor Manual
Matching Create asset record
Requestor ERP
Review and
approve
Manager/FO ERP
Review and
approve
Staff ERP
End
Tag asset
Requestor ERP /
Manual
Considerations:
1. Assets will be recorded at point of acquisition. Departments will enter all necessary
identification information online in the system.
2. Workflow would notify appropriate staff for review/approval.
Asset Acquisition – Projects
Capital Assets
Acquisition (capital project)
Future
DepartmentFinanceStart Track project cost
Manager/FO ERP
Close project
Manager/FO ERP
Project
complete?Yes
Review projects at
year-end for
completion
Staff ERP /
Manual
No
Determine value
Staff ERP
Create / modify
asset
Staff EFP
End
Considerations:
1. Capitalized costs for projects will be recorded throughout the year and capitalized at year end or
upon project completion.
Packet Pg 117
5
Asset Retirement / Disposal
Capital Assets
Disposal/Retirement
Future
DepartmentFinanceStart
Enter asset
disposal/retirement
Manager/FO ERP
Sell asset?
Manage sales
process
Manager/FO Manual
Yes
Approve asset
record change
Staff ERP
Update asset with
sales information
Manager/FO ERP
No EndStart
Generate physical
inventory list
Staff ERP
Conduct physical
inventory
Staff Manual
Missing asset?
Yes
No
Considerations:
1. The City expects that departments will have access to initiate disposal or transfer request within
the system. The process would then be managed by workflow.
Packet Pg 118
5
Accounts Receivable
Billing
Accounts Receivable
Billing
Recommended
DepartmentAccounts Receivable
Start
3rd Party
Invoice
System?
Create invoice and
match customer ID
with amount
FO / Admin 3rd Party Sys
(interface)
System/user
validates invoice
information
FO / Admin 3rd Party
Sys / Manual
Cash
Receipts/
Cashiering
Create invoice and
match customer ID
with amount
Staff ERP
System/user
validates invoice
information
Staff ERP
Send invoice to
customer
Staff Manual
Customer
File
New/updated
customer?
New/updated
customer?
No
Yes
Customer
File
Yes
No
Send invoice to
customer
Staff Manual
Yes
No
Considerations:
1. The billing process would only be utilized for miscellaneous receivables. The City has many
specialized billing applications that would continue to be used.
2. For all specialized billing processes, the City expects to have the ERP system track summary level
receivables. Interfaces will need to be created to allow frequent data to be transferred
communicating outstanding receivables for overall financial reporting.
Packet Pg 119
5
Customer File
Accounts Receivable
Customer File
Recommended
Accounts ReceivableDepartments
Billing New
customer?
Update customer
record
Staff ERP
No
Create customer
record
Staff ERP
Yes
System validates
information,
initiate workflow
Staff ERP
(interface)
Update 3rd party
billing system
Staff ERP
Interface
End
Billing New
customer?
Update customer
record
Staff 3rd Party Sys
No
Create customer
record
Staff 3rd Party Sys
Yes
System validates
information,
initiate workflow
Staff 3rd Party Sys
(interface)
Update ERP
Staff 3rd Party Sys
(interface)
End
Considerations:
1. The City would like to explore possibility of having customer files sync between multiple
systems. At this point, the customer file within the ERP system will be managed jointly between
finance and individual billing departments.
Packet Pg 120
5
Cash Receipts
Accounts Receivable
Cash Receipts / Cashiering
Recommended
Accounts ReceivableDepartmentsFireCustomer
Billing Walk-in?
Brings payment and
invoice
Customer Manual
Yes
Enters invoice and
payment
information
Customer ERP (self-
service)
No
Enters account
information
Staff Manual /
ERP
Collects payment,
validates account
information
Staff ERP
(interface)
Updates account
status
Staff ERP
(interface)
System generates
receipt
Staff ERP /
Manual
Receives receipt
Staff Manual
System validates
account and
payment
information
Customer ERP (self-
service)
System updates
account status
Customer ERP
(interface)
System generates
receipt
Customer ERP (self-
service)
Reconcile payment
information by
tenure type
Staff ERP/Manual
Daily
Prepare deposit
Staff ERP/Manual
Bank
Recon.
Considerations:
1. The ERP system will record all payments recorded in the ERP system and interface (or be
manually updated) to record bank deposit information for payments collected in other systems.
2. When payments are received in various systems against current receivables, the City expects
that any interface would also update summary level receivable in the ERP system.
Packet Pg 121
5
Human Resources
New Hire
HR to Benefits
New Hire
Future
DepartmentHuman ResourcesCandidate
Evaluation
Selects candidate
for official offer
Hiring
Manager NeoGov
Initiate personnel
action
Hiring
Manager
NeoGov
(interface)
Review/approve
personnel action
(workflow)
HR Director ERP
(interface)
Generate offer
letter and benefit
summary
HR ERP
Accept?
Return signed offer
letter
Candidate Manual
Yes
No
Initiate new hire
checklist
HR ERP
Complete items on
checklist
Hiring Dept/
Other Depts Manual/ERP
Initiate employee
self-service
HR ERP
Complete forms
and benefits
selection
Candidate ERP
Benefit
Enrollment
Onboarding
Considerations:
1. The system will interface with NeoGov to transfer initial information on new employee. The City
will then rely on self-service within the HR system to allow the employee to enter additional
information, enroll in benefits, and complete tasks.
2. The City expects that the ERP system will generate the offer letter using information in the
system and from interface with NeoGov.
3. HR would review information submitted and be available, if necessary, to assist employees.
4. The City expects that ERP system will be able to manage checklist of tasks that multiple
departments need to complete when a new employee is hired (turn on IT access, enroll in
benefits, receive training/orientation, etc.).
Packet Pg 122
5
Employee Personal Information Change
HR to Benefits
Information Change
Future
EmployeeHuman Resources
Start
Update
information /
changes in self-
service
Employee ERP
Requires
documentation
or approval?
Approve?
Yes
No
Notify employee
HR ERP
No
Workflow approval
HR ERP
Benefits?Update benefits
HR ERP
(interface)
Receive system
notification of
update
Employee ERP
Yes
No End
Considerations:
1. The system expects that most changes will be completed through self-service.
Packet Pg 123
5
Personnel Action
HR to Benefits
Personnel Action (existing employee)
Future
DepartmentHuman ResourcesPayrollBenefits
Start
Enter personnel
action
Supervisor /
FO ERP
Attach
documentation
Supervisor /
FO ERP
Review / approve
Department
Manager ERP
Start
Enter personnel
action
HR ERP
Attach
documentation
HR ERP
Workflow approval
HR ERP
Workflow approval
Benefits ERP
Workflow approval
Payroll ERP
Receive notification
of personnel action
complete
Dept Mgr /
Employee ERP
Considerations:
1. Personnel actions will be done in the system using workflow.
2. Workflow path can vary based on personnel action type
3. Workflow will include approvals at both department level an among the HR/finance department
depending on the type of change.
4. For changes that require documentation, the City expects the ERP system will allow
documentation to be uploaded.
Packet Pg 124
5
Personnel Evaluation
HR to Benefits
Personnel Evaluations
Future
Human ResourcesDepartment
New
Hire
Receive system
notification of
evaluation due
date
Supervisor/
Employee ERP
Review and
approve (workflow)
HR ERP
Review and
approve (workflow)
Dept.
Manager ERP
Review and sign
(workflow)
Employee ERP
Update personnel
record and initiate
personnel action
HR ERP
System generates
default evaluation
dates based on
business rules
HR ERP
Complete
evaluation
Supervisor Manual/ERP
Complete pre-
evaluation form
Employee Manual/ERP
Meets
expectations?
Review and provide
input
HR ERP
No
Yes
Personnel
Action
Considerations:
1. Performance evaluations will be done in the system.
2. Different departments/job classifications will have different evaluation templates
3. The City’s management staff create goals and are evaluated against goals. The City expects that
the personnel action system will allow employees to track goals which will be used as basis for
evaluation.
4. Workflow process allows employee to review and approve of personnel evaluation.
Packet Pg 125
5
Time Entry / Payroll
Time Entry to Payroll
Time Entry
Future
DepartmentPayroll
Start
Type of entry?
Exception Entry
Confirm hours at end
of pay period, enter
exceptions for leave
or projects hours
Employee ERP
Enter time worked by
day (or in/out); track
hours, leave, project
hours
Employee ERP
Submit timesheet
for approval
Employee ERP
Review timesheet
(workflow)
Supervisor ERP
Approve?
Positive Entry
No
Approve timesheet
Supervisor ERP
System calculates
pay based on
business rules
Payroll ERP
Yes
Payroll
Timesheet applies
business rules
Employee ERP
Considerations:
1. The City has different departments that provide very different services. As a result, it expects
that employees will enter time using a variety of methods.
2. Recorded time will need to be specific for project or position (for those employees working on
multiple projects or in multiple positions)
3. The city will use time clocks or other time entry devices.
4. The city expects time information to be entered on mobile device.
Packet Pg 126
5
Risk Management
Injury / Incident
Risk Management
Injury / Incident
Future
Employee/DepartmentRisk ManagementTPA
Workflow approval
to notify
appropriate staff
System ERP
Receive Incident
Information
TPA Interface
Start
Identify incident
and log into system
Employee Manual/ERP
Complete
additional
Information
Employee ERP
Complete
additional
Information
Risk ERP
Interface to TPA
Risk ERP
Update City with
financial
information
TPA Interface
Update Incident
Risk Interface
Manage Issue by
logging additional
information
Risk ERP
Considerations:
1. The system will be used to track events and record information related to injuries and incidents
for reporting to third party administrator and city-wide reporting
2. Interface with City’s TPA will transfer information on new injuries/incidents.
Packet Pg 127
5
General Liability
Risk Management
General Liability
Future
City AttorneyDepartmentTPAFunction
Workflow approval
to notify
appropriate staff
System ERP
Receive Incident
Information
TPA Interface
Start Log Claim
Employee Manual/ERP
Complete
additional
Information
Department ERP
Review Claim
Risk ERP
Update City with
financial
information
TPA Interface
Update claim
Risk Interface
Manage Issue by
logging additional
information
Risk ERP
Interface to TPA
Risk ERP
Considerations:
1. General liability claims will be entered into the system and tracked. The City expects to
be able to notify the City’s TPA with information entered into the system. Additionally,
the City expects to be able to add information to claim and report on claims.
Packet Pg 128
5
Attachment_12_Staffing
Schedule 1Estimated Vendor Staffing Indcated Date for Month 1
Month 1 = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30All Phases 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Finance000000000000000000000000000000HR/Payroll 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Budget000000000000000000000000000000Technical000000000000000000000000000000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30Phase Resource Type Resource
Total 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Project Manager 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Finance0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0HR/Payroll 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Budget0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Technical0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Month
Project Summary
MonthResource/Position
1-Vendor StaffingPacket Pg 129
5
Attachment_14_Cost
Attachment 12 (Costs)Vendor:
Cost Categories Total Costs Explanation/Notes (if necessary)Project CostsSoftware Fees (Schedule 2)-$ Professional Services (Schedules 3): -$ Other Fees (Schedule 4)-$ Total Cost During Project Period -$
1-SummaryPacket Pg 130
5